How the values can change your product story?

Agnieszka Zygmunt at UXDX Community: UX writing, UX in Construction and Product Values. Video: https://youtu.be/FE1AsvjMwM8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Values at the center of UX work

[00:00:00] Agnieszka: Hi everyone. My name is Agnieszka Zygmunt, and I'm the lead UX researcher at 10Clouds. On one hand, I'm taking care of everything related to research, so when we are talking about discovery and UX research, but I'm also working on strategy and service design. I'm not only looking for insights; I'm also creating services with my team. On the other hand, I'm leading the team of UX experts.

[00:00:26] If we go deeper into all of the fields I'm working in, we can find out that UX as a topic is a really broad topic. We have UX strategy, we have discovery, we have accessibility, we have usability testing, UX research, service definition, audits, and all the other different things. And there's one thing in the middle of all the services: values.

[00:01:00] That's something that I wanted to talk to you about more today. I hope that we all know the definition of values; we know what a value is. When we are thinking about values in the context of creating a product, for example, we are thinking that we have user values, and we have buyer values, because the user is not always the buyer. We can have unique value, like from the unique value proposition canvas, when we are looking for something unique to attract users, to be better than competitors. And we also have creator values, or the values of the company that we are working for, because as a creator, as a designer, as a person who's working on creating something, we also have an impact on the product. Of course, there are all the other different types of values that also have an impact on the product, like market values, community values, cultural values, and even family values.

Values on the outer orbit

[00:02:10] We all know that we have values. But if we look at the process of creating the product, we can find out that, if we compare the product to a planet, this planet has different orbits. The closest orbit to the planet is something that we are taking care of the most. We are focusing on features, we are focusing on bugs that we want to fix, we are focusing on the big backlog for development or for design, or the new features we want to add.

[00:02:47] But values are, in most cases, somewhere behind, like the last orbit of this planet. We know that this kind of information exists, but to be honest, we don't know exactly how we should use it to build the product. Sometimes we use it only in communication, for example on the website. Sometimes we use it in the strategy. But when we are talking exactly about building a product, about the design process, for example, we don't know how we should use the values.

Promise, fulfillment and value

[00:03:26] To answer this question, we need to go back to the basics. To understand values, we need to talk about promises and fulfilling those promises. When we are thinking about values, we have a really simple process. We have the promise, something at the beginning. Then we have fulfillment of this promise, to deliver the value. The value is always at the end. We need to have the promise at the beginning, then we have fulfillment, which is the solution, to give the value to the user at the end.

[00:04:06] To explain this process, it's really simple. For example, we can think about a milkshake. We can have the promise that it will be the best milkshake ever, the best milkshake you've ever had, and you'll be thinking about it all the time. You're going through the process of fulfillment: you are going to the shop, you are checking the menu, you are choosing the milkshake you want to have, you're making the order. If everything was correct, at the end you have the value of the best milkshake you've ever had. Maybe it will be a value connected with being happy, or something similar.

[00:04:49] Of course, it can be compared to any other process. For example, today, probably the promise for this whole event was that you will learn something new. That is the promise. Then we have the fulfillment: it's all about the preparation, about seeing the people who will be speaking today, about, for example, my preparation of the presentation for you. And at the end, I hope that you will receive the value of learning something new.

[00:05:23] If we want to go even deeper into this process, we can find out that behind every stage of the process we have some details. Behind the promise, we have the needs and problems of the users. Needs and problems are building the promises. When we are thinking about fulfilling these promises, it's about the solution: the service we are building, the product, the whole context. And values are really connected with expectations. A value is like a group of different expectations, one name for different expectations. For example, the value is transparency, and an expectation is something specific related to transparency.

Why focusing only on the solution fails

[00:06:15] But when we are creating products, what I've found from my experience is that in most cases we like to focus on the solution, something that is in the middle. It's not at the beginning; it's not at the end. We are focusing on the middle. And it's okay, because in most situations the solution is the biggest part. For example, we are building something for years, so it's quite hard not to focus on it.

[00:06:47] But if we forget that it's in the middle, we forget about the promise at the beginning, and we forget about the value. If we don't have the promise, the user will probably build the promise by themselves, and maybe this promise will not be exactly what we want to share with them. If we don't have the value, even if somebody uses our solution, they will find out, okay, this solution is not for me, because this is not the value I want to have. Because we don't know what promise we want to fulfill and what value we want to give them.

