What kind of product designer are you when things get messy?

A completely unscientific personality quiz for product designers.

Someone senior leaves a comment on your final design: “I just don’t love the blue.” No explanation, no follow-up, and the review ends in four minutes. Whatever you do next is probably a habit rather than a decision. You’ve done it before, in a different file, about a different colour.

Most “what kind of designer are you?” quizzes sort us by what we like doing. Research or visual design. Systems or storytelling. Big-picture thinking or polishing the details.

I’m more interested in the awkward parts of the job. A PM arrives with the solution already decided. Engineering says no. Research kills your favourite idea. The deadline moves and takes your plan with it.

That’s where designers start behaving very differently. Give six designers the same disagreement, and one will open the research. One will make another prototype. One will get everyone into a room. One will find the version that can actually ship. One will ask whether we should be doing this at all. And one will quietly fix the whole thing before everyone finishes debating it.

None of these approaches is necessarily better, but you probably have a default. So pick what you’d really do, rather than what you think a very mature product designer is supposed to do.

Twelve questions, about three minutes. Each answer has a symbol, so keep a tally as you go, and whichever symbol you collect most often is your result.

And please don’t bring it to your next performance review.

1. Your PM brings you a fully formed solution

“We need this pop-up here with these four fields.”

You haven’t discussed the problem yet. What do you do?

• A) Ask what’s fixed, what’s flexible, and what has to ship. ◆
• B) Ask what problem we’re actually trying to solve before talking about the pop-up. ●
• C) Mock up their idea plus another direction so we can compare them. ★
• D) Push back politely. I’m happy to explore it, but I’d rather not start with the solution already decided. ■

2. Engineering says your design will take three weeks

They can build a simpler version in three days. Your reaction?

• A) Prototype the simpler version. I need to see what we’d be giving up. ★
• B) Sit down with the engineer and understand what’s making it expensive. ▲
• C) Work through the expensive parts yourself and see what can be simplified without changing the whole flow. ✦
• D) Start stripping things away until we find the smallest version that still works. ◆

3. In the final review, someone senior comments:

“Can we make it feel a bit more premium?”

There’s no further explanation. You:

• A) Explain what the current treatment is trying to achieve and ask what feels insufficiently premium about it. ■
• B) Try two alternatives next to it. Sometimes seeing them is faster than debating them. ★
• C) Ask what specifically isn’t working for them. ●
• D) Make the adjustment and bring back something concrete rather than extending the debate. ✦

4. Two stakeholders give you completely opposite feedback

One wants fewer steps, the other wants more information. What happens next?

• A) Get both people into the same conversation. ▲
• B) Find the smallest compromise that addresses the biggest concern from both sides. ◆
• C) Design both versions. Sometimes people need to see the consequences. ★
• D) Go back to the user problem and work out which concern has stronger evidence behind it. ●

5. You’re reviewing another designer’s work

They’ve chosen a direction you wouldn’t have chosen, and nothing’s wrong with it. You:

• A) Leave it alone. Different isn’t automatically wrong, and the design works. ◆
• B) Ask why they chose it and see whether the reasoning holds up. ●
• C) Let the direction go and quietly fix the parts of the flow that still need attention. ✦
• D) Tell them what you’d do differently and have the trade-off discussion. ■

6. The team has been debating the same decision for 30 minutes

You’re starting to lose the will to live. What do you do?

• A) Ask what evidence would actually change anyone’s mind. ●
• B) Summarise what everyone agrees on and isolate the one thing we still disagree on. ▲
• C) Suggest the simplest reasonable option and move on. ◆
• D) Volunteer to prototype the competing options after the meeting. ★

7. User research contradicts your favourite design

Your first reaction?

• A) Fine. I already want to try another direction. ★
• B) Figure out how much of the design actually needs to change. ◆
• C) Check what failed and whether the pattern was consistent. ●
• D) Mild emotional damage, followed by a fairly enthusiastic debate about what we got wrong. ■

8. You’re given a vague brief

“Improve the booking experience.” Your natural starting point?

• A) Talk to the people who already have context before touching the design. ▲
• B) Open the existing flow and start fixing what you can improve straight away. ✦
• C) Explore a few directions to work out what the brief could become. ★
• D) Start asking questions until “improve” means something measurable. ●

9. The deadline moves forward by two weeks

Your beautiful plan is dead. What do you do first?

• A) Start reshaping the flow around the new deadline and deal with the obvious cuts first. ✦
• B) Get PM and engineering together and redefine what “done” means. ▲
• C) Push back on the deadline if the remaining scope no longer solves the problem properly. ■
• D) Work out which assumptions still need validating before we cut anything. ●

10. Your design review comes back with 23 comments from nine people

Half of them contradict each other. You:

• A) Group the comments into themes and work out which disagreements need a conversation. ▲
• B) Resolve the comments that are clearly preferences rather than product problems. ■
• C) Quietly work through the file and fix the things you can resolve without another conversation. ✦
• D) Prioritise the comments that matter to the outcome and leave the rest. ◆

11. Your PM builds a prototype with AI over the weekend

On Monday it’s presented as “basically the design”. You:

