I was a student at the School of Architecture working on an urban design project when I heard this interesting story. The story came from my 65- year- old father who, to this day, has very little idea of what it is that I actually do in my profession. My father is still clearly scared when he sees me tapping on a phone with no palpable buttons. To this date, the story is one of the best and broadest examples of UX design that I’ve ever heard.
During the 70s when my father was in the military, a team of urban designers came to his military base to make some necessary adjustments. They brought their designs and defined the paved paths, according to the plans they were provided with. The base commander listened to them carefully. When they finished, he thanked them for their efforts and suggested the following: "Start with digging everything up. Let the military walk around in the mud for a few weeks and create their own paths based on their daily routines and needs.” In essence, they avoided this:
I was in awe at how simple and efficient the solution was. The designers wasted a lot of time creating these designs, but they failed at the very first step of the process. They didn't do their research. Or at least, not in the right way.
I started off with this example, because after graduating from the School of Architecture, I awkwardly found myself working as a UX/UI designer. From what I've read online and seen in real life, there are quite a few people who decide to make the switch. So I wanted to share my experiences about the transition, because things are changing fast. The fact that you choose a profession in your 20’s, does not mean you have to spend your entire life doing it - unless you want to. A lot of people might be surprised to see how architecture-based knowledge applies to what is a completely different field. So here are both the similarities and the challenges, from my point of view.
What is UX?
I won’t dwell on the definition of UX too much since there are many definitions out there. I chose the one from UserTesting, because it easily applies to architecture:
"The exact definition, as outlined by the International Organization for Standardization, is a “person’s perceptions and responses resulting from the use and or anticipated use of a product, system or service. Or, more simply, user experience is how you feel about every interaction you have with what’s in front of you in the moment you’re using it.”
So apply it to architecture (or something entirely different for that matter) instead of software development and you'll know exactly what I’m talking about.
Similarities
- User-centered Approach
One of the things that impresses me most is how you use the same approach to solving a problem both in architecture and UX design. You have to think about your user and their needs. What is the fastest, most efficient and beautiful way for them to reach their goal? It's kind of like designing a kitchen since there are certain rules you should follow in order to make it functional.
You need to consider your user’s journey through space and define the steps they take on a daily basis to make that journey as efficient and pleasurable as possible. In an ideal scenario, you would have no glitches in your kitchen that would stop you from fulfilling a task. You can always break certain rules but that also depends on your users and their habits. This is why you ask a lot of questions and based on those answers you are able to create the best possible solution.
As for the aesthetic element, your kitchen UI would be made up of the colours, materials, handles and accessories that you've chosen. I find this a very visual way of distinguishing UX and UI.
- Tools
Here you might run into some new things, but all in all the transition is headache free. Some designers still use Adobe Illustrator and Photoshop, which you probably had to use at some point during your architectural studies. At RUBICON, we use Sketch for drawing, Abstract for collaboration, Work Control between designers and InVisionApp for communication between designers and developers. This is pretty much how the process works:
You design in Sketch. Sketch is sort of the optimized combination of AutoCAD and other Adobe tools. You have an endless screen to work in and you work with vector shapes. Sketch is cheap, lightweight and fast. Also, if you've worked with Adobe tools, you'll find that learning Sketch is not your biggest issue in the game. Even if you haven’t, it’s quite simple to conquer. You have so many resources online that will make the process a lot easier.
You sync your project to InVision for the developers to see. They can inspect all the data and implement them without using any design tools themselves. If something changes within your design, you can simply update the screen and all the changes are visible on InVision.
You continuously commit your changes and design in Abstract. Abstract is the so-called “Git for designers.” It works both as storage and project overview. If there are multiple designers working on the same project, they can create branches for different parts of the project and eventually merge them into the same master file.
- Details
In architecture, you get accustomed to doing things meticulously starting from how you write to how you draw. There are so many things to pay attention to and UI is no different. Everything needs to be pixel perfect and aligned. The type has to be consistent and don't even get me started on the colours. Therefore, attention to detail really comes in handy.
- Limitations and Dependency
An architecture project depends on and is limited by a number of things: client demands, surroundings, your team, finances, users and more. Software development is similar. There are certain rules to follow and people to collaborate with. You need to discuss your solution with developers, see what works best for them, and combine that with what works best for the user. There are a lot of pieces that need to fit together in order to get the best result.
- Creativity
Both architecture and UX/UI demand a combination of technical and creative thinking. I combined UX/UI here because one relies more on data and best practices meanwhile the other allows more room for creativity.
Differences
- Agile
The one thing that is always an issue in architecture is the constant delays. Architecture projects, regardless of their type, are almost always considerably late. This creates a lot of frustration both for the client and for the architect. You can do everything right on your end but there are so many variables which you have no control over making the process stressful.
Of course, I can’t say that this does not happen in software development - it does and there is no way you can predict everything. Agile makes it more predictable. Even if you are planning on staying within the profession, I would recommend you read up on Agile. Although the methodology mostly applies to software development, at this point, it can apply to almost any process or project you're doing - and it probably will in the future. To put it simply and not turn this into a definition of Agile, we can say that it helps fight unpredictability, gives you security and a great overview of your project flow. If you want to know how well it applies outside of software development, here is a great article that might inspire you.
- Technology
Now this part is quite different. For one, you will probably have no idea what the developers are talking about. I find myself googling everything after meetings and asking a million questions. Thankfully, developers are mostly a happy and entertaining bunch (at least the ones I work with are). They LOVE good discussions and trading knowledge. Therefore, this aspect of UX might take a bit of time and it might make you feel inadequate at times because there will be so many things to pay attention to. Luckily, you will be able to progress and eventually you will be able to adapt to this environment without any problems.
- Adaptability
You can't exactly test an architecture project. When you build a building, you can hardly give it a go for several weeks, tear it down if it doesn't work and build it back up again. Once it’s up, it’s up. If it's a bad solution, you can try to improve it through interior design and all the little things that make a space attractive. But then it's kind of like having a beautiful app which is a nightmare to use. You haven't really done your job well.
In UX, iterative design is key. You have to constantly test and modify your solutions until you find one that works well. And even then, there's always room for improvement so you do it all over again. You start by creating a scalable MVP (Most Viable Product), a solution that fulfils the basic needs of a product and then you add features over time - something you cannot do in architecture.
- Time
It takes a relatively long amount of time to wrap up an architecture project. It has its phases, as does a software development project. But while you can see the end result of what an app might look like, very clearly and rather fast, it takes ages to put an architecture project “in production”.
I could probably go on and on about the topic, and I’m sure you’ll find plenty of things to add. These are the similarities and differences between architecture and UX/UI that had the biggest impact on me and what I feel both sides will be able to connect to. I would love to hear your questions, thoughts and experiences. Even if you came into UX/UI from a completely different field, or if you disagree with what I wrote.
Have fun creating everyone!
Original blog post: When UX and Architecture Meet
Top comments (0)