Writing

The middle of things

When we review design work, there are a couple of familiar places to focus our attention.

At the high end, there are the big questions. Is this the right strategy? Are we solving the right problem? Does this make sense for the business?

And at the other end, there’s the polish. Is the visual hierarchy right? Is that button a little off? Are there unnecessary boxes and rules?

But there’s a whole world between those two layers that I think often gets shortchanged. The mechanics of how a design actually works, and how those mechanics produce the experience of using it.

This is where I like to spend a lot of my time with the design team.

In critique, we start by using the design and paying attention to how it makes us feel. Not evaluating it against a set of heuristics, or looking for violations of the design system, or thinking up alternate solutions. Just paying attention.

Where did it feel good? Where did it feel bad? Did we get confused? Frustrated? Bored? Did something surprise us, or make us hesitate, or leave us wondering what to do next?

These feelings are interesting because they often arrive before we have any idea what caused them. And that’s where the diagnostic work begins.

Something feels off

Let’s say we’re walking through a flow together, and something about the transition between two screens feels wrong.

Someone might raise their hand: “Hang on. When we clicked that button and landed here, something felt off to me. I was expecting something different, and now I’m a little confused about where we are. Did anyone else notice that?”

Now we have something to investigate.

Maybe someone else felt the same thing, but for a slightly different reason. Someone notices that the copy on the first screen set up an expectation that the next screen didn’t fulfill. Another person points out that the UI suggests we’ve completed a task when we’re actually halfway through it.

As a team, we’re beginning to move the ball down the field together, trying to get closer to an explanation of what happened.

Because everything in a design communicates. The words, the visual emphasis, the UI conventions, the sequencing, the interactions. So the question becomes: what were we trying to communicate, what is the design actually communicating, and how do we close that gap?

Sometimes the group comes up with explanations that sound perfectly plausible, but don’t really ring true. They don’t quite account for the experience we had. So we keep going back to the original experience, testing each explanation against what we actually felt and when. But then someone says something and you can almost see the room recognize it. Heads start nodding. Yes, that’s it. That’s exactly what happened.

Now we’ve got a working diagnosis. And the designer has something useful to work with.

Notice that we haven’t redesigned anything yet. That’s the designer’s job. The group’s job is to expand their understanding of how the design is working, so they can improve it themselves. We trust designers to design, and our role is to help them see the highest-leverage opportunities for improvement.

Getting better at getting better

I’ve often told teams that the real goal of critique isn’t to make the piece of work we’re looking at better. That’s great if it happens, and it usually does. But the more important goal is for the team to get better at doing this exercise. It’s like going to the gym.

Early on with a new team, I might lead a critique from the front, demonstrating how to pay attention to a feeling, investigate it, and connect it back to the mechanics of the design.

But after a few sessions, people start picking it up. So I start sitting back.

I draw quieter people into the conversation. I take notes. When someone makes a particularly useful observation, I bring the group’s attention back to it, and try to connect it to a broader design principle we can all carry forward.

And at the end, I ask the designer if they have what they need to move the work forward.

Over time, something really nice happens. The team takes these skills back to their individual work, and begins to solve more sophisticated problems independently. The things they bring to critique get harder, because they’ve already worked through the easier problems themselves.

The whole team gets faster and better, and increasingly autonomous.

Now sure, I could have simply run critique as a forum to tell everyone what’s wrong and what to do about it. That might make an individual meeting go faster, but eventually everyone is waiting for me to make the next decision.

Congratulations, Matt, you’ve made yourself the bottleneck.

There’s a cultural component to all this, too. The least useful critiques I’ve experienced are the ones where everyone is trying to sound smart. You get disconnected opinions, clever suggestions, and a lot of talking without much actual progress.

Good diagnostics require people to be comfortable saying things they haven’t quite figured out yet. “I don’t know why, but something about this feels off” needs to be a welcome contribution, not an embarrassing admission. Because sometimes that’s the most valuable thing anyone says all afternoon.

It’s taken me a while to recognize how much this longstanding practice with design teams owes to my childhood. But that makes sense to me now. Start with what’s actually happening. Get curious about why. Understand the mechanics. Find a simpler, better way for things to work. And if you’re lucky, find a great group of people to do it all with.

Thanks, dad.