Design is marvellous: it’s simultaneously simple and complex. One of my early ideas for this project was to define a base design process, as a reference point of exploring how architects might integrate UX processes. That’s still the plan; it’s an evolving reference point as this project grows.

Design processes are unique to the designer, and those are unique to the project, so there are millions of design process diagrams around. As a UX designer, I developed a base process that I adapted for each project, problem, iteration, sub-problem and so on. I’m now readjusting my process for my architecture studies, and it’s as good as any to serve as a base process for UX for Architects.

In reading about ‘architecture design processes’, I’ve observed two reigning categories of design process descriptions. The most common descriptions outline generic design-build processes; including pre-design, site analysis, schematic design, design development, construction drawings, contracts, bidding, negotiations, and post-construction. The other most common describes the creative design process and has similarities to designers of any persuasion.

The Architecture UX process base

To show the creative process similarities, I’ve adapted one of my own UI-centric design processes into a nice, simple diagram so that it could be talking about an Architecture project of the tangible kind.

So very nice and simple right? Well, in reality, the over-simplified version of my process is more like this:

But for this post, we’ll use the first diagram. It’s essential to remember that although the first diagram is a nice, ordered circle where each step flows neatly into the next, my design process (like many others) is non-linear, iterative, infinitely flexible, and at times, chaotic. At this stage of my studies, my Architecture UX design process is evolving like this:

1. Define

I try to obtain a thorough definition of what I’m about to do. I interrogate the brief; determine the scope; identify stakeholders (including user groups); map desired outcomes; loosely plan the presentation. I’ll note possible tangents or diversions, then see about joining the dots among all aspects uncovered so far. I’ll think of questions, without concern if they are answerable.

Additions for architecture: None yet.

2. Research

I’ll ask the questions and try to find answers. I’ll collect information and data, then identify, analyse and synthesise it. Often I’ll find research that influences the brief, so I’ll go back and re-define it.

Additions for architecture: New areas and methods of research.

3. Ideate

Usually, this is the longest phase for me. It’s always running behind the other phases, even after the project closed. I’ll sketch, draw, wireframe or talk it over, scribble a diagram of some kind. Most importantly I’ll play and rest and forget about it for a while, then check the ideas for relevancy and regularly cull.

Additions for architecture: More ways of generating ideas: new ways of drawing, model-making, inspiration-finding.

4. Test

I’d test with programmers and other stakeholders; user groups; against initial feasibility statements; and through sales and marketing channels.

Additions for architecture: Aside from playing with VR/AR experiments, right now testing my architecture designs takes the form of throwing ideas around a classroom. It’s safe and low-risk. Testing built work in Architecture is difficult and high-risk, so this is a phase I’m rethinking a lot.

5. Do

Probably the most fun part. All the previous work comes together and I’ll make a design.

Additions for architecture: New skills, methods, thinking, a whole lot. It’s why I’m at architecture school.

6. Feedback

Feedback is another phase that runs constantly behind my process. What changes is where it’s coming from: in early stages, it’s from research and stakeholders; maybe the client, project owner, or company directors. Later, it’s from my peers and other business areas as the project develops. The Feedback phase comes to the fore after the project is completed and presented, and the stakeholders now typically include the end-user. As the feedback comes in, I’ll process it as needed.

Additions for architecture: No change.

Thoughts on Rendition 1

It all sounds very efficient. In some ways it is, and in others it isn’t! When I’ve been thinking about how to write this article, two particular themes caused me much chaos as I tried to communicate this complicated concept simply. These themes loom too large to not mention alongside my process, although each could easily have their own post and accompanying book.

A note on empathy

‘Empathise’ has been a buzzword in the design community for some years now. Many of the UX-centric design process diagrams I looked at while researching this article include ’empathy’ as a step, sub-step or note somewhere. Architects love this word too, and it evokes a lot of good-feels in even more people. Empathy is a great thing to have when designing things for people or any living being.

In my process, empathy isn’t a phase or step. Empathy is a tool, it can be learned, and one can become highly skilled at using empathy. I can, and regularly do, empathise in my designs and life. When designing for different groups of people, it’s a valuable skill to be able to think in a way that is more like that group and less like yourself.

What the design community doesn’t talk about so much is the ethics of empathy, and I think there is a huge misunderstanding in how our culture at large defines it. UX and Architecture should rightfully care about empathy, exercise it, and understand how powerful it can be. There’s enough to fill a book here (like this one*).

Dark patterns are a trend in UX design where empathy is used in less-than-nice ways. Dark patterns are techniques like trick questions, misdirection and bait-and-switch, done to manipulate a user into taking an action they may not want to do. Thinking of things like this requires an in-depth, highly-skilled understanding of the end-user: the very definition of empathy.

Architects and designers must advocate that empathy is neutral—it is neither good nor bad—and is used by all people—who are invariably not neutral. It is architects’ and designers’ responsibility to distribute this awareness and regulate how they maintain and use their own empathy.

A note on ego

Ah, the ego, with so much to say. What I will say, is that UX process requires a much broader self-awareness of the designer’s own ego than other design processes I’ve encountered. Often the needs of a user compromise an original concept, so one can’t be too precious about concepts. And then there’s the communication of the design process with stakeholders. A self-aware designer ego can do a better job of communicating between stakeholders, an essential part of design processes that UX designers do well. But there’s so much to unpack on the topic of ego, that I’ll just leave it here and you can transcendentally know it’s a kind of really a very big deal.

A wicked problem

Architecture UX is a wicked problem, although we’ll likely find multiple solutions to each of its multiple problems. My thinking is that with a definable, flexible base process, we’ve got some sort of reference point to work out what problems and solutions in the process might be, and facilitate some really great future architecture.

Rendition #1 of this base process is a simple start, and reflects where I currently am at with my experience and architectural education so far. There will likely be a Rendition #2. In the meantime, I’m interested to learn your thoughts on Architecture or UX design processes, how they differ, or just what your own process is.

* I don’t know the author personally and I don’t receive any financial benefit from any sales of this book. I read it, liked it, and now I recommend it. Enjoy!