Perfection and Designers
Some of the Designers from DesignMap recently attended the fabulously-curated Mind the Product Conference (with great talks from Ken Norton, Maria Guidice, Des Traynor, Peter Merholz, and Laura Klein, among others). This conference is attended by Product Managers and their managers nearly exclusively, so we couldn’t resist the urge to squeeze in a little research: We put up a white board and asked folks what their greatest fear is when working with designers.
Along with the things we’d expected to hear (“How do I evaluate the quality of the design?”, “What if my engineers hate them?”), we also heard concerns from several people about perfectionism, people who are uncompromising or have an ego (we assume in a bad way).
Specifically, we heard Product Managers worry about Designers, “What if they’re perfectionists?”
This isn’t a fear we’d heard or considered before — maybe this is one all our clients have, but they don’t want to share for fear of insulting us, or maybe they haven’t really thought about it. But we had several people mention this, and after checking in with some friends, we decided that this is a pattern worth addressing: How do you deal with Designers who are perfectionists?
What is Perfectionism?
Defining our terms a bit here, true perfectionism is actually a pretty bleak assessment of a person. The personality trait is linked to higher incidence of suicide, according to several studies cited in this New York Magazine article. The article points out that it’s not even good for business: “Research confirms that the most successful people in any given field are less likely to be perfectionistic, because the anxiety about making mistakes gets in your way. Waiting for the surgeon to be absolutely sure the correct decision is being made could allow me to bleed to death.” In this Atlantic article, the psychiatrist who heads the women’s addiction program at Toronto’s University Health Network sees a pattern in the professional women who come to see her: “Perfectionism.”
Designers Aren’t Inherently Perfectionists
I believe that perfectionism per se is counter-inherent (if that’s a word) to design, and here’s why: If perfectionism is insisting on things meeting ones own internal standards, that’s a pretty self-gratifying perspective. “Things must be perfect because only then will I feel ok,” kind of thing. Whatever the driving force behind a person’s perfectionism, the need being met is their own. But Designers are Designers specifically because they like boundaries, which force them to solve problems creatively. This kind of pragmatism comes from meeting external demands— the needs of the user, the needs of the client, the needs of the business, etc. Perfectionism isn’t so much a boundary to be creatively solved around as a theoretical construct imposed to meet the demands of one’s own ego. (Not ego in a bad way… but it’s more the purview of art than design.)
When their goal to do perfect work is in conflict with a business goal (for example, “Release the first version of our product and see what response it gets from users, minimizing investment until we can test our hypotheses.”) and the Designer argues to prioritize their own personal goal over the businesses, then you may have a real live perfectionist on your hands, and you’re right, you do have a problem.
Perfectionism can be a serious problem. But for Designers perfectionism is the exception, not the rule.
So first, let’s hope that your Designer isn’t actually suffering from perfectionism and rather is just setting reasonably high demands on themselves and the product!
Then Why Do They Seem That Way?
Throwing caution to the wind and generalizing grossly, Designers see the world differently. A Designer can spot Arial a mile away and cringe. Their whole day was ruined when Instagram released their new logo.
This isn’t in a snooty, better-than-you kind of way, it’s just something about the way they tick. Not unlike the way engineers see the world differently — for example, my daughter’s bricked iPad isn’t an agonizing pain-in-the-ass, it’s a fun problem to be solved (thanks Dad!). For a Designer, the difference between just ok is really not that far from bad. To get something really good, that’s where the work is. And it’s not perfect, it’s just good. Perfect is way off the edge of your screen somewhere.
Other people may see something that’s “fine”, and feel it’s waaaaaaay better than bad. They’re just different scales:
So for the rest of this article, I’ll use “perfectionism” to mean “high standards for ‘Good’”. Bridging the gap between the ways we perceive the world is entirely possible.
But people who are worried about perfectionist Designers are right, we should tackle the standards gap up front with some plain conversation, and by aligning our language and our goals.
So What Can I Do About It?
Some specific ideas when you or a Designer you work with seems in danger of being a perfectionist:
Ask the Question
Ask the question at the beginning of the project: Are you a perfectionist? How do you think that will impact the project? Whether interviewing a vendor or a potential hire, this is a fair question to ask, and interviews or meetings like pre-mortems are a fair and non-threatening way to address the issue up front. The answer I would look for in a Designer is, “Yes, but…” I mean, they are Designers, right? You do want someone who cares about their craft, about details, about really getting it right. But “Yes, but in a pragmatic way,” or “Yes, but when it makes sense,” are good answers.
Align Goals
Make sure that the team is aligned on the goals of the project. Hidden in the statement, “I’m worried the Designer will be a perfectionist,” is the idea, “I’m worried that the Designer will take too long, because they won’t understand that for us to achieve our business goals, speed is more important than perfection.” So make sure the Designer knows the business goals! There is a reason places like CCA (a renowned design school) are offering MBAs to students of design — they need to understand this stuff, and it’s generally not taught in design programs. Product Managers can help the entire team understand what success will look like, and the team should ask if they don’t get the information or understand it deeply.
Without shared goals, there is a void where there needs to be a counterbalance to any ego-based perfectionism.
Perfection Relativism
As projects vary, so might the degree of perfectionism required. Fine-tuning a checkout funnel that sees hundreds of people per day requires a more careful hand than soft launching the MVP of a new product that only a few hundred people are ever expected to see before it’s revised. Everyone on the team understanding what’s an appropriate standard of work for this project is key. For example, that 80% of the Designers best effort across 100% of the pages is preferable to 100% of their best effort on 80% of the pages for this one. Maybe next time it’s different. This is actually a kind of goal, and can be part of the planning conversation / pre-mortem too. Degree of perfection needed will depend on several factors:
- number of people who’ll see it
- business impact
- how many times you’ll be able to iterate later (see “pots”, below)
- how long it will be around before it can be revised
- the overall scope of work and number of resources available
- what you need to get out of the release (see “goals”, above)
Teams will need to find their own language for this — the percentage won’t have the same meaning to everyone. Maybe it’s number of revisions, or amount of time spent on a first pass, but agreeing up front will save a lot of headache later.
Acknowledge Value
Shrugging off another round of design iteration can easily feel to a Designer like shrugging off the value of their contribution to the project. Project and Product Managers may help move things along by simply acknowledging how great it would be to do another pass, but (remembering the goals), how much they are needed on something else, or how important it is to get the current version in front of people. This might seem like babying a fragile ego, but everyone needs to feel like they’re doing something meaningful to be happy. (And you should feel like their contribution is meaningful too — or else something is seriously wrong!)
Keep the Promise of Lots of Pots
There is an old canard that a ceramics professor split her class in half. To one half she said they only had to produce one perfect pot by the end of the semester and they would get an A. The other half would be graded on the number of pots. It didn’t matter whether the pots they made were good or not. Quality wouldn’t matter. Of course you know how this has to end: the half of the class graded on quantity of pots also produced higher quality pots.
But imagine if the half of the class told they’d be graded on number of pots then unexpectedly got graded on the quality of their second pot. Do that once or twice and those students are going to be much, much more careful about that first and second pot!
Designers are generally good at iterating, and know that quality comes from continual improvement. We learn this in design school, where we practice, get critiqued, try again, get critiqued, ad infinitum. Make sure there is time to iterate, or if there isn’t, that it happens rarely and it’s clear why.
And both teams and Designers independently can build in their own iteration cycle, even if there “isn’t time”. This takes a lot of will power, but you can trick yourself into it: If you have two weeks to design something, before starting you can schedule a usability session at the end of the first week (or exec review, or something) as a forcing function to get something out there fast, and then you have time to iterate. If you have two days, plan to visit a coffee shop to guerilla test a few things on the morning of the second day. Etc.
Designers’ 20%?
Sometimes Designers see stuff that other people don’t. Maybe it’s kind of like Developers seeing crappy code that no one else actually sees either. But when Developers wave their hands and start using words like “bubble gum” and “bailing wire”, we have a good solution: Marty Cagan’s rule of 20%, which gives Engineering teams 20% of the available resourcing to address whatever they feel is most important. Maybe it’s reasonable for Designers working on large or older products to have that same 20%, to solve problems they see and understand differently than other people might, with the explicit understanding that ultimately the business should benefit from that 20% (although how could vary widely, from brand perception to something as specific as conversion rates).
I’ve written this to Product Managers and other people working with Designers, but I hope it’s useful to everyone on the team. Ideally Designers are the ones starting these conversations, or forwarding this article, or just checking their own high standards against the business needs.
I’d love to hear from others how you address these challenges, and especially if you have any shared language for what “Good” means. I’ll look for you in the comments…
DesignMap is a full service design consultancy that specializes in making enterprise software easy to use. You can learn about us at designmap.com.
