This post is a complement to episode 346 of Design Details, Quality Software. It is also informed by the 2018 WWDC talk, The Qualities of Great Design.
Quality is subjective and hard to define. In software, it can be unclear why certain applications seem better than others. This post aims to outline the characteristics of software that we believe determine its fundamental quality. The following notes are from a conversation with Marshall Bock, so I'll be writing this post as a we/us/our.
It can be helpful to think of the characteristics of high quality software along the axis of users and developers and attention and intention. These axis overlap, and drawing clear boundaries between them isn't always possible.
Design is in the details, so they say. It takes a lot of energy to pay attention to the details. This is usually because the details are subconsciously understood and are harder to justify in development planning. Shipping pixel-perfect applications takes time, and many of those little details will be absorbed by the user without them even knowing it. Does text have enough contrast to be visible in different lighting? Do animations play at sixty frames per second? Are colors used to communicate similar ideas? Are atomic objects consistent and clearly understood?
In modern software, especially on mobile devices, the details go deeper than visuals. Are interface elements clearly labeled for accessibility on screen readers or in VoiceOver? Are haptics used appropriately to signify events, warnings, or meaningful state changes? Having thoughtfully answered questions like these puts an application into a new tier of quality.
It's easy to build features: slap a button here, tuck a disclaimer there, and pin a tooltip on every new feature. It's not so easy to take those things away. It's a tough job to effectively educate people about new features or changes in the software. And it's even harder to ignore a loudly-requested feature for reasons that might not be easily understood by users.
Quality software knows when to stop adding features. It knows when something works well. And it isn't afraid to take things away, especially if a feature is no longer in service of a broader vision.
Quality software uses motion, iconography, and color with intent. Animation is in service of orienting users, communicating an idea, or guiding them towards an objective. Form is an expression of function; the drop shadow exists to communicate depth, to afford interactivity, to help a user distinguish what can be touched and what cannot, not because it looks nice, or because the screen needed more "stuff" on it.
People are busy and they have things to do. Software is most often a means to an end, not an end itself. Quality software understands this and respects a person's time and attention.
Quality software exists in the service of a human outcome, like saving time, earning money, or increasing productivity. These outcomes are the result of designers and developers talking to real humans, watching them use the software, and determining ways to remove complexity.
Quality software is fast. Data is cached. The first paint feels instant. Interactions respond in milliseconds. It makes optimistic guesses about common paths that users follow in order to pre-fetch and pre-render. When the software can't be fastâfor example, when operating over a slow networkâit communicates the status of ongoing work to a person.
Quality software understands its own role within the operating system and device. It takes advantage of available sensors and heuristics to provide a superior experience to a person, like a phone screen waking up when reached for.
Software can also get better with use. Typeahead, predictive search, and pre-rendering content based on a user's past experiences in the app all make the software feel more personal. For example, FaceID improves over time, accounting for changes in facial orientation, characteristics, and expressions.
In addition to respecting a person's attention, quality software respects their privacy. People understand what data is being collected, how itâs being used, and how to remove it. Quality software uses the minimum amount of personally-identifiable information necessary to complete a job (if any at all) and nothing more.
Quality software considers many contexts a person may be in. Are they walking? Distracted? Hands-free? Using a keyboard or tapping? Do they have a fast internet connection, or is the network dropping?
Quality software accounts for situations like these. It provides prominent, conveniently-placed actions for single-handed users on the go. It uses clear typographical hierarchy and color to make pages scannable at a glance. It adapts itself to any input mechanism: touch, keyboard, voice, pointer, controller, or screen reader. It can queue changes locally in the event of a network loss, and it can calmly communicate the impact of a degraded network connection.
Quality software understands people and how they navigate the world. For example, it knows that some people are colorblind, so it either removes commonly-indistinguishable colors from its palette or provides opt-in overrides to the system.
If it knows that people might be using pre-paid data plans, it considers the very real user cost of sending large payloads over the network. It offers things like"data-saving modes" to give people a choice about when to spend their money.
Software exists in the context of the world with changing dynamics, tastes, and crises. Locally, it exists in the context of its brand. A person rarely encounters a piece of software in isolation; thereâs priming thatâs already occurred through advertisements, landing pages, app store screenshots, and onboarding flows. Because of this, quality software understands the expectations of its users and works to exceed those expectations. A highly polished visual experience is expected to behave in a highly polished way. A highly polished brand is expected to produce high quality software.
Quality software is built for humans. Messy, distractible, impatient, and imperfect humans. Because it understands this, quality software is forgiving. Destructive actions are presented clearly and are easily undoable. If something breaks, the software provides a clear reason that non-technical people can understand. It doesn't patronize its users or make them feel dumb. Errors are never dead ends; invalid user inputs are clearly highlighted, and failed network requests are retried.
Like mis-timed foley or a smudge on the wall, we notice quality more often by the presence of imperfections than by their absence. For this reason, it can be hard to articulate why something is high quality. We can feel it. Like the threshold test for obscenity,"I know it when I see it."
This leaves us with a question: how much should âeffort exertedâ be considered when we evaluate the quality of software? If you ate the worst slice of pizza you've ever had, would your disgust be lessened by knowing that the chef had worked oh so very hard to make it? Probably not.
Still, it's clear that quality software canât be created without hard work. Or, in the most optimistic sense, oneâs long history of hard work enables high quality to be more easily achieved in later projects. So the two are intertwined, but we don't feel that the work itself is a necessary component in determining the quality of the software itself. An A for Effort doesnât ensure an A overall.
It can be disenchanting to look at the current software landscape. It feels like we're spinning in circles, solving the same problems that we've been solving for years. Computers get better hardware, so we build more resource-hungry software, and things never actually get faster.
The world has become a tangled mess along the way. There are hundreds of screen sizes, operating systems, browsers, settings, and modes that designers and engineers must account for. It's no wonder that software doesnât feel much better today than it felt five years ago: we're stuck in a constant game of catch-up.
I predict that more startups will move away from a one-size-fits-all, must-scale-to-seven-billion-users mentality. Instead, we're seeing the proliferation of the independent creator. The person who builds software for a few thousand people, but in a way that is deeply personal and understands what's most important to their audience. More designers and developers are realizing that a healthy income and a happy life can exist with a thousand customers, not a billion.
We approached the conversation of software quality from the perspective of product design and user experience. Of course, thereâs a different framing of the topic that focuses on the quality of the written software and not the final experience.
To read more about this, Iâd recommend reading this post by Martin Fowler or this post by Jake Voytko. Quite often, quality internal software correlates to high quality user experience. We should strive for both.
A small favor
Was anything I wrote confusing, outdated, or incorrect? Please let me know! Just write a few words below and Iâll be sure to amend this post with your suggestions.
The email newsletter
Get updates about new posts, new projects, or other meaningful updates to this site delivered to your inbox. Alternatively, you can follow me on Twitter.