The Intersection of Interior Architecture and Product Design
I get a lot of questions, or confused looks when I tell people architecture and product design are very similar. Today I thought I’d use this space to show the truth behind this statement! Inspired by another article which speaks to the soft skill similarities, my focus is on the hard skills. I want employers to see the design processes side by side and show how much these two disciplines truly have in common.
As you already know, the design process is based around a user’s experience. Whether this experience involves physical or digital interactions, the goals are one in the same, and the process in achieving those goals are actually alike too.
Let’s take a closer look at two unrelated projects from each discipline to better understand the relationship between UX and Architecture.
Before I even introduce the projects, take a glance at the processes. Research, ideation, prototyping..all critical elements when designing whether we’re talking floor plans or wireframes! There are phases in interior architecture much like in product design, and for good reason. It’s important to use data, explore concepts and iterate on ideas in order to solve problems.
Okay, here are two projects I led from each field.
Interior Architecture Example:
Carta: Design & Construction of new office headquarters in San Francisco.
Product Design Example:
Caviar: Robust Waitlist Feature for existing food delivery app.
Clearly at first glance, these projects look nothing alike. I mean one is a sixty thousand square foot building and the other is a feature on a mobile app. But I’m telling you! We got to that final shot in almost the same way.
Let’s Talk Research.
In an architecture project, research is done through market analysis, interviewing clients on needs, desires, and goals. Typically we have what are called visioning sessions, where we can complete a series of exercises that help us get to know the users or stakeholders and what would make sense for their space. We’ll also walk the existing space to observe how they use it!
Another part of research is creating a general site plan to study the area inside, and outside of the building. It’s important to observe whether or not any activities would impact the people using the space, e.g. noise, light, security, etc.
For product design we also do market analysis, surveys and interview users to get a better understanding of the needs or pain points. Perhaps we’ll do onsite visits to observe user behavior when using a software. Similar to a site map in architecture, we also create content maps for products to get a first look at how everything will work together.
Define vs. Programming
The “Define” phase in architecture is known as programming. Sometimes a client will already have a developed program or guidelines for us to work from. Other times we need to create one, based on results we get from interviewing users, market research, or other information we receive from the client. The program is our guideline as we layout the floor plans, as it lists various space types and quantities we have to include on each floor.
In product design, when we start to define our project we are creating a consolidation of our research in order to refer back to it as we design. Really, this is a program of sorts. Whether its a storyboard, to remind us of the user journey or sequence of events, or a user persona to solidify needs, goals, and restrictions.
Ideate vs. Test Fit
Commonly in Interior Architecture, we begin our designs with a “test fit”. By using the program, we simply see if everything required will fit into the existing floor plan or “core and shell”. This is done especially in workplace design as the projects are often existing buildings in which the client is leasing. If we are not designing the entire building from scratch, we have to work within the limitations of the building shape and orientation of its core (Restrooms, Mechanical rooms, etc. which are costly to relocate). The test fit is high level, often blocking out areas and testing adjacencies.
Ideation in product design is as you may guess by now, quite similar! User flows, wireframe sketches, or lo fi frames are all “test fits”. We are testing possible routes a user might take, and observing the relationships between screens or even elements within each screen. This is not yet about color or other UI, but the initial layout of the technicalities. More high level, it’s largely to scope the solution and determine how much design work is needed based on the user and use cases.
Design.
Schematic Design in architecture is where we begin to develop the look and feel. In part, this is further developing the plans beyond the test fit and starting to add more detail (rooms, doors, ceilings). This is also where we start presenting aesthetic concepts to the client. Inspiration imagery becomes a color palette & materials, creating a cohesive package (similar to a UI kit).
The design phase in product design is where we too further develop wireframes and begin adding some of the UI elements (Still iterating and testing along the way). Even if this is an existing app like Caviar, when building a new feature we still have to compare the existing UI standards and make sure they align. Often times large companies like Amazon or Salesforce have design standards in architecture too, and it can be a challenge to integrate them into new spaces. In both disciplines, “design” is huge phase that could be a whole article in itself, but for this purpose hopefully you get the gist!
Prototype, Test & Iterate.
The equivalent phase for prototyping in architecture is called Design Development. This is when we have fully developed plans, and customized design features throughout the project. On the technical side, we have begun creating a drawing set with construction details, elevations, etc. for the contractor to price (also serves as a draft for the final set which will need permit approval from the city). On the client side, we present realistic 3D renderings, and virtual walkthroughs to show how the space will look, feel, and function.
Similarly, in product design we test hi-fi prototype’s with users in order to get the clearest picture of how the product will run. It also identifies pain points with functionality and overall user experience. Additionally, this often serves as an internal way to show stakeholders, in order to get necessary approvals.
Development Ready vs. Construction Documents
The biggest deliverable for an architecture project is the permit set, or construction documents. Essentially this is the instruction manual of the project! There are no pretty pictures, but rather a full detailed compilation of every surface of the project. It includes finish specifications, floor plans (partition, ceiling, finish, power & signal, etc.), annotated wall elevations, details (ceilings, partitions, millwork, etc.), axonometric views and more. This set is signed and stamped by a registered architect, and approved by the city to be built. It must include every possible instruction necessary for the contractor and engineers to build it accurately, safely, and aesthetically as intended by the designer. The designer is still heavily involved in the project beyond this point, but this starts the transition of weight from design to construction.
In product design, this deliverable can depend on the practices or software used by the company. But generally speaking, it is the final designs that have been approved for development. Whether it’s a Figma or Zeplin file showing code, or a full UX write up with specifications, it’s the same as above; an instruction manual for a builder! As with architecture, there will still be team check in’s and adjustments as the process continues but it begins V1, or the transition from design to product development.
Development vs. Construction Administration
During construction, architects stay close to the process making sure everything is built as instructed. The contractor must track everything they do and ask the architect for any information needed if they are unsure of something along the way, or a surprise is uncovered on site. At project completion, the architect and contractor perform a “punch walk” to identify final touch ups needed before the user moves into the space.
In product design, a huge part of your role is working closely with engineers as they build out the product. There are team meetings, “desk checks” and design scope modifications that happen throughout this phase in which the designer will need to participate through to launch.
Regardless of the project success, in both disciplines there are always lessons learned for next time! After a product launch or construction is complete, the users will report back on issues that didn’t go smoothly or caused confusion. And so continues the ever changing cycle of iteration and improvement.
