When it comes to experience design, “empathy” is more than just a buzzword. Designers are trained to empathize with the end user, understanding that this enables them to build better products, but should empathy end there?
Empathy for Stakeholders
I have read many articles that encourage designers to feel comfortable killing features, and in most cases I agree. Many features are superfluous, and the adage “less is more” often holds true. However, sometimes this leaves me wondering – why doesn’t the concept of empathy seem to extend to project stakeholders?
Instead of taking a hard stance on feature development and killing this or that, why not take the same approach with your stakeholder as you would with the end user? Ask questions about the project and its goals. How will we gauge the success of this feature? What do you think is frustrating about this part of the product?
The user’s experience is the gateway to the product’s features, but overlooking valuable insight from the stakeholder’s point of view can be harmful for the user and the product.
Stakeholders Versus Users
Let’s dig in a little deeper and define who and what we are talking about: users and stakeholders. Users are your customers or individuals utilizing your digital product. A stakeholder is an individual that is actively involved in a project or whose interest might be affected (positively or negatively) because of project execution or completio n.
In other words, users are the people experiencing the software or service, and stakeholders are members of the business responsible for planning and preparing the features that will be included in a product. The stakeholders’ focus is on the business and the features are the way they create value.
So this begs the question: who is more important? The answer is that it’s not really a question of one or the other. If both groups benefit from a feature-rich, intuitive solution, why can’t they coexist? Some will argue that feature offerings in a product should always be a top priority, while others believe the user experience is paramount. Neither is true, but let me explain.
The users of your application are not won over by features. They're won over by the overall product experience. But features are the solution to the problem the product addresses in the first place.
Designers are really curators of good software, services, and experiences. They must know how to curate features into an easily digestible manner to make a complex system seem like a simple solution. Jason Fried of 37Signals writes:
I don’t think the number of features is what makes software better or worse. One more or one less isn’t really the issue… What matters is the editing. Software needs an editor like a writer needs an editor or a museum needs a curator. Someone with a critical eye and the ability to say “No, that doesn’t belong,” or “There’s a better way to say this.”
When designers begin thinking like curators, they are no longer choosing between the needs of the user and the objectives of the stakeholder. They are building something that is greater than the sum of its parts.
Designers must know how to curate features to make a complex system seem like a simple s olution.
Features Versus Experience
I’ve participated in many meetings where product management, developers, and stakeholders were trying to add value to the application by adding additional features. It’s a knee-jerk reaction and an understandable one.
The typical response is, “Let’s squeeze this into the next sprint and get it out to the users.” The problem is that the next thought is often, “We can circle back to UX in the next release cycle.”
Adding new features for the sake of adding new features does not automatically make it a valuable addition to the product. If you have an app that has a robust amount of functionality, that’s great! However, simply dumping features into an app without careful forethought does not provide value, which stakeholders sometimes don’t realize or lose sight of during the development process. What’s most important is organizing those features so the user intuitively understands how to access them and use them. We call this “the experience.”
You can have all of the features in the world, but they’re not useful if the user doesn’t understand what they do or how to access them.
Whether your application displays data analytics for your business or shows you the closest gas station with the lowest price on the road, the user’s experience can make or break the success of the project. You can have the most important and useful data at your fingertips, but as a user, if you don’t know how to access or interact with it, it’s meaningless.
There is always a desire to add functionality to cover multiple edge cases or to make sure products are “complete.” But here’s the thing: you won’t cover every use case. Likewise, products are never actually completed.
So before adding a new feature because someone ha s made a request, take a beat and ask these questions: What problems will it solve? Why do users need it? What drives users to actions? Finding out answers to these questions, through prioritizing features, prototyping and testing, will lead to better results, better engagement, and ultimately, a better experience.
Designing for Balance
Knowledge about real-world user experience empowers us to make the right decisions for building successful digital products and services that users crave. Often this comes from data, but stakeholders do have valuable insight into their customers’ needs.
The designer’s job is not to ignore the stakeholder’s perspective or cater to every request; it is to filter out the most essential functionality to curate a seamless experience. By employing empathy for the user and stakeholder, the design process helps create stronger, more successful products.
If you want to learn more about empathy and other design thinking essentials, consider “How Design Thinking Can Transform Dying Organizations,” a new whitepaper from Matt McBride, SoftServe’s vice president of global experience design.