User Complexity Scoring: A Metric To Help Non-Product/UX People Gain User Empathy
One of the most frustrating elements of working in a team with multiple stakeholders who have various priorities (ie sales, marketing, finance, engineering, etc) is that it’s easy to lose sight of what drives a digital business forward. Most industries in 2020 are extremely competitive and the days where you can skate by with a crappy product and good marketing are behind us. The next generation of digital marketing is going to be driven more by great product experiences and organic growth than by paid media. But that is more of a supporting observation than the core point of this article.
If we assume that more than ever, digital companies live or die by the quality of their user experience, then it follows that it’s very important for every member involved in the product development and strategy conversations to have a high level of user empathy and be constantly thinking about user experience whether they are modeling business growth in a spreadsheet, brainstorming about brand positioning, etc.
Many modern product and engineering teams use some variation of scrum and agile development, write user stories and do a reasonably good job understanding the cost (time to develop) and benefit (user benefits) of each feature that they are considering developing and in what priority.
The problems occur when people outside of this small group of stakeholders (product managers, designers and engineers) are pressuring the team to build new features. These groups, whether its executives, sales people, marketers, etc may believe that some new feature or functionality is really valuable to users. Sometimes that might be true, but in many cases it is more true in their imagination (where they have the luxury of ignoring all of the small details and hurdles to getting someone to actually use a feature or functionality, etc).
I’ve found that a very helpful framework for teams to implement when dealing with these challenges is to add a metric to the traditional cost/benefit analysis that I call “User Complexity Score”. If you add this concept, then you have 3 variables by which to evaluate feature prioritization (engineering complexity, user value and user experience complexity). There are many product feature ideas that may be valuable in a vacuum, but the complexity of using them can be so prohibitive that it doesn’t make sense to build them (or make them a high priority) no matter how enamored a particular stakeholder with significant internal influence is with their idea.
By forcing anyone who makes a product suggestion to provide a “User Complexity Score” when describing it, it demands that they imagine themselves stepping through the required user steps to actually benefit from the feature they have in mind. In many cases, this makes prioritization discussions more effective because it ensures that user experience is always a central theme. It also forces people to think about user behavior in more detail before blurting out an idea (especially useful for members of a team who aren’t in the habit of thinking this way).
Even within product teams, this provides a very helpful dimension for prioritization. In theory, this attribute could be implicit within a “user benefit” scoring system, but by making it explicit, we ensure user experience is always top of mind.
Hopefully this will help prevent some headaches when trying to explain to colleagues that rocket ships are good for going to Mars but not always in consumer or B2B applications.