Thanks for bearing with me, picnickers – this is the fourth and last part of our two-part series on how to fix all the problems with the entire field of UX design. 

In the first issue we talked about the incentives of product teams drifting away from user-centered principles. In the second, we looked at how designers are thinking about where design could fit in this new world that would let us apply more leverage than we can as a delivery function. And last week was dedicated to applying that leverage, through developing a design-driven strategy. 

This week, we’re going to talk about feedback. Specifically, feedback loops.

Diagram of the Week

One of the most harmful notions perpetuated by the various models of the design process is linearity. While practitioners understand implicitly that design is an iterative process, cross-functional partners used to looking at linear roadmaps saw the double diamond or the “design thinking” sequence as a series of gates. We do research, then we do design, then we do prototyping, and then we are done. 

The process only really works that way if, upon completion of each step, we have learned absolutely nothing new. In reality, if every step is correctly designed to gather some new information, then we might find ourselves going back to a previous “stage.” 

This is why I prefer to depict the design process more like this: 

Reading Material

Let’s dig into the diagram a little further. We’re not really keeping to the “learn, design, build” sequence in the title here – Expertise and Critique are both design activities, while Experiment covers both “learn” and “build” for given definitions of build. Position, I would also argue, is the responsibility of design, albeit one that we often give away all too easily to other functions. But perhaps that’s the entire point — the loops aren’t meant to be sequential.

The Expertise Loop

The innermost loop – expertise – mostly overlaps with what the industry calls “craft.” Does the design I am producing match my designerly taste? Does it satisfy the heuristics of my professional judgment? Is the artifact itself constructed in a sensible way? If the answer is yes, many designers are tempted to check the “done” box and go do something else. 

But it’s really only the beginning. While you do not owe it to your colleagues to justify your design decisions, you ought to be able to explain them if you want to behave like a true partner. From this need, the rest of the feedback loops blossom. 

The Critique Loop

It is my personal belief that, done correctly, critique is the secret sauce of design. The thing that separates useful critique from mere criticism is a skill that needs to be taught. Designers expecting to receive the former from cross-functional stakeholders in the same way that they could get it from classmates and professors will be sorely disappointed – the stakeholder is not like me. 

In the workplace, you are the design expert. Stakeholders will not give you useful feedback by default, regardless of the fidelity of the artifacts you bring, unless you own the feedback process. That means pushing back on unhelpful opinions and “I would have done it differently” statements. Daniel Ferreira has a simple suggestion to get you started: ban talking about solutions for the first 15 minutes. Only once we agree on what problem we are solving, will we have a productive conversation on how to solve that problem.  

The Experiment Loop

It is simply not true that we must build something before we can learn something. While the artifact you create for the experiment might not be the artifact you created for critique, code-in-production is rarely going to be the cheapest or fastest way of answering your research question. Indeed, the best feedback is usually going to come from testing artifacts that are wrong in an interesting way. 

If you do not know what your research question is, you are not ready to produce any kind of artifact, in code or otherwise. Any information you gather will be tainted and you’ll just end up enshrining your assumptions without having had an opportunity to examine and evaluate them.  

Joanna Weber’s assertive enquiry is a good mindset when there’s already an assumption and you’re being pressured to check the box and move on. 

The basics of user research are a topic for a book rather than a newsletter, but Himanshu K has a list of research principles you may find helpful. Christina Wodtke’s primer on needfinding is nearly a decade old but still gold; it pairs well with her piece from two weeks ago on how to use qualitative data correctly without falling into the trap of mixing up tasks with results. 

The Position Loop

Metrics? Strategy? Isn’t this within the remit of product management? Well, maybe. But they’re making a hash of it, in part because they are marking their own homework. If designers don’t step in and interrupt the routine of business-as-usual, they condemn themselves to a career of local optimization. 

We talked about strategy last week, but one of the most important parts of the positional loop also concerns internal impacts – impacts on the business rather than the product. And actually shipping the thing you designed is very much an internal-facing business problem. The product-facing impacts your experimentation identified are great arguments in favor, but there’s more work to be done. Your vision is only part of the equation. 

I’ll end today’s issue with a bit of design philosophy from Grady Booch by way of Jabe Bloom. Our design decisions are entangled with both past choices and future ones, and it’s very easy to design ourselves into a corner if we do not purposefully attend to that aspect of the practice. 

– Pavel from the Product Picnic