Stop Making Zombies: Explaining User Requirements
Here is the scenario: You are a UX designer or researcher and have a new product on which
to work. During the kickoff meeting with the product owner and technical lead, they begin to list the technical and business requirements.
"Do we know the user requirements, or do those need to be explored and gathered?" You ask.
"We don't have user requirements, but we know what we need to do for MVP," someone says.
If you are like most designers, alarm bells begin to ring and your eye begins to twitch. How can we know what our minimal viable product should be if we don't know what users want?
In design thinking, three types of requirements--business, user and technical--create the basis for a holistic product. Tim Brown, CEO of IDEO, summed it up perfectly when he said "Design thinking is a human-centered approach to innovation that draw from the designer's toolkit to integrate the needs of the people, the possibilities of technology, and the requirements for business success."
All three -- needs of the people, possibilities of technology and business success -- are what safeguard products against becoming obsolete.
Good product management is the intersection between the three, creating a product that is useful, feasible and valuable. When only business or technical requirements are gathered, which is often the case for enterprise software, designers can often find themselves struggling to design for scale.
In these cases, I often use the following analogy: Products without user requirements are like zombies. How so?
1. They annoy people
Bad products behave much like zombies - they destroy, decay and ultimately ruin your day if you must interact with them. Interaction is usually forced, not something a user would willingly subject themselves to unless required. Think of the last time you willingly spent spare time browsing through the features of your corporate software because you wanted to, not because your job required you to.
Unfortunately, because most enterprise software is developed to cram every possible robust feature into scalability, user needs are rarely a KPI which drive development, resulting in annoyed employees creating mental models to work around poor usability.
2. They are dangerous in large groups
If watching The Walking Dead has taught us anything, it's that one or two zombies are easy to handle, but when they become a mob - run. The same is true for products built without user requirements driving the experience.
One or two poor experiences in your product portfolio are easy to handle, but if your entire environment is full of lumbering, awkward encounters, bad data structures and patched-together workarounds, the cost in productivity soars.
Adding to this landscape is the model of sunken cost - the investment spent by corporations to secure the software most capable of handling the scale and requirements of the business and bring it into the environment. Once procured, the investment is doubled through time invested in training employees how to use the tool, thereby solidifying the 'need' to use the tool, regardless of usability. Dealing with one or two zombie products? No problem. When faced with a hoard of bad usability and inefficiency, however, users tend to run.
3. They cannibalize other products
Poor user experience design creates a competition among existing products in an enterprise environment, one driven to be most relevant and efficient, without thought to being the most used or effective. Features from other platforms are 'consumed' or integrated by force in an effort (more often than not) to make up for the fact that features are not driven by users.
When user feedback and behavior is a constant source of measurement, ideas for features are driven by users, not by recreating what already exists from other platforms.
4. They wreak havoc on productivity
In most zombie tales, encounters with the undead make for an unproductive day. Usually, characters are just trying to go about their day when, suddenly, a single encounter forces detours. This is the same with poorly designed products, especially those in enterprises, where users cannot easily escape to use an alternative.
In his paper "Complexity of Mental Models in Enterprise User Experience Design" author Vineeth Nair touches on the dichotomy of enterprise software design and user productivity, showing that the relationship between the two is often one that is forced.
"Enterprise products are designed to tackle niche business problems, used to accomplish definitive tasks, and, unfortunately, most often, forced on end users whether they like it or not," Nair writes.
"Enterprise products are designed to tackle niche business problems, used to accomplish definitive tasks, and, unfortunately most often, forced on end users whether they like it or not." - Vineeth Nair
Were enterprises to truly calculate time wasted by employees through forced workarounds in poorly designed software with the same rigor as tracking cost, the casual acceptance of poor user experience would come into question.
5. Zombies are not heroes
Finally, zombies are rarely the heroes. In fact, most plots involving the undead revolve around curing them, killing them or finding safety. When it comes to products, users rarely jump for joy when encountering frustrating experiences and designs clearly intended to solve only technical and business needs.
Building a good product is hard. The disciplined excellence needed in engineering, design and product management cannot be substituted. I've used this analogy as a quick and light hearted way to introduce the concept of UX requirements during team meetings or quarterly town halls. While it by no means dives into the complexity of user experience as a discipline, if you only have five minutes to talk about UX, using zombies is a good way to capture people's attention.