Amogh N P
 In loving memory of Amogh N P — Architect · Designer · Visionary 
Architecture students at a studio jury with a white massing model of a mid-scale mixed-use complex — where programming becomes form.
Unit IArchitectural Design V

Mid-Scale Complexes & Programming

When the problem is no longer one room — and why you define it before you design.

≈ 40 min + studio task

Design V steps up in scale — from a single building (the work of Architectural Design IV) to a small complex of several uses. At this scale the most important work happens before any line is drawn: architectural programming, which Peña's Problem Seeking calls the act of defining the problem so design can solve it.

Learning objectives

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

1
CO1 · Understand

Explain why a mid-scale complex is a different design problem from a single building.

2
CO3 · Understand

Describe architectural programming as problem definition (Peña's five steps and four considerations).

3
CO3 · Apply

Outline the stage-wise design process — programming, schematic, development, documentation.

4
CO1 · Apply

Turn a brief into a zoned, sized programme for a small complex.

Peña's problem seeking

Programming — define the problem

Programming is problem definition; design is problem solving — two distinct, sequential acts.[1] Five steps (goals, facts, concepts, needs, problem) are weighed across four considerations (function, form, economy, time).

Programming: define the problem in five steps GoalsFactsConceptsNeedsProblem = 1st step of design …each weighed across four considerations: FunctionFormEconomyTime Programming = problem DEFINITION. Design = problem SOLVING. Define before you solve.
DiagramPeña's five programming steps — goals, facts, concepts, needs and the problem statement — across the four considerations of function, form, economy and time

Define before you solve

Peña's Problem Seeking makes one central distinction: PROGRAMMING is problem definition; DESIGN is problem solving — two distinct, sequential acts. 'Stating the problem is the last step of programming and the first step of design.' FLAG THE MYTH: do not design while programming. At mid scale, where a wrong brief wastes a whole complex, defining the problem fully first is what separates a resolved scheme from a confused one.[1]

Two acts, one hinge Programming analytic · problem DEFINITION goals · facts · concepts · needs Design creative · problem SOLVING schematic · development · documentation PROBLEM statement the last step of one is the first step of the other
DiagramTwo distinct acts — programming as analytic problem definition and design as creative problem solving — joined by the problem statement
Organising many uses

The complex as a problem

A complex has several uses, so the design problem becomes their organisation — zoned by publicness, tested by adjacency, written into a brief before form is fixed.[3, 1]

Zone by publicness — public low, private high Private — residences (quiet, views) Semi-public — offices Public — retail, lobby (engages the street) more private →
DiagramA section zoning a complex by publicness — public uses low, semi-public in the middle, private quiet residences at the top

Many uses, one organism

A single building has one occupancy and one circulation idea; a complex has several. The design problem becomes the ORGANISATION of parts — which uses go where, how they connect and separate, where the cores and services sit, and how the whole reads as one building on its site. Spatial organisation, not room design, is the skill the studio builds.[3]

The programming facts

At a glance

AspectOneThe other
The actProgramming: problem definition (analytic)Design: problem solving (creative)
Scale of problemSingle building: one occupancy, one circulation ideaComplex: many uses — the problem is their organisation
First moveZone the programme by publicness and noiseTest adjacencies before fixing form
DeliverableProgramming → the brief (goals, needs, problem)Design → schematic → development → documentation
Peña's fourFunction & formEconomy & time (incl. growth/change)
Vocabulary

Key terms

Programming

Architectural problem definition — the analytic front-end that precedes design (Peña).

Problem statement

The fifth and final step of programming — the distilled essential conditions that the design must answer.

The four considerations

Function, form, economy and time — weighed across every step of programming.

Brief / programme

The written statement of goals, facts, quantified needs and the problem — programming's deliverable.

Schematic design

The first design stage — concept, massing and zoning options generated from the programme.

Spatial organisation

The arrangement and connection of a complex's many parts — the core skill at mid scale.

Adjacency diagram

A bubble diagram testing which spaces must be near or far before plan form is fixed.

Mixed-use

A complex combining several occupancies (retail, office, residential, hotel) in one project.

Apply it

Studio task

For your studio project, write a one-page programme: the goals, the key facts (site, budget, codes), a list of spaces with areas, and a single problem statement. Then zone the spaces by publicness in a quick section.

Check your understanding

Self-assessment

1. In Peña's Problem Seeking, programming is —

2. Which is NOT one of Peña's four considerations?

3. The first organising move for a mixed-use complex is to —

In a nutshell

Recap

At mid scale the design problem is the organisation of many uses, not the design of one room.
Programming (Peña) defines the problem before design solves it — five steps (goals, facts, concepts, needs, problem) and four considerations (function, form, economy, time).
Zone the programme by publicness and noise, test adjacencies, and write the brief before fixing form.
Then run the project stage-wise: programming → schematic design → development → documentation.
The evidence

References & further reading

  1. [1]William M. Peña & Steven A. Parshall, Problem Seeking: An Architectural Programming Primer (5th ed.). Hoboken: Wiley, 2012.
  2. [2]Edith Cherry, Programming for Design: From Theory to Practice. Wiley, 1999.
  3. [3]Francis D.K. Ching, Architecture: Form, Space, and Order (4th ed.). Wiley, 2015.

Further reading

  • Peña & Parshall, Problem Seeking. Wiley.
  • Edith Cherry, Programming for Design. Wiley.
  • Ching, Architecture: Form, Space, and Order. Wiley.

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.