Ever look at some piece of fully functioning software and thought to yourself “how did it get like this?” Sure the thing works, but who would release something that feels so broken? Whether installed on a computer or embedded into an appliance, usability often gets squeezed out of otherwise functional software. How does this happen and why do larger organizations tend to be more susceptible? While there are many factors, the one I want to address is numbers. Data is generally a good thing, so good in fact that it’s very easy to simply say “show me the numbers or shut up,” but therein lies the problem. Data is only as good as what’s being measured and not everything can be measured.

Software usability is roughly the sum of two roles: engineering and design. The former is responsible for function while the latter guides the look and feel. Engineering is more-or-less a hard skill requiring some combination of training and ability. Design, on the other hand is a soft skill. While there is plenty to learn, rules of thumb, styles, history, etc…, much of design is informed by intuition, taste and commonsense. Software engineering requires engineers, but good design can come from anyone (though not everyone is a designer.) This is not to say that designers aren’t hugely beneficial, but that many design problems are solved, at least partially, by engineers with some design sense. I would also wager that commonsense-level design is particularly high in software development simply because there is a ton of reference material. Where should the close button go? Upper-left if we’re on a Mac, upper-right if we’re in Windows. Obviously. 

Commonsense design often prevails in smaller software teams, where visibility and focus are high. But as teams grow, more resources are hired, necessary processes spring up and soon even more resources are hired to manage those processes. Once a project is big enough for upper management to lose sight of the day-to-day, various levels of middle management are needed to communicate details and ensure that development is continuing at an acceptable pace. This is when numbers put commonsense design at risk. Numbers are a manager’s best friend. They are simultaneously concrete enough to stave off doubts while at the same time malleable enough to convey a narrative. Want to look smart? Get some numbers and put them in a chart.

But numbers only capture what can be measured. Below is a list of what I have seen measured in various software companies.

• Time
• People
• Features
• Bugs

That’s a pretty good list. You’d be hard pressed to find anyone complaining after seeing a chart showing a smaller team delivering more features with fewer bugs in less time. Now here is a list of things that I haven’t seen captured:

• Userflow
• Interface performance
• UI Labels
• Issues that aren’t technically bugs  

Not only are these things that can’t easily be measured, they don’t even have clear thresholds of success even if they could. They are open ended questions with no concrete answers. Is the animation smooth enough? How should that button be labeled? Is that dialogue box too annoying? Is this feature enjoyable to use? Managers often do not have the luxury of dealing with this loose-y goose-y nonsense and who can blame them? What would you rather tell your boss, that there are empirically fewer bugs than before or that the team thinks that the “Share” button is more clearly labelled? What are the odds that the news of the button label will fall totally flat? Worse yet, what if the buttons provide fuel for some other discontent. “So your team originally screwed up the “Share” button?” or “Maybe if you’re team hadn’t been messing around with buttons, maybe they’d get to some of these features.”

Design and commonsense don’t translate well into numbers and is therefore discouraged as team members are boxed into specific measurable engineering tasks. So who does that leave to ensure that even commonsense-level design prevails? 

The obvious answer is a product design team. Let engineers be engineers and designers be designers, and they can all work together to make great software, right? As I wrote above, software in particular requires both engineering and design, but in my experience product design teams are regularly cordoned off from engineering. The rational often being that engineers won’t offer any value which is affirmed when their output is stripped of all design sense. Besides, any result from a collaborative meetings with design won’t be measurable anyhow and what manager wants to deal with that? Further more, if either the design or development team is outsourced, any communication may be strictly regulated due to hourly cost. This common disconnect leads to disjointed user experience such as nice looking, but non-functional UIs or labels that still don’t make sense because the designer never understood their purpose in the first place.

The sad reality is that many of the same software companies who have squeezed design out of engineering also never bothered to hire any designers. Instead, they ludicrously delegate the task to customers. This is never explicitly communicated lest customers start demanding a paycheck. Instead design-by-customer comes in the form of surveys, rating dialogues, feedback buttons, support forums, and so-on and so-forth. The best part is that these design-by-customer tools provide managers with… wait for it… numbers! Never mind that these numbers lack any context. Were there no complaints about the feature because it was perfectly executed or because no one discovered its existence? Who cares! The manager can now once again empirically show their bosses a narrative that their team delivered.

I have been hard on managers throughout this post, painting them as villains who willfully undercut greatness at every turn. The reality is that managing teams is hard and requires a specific set of skills and too often managers aren’t even hired for those skills, usually because they were promoted for greatness in some other position. So without any training or experience, managers are expected to deliver results or people get fired. Numbers are a necessity that also happen to be the easiest lifeline that smart managers use to protect themselves and their teams. Design and commonsense don’t go by the wayside because of managers, but because numbers often become the sole metric for communicating their teams’ success.