Before information architecture, there was… Architecture
As an architect turned product designer, I believe many of the skills we learn in one field of design can translate into different contexts.
Before Information Architecture, there was…well, Architecture.
After all, IA, despite being such a prominent part of UX, was officially coined in 1976 by Richard Saul Wurman, an architect.
In an IBM research paper written in 1964, some 12 years before Wurman, architecture was defined as:
‘the conceptual structure and functional behavior, distinguishing the organization of data flows and controls, logical design, and physical implementation.’
Meanwhile, Google gives us something like this:
‘Architecture — the art or practice of designing and constructing buildings.’
Google is technically correct. Architecture certainly is designing and constructing buildings, as much as UX is designing and constructing apps/websites. We barely scrape the surface with a definition like this. While the end products are different, the design process of architecture is very similar to the way we approach IA and UX design. Not shocking, I know, since design thinking is designed to be universal, but let’s explore.
It’s easy to generalize the field of architecture into its most conspicuous structures. We think of monumental skyscrapers like NYC’s Freedom Tower or Dubai’s Burj Khalifa and imagine people in hardhats looking at intimidating blueprints figuring out how to construct it. Certainly, this is a part of architecture, but it is only just the execution piece of the overall design process. Think of blueprints like lines of code. The lines of code are simply the results of a coordinated execution and are preceded by a thorough design and research process. Architecture is no different (when done right!)
To discuss the similarities between UX and Architecture, let’s break down the initial stage of most architectural projects, the Schematic Design phase that takes place way before blueprints become blueprints.
The Bubble Diagram
Architectural design usually starts with a program. A program is usually the main function(s) of a space. It can be an existing category such as a residential home, or broken down into the specific purpose of a space, such as eating, sleeping, working, etc. Certain buildings include many functions - a school’s program would include a library, cafeteria, kitchen, classrooms, faculty offices, gymnasium, theater, music rooms, locker rooms, etc. When a variety of programs have to be addressed for a project, architects often start organizing these needs with something called a bubble diagram.
A bubble diagram does several things. By definition, a bubble diagram is a freehand diagrammatic drawing for organization and space planning, but if I were to redefine this in terms of UX, I would say a bubble diagram is the convergence of user flow, content inventory, sitemaps, and more.
Circulation (User flow) — How an inhabitant navigates from one space to another. Which chronology of spaces makes the experience most fluid and relevant? This also can determine point or points of entry into a building. Does the inhabitant enter into a lobby that stems off into other programs? An example user could tell us a lot about possible routes and what relationships these programs could have.
Proximity (Sitemapping) — Creating associations between programs and establishing a spatial relationship between two correlated functions. A common association example is placing a cafeteria in near proximity to bathrooms. Refined design choices here will lead to bathrooms being strategically placed away from areas where food is served but still visible to users.
Area Hierarchy (content and visual hierarchy) — Determining which programs will need the most amount of space in relation to each other. In an elementary school, a playground may take up a large portion of their outdoor square footage, whereas in a mall, a playground is a minor feature indoors. As we all know, real estate on a small smartphone screen is pretty limited when it comes to content we want to show above the fold. Infinite scroll is good for those who want the intended behavior to be infinite browsing. When it comes to reducing time spent on a checkout funnel, not so much. How we use screen real estate depends heavily on the intended use of the screen just like how space approximation depends on the space’s intended program.
Determining physical site needs (Wireframing)— In the bubble diagram, many of its functions indicate a shared need for daylight (windows!). This is where the planning starts to go towards more defined ideation and execution details are explored. The final design/form of the building will probably not resemble its bubble diagram, but this will begin to help the designer start to use spatial reasoning to solve these function and program relationships and gradually define a form. Think about when a UX designer starts low fidelity wireframes from an abstract user flow. Some features will share UI elements for related functions — a search bar and filters — while unrelated features could be placed near each other on a homepage simply for its own visibility. Of course, we have easier ways of validating design choices with A/B testing so it’s more often than not we can have a reason for every decision we make.
So if the design processes were so similar, why did I make the jump from architecture to UX? Of the many reasons, the one that I struggled with most was that architecture is often not user-centric.
The program for a given project is often defined by the client and not by the end user’s needs.
In my time as an architect, I worked on several school and university projects, which usually had very specific and prescribed programs that weren’t necessarily from a user need or pain point. One client wanted a new lounge space for their students that looked like the lobby of a high end hotel. While it looked great on the school’s brochures, I wasn’t fully convinced that that was what the students really needed.
Projects without a defined program are not very common within architecture but I find them the most interesting because you can conduct generative research and critically analyze the problems and needs at its roots! These projects usually have clients who are very flexible with their budget — think of quirky residential projects that are custom designed for the client’s specific needs. Most architectural projects will have a defined program and some even come with a defined physical form that you must then try to make compatible with its needs. Research-based ideation and validation is one of many reasons why I transitioned from architecture into UX.
In architecture, it’s also common to see a client not only prescribe a program but also attempt to form their own design solutions and ask the architect to execute their (usually short-sighted) design. I have seen clients request architects to put more bathrooms in an office at a certain location without any consideration to existing plumbing, ventilation, and even program context — do you really want this bathroom far, far from their users and at the end of this dead-end hallway which could potentially be a violation of fire code?
As a product designer, I still run into self-proclaimed-designer clients or stakeholders who prescribe solutions but I believe my past experience as an architect has also helped me navigate these expectations and empathize with their intents to come up with better solutions!
(Architects &Ux’ers, if you have any feedback or thoughts about these similarities, let’s talk!)
https://www.linkedin.com/in/designeryoonshin
