I contend that these trade-off decisions should not be framed as win-lose propositions, where user experience needs to win or lose, nor should they be framed as compromises, where both sides give up what they really need. Obviously, the best outcome is a creative solution that meets user needs with minimal impact to the technical infrastructure. But what if we can't find that solution? It's a difficult conversation in part because we're comparing apples to oranges. And sometimes we really do need to choose between bruised apples or rotten oranges.
I suggest that we try framing the supposedly competing interests as contributors to the same goals. We can treat them either as subsets of the overarching user experience, or as contributors to business results. By using common goals, and even common metrics as the basis of the conversation, we create the possibility of grounding the discussion with a rational and sometimes quantifiable goal--a user experience that drives results. How is this possible in the real world?
Let's take a look at some of the specific needs that can get positioned in opposition to user experience:
- technical complexity
- sales (or other business results)
This is an apples to oranges trade-off, virtually impossible to resolve rationally, and with no metrics we can use to compare the impact of the decision to both the user experience discipline and the engineering discipline.
We need to reframe this decision as all about user experience, and we need to do that while vigorously defending the importance of performance.
Why is performance important? Why does anyone care about page load times and infrastructure scalability? First and foremost, performance is important because it is a significant contributor to the user experience.
We created a key performance indicator that measures the overall user experience, and then we analyzed the impact of several variables on the user experience scores. Sure enough, performance (response time, site availability, etc.) significantly correlated with user experience. As user's impressions of performance went up, so did their satisfaction with the site, likelihood to recommend, likelihood to return, etc.
And there's one more frame that we can use to turn this trade-off discussion into a more rational dialog: Why else might we care about the impact of a change on performance? Money. Performance can cost big bucks, and if we cavalierly design products that take big bites out of the servers and networks, that costs money. And for most of us, the reason anyone pays us to pay attention to the user experience is because this has been repeatedly shown to drive positive results, which typically translates into either money saved or money earned.
With either of these new frames, we can now compare apples to apples. Which solution will have the greatest overall impact on user experience? Which will best contribute to our financial bottom line? Move the conversation away from a religious war between the UX believers and the high priests of engineering. Make it a rational apples-to-apples equation grounded in common goals.
Coming soon, the next false trade-off: user experience vs. technical complexity