A formula for when (and when not) to fight for that design detail.
Whether you’re an architect fixated with the way a series of fluted ivory columns reach up to meet a ceiling full of geometric openings that let in just enough light or you’re a UX designer in love with the way the subtle shadow of an element animates and transforms to become a different page, all designers are obsessed with details.
Steve Vassallo in his incredible book, The Way to Design, even includes this quality in his definition of a designer:
[Designers are] people who have lived among tools; who have experienced the deep satisfaction, of refining, the smallest details of something to an exacting finish; who know the pride and suppressed glee of finally unveiling a completed work to the world - even if that population of that world numbered just one person and saying I made this for you.
This obsession (read: attention) to detail is often what sets apart good designs from great designs. While most people might not be able to describe why they love one experience over another, designers are able to pinpoint the details that made this happen.
But no matter what design project you’re working on there’s an evil four-headed monster lurking behind this focus on details: money, time, people, and space.
Because design details are in constant battle with this efficiency-driven monster, other members on our team will often put our design details on the chopping the block. Project managers will say we don’t have the time or the resources to make them happen and engineers will say that it’s too much work to pull them off.
What makes this so challenging for designers, is that we’re not in complete control of transforming those design details from prototype to built reality. We inevitably have to have difficult conversations over the fate of our precious details.
And the truth is, we’re not really prepared for this kind of fight (read: debate)... In school, designers spent countless sleepless nights iterating and refining their designs to perfection. There’s no budget or reality in most design school projects so we get used to making everything the way we want — down to the last detail. That is until we graduate and are thrust into the pain of the real world.
I’ve experienced the pain of this first hand. After 7 years of design school, I became the only UX designer on a team of about 30 developers inside of a company with around 60 total employees. As soon as I was up to speed, I began to fight for every design detail. Pretty soon this obsession (read: attention) to detail earned me the nickname ‘Pixel Prince.’ For a time, I wore this like a badge of honor. I told myself I was fighting for the best possible experience for our users.
Over time, however, the fighting took its toll and I began to wonder whether investing in every design detail was the best idea…
Vassallo offers a glimpse of an answer in the later pages of, The Way to Design, (again I highly recommend this book):
You have to wisely pick and choose when you can obsess over a picayune detail and when a solution that might not be perfect is still good enough to ship -- all the while always keeping the broader mission of your startup [organization] in perspective.
What Steve is arguing is that if you don’t deliver, you’re not really helping anyone. The longer you keep perfecting your design, the longer your users have to suffer with the status quo. But on the flip side, he’s also arguing that some “picayune” details do matter — a lot. Getting those details wrong could be the difference between whether your design is life-changing or underwhelming.
This puts us designers in a really tough position.
Which details matter and which ones don’t???
Once I came around to the fact that obsessing over every design detail might not be worth it, I began to initiate a give-and-take relationship with other members on our team. In the beginning, this was purely based on a gut reaction. If I thought that the detail mattered, I would play my ‘Pixel Prince’ card and push that detail through. But if my gut didn’t tell me it mattered, I would let it slide.
What I soon realized about this method was that it was heavily influenced by my mood and my relationship with the other person fighting to destroy my baby (read: design). In a way, I would intuitively monitor my give-and-take relationship with that person to fight for some details, but let other ones go in order to make them feel good.
This worked well for building camaraderie on the team, but it would feel awful when I would see a finished feature out in the wild with some terrible detail…
Since then I’ve come up with a much better process for determining which details matter and which ones don’t.
It’s a simple three step process.
Step 1) The Benefits: How important is this detail?
Over time, I’ve devised a list of questions that I ask myself to figure out the importance of that detail. Every answer is assigned a score of 0, 1, or 2.
After running through those questions, I add up all of the points. This total score gives me a good sense of where I stand on the importance of this design detail and just how beneficial it would be to do. (It will also be used in a handy little formula later on).
Step 2) The Costs: What’s the alternative like?
Next up is having an open and honest conversation about why the other person is not a fan of the design detail in question. It’s really important in these conversations to listen. You have to realize that you have a bias for keeping it the way it is and they have a bias for making it as easy as possible to build.
I like to start these conversations by asking them to explain what exactly their proposed changes would look like. Then there are a couple of scenarios that can occur.
Scenario 1: You realize that what they’re proposing is actually as good or maybe even better than what you originally designed. In this case, immediately proceed in that direction. If the alternative is better and they’re saying it’s cheaper or saves time, it’s a no-brainer!
Scenario 2: Even with the newly presented information you still feel that the original design is better. In this case, your next step is to calculate the costs of going with this option over your original desired design. In order to determine the costs, you’re going to need to add up two numbers.
Third Step: Decision Time.
Once you understand how important the detail is (the benefits) and you understand the alternative (the costs), it’s simple to tell whether a detail is worth it — just compare the two different total points.
In other words…
If getting the detail perfect is really important, and there’s not too much extra effort required to make that happen, and/or the alternative isn’t that great; then it’s worth taking the time to fight for the design detail.
If, however, the detail isn’t that important, and there’s a ton of extra effort involved, and/or the alternative is pretty good; then it’s not worth fighting for that design detail.
The Big Picture
Efficiency is in a constant battle with creating the ‘perfect’ design. Improving our design decisions at an individual detail level is critical to delivering our designs to the people that matter. Blindly fighting for every detail isn’t productive and just giving up based on a gut feeling isn’t a great solution either.
Over time, you’ll start to see where your organization falls on the spectrum of efficiency vs ‘perfect’ design. Some companies like Apple place a huge importance on the details. Other companies like Amazon care more about efficiency. It’s important to monitor this over time and work towards getting your organization to where you think it belongs. It’s all part of the larger game of figuring out which picayune details matter and which ones don’t - “all the while always keeping the broader mission of your startup [organization] in perspective.”
