Architects: the original Experience Designers

Chris O’Brien at UXDX Community: Motion Design and Physical to Digital. Video: https://youtu.be/GPqSQxbdfIo

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

How architecture caught my interest

[00:00:00] Thanks so much for inviting me to talk about this. This is something that came out of my weekend thinking, and the more I explored, the more I really got into it, so I thought it'd be something great to share with everybody today. I won't spend too much time on my introduction; I think you did a great job. I'm Chris O'Brien. I'm a design principal at ExxonMobil, and I really just wanted to share why I think that architects are the original experience designers.

[00:00:34] I started my design career working in environmental graphic design. We designed environments for retail stores and car dealers, museums, hospitals, just to name a few. The people I worked with were, as you can see, incredibly creative, but they often had a degree or were in school for architecture, or they had some kind of architectural background. This is where my interest was first piqued in learning more about architecture and what goes along with it.

[00:01:05] It was after that that I started to notice architecture in movies, and how it helped tell the story: how architecture was used to show scale or establish a hierarchy, how it communicated different messages like loneliness or brutality. And then I would read about all the different incredible architecture from around the world, and I was even lucky enough to have an opportunity to visit some of these locations.

[00:01:32] But it was in looking closer at domestic architecture that I started to think about homes and the people that lived in them, and I began thinking about the architects that designed those homes. That's when I had my aha moment: I bet architects were the original user experience designers. You see, they think about the people who will be living in these homes. They talk to them about what they want in a home, and then they go about meeting those needs in different ways. They think about the experience of a space: how a person moves through it, what utility it serves, and how aesthetics play a part in it.

From the hut to the modern home, from the command line to apps

[00:02:08] Then I went down a rabbit hole, and I'm going to take you with me for a little bit, so just be patient. Imagine with me the evolution of home design. In the beginning it was simply a hut. It provided shelter. It was a purely functional dwelling, all about utility. But now you look at the modern home, and it's grown into multiple rooms, each serving its own purpose, sleeping, cooking, bathing, and each designed to meet the needs of the individuals living in it.

[00:02:41] The modern architect works with their clients to identify their needs and the problems that need solving. Then the architect designs the home, defining the spaces and their utility. For example, a living room might be where the family can gather, but is the focal point a fireplace? Is it a media center? Or is it a scenic view of the woods outside? These are all questions that can only be answered by the people using the space. The space is created with the users in mind. The space is to be experienced and interacted with.

[00:03:16] How does this correlate with UX? Quite simply, architecture delivers a physical object while UX delivers a digital product. I know UX can deliver much more than just a digital product, but for the sake of this session I'm going to focus on digital products.

[00:03:33] Now let's look at the evolution of the computer. In the beginning it was simply a command line interface, purely a functional way of interfacing with a computer. Type a command, said command executes. But look at where we are now. The graphical user interface was created, and the rest is history. Modern software and applications have grown into working on multiple devices and interfaces, all serving their own purpose: apps for fitness, for groceries, for banking, for our cars, even for dating, each designed to meet the needs of the individuals using it. Just like architecture, it's all about the people using the software.

Discover: meeting the client and analyzing the site

[00:04:19] After seeing these similarities, I wanted to see if there were any more. Specifically, I wanted to look at the architect's process and compare it to the UX process. As many of you probably already know, the UX process is made up half of research and half of design, and those are further divided into what we like to call the four Ds: discover, define, design and deliver. I find this double diamond to be a helpful way of thinking about the UX process. What I uncovered was that architects share a very similar process. There are similarities worth calling out, and some additional things that I think we can learn from them and add to our own process.

[00:05:04] We start with the discover phase, and they have a very similar discover phase to ours. They begin with meeting the client. The meeting isn't just about gathering a list of things the client wants. It's about hearing what they like and don't like, hearing their thoughts about the environment and the ideas that they have. How do they see the space being used? They often walk the site where they want to build with the client, who gives impressions and ideas. This isn't something that can just be done over the phone.

[00:05:40] In the UX world, we do the same with our clients. We often have two clients: the stakeholders, and then those who will actually be using our products. We have to meet with our stakeholders to hear what they want, but we also meet with the people who will be using our products. We want to hear what they want. What are their goals and their needs? What problems do they need our products to help solve? Our job is to find where the users' needs and the business needs overlap. We have different methods for this. We do stakeholder interviews and stakeholder mapping. There are field observations and ethnographic studies. We build scenarios and empathy maps. These are all methods that we use.

[00:06:27] Then the architect moves into what's called a site analysis. This is the process of evaluating a particular location's physical and social characteristics. During the site analysis they're looking at the location, neighboring buildings and structures. They're looking at access points, restrictions and hazards. There are a lot of things to consider before you start to design, and this is true in the UX world as well. We have just as much to consider with a digital product.

[00:07:01] Where will people be using this product? Where I work, we think about: is it at a gas pump? Is it in a refinery? Is it up on scaffolding? Is it behind a desk? Is it indoor, is it outdoor? What are they using? When are they using it, at night, in the day? Is it a high-stress situation? Are there high distractions? And what technology do they have access to? Is there a smartphone, low bandwidth, desktop only, no Wi-Fi? What limitations are they dealing with, both physical and digital?

Define: parti, the big idea

[00:07:33] After the discovery stage, the architect moves into the define phase, and they start with what they call the big idea. It's called parti. Parti signifies the architect's overall guiding idea for the design. It's fuzzy in the beginning, and it's meant to be. Parti typically has less to do with technical, financial and utilitarian issues, and more to do with view, massing, scale, transparency, opaqueness and other architectural issues. I could spend a good portion of this session just talking about parti. It can be hard to grasp, but I think I have some examples that might give us a better understanding of exactly what parti is.

[00:08:24] An example I find helpful is the concept of making your kitchen match the greenery outside. It can be about the surroundings and how they interact with the building, or how the structure itself interacts with or elevates above its surroundings. It could be like Fallingwater. Fallingwater is a famous house designed by the architect Frank Lloyd Wright in rural southwestern Pennsylvania. It's well integrated into the environment and appears to be built into a small waterfall. Its parti can be described by the well-known Frank Lloyd Wright quote: "No house should ever be on a hill or on anything. It should be of the hill, belonging to it."

[00:09:09] What does parti look like in product design? It can be an integrated product, maybe across multiple technologies. Or maybe it's a baking website that looks so good you want to eat it. It could be a specific illustration style, or maybe it's new wearable technology. Parti is that guiding idea at the beginning of the design, which then needs further fleshing out in what's called the design concept.

The design concept, episteme and techne

[00:09:38] The design concept is where the overall design begins to come more into focus. A strong architectural concept gives the architect a clear direction and framework when making design decisions. It provides a methodology to the thinking process by offering a type of rule book. And the concept is not just the structure, not just the building itself. It's the landscape around it. It's the colors, the styles, fixtures, finishes, the materials that will be used.

[00:10:13] In UX, the design concept is very similar. All the work that's been done up to this point comes together and informs the work going forward. This is where the research from the first diamond starts to merge with the second diamond, and we start to design.

[00:10:36] What I like about this part of the architect's process is that it relies on two of my favorite things: learning and doing. The architect relies on their knowledge to guide the craft of doing and making. It's what the Greeks called episteme and techne. These are the fancy words you get to take away from today's session. Well, these and parti. Architects are always reading and learning about the materials they're working with. They study people, how they interact with each other and how they interact with their environments.

[00:11:13] And so do we. As a designer, I love learning about new mental models and interaction patterns. While I believe designers do not necessarily need to know how to code, and there's a big discussion around this that I won't get into, I do believe they need to know about the code itself. Just as an architect needs to know about the different materials she'll be working with, wood, steel, concrete, so does the UX professional need to know about APIs, Angular, React, and the myriad of other technologies out there. And again, knowing about people and how they interact with products and their surroundings. It's not a coincidence that quite a few UX professionals come from an anthropology background.

Design: sketches, models and prototypes

[00:12:00] Architects also start with sketching. I love this part of the process. As you can see, there are all kinds of levels of fidelity. Sometimes it's just a scribble to get the idea out of the head and onto paper, while others are more precise, communicating more about the final design. The same is true for the UX process, or at least I think it should be. I know in modern times we're able to jump right into Figma or Adobe XD, but there's something to be said for starting with pen and paper.

[00:12:30] I like sketching because I'm a firm believer that the fidelity of your design should match the fidelity of your thought. Don't jump right into a detailed design. Give yourself time to experiment with different styles and different approaches. I think this quote from Eric Reinholdt of 30X40 Design Workshop says it quite well: "Architectural design is iterative. Everything you do builds on your previous work as you develop a deeper understanding of the issues affecting the design. You'll start rough, refine, retool, rework."