• A) Point out the important states, decisions and edge cases the prototype hasn’t resolved yet. ■
• B) Treat it as one direction and quickly prototype another before deciding. ★
• C) Ask what they were trying to test and what they learnt from making it. ▲
• D) Keep what’s useful, fix the gaps and move the project forward. ✦

12. The feature ships differently from your design

Nobody told you. You:

• A) Talk to the engineer and find out what happened before deciding whether it’s a problem. ▲
• B) Check whether the differences hurt the experience. If they don’t, move on. ◆
• C) Update the Figma file so design and production agree again. ✦
• D) Raise it. If the team made a different decision, design should at least understand why. ■

Count your symbols

Whichever one you picked most often is probably your default.

● The Evidence Collector
▲ The Diplomat
■ The Challenger
◆ The Pragmatist
★ The Explorer
✦ The Quiet Fixer

● The Evidence Collector

Your favourite question is probably some version of: “How do we know?”

You don’t particularly enjoy watching assumptions turn into facts just because someone says them confidently. You’ll look for research, analytics, previous experiments, support tickets or anything else that makes the decision less hypothetical. When somebody says “users probably want this”, you’re already wondering what the word “probably” is doing there.

That’s useful. Product teams make a lot of decisions with incomplete information, and you’re often the one who notices when a confident opinion becomes a requirement.

Your danger zone is waiting for evidence to remove uncertainty completely.

It won’t. At some point, “we don’t know yet” is still enough information to make a reversible decision.

▲ The Diplomat

You often notice when the real problem isn’t the interface. It’s that product, engineering and design are solving slightly different problems.

You ask questions, translate concerns and get the right people into the same conversation. When two people disagree, you usually want to understand why before choosing a side. That’s valuable when a team is stuck because everyone is arguing from different assumptions.

Your danger zone is turning every disagreement into a conversation. Sometimes there isn’t hidden context to uncover. Nobody needs a workshop; someone just needs to make the call.

I ran into a version of this myself as a lead, after being told I was “too nice”. The problem wasn’t kindness or avoiding conflict. I was waiting too long to be clear.

■ The Challenger

You’re unusually comfortable saying: “I’m not sure we should do that.”

You question briefs, challenge assumptions and tend to notice when a suggestion has turned into a decision without anyone really examining it. When you think the reasoning is weak, you’ll say so.

Teams need people willing to do this. Plenty of bad product decisions survive simply because everyone in the room assumes someone else has a good reason.

Your danger zone appears when every disagreement starts feeling like something worth defending. Sometimes the stakeholder’s annoying suggestion is fine. Sometimes the designer you’re reviewing made a different choice and it’s also fine.

You don’t have to die on every hill just because you can see it. I wrote more about that in the more senior I get, the less I want to win every design argument.

◆ The Pragmatist

You have a suspiciously strong fondness for phrases like: “What can we actually ship?”

You look for the useful middle ground between the ideal experience, technical reality, business constraints and the date somebody already promised to somebody else. When engineering says something will take three weeks, you’re probably already working out what the three-day version looks like.

Your danger zone is compromising so efficiently that the team slowly forgets what the better version was supposed to be. Every reasonable trade-off creates a small promise that you’ll come back to it later.

You know how that usually goes.

★ The Explorer

Someone says: “I don’t think that will work.” Your instinct is: “Let’s see.”

You understand ideas better once they’re tangible. Rather than debating two hypothetical approaches for 30 minutes, you’d often rather build both badly in 20 and discover which assumptions survive contact with an actual flow. That’s handy when a team has talked itself into circles.

Your danger zone is continuing to explore after you’ve answered the important question. Trying another direction is cheap, but that doesn’t mean every decision deserves five of them.

Eventually you have to stop opening new Figma frames and choose one.

✦ The Quiet Fixer

You’d rather not spend 45 minutes discussing a problem you could probably make clearer in 20. You’ll open the file, untangle the flow, clean up the component, rewrite the copy, investigate the implementation or fix something nobody formally assigned to you. Then you’ll come back with something everyone can react to.

This works, which is exactly the trouble.

Your danger zone is that people get used to things mysteriously becoming better around you. Eventually you’re fixing decisions you don’t own, cleaning up processes nobody asked you to own and absorbing the gaps between other people’s responsibilities. Then one day you wonder why you’re exhausted.

I’ve been this one. I wrote about getting out of it in I stopped fixing everything and started fixing the system.

Got a mix?

Good.

Real designers obviously don’t fit neatly into six boxes.

You might be an Evidence Collector when someone makes a strong product claim, an Explorer when you’re unsure how an interaction will behave, a Challenger when a solution has been decided too early, and a Pragmatist the moment engineering tells you the sprint ends on Friday.

There’s a slightly more serious idea under this very unserious quiz. The question isn’t which type you are. It’s whether you keep reaching for the same response no matter the situation.

Most of these behaviours are useful until one of them becomes the only response you reach for.

What did you get? Tell me in the comments, especially if you think the quiz got you wrong.

Further reading

• When being “too nice” isn’t the real problem
• The more senior I get, the less I want to win every design argument
• I stopped fixing everything and started fixing the system
• What Designers Actually Struggle with on Product Teams, by Laura Klein (Nielsen Norman Group)

What kind of product designer are you when things get messy? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.