Turning user needs into measurable values

To get the “why” right in the research phase of your product you first need to understand the needs of your users and objectify them into user values. Value Driven design gives you handles to not only objectify, but also to quantify requirements and needs. These can then be easily assessed, without too much interpretation. Here’s how.

Getting to the “why”

Most producers of digital products have a solid handle on their business and development stakeholders and know when it’s good enough for them. Users, though, are a different lot altogether. How, then, can you tell when your product is good enough for them?

To make a product successful, it’s not enough to objectify features, i.e., the “what”. A product can only be successful if it satisfies the “why”; Why are my users using my product? And why are they using mine and not my competitor’s?

Value

Value is a strange thing. People often think that they know why a product is valuable to them. But when you ask them why, the answers from producers, customers and users are usually vague. Which is odd, because quite a few decisions are based on the value that product has for them.

Producers may be targeting “more sales”, but what kind of sales specifically?

Customers may be targeting more efficiency for their employees. But how exactly should the product improve the efficiency? 

Users sometimes don’t have a choice, because their employer tells them to use a product. Increasingly, though, users are involved in the buying process. And, in the end, if a product fails to deliver for users, it isn’t valuable to them, and they won’t use it (or else they’ll get really frustrated in the process).

Objective user values

The catch is that users have their own perceptions of measurable things. So, if a product needs to be “quick to load”, you can objectify “quick” in a measurement of time, like seconds. And you should because that’s a strong indicator. However, 2 seconds is slow for one user and fast for the other. (Of course, if 1 second is unattainable you can use effects like skeleton screens to manipulate a user’s sense of time.)

Objective user values can be very powerful as instruments to focus design and development. Load time is a great example, another one is the objective accuracy of search results in a product.

Subjective user values

Most user values are subjective, but that doesn’t mean you can’t measure them. The first step is to make the user value as clear as possible, for instance by decomposing it into more concrete facets.

For a less practical, but insightful example, have a look at Tom Gilb decompose Love.

Facets can be objective, but they can be subjective as well. The best way to quantify subjective facets is to work with “user ratings”. That’s because the only ones who can tell you if a subjective user value is met, are the users themselves.

Example

Before I dive into the example, I want to make clear that this is a fictional case. The Dutch National Police is a client of ours, but I was not in any way involved in a project. Nor do I have any knowledge of such a project, or if it even exists.

Anyway, as an example I will use a fictional mobile app for police officers. They use it to report crime. I’ll skip over any security issues by assuming that the app is used on a device created for the police specifically and that security is guaranteed.

So, this app will be used by a police officer when a shopkeeper reports a theft; it will be used when a police officer reports a traffic violation, etcetera. The user is the police officer, not the victim of a crime.

In the research phase of this project, you and your team find out that a major user need for this app is that it should be Dependable.

Dependable can be a very broad term, so let’s peel it off and find some value facets:

• Operational at all times (objective)
• Accurate output (objective)
• Complete output (objective)
• The output is securely filed (objective)
• Easy to use (subjective)

In this specific case, “Easy to use” relates to being confident about using the app. You are not competing with a different product, you just don’t want to be stuck with uncertainties after filing the report. “Did I do this correctly?” You will want to “send and forget”.

Now, the facets that cover Output are easily objectified and quantified if you take a look at why they are needs in the first place: the reports are used in the subsequent process. If they are not accurate or complete, whoever is working on that process will have to get back to the officer that filed the report for more information.

Possible user value

User value: Monthly requests for additional information
IST: 10
SOLL: 2

Of course, in your design you were already looking at the information that the next person in the process needs. But this value might make you dig deeper into what caused such requests before. And of course, it will give everyone in the project insight into what to strive for.

Let’s have a look at the subjective user value, “Easy to use”. While this will be different in every context, for this example we have a very clear “why” that we can check with user ratings.

“How confident are you that you fill out your reports correctly?”

From functional to FUNctional

I started this blog with Google Maps versus Apple Maps and Spotify versus YouTube Premium. And then I used a very functional example. Obviously, consumer products can be very functional as well, but there can also be a fun-factor and an aesthetic factor in there.

These, though, are highly subjective values for which you need user ratings.

And next

I hope I’ve been able to show you some benefits of turning user needs into user values that can be quantified. Was it useful? Just check out a user need you identified in your project. Can you objectify and quantify it? Would that help with finding design solutions? And with talking with your stakeholders?

If thinking in terms of value related to design intrigues you, you could always check out An Introduction to Value Driven Design.