[00:13:08] That's when you see them moving into architectural models. This is a new level of detailed design. As someone who has trouble putting together IKEA furniture, I'm amazed at the talent and skill that goes into these models. And it makes perfect sense why they do it. There's no other way to see their design before it's built. Even in 3D software, one struggles to feel what the design is like.

[00:13:37] The same applies to prototypes in UX. They are quick and easy ways to learn about our designs. They provide a way for us to see how people interact with and use what we're designing. They also provide a way for us to see our own work. I can tell you there have been a few occasions when I've been working on a design on the computer that I thought was great, but then when I used it on the phone, I realized it wasn't going to work. And as you can see, prototypes come in all shapes and sizes. Just because it's a digital product doesn't mean it has to be a digital prototype.

Deliver: working with engineers, blueprints and specs

[00:14:13] Then we move into the deliver phase. Hearing about how architects and engineers work together, I was happy to see that it wasn't much different from how designers work with developers. It's a yin and yang relationship. Sure, there are times when we butt heads, but it isn't out of anger, well, not most of the time. It's out of what is best for the product. Just like with architecture, we need to engage with the engineers early and often to ensure that what we're designing is structurally sound.

[00:14:48] While diagrams and floor plans are handy from a design perspective, you need technical drawings to build from. We've all seen that classic blueprint drawing at one point in our lives. And just as there are blueprints to build from, there are design specs to develop from. These cut down on misunderstandings and time wasted going back and forth on how the design should look and work. These days design specs are automated through plugins and different software, but there was a time when this was a manual exercise for every design a designer worked on. It was tedious work, I can tell you that much. But it was better than there being no specs at all and the developer being left guessing the distance between the form fields and the buttons and the labels.

Construction versus architecture

[00:15:40] As we've seen, the design processes of an architect and a UX professional aren't that different, and there's a lot to be learned from digging deeper into the work that each does. To wrap up, I want to share a quote with you from, well, you guessed it, an architect: "You employ stone, wood and concrete, and with these materials you build houses and palaces. That is construction. Ingenuity is at work. But suddenly you touch my heart, you do me good. I am happy and I say, 'This is beautiful.' That is architecture."

[00:16:20] This may sound a little fuzzy or a bit esoteric, but I think it's important to stop and ask ourselves how we think about design. Oftentimes I encounter people who are simply thinking about the construction of the software or app: what technology can I use, what features can I include, how fast can I get this done, and how can I avoid spending more money than I have to? If we just focus on these things, then we will merely be constructing products.

[00:16:50] Let's think about the difference between construction and architecture. It's rather easy to simply construct a building where people go to work every day, sitting in their cubicle maze. Where I work is shown on the right of this slide. This is our campus in Houston, and it's quite different from the standard office building you see on the left. The campus was created with people in mind. It was created for chance encounters and spontaneous interactions. It was designed so that innovation and collaboration can occur. This was the parti, the big idea. To achieve this, there was a process that was followed and a craft involved that elevates it above just construction. It goes beyond just a place where people go to work, more than just an office.

[00:17:44] The same is true for the products we are creating. They are more than just products that we construct to make the company money. They are products that improve the lives of our employees and our customers. Uncovering these needs and designing products that meet them requires a process, a craft and a skill. This is how we elevate our products beyond simply being constructed. We elevate them to being products that solve problems, that improve lives and that bring delight.

[00:18:21] Thank you for listening. I have a couple of references for those of you who are interested in learning more about architecture, and I'm also happy to answer any questions you might have now.

Q&A

[00:18:34] Host: Awesome, thank you very much, Chris. That was a really interesting analogy, or syncing of the two. The thing that came to my mind: I love those TV shows where they've got the architect transforming a house, and what I always take from it is that architects don't care about your budget. They are going to...

[00:18:58] Chris: Yeah, it's true, it's true. I'd love to live in that world, but we all have those constraints.

[00:19:06] Host: Hopefully you're not advocating for that aspect of architecture. As Chris did say, please send in any questions you have, on UXDX or YouTube or LinkedIn, whichever platform you're watching this on, and we'll put those questions through to Chris. I have a question to get started, though. It's something I'm seeing a lot more: as we move away from the big project and the big plan up front, to doing much smaller, quick, iterative releases, is there a time for parti? Or are you constantly just iterating? If we take the analogy of a building, are you just building wall by wall, door by door, window by window, and not really getting the ability to step back and look at it in its environment?

[00:20:02] Chris: Yeah, I recognize the aspirational nature of parti, and it's something I wish I could say I'm doing on a daily basis, or even on a project basis. It is true that as we move into working on all different types of applications, we don't really have that opportunity. But I think, on a small scale, we can still try to apply some of it, even if it wasn't created at the beginning of the project. Is there some small way we can apply it? Whether it's the little features we're trying to add that are already in the backlog, or maybe we're out trying to discover what other needs our customers have and how to add that. Every so often you'll land on a project where you get to have this big idea at the beginning, but I also recognize that on a day-to-day basis it is hard to come by.

[00:21:10] Host: From my experience, I land a lot more on the existing legacy product that we're just moving forward with, rather than the green fields. Is there anything you would recommend for how to take that step back and examine it? Yes, you've got your legacy, you've got what's already there, but how do you move forward?

[00:21:32] Chris: I think it's never too late to come up with a vision. I think a lot of products really do lack a vision statement. What is the UX vision? That's always a good thing for a project team to rally around, and then it helps guide you. That's your north star that you're able to design around. I think it helps from a project standpoint too, because from a business standpoint it might all be financials and customers, how do we get more, very numbers driven. And from a development standpoint, maybe for them it's just getting in there, grinding out the code, getting it to work. So to have this vision that a team can rally around, I think that has such a positive impact on the work we do. It's a fantastic way to really start to add some of this, which often falls to the side.

[00:22:39] Host: Excellent, I fully agree. I love the concept of a vision that people can aim towards. I think it's really empowering and inspiring.

[00:22:46] Chris: Yeah.

[00:22:48] Host: The quote you finished on, where anybody can build a building, but, I'm paraphrasing now, being good architecture is something else. How do you get that skill set? As you're starting your career, what are the things you should be doing to get to that next level?

[00:23:13] Chris: I think back to my own career. In the beginning I was just trying to get things to work, just trying to make sure the functional piece was there. Then you start to better understand who you're designing for, and I think that's a critical piece: really getting out of our own heads and learning more about the people we're designing for. It's from there that you're able to stretch beyond just your own interests, or the interests of others too. And always stay in touch with what's going on out in the industry. To steal from Austin Kleon, we want to steal like an artist, so always look for inspiration to see what other people are doing.

[00:24:13] Because you do reach a point, to use this construction analogy, where you've been building, you've been constructing things, and there's a true craft there. In the quote he says ingenuity is at work, so it's a very positive thing. But then you take it a step further. After you become comfortable with the construction of the piece, comfortable with the technologies you're using or who you're designing for, as you learn more, and I think that goes back to episteme and techne, those two go hand in hand. You can't just have one or the other. They really build off each other, and as you get better at one, you realize you've fallen behind a little on the other, so it's this constant back and forth between the two. But like most things, it's really time, time and how you spend it.

[00:25:21] Host: Excellent. I think we have time for just one last question, and I guess it's future gazing, so we don't know the answer. When you mentioned designers don't need to code, I was thinking about how advanced level one of Copilot and Ghostwriter and those code-writing AIs is. They're pretty powerful now, so level two or three is going to be very powerful. The equivalent I've seen from a design perspective is where you can give a prompt and it will lay out pages for you.

[00:26:00] Chris: Sure.

[00:26:01] Host: If we move away, like you said, from redlining manually to the systems doing it automatically, and they're going to take over a bit more of what we do, how do you think people are going to get to that level if you're taking away the lower-level pieces that they're doing?

[00:26:19] Chris: Yeah, that's the big conversation right now, AI taking over everything. I think it's a tool like everything else, and I think it's going to be to our advantage. At first it might be a little threatening, but I think there's more to it. There are some things that can easily be laid out, and you can have it do that work for you, but it frees you up for the bigger challenges. From my standpoint, a lot of the time we get pulled in by people who think we just do interface work, and our complaint is, well, we haven't had time to do the upfront work. What I'm always saying is that research informs the design. It's one thing to plug "I need a login screen" into AI, but what's the work up front? The login screen is a small piece of what we do, and it's near the end of our process. It's the beginning, the understanding we're trying to do, that I see this freeing us up to do more of.

[00:27:36] Host: Excellent. I agree. AIs can spit out what exists, but they don't know what's new, at this current generation at least.

[00:27:45] Chris: Yes.

[00:27:47] Host: That brings us to time. Thank you very much, Chris, for sharing. I really enjoyed that, and I hope everybody out there did as well.

[00:27:54] Chris: Thanks so much for having me. This was great.