post icon

Architecture and Design: Programming 101

Author:

Architecture is a broad field that encompasses a wide variety of professionals. For those hiring a design professional, it can quickly feel overwhelming when presented with a list of available services. Having a basic understanding of what architects do and what services they can offer will help you engage in a meaningful dialogue and ask the right questions. Over the next few months, we’ll dive deeper into what architects do (and don’t do) and what each step of the design process entails so you’ll feel comfortable using the terminology and will be better prepared to discuss your next design project with a professional.

For architecture projects, the steps of the process can be broken down in several ways. For the sake of simplicity, we’ll take a look at the broad steps that lead from project inception to completion. The main phases of a project include:

  • Programming
  • Site Design
  • Schematic Design
  • Design Development
  • Construction Documents
  • Materials & Specifications
  • Bidding
  • Construction Administration

This series aims to simplify a process that is highly complicated, with each step integral to the others. Keeping that in mind, the order of the process may fluctuate or repeat depending on the project or specific needs of the client. A design professional with experience in architecture projects can help you understand which steps in the process are likely to play a larger role in your specific project. It is also good to note that code review studies, zoning/regulation studies and budgeting/feasibility studies are integral to the entire process and will occur throughout the beginning of the project timeline.

Programming – The Basics

The first step in design is referred to as programming. Programming entails discovering the client’s needs and goals and getting them down on paper in either written or graphic format (or both). For example, a client may need a new home designed to accommodate their growing family. An architect or designer would discuss the needs the client has in terms of number of rooms and size of rooms from a quantitative perspective. They would also ask questions from a more qualitative perspective to understand how the client envisions these rooms. The qualitative discussion might center on issues of natural light, views to the outdoors, noise concerns, or proximity to other rooms in the house. The balance of quantitative and qualitative components allows the architect or designer to understand the client’s needs in terms of hard numbers (square feet) and emotional expectations for how the space will feel and function

During programming, it is important to have an open, honest conversation with your architect or designer about budget, space requirements and overall expectations. Often, clients will discover that some of their desires or needs are in direct conflict with their budget or other goals. Talking about the types of materials you want to see in the design, the size of the house, and the way your current home meets or fails to meet needs will give insight as to how your project will come together.

Programming – Digging Deeper

On the surface it seems easy to come up with a list of rooms and general sizes required for each. However, effective programming will also seek the reasons behind each requirement so that if two requirements are in conflict with one another, the architect or designer can make the best decision to achieve the intended outcome. There is often a need to ‘translate’ perceived needs into actual needs. As an example, a client requesting a new house may say they need a walk-in pantry. They may also say that they need a 20′x20′ bedroom. During the programming process, it is important to ask ‘why?’ for each need or goal. While the client may request a walk-in pantry, what they actually need is a pantry that is easily accessible. An easily accessible pantry does not always translate into a separate room with a door. In fact, a designer who understands the clients true needs will be able to come up with a better design than if they are limited by perceived needs that are narrowly defined. Likewise, a 20′x20′ bedroom may be a ‘need’ simply because the client wants to accommodate a sizable collection of furniture in the room. Talking about how the furniture is used, when it is accessed and the preferences for where it is located can free the designer to reduce the size of the bedroom and accommodate the furniture in other places. These freedoms will provide the designer with more opportunity to create a space that is not only beautiful, but will meet the true needs of the client. It is often helpful to walk through the client’s existing space (whether home, office or another building) and observe how the space is actually used – making note of successes and opportunities for improvement. An exercise known as “a day in the life” is often helpful, as it goes through the paces of a typical day to discover the underlying needs and goals of the client. It is important to be honest about whether needs are true requirements or if they are preferences. The difference can determine whether a designer is allowed the freedom to create an efficient and effective design solution.

