A Developer’s Guide to Empathy

UX. User Experience. Usability. These terms keep popping up in all the product development meetings I attend, and I’m told it’s the key to success in the world of technology design and development. Jeff Bezos (you know, the guy behind Amazon, the Washington Post, and other great hits) seemed to agree when he said

Above all else, align with customers. Win when they win. Win only when they win.

But as a front-end developer, I don’t need to worry about it — I work on a team with a UX designer, so they’ll have it covered. I’ll take care of the codebase, the user is their responsibility. Right?

Who is in charge of the user’s experience?

Traditionally, the web and software development cycle has been broken up into silos, with experts in charge of all the deliverables in their fields of work. Business analysts, for example, extract and document business requirements; visual designers create the visual designs for the product, and developers, well, develop the final working product. Looking at it this way, it makes sense that our UX designers would be responsible for all aspects of the user’s experience. It’s right there in the name!

Siloed teams rarely work well together (image sourced from Thomaslarock.com)

One problem with this siloed approach is that it takes the user out of the equation for everyone but the UX designer. Inevitably, situations come up where we have to deviate from the proposed design or solution — because of time, technical constraints, or otherwise. As a developer, If I’m not focused on the user’s needs, I am more likely to choose the option that keeps my code looking pretty, or the easier option to develop.

A better perspective is to understand the role each team member plays in the final product, and therefore in the user’s experience. For instance, my decisions as a front-end developer can impact the time it takes for a page to load, or how performant a given piece of functionality is, which will have an impact on the user.

Ultimately, it’s about understanding, and building empathy for, your users. If you understand the user’s needs (and care about them!), you’re more likely to try find a solution that helps the user achieve their task with less fuss. This is a win for your users, and ultimately a win for your business too!

Meeting often with users will help to build empathy within your team

How do you make your team care about users?

So obviously, if your team cares about your users you’re more likely to come out with a good user experience. Unfortunately, it can be difficult to care about someone you don’t know — especially when their needs make your job difficult! Luckily, there are a few ways to build empathy for your users, even when you’re not meeting with them daily.

Framing is everything

When we develop user-centred products, we break up tasks into user stories, but not all are created equal. Compare these two stories:

  1. As a user, I want to open a product detail modal so that I can see the details of a product
  2. As a researching customer, I want to see detailed photos of a product so that I can make an informed purchasing decision

Both aim to present the functionality from the user’s perspective, but which one tells you the most about the user’s problems, and how the solution will solve it?

It seems simple, but thinking a bit deeper about how you write your user story names will go a long way to putting your team in the user’s shoes.

Ask for context

Developers already know that more information makes for better products, but we often only ask for technical details. Some other helpful questions include:

  • What is the user hoping to achieve with this functionality?
  • How does this fit with the user’s overall journey?
  • How do we think this functionality will help the user achieve their goals?

In general, the more you know about the user’s context, the better.

Designers, the more context you provide upfront, the easier it is to build empathy into each piece of functionality, so help your team by providing answers to these questions with each design.

Meet your users (or develop personas)

Even if you’re not a UX designer or researcher, you can benefit from sitting in on a user research session. As a developer, I’ve found that participating in user testing sessions, for example, gave me a better understanding of the real user problems we were trying to solve. And if you can’t participate, a summary of the results can be super helpful too, so go ahead and ask your designers and researchers for this kind of information.

If you don’t have the time or budget to meet with real people (or even if you have already participated in a handful of user testing sessions), personas can be a great tool to help enrich your understanding of your users. They represent core aspects, demographics, needs and pain points of your users. They help to keep your team focused on your users, and can be a valuable compass when making design or development decisions.

How do I start?

If you’re currently locked into a siloed workflow, it can be hard to make changes to your team’s processes or attitudes. However if you look at the benefits to your product, your users and your business, it’s clear that it’s worth the effort. Start your next development task by getting to know your users and their needs, and soon enough these steps will become second nature.

Juan Ojeda, Front End Developer (UX Enthusiast)

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.