[00:07:30] Also, if we are only focusing on the solution, we are forgetting a really important connection here. It's not the solution that builds the value; the promise builds the value. The promise builds the expectation. What we have at the beginning, mainly in the communication, builds what somebody is expecting at the end. Of course, the solution is what delivers the value, because if we don't have the solution, we are not able to fulfill the promise and deliver the value. But to build the expectation of the value, we need to have the promise at the beginning.

Building the promise from the value backwards

[00:08:11] So there is a question. We have the values, we have this process of promise, fulfillment and value. We know that if we want to create a solution and give the value at the end, we need to have the promise. So how do we build the promise? The best example to understand this is a matryoshka. When you want to build a matryoshka from the beginning, you need to start with the smallest element. It will be in the middle, so no one will see it. You will see the biggest part of the matryoshka, but you need to have the smallest element in the middle to be able to build and use all the pieces of the matryoshka.

[00:09:05] It's the same situation with promises. If you want to build a promise, you need to start from the end. You need to start with the value. You need to ask yourself: what values is the user expecting from us? If you have the answer to this, if, for example, you found them in the research, then you ask yourself: okay, I know about the values, what are the exact expectations related to those values, to go into more detail? After these two steps, you are able to answer: okay, I know the values, I know the expectations, so what should I promise them?

[00:09:44] It's also really simple. Like the process of promise, fulfillment, value, here we have value, expectation, promise. But believe me, it can change how you're thinking about the process. Mainly, when we are thinking about adding values and promises and everything related to this part of UX, we think it will take a lot of time, or, for example, that after a few months of research we'll find out that we need to build a whole new service or a whole new product. But to be honest, by using these two things, promise, fulfillment, value, and value, expectation, promise, you can find out that sometimes you don't need big changes. It helps you understand the user better, and understand what exactly you need to change in the design, but also in the communication, to fulfill the promise and give the value.

Case study: the black value hole

[00:10:42] Let me tell you a story from my experience. A few years ago, I was working for a client that wanted to redesign their training service. It was one of the biggest projects. They knew that there was a problem with the target group, but no one knew what the cause of the problem was. No one. We started with user research. We had a lot of interviews, surveys, focus groups, a lot of workshops. Everything was in place in terms of the process.

[00:11:22] After we mapped everything, all the needs, the problems, the whole journey, the whole service blueprint, we found out that we had a lot of information. We were saying that we had problems, but we still didn't know what was causing them. To be honest, we were stressing out, because we didn't have a lot of time to make another round of research. And we had everything that we could find out from the interviews. There was a piece of the puzzle that was missing.

[00:11:58] Then we decided, okay, maybe we need to take a step back. We decided to add two additional points to the customer journey map. Instead of only focusing on stages, actions, problems and emotions, we decided: what if we map promises, so what we are promising to the users, and what if we map values? Not only the values that the user is expecting, but also the values that we have in the company.

[00:12:31] It was a game changer for us, like a jackpot. We found out that we had a few points in the whole journey where we had really big promises, and nothing in terms of the values we were delivering. We called this the black value hole. To be honest, it was the best name. And we decided: if we are saying that something is missing, what if we try to fill it with small actions? Not changing the whole service, but, for example, we added an additional email, we made some small automation, we added a phone call to the client during the process.

[00:13:16] After a few weeks of this experiment, testing the small changes, because it was really easy to add these points to the customer journey and to the process, we found out that most of the problems were gone. We didn't even think that such small changes in the process could solve the biggest problem, because we were starting to deliver the value to the users. Instead of losing a lot of money building a whole new service, it was only a few percent of the whole budget to introduce the small changes to the current service. And it's still working really well, because they're still working on values and checking whether they are delivering the values and good promises. In this case, it was about checking where we had holes in the values and filling those holes.

Same solution, different promises

[00:14:21] In another case, you can imagine that you have a product, and I know it's just an example, but in this example your product is the sun. You can tell one person that it will support your health, because being in the sun helps with vitamins and it's better for your bones. When talking to another person, you can tell them that it supports producing energy for you. Maybe for another, that it will make you happier, because for this person happiness is the value they're expecting.

[00:14:56] We had a similar approach for the last product we were working on at 10Clouds, a virtual branch. This is a product for banking services, where you have the opportunity to have a video conference with an advisor. What we found out was that we had a lot of users: we had banks, we had banks' clients, we had different types of advisors. Because we had lots of users, we had lots of different needs and problems. And what we found out was that, even with different needs and different problems, we could solve them with the same feature. What we needed to change was the promise that we were giving at the beginning.

[00:15:46] Because we knew what the value was, what the solution was, and what the promise was, instead of building, for example, new features or a new solution for another target group, we decided, since it was working really well, that we would only change the promises and offer the same product with a different promise at the beginning, because we knew that this solution would also deliver the values.

Values in the design process

[00:16:16] But this is about communication. What if we are thinking about values as part of the design process? Because values are not only about communication. You can check, for example, Google Calendar. When we are thinking about values, we need to remember that they are in everything in the product. It's communication, it's how we approach and build the processes, how we build the user flow, how we design something. For example, if somebody is looking for privacy, it's not only about telling them that you are private. First, it's a solution that supports privacy. It's also about small features. For example, in Google Calendar, if you're creating an event, you can make the event private, so you see it in your calendar but nobody else sees it.

[00:17:17] If somebody is looking for transparency, you can think about how you should build, for example, the pricing plan, and the way you want to design and show the comparison between the plans. If somebody is looking for transparency, you probably need to add more information, not only the prices, but more information about everything, to give a better overview of the different plans.

[00:17:48] If somebody is looking for values related to community, and, for example, you are not able to build a whole community because it's a lot of work, maybe you can design something like an FAQ or a knowledge base that will give the feeling, give the value, of community even if you don't have the community. The direction you choose in the design is really important, because designs can also be affected by the values, and how you design something is a part of the solution that delivers the values.

How to find the values

[00:18:30] Okay, I'm talking about values, and I'm talking about examples of how they helped me with projects. But to use the values, we need to have the values. The next question is: how do you find the values if you want to use them? Of course, because I'm a UX researcher, the first thing is to look for them in the research. I'm not talking about any specific approach in terms of tools or methods. You can use interviews, you can use surveys, anything that works for you and for the project. But it's about what you are looking for. If you ask the user directly what values they are expecting, it will probably be really hard for them to answer. Values are really difficult to explain sometimes.

[00:19:31] But if you look for feelings, if you look for emotions, if you look for expectations, and then compare this with all the other insights about problems, needs, actions and the context, it will help you understand what values you need to deliver at a specific point or stage of the process.

[00:19:59] If you are not able to do the whole research, you can establish this with stakeholders. We do a really simple task with our clients that works really, really well, with three steps. First, we talk about the users: who the user is, their problems, needs, motivations and sometimes goals. Once we have this base that explains the user, we ask: okay, we have the user, we know what they want, can you explain to us what their values and expectations are? So we map the values and expectations. At the end, once we have the users and we have the expectations, we ask about the promises: what should we promise them? If you are looking at the problems and needs, and at the expectations, what do you think we should promise them?

[00:20:58] It also works really well when we are talking about solutions that already exist. For example, in the last workshop with a client, we did this exercise. We established the users, we established the problems, then we established the expectations and the values. Then we asked them: okay, you know what they expect from you. Can you please tell us what you are promising them right now? Not what you want to promise them, but what you are promising them right now.

[00:21:29] What was really exciting for us was that the client saw that, when we were talking about user expectations, they were talking about partnership, about security, about transparency. But when we started talking about what they were promising right now, it was all about financial expectations. That was the point when everything became clear: the user is expecting something related to partnership, for example, and we are promising them something related to financial expectations. That was the point when we told them: okay, we probably need to take a step back and just change the promises, because as you can see, what you promise doesn't match what they expect. That is the reason why it's not working.

Mapping values with checklists and priorities

[00:22:24] If you have the values, because you found them in the research or established them with the stakeholders, you just need to map them. Please use a customer journey map, or a checklist. A checklist is really simple, but to be honest, in my opinion it's one of the most powerful tools to use when designing something or creating a service. Because it's not that you have one value for the whole product. You create a checklist of the values that you need to deliver in every stage.

[00:23:03] In the first stage, for example, if you are buying a ticket for something, you need to have transparency, and you need to have security because you will be paying for something. But in another stage, when you are at the concert or at the conference, you have other values that you are expecting, for example having fun, or meeting new people, or learning something. Having different checklists for every stage of the process helps you check whether you have everything. Okay, I have security, I have control in the communication, I don't have transparency. So how can I add transparency to the product, to the process? Maybe it will be in the copy, maybe it will be in another form, maybe I will need to add another feature that will give this feeling, this value. A simple checklist helps you really remember that you need to add specific values to specific parts of the product.

