Applying Architecture to Product Design: Program
Welcome to the 2nd post in my mini series about applying architecture principles to product design. As a Product Designer at Percolate with a background in architecture, I’ve seen many parallels between the two fields.
In the first post, we discussed the importance of circulation systems to both architecture and product design and learned to think about circulation early and often in the design process. The easier it is to navigate your product, the more likely it will be a success.
In this post, we’re going to discuss how architects get started with their design process and see how the initial steps are applied to product design at Percolate.
Design is Problem Solving
In architecture school, you’re taught that designing is problem solving. Think about architecture in your daily life: your house is designed to be a solution to the problem of needing shelter. Your office is a solution to the problem of needing a place to work. Every design is a solution to a problem.
Architects learn the best way to begin solving a design problem is to define the problem at hand. Within the architecture industry, this process of defining the design problem is known as “Programming.” In the book Problem Seeking: An Architectural Programming Primer, architects William M. Pena and Steven A. Parshall describe the role of programming in architecture:
Good buildings don’t just happen. They are planned to look good and perform well. They come about when good architects and good clients join in thoughtful, cooperative effort. Programming the requirements of a proposed building is the architect’s first task, and often the most important…You can’t solve a problem unless you know what it is….main idea behind programming? It’s the search for sufficient information to clarify, to understand and to state the problem.
The process of defining a design problem is similar for architects and product designers. In both industries, the design problem begins as a simple set of goals and requirements. The designer then researches the design problem and records the findings.
The research is then analyzed and organized, and presented in a written document. Architects refer to this document as the “Program” and Product teams at Percolate refer to this as the “Scope.” In both cases, this document aims to reflect a detailed definition of the design problem and serves as a scope of work for the project.
Now that we know a bit more about the idea of programming, let’s learn more about the research process of architects and product designers that helps them define the design problem.
Researching the Building Type
Architects begin research with the building type such as residential or commercial. The Client delivers the type, and the Architect studies the type to recognize it’s patterns and jargon. Imagine if Percolate were designing a new office, the Architect might study commercial design in NYC, visiting other startup offices such as Facebook or Google to understand the spaces, layouts and ambiance. They may also learn more about startup culture to understand the client’s jargon. Terms such as “product” or “client solutions” may not be as obvious at first and will be important for the development of the building.
Similarly, Product Designers at Percolate begin projects by recognizing and studying the project type. When developing the Monitoring dashboard, an aggregated view of Twitter and Facebook activity, the design team studied Twitter and Facebook to understand the native platforms. Additionally, we looked at other monitoring aggregators such as Tweetdeck, Tweetbot, and Hootsuite to become well versed on some of the design patterns for this type of experience.
Researching the Site
Architects also research the project site to record and analyze existing conditions. Some of the key site factors an Architect might review includes; climate, topography, zoning, traffic, and landscaping.
Given the new Percolate office example, the Architect might diagram nearby subways to better understand commuting patterns. The Architect might also look at the location of windows and their directionality to understand which areas receive the greatest light at various points throughout the day. During this phase, it’s about noting anything and everything about the site that might influence the new designs.
Percolate Product Designers also spend time thinking about the project’s site. Whereas a building’s site might only vary in a few ways, like the changing of the seasons, a product’s site varies quite a lot.
Product Designers must consider variances between devices such as monitors, laptops, tablets and mobile phones. The designer must also consider differences between operating systems such as Mac vs PC, or iOS vs Android, and browser types such as Firefox, Chrome or Internet Explorer. In short, it’s about understanding building an awareness of the variances, and designing something that works in different situations.
The following is an example of how Percolate Product Designers have designed the same content calendar functionality for 2 different sites: web and mobile. Whereas the core functionality is the same in both sites, the experience is slightly different based on the site’s limitations.
Research Interviews
Architects also conduct interviews to research the opinions and needs of team members related to the project. In Problem Seeking, Pena and Parshall describe the Architect’s interview process as;
Work sessions are used to verify information and to stimulate client decisions…
Goals: What does the client want to achieve, and why?
Facts: What do we know? What is given?
Concepts: How does the client want to achieve the goals?
Needs: How much money and space? What level of quality?
Problem: What are the significant conditions affecting the design of the building? What are the general directions the design should take?
Similarly, Product Designers at Percolate conduct client interviews to examine the needs and interests of users related to the project. Prior to the interview, the Product Designer prepares an interview script which focuses on the tasks our subjects do as part of their job. The interviews are recorded and stored on Dropbox, so other team members can easily access it later. Afterwards, the highlights are documented in a Google Doc and shared with the team. Earlier this year, the Percolate Design Director, Dom Goodrum, wrote an excellent post about the interview process.
Researching Functional Affinities
Architects also research key relationships between spaces. In Problem Seeking, Pena and Parshall note:
…correct interrelation of spaces promotes efficiencies and effectiveness of people and their activities. This concept of functional affinities is the most common programmatic concept.
Given the new Percolate office example, the Architect might note the Product and Client Solutions teams works closely together, and should be located near one another.
Percolate Product Designers also spend a lot of time thinking about key relationships between functionality in a given project. When thinking about our mobile experience, we set out to build a suite of iOS and Android apps, each for a specific marketing role. Whereas the Community Manager App is focused on streams of audience messages, the Photographer app is focused on uploading images to the brand’s media library. Understanding these relationships helps designers identify and develop the correct design patterns.
Researching Future Growth
Last but not least, Architects also research the the future of a building. When considering a new Percolate office, the Architect might ask Noah and James about the company’s hiring plans. There’s a big difference between a company planning to grow 2x and 10x in the next few years, and the design for the office, should fit the growth plan accordingly.
Product Designers at Percolate also consider future product growth with each project. On one hand, product growth at Percolate means constantly building towards our company’s greater mission of becoming the System of Record for Marketing: the operational layer that sits at the center of the marketing organization, coordinating communication that happens between companies, employees, suppliers, and platforms. On the other hand, product growth involves considering client feedback and requests. It’s an exciting roadmap, with lots to consider at every step along the design process.
Lessons Learned
If you take away anything from this post, I hope it’s the idea that designing is problem solving. Both Architecture and Product Designers at Percolate follow a design process, where each step grows upon the next. The first step is about defining the problem at hand. It’s about working with a diverse team and considering things such as project type, site, functional relationships, and future growth.
As noted in the chart below, this ‘programming’ phase of a design project is the best time to ask questions and make decisions because the cost of a change is at it’s lowest and the opportunity for influence is at it’s highest.
For example, Architects know it’s much easier to add a room to a “Program” than it is when the project is knee deep in design or construction. Similarly, Product teams at Percolate know it’s much easier to change requirements in a “Scope”, than it is to change in Photoshop or in development.
Once the design problem is clearly defined and documented, Architects and Product Designers can then confidently move onto the next step in the design process.
Thanks for reading! Look for more posts in this series coming soon.
You can follow me on Twitter at @lissalauren.
Looking for a design job in NYC? Percolate Design is hiring! Say hello.
A version of this article originally appeared on the Percolate Blog.
