Amogh N P
✦ In loving memory of Amogh N P — Architect · Designer · Visionary ✦
Architecture students working through bubble diagrams and adjacency charts on a studio wall — programming a brief before design.
Unit IIArchitectural Design - IV

Architectural Programming

Problem seeking before problem solving — the data that shapes the design.

≈ 40 min + studio task

The best designs are won before the first line is drawn — in the programming. Architectural programming is the disciplined gathering and analysis of information, the “problem seeking” that precedes “problem solving”. Learn Peña's five-step framework and its four considerations, and the tools that turn a brief into a plan: data and case studies, the adjacency matrix, the bubble diagram and the space programme that fixes how big the building must be.

Learning objectives

By the end of this lesson, you will be able to — mapped to the course outcomes for Design of Structures I:

1
CO3 · Understand

Explain architectural programming as problem seeking before problem solving.

2
CO3 · Apply

Apply Peña's five steps and the four considerations to a brief.

3
CO3 · Apply

Use the adjacency matrix and bubble diagram to turn a brief into a plan.

4
CO6 · Apply

Build a space programme / area statement from a brief and case studies.

Peña's framework

Problem seeking before problem solving

Programming runs five steps — goals, facts, concepts, needs, problem statement — under four considerations: function, form, economy and time. The problem statement is the hinge: programming's last step and design's first.[1]

Problem seeking before problem solving (Peña) 1 Goals 2 Facts 3 Concepts 4 Needs 5 State theproblem Design seek the problem → solve it Four considerations: Function · Form · Economy · Time
DiagramPeña's five-step problem-seeking flow into design, under the four considerations of function, form, economy and time

Seeking before solving

Architectural programming is the systematic gathering and analysis of information BEFORE design — analysis precedes synthesis. It produces the problem statement, which is the last step of programming and the first step of design: the hinge between problem seeking and problem solving.[1]

Matrix, bubbles, programme

The tools of programming

Case studies supply the norms; the adjacency matrix records which space must be near which; the bubble diagram visualises it; and the space programme quantifies how big — input to design, not the design itself.[2, 3]

The adjacency matrix — the data behind the bubbles EntryHallOfficeStoreToilet ● must be adjacent ○ keep apart Cross-tab every pair of spaces; record required proximity. The matrix is the data; the bubble diagram is its picture.
DiagramAn adjacency matrix cross-tabulating spaces, marking which must be near which
The bubble diagram — relations, not geometry entry/hallofficepublicstoretoiletsstaff Circles sized by area, lines for needed connections — built from the adjacency matrix, never a scaled plan.
DiagramA bubble diagram of spaces as circles joined by connection lines — a relational abstraction, not a plan

Gathering the facts

Programming gathers facts: user needs, site analysis, codes, and — crucially — case studies of comparable buildings and literature studies of typological norms (from Time-Saver, Neufert). These supply the standards that seed the space programme.[2, 3]

The contrasts

At a glance

AspectOneThe other
Two halvesProgramming: problem seeking (analysis)Design: problem solving (synthesis)
Data vs pictureAdjacency matrix: the proximity dataBubble diagram: the visual built from it
Two stagesSchematic: concept, broad organisationDesign development: dimensions, materials, services
Output vs formSpace programme: what and how bigThe plan: what form (designer's job)
Pena's qualitative vs quantitativeGoals, concepts, problem: qualitativeFacts, needs: quantitative
Vocabulary

Key terms

Architectural programming

Systematic gathering and analysis of information before design — 'problem seeking'.

Problem statement

Programming's last step and design's first — the hinge between seeking and solving.

The five steps

Goals → facts → concepts → needs → problem statement (Peña).

Four considerations

Function, Form, Economy, Time — the lenses applied at every step.

Brief

The client's statement of requirements; programming tests and expands it.

Adjacency matrix

A grid recording required proximity between every pair of spaces — the data.

Bubble diagram

Circles-and-lines sketch of spaces and connections — a relational abstraction, not a plan.

Space programme / area statement

The quantified list of spaces with areas that drives the building's size.

Apply it

Studio task

Program a small café: list its spaces, build an adjacency matrix (which must be near which, which must be apart), draw the bubble diagram from it, and write a one-page space programme with approximate areas. State the design problem in a single sentence at the end.

Check your understanding

Self-assessment

1. The last step of Peña's Problem Seeking is —

2. Peña's four considerations are —

3. A bubble diagram is best described as —

In a nutshell

Recap

Programming is problem seeking — gathering and analysing information before design; its problem statement launches design.
Peña's five steps (goals, facts, concepts, needs, problem) run under four considerations: function, form, economy, time.
Case studies and the adjacency matrix supply the data; the bubble diagram visualises it; neither is a plan.
The space programme says what and how big — input to design, not the design itself.
The evidence

References & further reading

  1. [1]William M. Peña & Steven A. Parshall, Problem Seeking: An Architectural Programming Primer (5th ed.). John Wiley & Sons, 2012.
  2. [2]Edward T. White, Introduction to Architectural Programming. Architectural Media, 1986. https://archive.org/details/introductiontoar00whit
  3. [3]Joseph De Chiara & Michael J. Crosbie, Time-Saver Standards for Building Types. McGraw-Hill, 2001.
  4. [4]Sam F. Miller, Design Process: A Primer for Architectural and Interior Design. Van Nostrand Reinhold, 1995.

Further reading

  • William Peña & Steven Parshall, Problem Seeking — the programming classic.
  • Edward T. White, Introduction to Architectural Programming.
  • Joseph De Chiara & Michael Crosbie, Time-Saver Standards for Building Types.

Sources gathered and fact-checked June 2026. Published values vary by source, sample and method — treat as indicative and confirm against the cited standard before structural use.