Why “Pixel Perfect” Isn’t Perfect

When a product is close to launch, many designers will focus on the intricate details. Ultimately, those who are passionate about design often do the job because they love it and genuinely see badly kerned fonts as an affront to common decency. As an industry, we obsess about “pixel perfection” to the point where many job specifications require someone who can produce “pixel perfect designs”.

In this article, I’m going to make it clear why I don’t think this is quite the right approach.

Pixel perfection is impossible

It is 2015, the future! We may not all have hoverboards yet (although they are on the way) but what we do have is a plethora of smartphones, tablets and other internet connected devices.
Unlike print, the web is a flexible medium which can be consumed by a range of users with differing technology. You might achieve “Pixel Perfection” on your beautiful 27 inch iMac or possibly on your corporate client’s creaking XP laptop. Maybe you’ll achieve it on both, but what about your client’s husband’s iPhone 6 Plus? What about your boss’s HTC One with stock Android browser? Ultimately a pixel is a meaningless unit which can vary depending on the pixel density of a screen. You’re probably more likely to achieve some semblance of consistency by using relative units rather than precise pixels.

In Branden Kowitz’s article “Why you should move that button 3px to the left” (which inspired me to write this piece), he mentions that “Trust increases when we get the details right” citing Stanford’s Web Credibility Project. Whilst I agree with the premise (supported by peer reviewed, academic research), I disagree that the principle applies infinitesimally. At some point you have to accept defeat by the law of diminishing returns. Is moving buttons marginally to the left or right really the best use of your front end developer’s time this close to a launch? Is there something else they could be doing which will have more of a positive impact on the user experience?

Design Like a Developer

Whether your design workflow involves passing intricately designed PSDs to developers, high fidelity prototyping or a mixture of both, patterns and conventions should emerge. Those patterns help users develop a mental model of how your website works. Simply put, we use memories of how similar things work to predict the behaviour of new things we haven’t used before. For example, in the following video, a young child builds a mental model of how shiny things with pictures work using an iPad and then is frustrated when applying it to magazines.

Take the time to document those patterns and conventions in a styleguide or pattern library. Establishing those conventions and sharing them with your developers, will help them understand those patterns and present them consistently. It also empowers other members of your team to experiment with different design concepts independently, so that you have more time as a designer to focus on those which will see the light of day.

When running prototyping projects, I’ve often noticed front end developers becoming frustrated after receiving updated PSDs from designers without clear instructions about what has changed. Often, they may not be as passionate or knowledgable about typography as you are, just in the same way you might not be highly proficient in Angular JS. Working together to create style guides and accompanying CSS means that you’ll have less mutually painful conversations about leading (or as they’d put it, line-height.)

By “Design like a Developer” I’m not advocating using interfaces purely designed by engineers. (Which tend to be fairly painful, both from a design and UX perspective.) Developers like to use frameworks such as Bootstrap or Foundation, because they can abstract the patterns and create reusable components. In our design, rather than giving them similar components with many variations with little or no benefit to the user, we need to focus on consolidation, so that those precious hours can be spent delivering that which really matters.

The button will still be there tomorrow

How many times have you worked with your team up until the end of a project, with the project manager promising that your vision will be fully realised in phase 2? How many times has phase 2 happened? As Jeff Gothelf wrote in “Lean UX : Applying Lean Principles to Improve User Experience” : “The biggest lie in software is Phase II.”.

Before the web became mainstream, the software industry relied on shipping physical, boxed, software which led to infrequent releases, due to the burden of manufacturing the disks. Those practices have survived, yet don’t take advantage of how easy it is to release something online. With one release, you might devote lots of time to perfectly aligning a button. What if it turns out that your users won’t click the button at all unless it’s a completely different colour? What if the button in it’s current guise is distracting users from another element on the page which is more important to the commercial goals of your client? You might pick up some of this in usability testing, but some problems may not come up as the test could be based on certain journeys through your product.

Often, we have a propensity to treat assumptions or persistent myths as facts. A good example of this is Maslow’s Hierarchy of Needs, there is little empirical evidence to support it yet it’s repeatedly regurgitated as the basis for certain design decisions.

The solution to this is adopting an iterative methodology such as Lean UX. Lean User Experience recognises that product development is based on assumptions. By documenting hypothesis around these assumptions and then meticulously testing them (starting with the riskiest), we can ultimately create better products.

Minimum Viable Products

Over the last few years, I’ve heard the term “Minimum Viable Product” repeatedly abused by those who’ve never read anything about Lean. A MVP is not “Phase 1". An MVP isn’t “doing the bare minimum” and leaving it forever. A minimum viable product is a grand experiment where enough features are released to validate whether your assumption that there is market for your product is correct. It only works if you continue to monitor user behaviour and frequently release features, changing course when assumptions are proven incorrect or more often than not, “half correct”.

Ultimately this empowers clients, product owners and their stakeholders to make decisions based on evidence rather than conjecture. Working in this way is addictive! Rather than wasting time on features which there is no market for, your team will end up laser focused on things which matter to your users and achieve better commercial outcomes.

In Conclusion

During digital projects, you will always be limited by budget and time. However, there are many artificial limitations imposed on what you design based on assumptions about what users will or won’t accept. By moving to an evidence based approach and acknowledging those assumptions, you can try bolder ideas, limited only by creativity and available technology.

You may not be able to fix the button positioning today, but changing how you approach projects means that you might be able to fix it tomorrow.

Show your support

Clapping shows how much you appreciated Adam Babajee-Pycroft’s story.