“The only thing that matters in software is the experience of the user.” – Ryan Dahl (Node.js)
This post is part of my sporadic Notes to a Young Software Engineer series.
At 17, I got my first internship at a software startup building “you might also like” recommendations for e-commerce websites. It would be my first opportunity to learn that the user— and not I, the software developer—was king.
In one planning meeting, I (forcefully) advocated for placing the recommendations right next to the buy button. For me, it was the most impactful place to put them given my own behavior. And I pushed to use data from the recent past, rather than digging into historic data. Recent data, I argued was most predictive—but secretly I didn’t want to clean up the messy, older data. And of course, I wanted to pick that buzzy new language, rather than dealing with our client’s stack.
With better mentors, I eventually learnt these decisions were wrong. The retailer had reams of data on where to place the recommendations for their site, and better intuition for what data actually worked. The technology stack should be chosen with the problem in mind, but also the team in charge of eventually maintaining it.
Every software engineer will encounter the same disconnect I did, choosing between what made product sense to me and what made my engineering days fun—and what our users actually valued.
Building software shares similarities to a professional athlete or a published writer: You work at the pleasure of the audience. If it’s important to build products used by others (and it is), spend time understanding your users.
If you want your product to be widely used—or to work on projects that won’t be shut down at the first sign of trouble—remember that the user is king.
The Customer is Always Right
In the 21st century, the gulf between what software engineers think software users value, and what those users actually value, is vast. Much of the world touches software in the 21st century, while only a select few build for them.
On Hacker News, software engineers dismiss products like the Amazon Echo1 or Spotify or Facebook, while these product continue their torrid growth. If the Echo had been marketed exclusively to developers, it would have failed.
Hanging out in software engineering communities has its own issues: the debates focus on what makes a developer’s day fun, not what users value.
Spending significant time in these communities is akin to joining a vintage automobile group: The features extolled (performance, styling) are widely different from what most car drivers in the world actually value (cost-effective, reliable, ease of use). Taking this world literally would mean building exclusively Porsches and Deloreans, rather than Toyotas, and Kias, and Fords. This is where understanding that “the user is king” helps.
It is software’s version of “the customer is always right.” As a literal matter, of course the customer isn’t always right. As a practical matter, it helps to think they are if you want your software to be widely used.
Assuming your job and salary is secure, why even care what a user thinks since you have the freedom to build what you want, how you want it?
Almost every engineer I know values that others people use their software. Building with users in mind also reduces thrash, the risk that a project you’ve put your soul into is unceremoniously dumped. And, if you have deeply held beliefs about how software should behave, you’ll eventually have to ensure your users agree.
On the worst teams I’ve seen, the user was perceived as an impediment to building good software: capricious, irrational, needy, a stakeholder to be mollified, a relationship to be handled by someone else. Minimizing boring engineering work, working on favored technology, and blaming issues on “incompetent” users was all that mattered. And to be fair, users are never entirely rational.
By contrast, the best teams have empathy for their user. Decision are based on how it makes the user feel and act, even when it means more—or unexciting—engineering work. It doesn’t mean these teams mindlessly take what they hear from users. That would also be a mistake. Instead, the best teams respect their users enough to build for them, rather than despite them.
Mistakes
As an early engineer, you’ll make two classic mistakes.
First, you think the user is just like you. In some contexts—developer tools, open source software—you’re actually a pretty good proxy for the actual user. But especially today where tech is used by billions of people from all walks of life, you’re only one small group—and probably not the most important one.
Developers are a poor proxy for the typical user of technology. We value power of the CLI over the relative simplicity of the GUI. We want privacy and security and performance. Most users, by comparison, want usability and convenience, no matter the cost. (This isn’t to say you can’t have deeply held values about decentralization or privacy. But rather than selling users on these features alone, convince them by concurrently bundling the features they value)
In fact, being a “good” engineer may lead to less empathy for your user. The skills and values for programming can be at odds with the skills and values needed when deciding what users value. For this reason, startup incubators, like Y Combinator, so consistently push their (engineering) founders to talk to customers.
The second mistake is favoring what makes your job easier or benefits your career, even if it hurts the user’s experience.
Users care little about the technologies that underlie their software. As a software engineer, you may prefer performance—say by picking a new, exciting language or framework—but this comes at the cost of valuable features for the user. Or you may prefer to add a specific technology because it lets you learn a new technology valuable to your career, despite the productivity hit your team takes.
Immerse yourself in the world of your users
Whenever you build a new product, immerse yourself in the world of your users. If you haven’t interacted with some of your users, you’re doing software wrong.
It’ll be more fun to build products for a community you know and can empathize with. Developing intuition for your users will also reduce the likelihood of building features that are then discarded because your intuition was wrong.
To start, spend time observing and talking to your users. A surprising number of software engineers have never interacted with their users, especially in large companies where teams are big and specialized.
Asking even a few questions can give you insight when it’s time to prioritize or craft the next feature. If it’s possible, try to shadow your users through key tasks, as what users do, think, and feel are often even more important than what they say.
Source: Public Policy Innovators
Observe your users through your product. Look at the data of what your users do. If you advocate for a feature, ask yourself what user experiences and data support your conclusion, and then follow-up with its actual usage.
No matter who claims to speak for your user, you should still try to learn about your customer directly. Product managers come with their own dangers (speaking as a sometime product manager myself). They insulate you from the user, and the responsibility for providing user value shifts solely to them. Nothing beats personally interacting with and observing your users.
Finally, make your excitement a function of how much user value you are delivering, not simply how much you enjoy the technical work in front of you. Focusing on the user value you provide is hard, but more fulfilling in the end because you’ll end up delivering a better product.
Problems with the “user is king” philosophy
Inflexible maxims like the user is king can be daft when applied mindlessly.2
What users want and what they say they want aren’t the same thing. Henry Ford purportedly (and probably apocryphally) said, “If I had asked people what they wanted, they would have said faster horses.” Plus, figuring out how to balance user desires in the real world can quickly get complicated.
What happens if you work in devops and your customers-your company’s engineers-needs diverge from the ultimate customer? Your company’s engineers may want not a second of downtime, but this prevents you from building the platform that solves the long terms needs of your company’s customer.
What happens if your sales team clamors for certain short-term features that make the sale easier? Their desires come at the cost of long term features that transform your customers’ lives.
What happens if you build a social network that favors click bait, fake news, and sensationalism, and maximizing the time users spend in your company’s app? Based on your users actions, these features are clearly something they desire, but they are not what the users need.
Ultimately, the “user is king” is a starting point to understand your users and a method to avoid bad habits that put your desires first. It is not an incantation to be followed at any cost.
- When the Amazon Echo was announced in 2014, Hacker News erupted with concern. One commenter shared the prevailing sentiment:
> I don’t think I need to explain to HN why an always-on, internet connected voice recording device is something to keep out of your house.
There were many others where the same sentiment was expressed, including when an Echo hijacked a thermostat or when an Echo recorded a murder that police were investigating.
In the intervening years, tens of millions of Echos have been sold. ↩ - See my thoughts on tradeoffs. ↩