4

How to explain your design when your manager only cares about metrics

 1 year ago
source link: https://uxdesign.cc/how-to-explain-your-design-when-your-manager-only-cares-about-metrics-b092fec3c988
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

How to explain your design when your manager only cares about metrics

How to think about design when your manager seems to only care about the numbers

Two sets of hands going over a report. One is pointing at a graph and wearing a business suit, while the other set of hands is reading over the rest of the report.

Photo by Pixabay: https://www.pexels.com/photo/business-charts-data-document-259006/

I recently did my performance review, which got me thinking about "Bill," a metrics-obsessed manager I once worked with.

When you work on design projects, you encounter many different types of team members, some of which are trickier to deal with than others. Bill was initially tricky to deal with because I was still somewhat new to UX and had yet to learn much about metrics.

He'd discuss project goals and metrics in meetings to keep us focused. He'd also shut down my design ideas, using KPIs and metrics to explain. Every action was taken in pursuit of better benchmarks.

It took me a while (and a lot of struggle) to figure out how to work with him, but I was eventually able to do so after learning a little bit about his neck of the woods: metrics. Here's what I discovered.

Surrogation, or the problem of the bird's-eye view

First of all, if you encounter this sort of person, you're not alone.

In her book Just Enough Research, Erica Hall mentions that the most frequent question she gets is, "How do I convince managers to pay attention to qualitative research when all they care about are numbers?"

This phenomenon is often common enough that there's a name for it: surrogation. Surrogation is the tendency of managers to substitute metrics for meaning. And it's much more dangerous than you realize.

Metrics and KPIs provide a bird's-eye view of a product, and a product's performance is often condensed into metrics on a dashboard. It's quantitative research for business people that's usually assembled from the analytics of thousands of users. But there are several problems with this.

First, this bird's-eye view aggregates a ton of data, so you lose much of the nuance. For example, users spending an average of 3 minutes on a page sounds okay, but if half your users spend 1 second and the others spend 6 minutes, you won't see that detail (which might suggest something needs to be fixed).

Not only that, this approach reduces users to a single metric. It undoes a lot of UX designers' work, creating personas and storyboards to put a name and face to the faceless user.

But most importantly, this approach is dangerous because it doesn't ask the most critical question: "Why." For example, metrics might tell you that users spend a lot of time on a page, but it doesn't tell you why. This is why we need Qualitative User Research (like user testing and interviews), but getting that across to managers that think this way can take time and effort.

So what exactly should you do about this?

How to deal with metrics-obsessed colleagues

Consider their viewpoint

There's a reason why people hold this sort of viewpoint, even if it seems crazy: it works (sort of). Businesses that raise their KPIs or meet their metrics tend to earn more money, make shareholders happy, and net your manager a fat holiday bonus. So from their viewpoint, they are correct to obsess over metrics (especially if their bonus depends on it).

However, that approach isn't quite right either. Often, chasing after metrics results in short-term gain at the cost of long-term user satisfaction. Unfortunately, this also usually results in a lot of technical or UX Debt to chase after performance metrics.

But understanding this viewpoint helps us understand our approach: if this is what they care about, we need to ensure that the business is aware of the impact good design decisions have on metrics.

The best UX Designs don't just result in 'qualitative' improvements (i.e., it tests better): it often moves the metrics after it's made public. This is because metrics are often the 'input' and 'output' of the project: poor metrics cause something to be re-designed and looked at, while good metrics are what the business wants at the end of the UX Design and research process.

So you need to show the way you set up your argument.

If you can, use Analytics to highlight problems in the process

Metrics often play a significant role in your being assigned a project. If a project produces poor metrics (or users are vocal about their unhappiness), the business will find the budget to re-design it. Or, if they discover a customer need for a new feature, they'll gather resources to design it.

That same logic can help highlight problems that Designers can solve. I've written a book about Designers and Analytics, so I will only go into a bit of detail. However, here are some ideas of what you can highlight if you choose to learn a bit about Analytics:

  • According to the behavioral flow map, users don't access this particular page or feature. This might be a problem with the navigation.
  • According to time spent on a page, users spend twice as long on this page compared to others.
  • According to user engagement, we're losing way more users than average when going from the 1st page to the 2nd
An analytics chart, showing that there’s a huge drop off between the first and second category

How to design with data

However, learning Analytics can be intimidating, especially when you're getting started. That's why you don't necessarily have to learn it to use this type of argument. Instead, we can use UX KPIs (like User Error Rate) and the Google HEART framework to set up similar arguments.

A summary of Google Heart framework, paired with Goals, Signals, and Metrics. Each category is defined, like the Happiness having “User Satisfaction” as a goal, “Survey ratings” as a Signal, and “Satisfaction” as a metric.

https://measuringu.com/heart-framework/

However, Analytics and metrics can be hard to grasp if you're unfamiliar with them. Using them can make your usability problems more understandable, but there are other ways.

You can also make use of a business term, forecasting.

Communicate your design solution as a method of forecasting

If you do qualitative user research (like interviews and testing), it can be challenging for your managers to understand your methods.

I've been questioned why I only test with five users, even though we know that it finds 85% of usability issues.

However, I found my answer to these issues in an unlikely place: finance. There's a term called forecasting, which is about making informed guesses about specific business metrics to predict the future.

A slide that says Forecasting, the process of using historical data to predict future events

https://www.investopedia.com/terms/f/forecasting.asp

Business people understand this because they make these predictions when rolling out products, fighting for market share, and more. So we can use that same model to get them to understand our design solutions.

Saying, "Based on our user research, we expect X problem to be a significant issue that we must resolve or face user backlash." can help to set the stage for your recommendations.

One of the fundamental differences between qualitative and quantitative research is statistical significance. You don't have enough users (when you test with five users) to say, "Changing X will result in a 15% increase in Metric Y", which is often what metrics-focused managers want.

However, the forecasting mindset accepts that there is little uncertainty in predicting the future, allowing them to process it better. In addition, modeling our design recommendations based on past user behavior is similar to making a business prediction based on historical data.

The key to this approach is to use words like 'predict' and 'expect' in your explanations to pair with your data. So, for example, rather than saying, "3 out of 5 users encountered this problem" (a fact), you might say, "we predict that a lot of users will run into this problem due to 3 out of 5 users encountering this problem." This tends to pair well with Data Visualizations or highlight videos since we use data points as the basis of our' forecasting'.

I admit it's not the usual way to explain my findings. However, learning to communicate usability issues and recommendations to specific audiences has been one of the essential skills I've had to learn to get my team on board. Whether it's metric-obsessed managers or waterfall-based developers, adapting how you explain things will significantly affect whether your ideas are accepted.

Ultimately, projects are a series of design decisions

What's important to remember is that, ultimately, we want to ensure that the right design decisions are made for a project.

As a result, you and your metrics-obsessed colleagues must come together and make the right decisions. While it might be nice to work with colleagues that understand UX, sometimes you need to reach across the aisle to relate user needs to business terms they're more familiar with.

While metric-obsessed managers might be a headache to deal with sometimes, it's essential to ensure that you can get through to them and get them on board with your design decisions.

So if you're working with someone who seems to only care about metrics, don't despair: use their understanding and mindset to get your design ideas approved.

Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK