How to win at user happiness: tips for developers

For as long as they’ve existed, the average common or garden developer has been a complete mystery to the rest of the world

A programmer’s wife sends him to the grocery store with the instructions, “Get a loaf of bread, and if they have eggs, get a dozen.”

He comes home with a dozen loaves of bread and tells her, “They had eggs.”

Despite the jokes, in practice there’s very little difference between developers’ relationships with end users and the relationships any other web professionals have with end users. Whether it’s SEO consulting, web design, marketing, or any other role, the provider-consumer relationship is always complex. It has to be proactively managed to have a chance of being successful, so having a strategy really helps.

Your approach will vary depending on what you’re doing and who’s involved, but as a starting point, consider these three areas:

1. Expectation

While managing expectations is always an ongoing task, putting in as much groundwork as possible is vital in the early stages of a project or process for the best first impression. The tone for the rest of the project will be set whether you do anything or not, so you may as well use your power of influence at the start. Everyone should be comfortable with their roles, the tasks being completed, key milestones, timeframes, and expected results. If you’re a freelancer, this should always be agreed in writing in advance for client work.

To manage expectations within processes themselves, users should always be clear on why they’re being asked to perform a particular action (e.g. providing personal details), and what the outcome will be. The process should be as intuitive and predictable as possible, and any information required should be given beforehand rather than after (password requirements, I’m looking at you).

"It's not what the software does.
It's what the user does."
Hugh MacLeod

As much as you plan and predict, there will always be surprises. Most developers have a ‘logic/code first’ approach, and argue that something wasn’t designed to be used that way or that the user should be behaving differently. Users behave intuitively, so you need to account for their behaviour rather than simply labelling them wrong or trying to adapt them. You’re fighting a losing battle unless you code for users, not for yourself.

Get as much real-world testing from end users as you can, either in person or through video/Skype/screen sharing. It’s also vital to have heat mapping data and established goals and funnelling analytics available to evaluate common behaviours and unexpected drop offs. This should continue to improve over time as you test changes and implement changes with increasing amounts of data.

2. Education

Once you’ve got an effective expectations strategy under your belt, the next danger area is user knowledge. With processes, if you’re tracking end user behaviour for processes and making changes based on that, you should be good to go. However, it’s a very different story for projects as you’re more likely to be explaining how features work to specific individuals – databases, CMSs, and so on.

In this situation, there are three types of users: the ones who nod and smile, the ones who carefully write everything down, and the ones who ask questions. The questioners also come in two flavours – people who ask questions about things they don’t understand, and people who use questions to frame complaints about why something doesn’t behave in the way they expect.

What you get at this point can be strongly influenced by expectation management, although existing user knowledge and personality are also important factors. Regardless, preparation is key for good explanations. This is especially true if the project is big or complex, because if you’re trying to find particular functionality because you can’t remember where it is or how you did something, the learning process is going to be tedious for the user, not to mention confusing.

The real key to user happiness here is to understand as much as possible about how the person works and what tools they use. Most developers tend to simplify it down to a purpose, for example ‘blog’ or ‘booking system’, whereas knowing as much as possible about what features are needed at every level, no matter how minute, and how the user expects things to look and work is vital. You also need to accurately assess the users’ understanding to provide explanations that are neither condescending nor overly complex. You can gauge your success at this by paying attention to how many of your explanations are responded to with another question.

For example, if you’re building a blog, what header images will the author be using – i.e. what size limit and file types will you need to make available? Do they need a blog commenting system, and if so, does it need to be native, Facebook, Disqus, or something else? How capable are the users – what access to code do they need and what, if any, markup will they be writing? There are a million questions that need to be considered as each end user has their own style and preferences which need to be balanced with technical practicalities and compromises to please all.

Therefore ‘Education’ doesn’t just cover the user’s education, but yours too. If possible, spend time with the user to see how they work, and take a look at any existing assets to get the minute details right. As well as impressing the user, you’re also drastically cutting back on the changes and snags you’ll need to make later on. You can never ask too many questions at this point.

3. Evaluation

Again, this element should happen from two perspectives: yours and the end users’. The average developer tests functionality to make sure it works and marks it done. The best developers complete the process with real details in the live environment – even if this means writing a page for the website to match the company’s style, or placing a genuine order. It shows attention to detail and saves time in the long run. It also makes it easier to discover bugs and process flaws yourself rather than relying on end users to do it for you. And, of course, it reduces the frustration experienced by the user.

What are your top tips for developing user happiness? And how do you stay sane in the process? Tell us on Twitter.

‍