A large part of programming investigates the proximity of spaces while considering whether their proximity will meet the goals laid out for each space. For example, a client may request that their kitchen be close to the dining room and that both spaces have views to the outdoors. For the architect or designer, this means the spaces could be immediately adjacent and share a single, common view to the outside. Alternatively, these same spaces could be visually separated from one another and each have their own view to the outdoors. As with any other goal or need laid out during programming, it is important to understand the ‘why’ behind each decision. Is it important the kitchen has windows so that herbs are easily accessed, or are the views mainly for the enjoyment of the chef? A single question such as this will help determine where the windows are placed. For proximity studies, it is important to recognize the difference between adjacency and absolute positioning. It is wise to approach the design in terms of adjacency, which stipulates relationship of spaces with terms such as “near”, or “close to”. Absolute positioning severely limits the design solutions with terms of “must be to the right” or “in the center”. While some elements can be designated in absolutes, it is rare to create a successful design with more than a few absolute requirements. Absolute space positioning can result in budget concerns, inefficient spaces and failure to meet multiple goals. This is why it is important to think critically and analytically about why spaces will be located next to one another.

Finally, effective programming will not only examine the current needs of the client, but will seek to anticipate and prepare for future needs. A talented professional will recognize areas that may pose a problem for the execution of goals and will recommend solutions to accommodate future needs. This facet of programming can often be difficult, as it is the most abstract and unknown. Balancing unknowns with set budgets or property locations can be a true challenge. Often, a solution to future needs can be achieved through flexible spaces (spaces that serve more than a single purpose) and allowing room on the site for expansion.

Bubble Diagram

Bubble Diagram

A tool that architects and designers use for representing programs visually is a bubble diagram. A bubble diagram represents spaces with simple circles or squares that are sized relative to one another. Lines can connect the spaces to represent corridors or hallways, and the shapes can be grouped together quickly in multiple arrangements to see which layouts achieve the needs and goals of the client. In addition to bubble diagrams, lists of spaces with quantitative and qualitative notes will be provided as a basis for the design solution and as a metric for success.

Bubble Diagram

Bubble Diagram

Next month we will take a look at Site Design and how it relates to the design process. Always remember to ask lots of questions when working with a design professional. No question is out of bounds when your goal is success.

Brinn Miracle is an architectural intern, journalist and residential designer. She writes about architecture and design topics at her blog,www.architangent.com/blog

11 Comments

Leave a comment
  1. Moneca
    August 14, 2012 at 10:58 am #

    thanks for a great article. Can you refer me to some examples of good Design Program Questionnaires. I am trying to develop one and would like to see some well done examples.

    • Brinn Miracle
      August 15, 2012 at 1:33 pm #

      Hi Moneca,

      I actually don’t use a standard questionnaire, as I find my programming happens during conversation that naturally leads through a client’s needs. I tend to take notes, then send a summary that defines space sizes and characteristics for approval. Creating a template or questionnaire is a good idea for a starting point with all clients, but be sure to leave room for deviation from the template for clients who may have unique requirements.

  2. ali
    September 25, 2012 at 5:18 am #

    im a student from iran and im studingt civil engineering.
    i need some help in this way, is there any body who can help me?

Trackbacks/Pingbacks

  1. Architecture and Design: Site Planning 101 | Archability - July 18, 2012

    [...] Architecture and Design: Programming 101 June 20, 2012 [...]

  2. Architecture and Design: Schematic Design 101 | Archability - August 21, 2012

    [...] Architecture and Design: Programming 101 June 20, 2012 [...]

  3. Architecture and Design: Design Development 101 | Archability - September 19, 2012

    [...] Architecture and Design: Programming 101 June 20, 2012 [...]

  4. Architecture and Design: Construction Documents 101 | Archability - October 26, 2012

    [...] Architecture and Design: Programming 101 June 20, 2012 [...]

  5. Architecture and Design: Materials and Specifications 101 | Archability - November 27, 2012

    [...] Architecture and Design: Programming 101 June 20, 2012 [...]

  6. Architecture and Design: Bidding 101 | Archability - December 20, 2012

    [...] Architecture and Design: Programming 101 June 20, 2012 [...]

  7. Architecture and Design: Construction Administration 101 | Archability - January 25, 2013

    [...] Architecture and Design: Programming 101 June 20, 2012 [...]

Leave a Reply

You must be logged in to post a comment.