[00:24:10] If you have the values, if you've mapped them in the customer journey or created a checklist, please also remember about choosing priorities. Values are the same as features: you are not able to give everything at once, because it's too hard. You need to build something that will give this value; for example, you need to build a feature. When we talk about values, the simple division is into base values and unique values. We all know about unique values, and that we need to have a balance, but we don't talk about base values.

[00:24:51] It's the same as base features. If you have the base values, the user probably will not notice it. But if you don't have the base values, they will notice, because for them it's the basic, the must-have that you need to have in your solution. Always be sure that you have the base values, and also be sure that you're adding something extra as a unique value. Having only the base, you are the same as competitors. Adding something from the unique values helps you attract and reach the user, and show them that it's worth using the solution.

Summary

[00:25:32] Summing up, because I'm running out of time: when we are talking about values, please remember that values help us design for the expectations of users, not ours. It's a tool that helps us better understand what we should deliver at the end for the user, because this is the last element. It helps us remember that the solution is in the middle. It's not at the beginning; it's not at the end. It helps fulfill the promise, to deliver the value for the users.

[00:26:09] And if you have values, please stop just saying that you have values. Please stop only putting them on your website, for example, or in the content. Start using them as a tool, because it's really simple. You can just create a checklist and check whether you have everything. You can use the values to help you build better features, a better product, better processes. And as I was saying in the first example from my experience with the client, it also helps you avoid the situation where you have problems but don't know what's causing them, because you were never thinking about whether you are delivering the promise that you are giving to the user.

[00:27:03] Thank you very much. It was really nice to share something with you, and of course if you have any questions I will be really happy to answer them.

Q&A

[00:27:12] Host: Great, thank you very much. That was a really great deep-dive insight into the difference between values and promises. What I took away from it was that a lot of it is really marketing, is how I see it, and the collaboration that often doesn't happen enough between the people building the products and the people marketing them.

[00:27:35] Agnieszka: I agree 100%. My experience is really related to marketing. I was an industrial designer at the beginning, then I changed, because I was focusing mainly on research, but I was also working with marketing strategists and business strategists. I really believe we need to have this holistic overview. We have our specializations, but we need to remember that everything has an impact on everything. The product has an impact on marketing, and marketing has an impact on the product. We need to work as a team and understand what connects us, instead of only thinking about building the product, or building the strategy, or just executing the strategy.

[00:28:21] Host: Exactly. I'm all for cross-functional collaboration. I have a question, but if anybody does have any questions out there, please do post them in the chat box on the right-hand side of the screen.

[00:28:35] I want to jump in with the values. When you were elaborating on some of those, I was thinking of what other people have called non-functional requirements: is it secure, is it stable, the "-ilities," accessibility, those kinds of things. Is that what you're referring to with values, or can you give me some more tangible examples if it's something slightly different?

[00:29:06] Agnieszka: I don't know if I'll answer correctly, because I had a problem hearing you for a second. I know we have a problem with my connection. But when we talk about values, I never divide them between something related to the technical side and something non-technical, because it's on our side to decide how we want to deliver the value: whether we deliver it in a technical way, for example by building a feature, or through communication. Sometimes maybe it will be both.

[00:29:44] As I was showing in the examples, transparency is not only about communication; it's also about how we build something. Security will be about the technical part of the solution. For example, if we have video conferences, we can choose different ways of transferring the video: one will be more secure, one will be less. But it will also be about how we design the whole experience, and how we communicate the whole experience and its security. It's still connected. We have the values, and then we need to decide what we want to do and what the best path is to deliver them, technical or non-technical.

[00:30:29] Host: Excellent. I had one other question, but I might actually post it on the Slack group. I love the explanation, but for me personally, maybe I'm just a little bit slower at picking these things up, I would love a bit more of an example: here's some process, or values, or, sorry, what is it, the values, the promises and the... I'm getting confused now. I'll write the question in the Slack group, and it'd be great if you could give an example: here's what you were working on, these were the user needs, these were the values and these were the promises, so that people can have a more tangible example of what was working.

[00:31:15] Agnieszka: Yes, I will, because I knew it was only 25 minutes, so for me it's hard to cover everything. Especially since I love to talk a lot, and I want to share as much as possible. Values are a really deep topic if you want to talk about them, so I'll be happy to share more on Slack.

[00:31:40] Host: Great. And we have some feedback from Brenda, who said, "Thank you, Agnieszka, that was a valuable speech. I definitely took notes from it." So you've got some admirers right there. Thank you very much for sharing your case with us.

[00:31:55] Agnieszka: Thank you very much.