Why do you need to know this?
I’m a UX designer in a big grocery company, and I really don’t like edits, and you already scroll further, because “it’s impossible, you are not an artist” and “nothing new, nobody likes”. I value my colleagues, customers and users. But 10 stages of coordinating layouts, where each participant speaks out about what he does not like in design, is not only difficult, but also ineffective. Instead of discussing the product, why it will be used and why not, what is important for the user and what is our own speculation, we often go into holivars and discuss our tastes and preferences. This is a normal story for large companies: there are many people interested in the product, everyone wants to do something worthy or take part.
Nielsen heuristics, user research, customer interviewing, and UX artifacts help me. I’ll tell you about artifacts. My path is more suitable for UX-eaters in food companies with a large number of stakeholders than web designers from small studios.
From 8 to 20 people participate in the work on the product: the customer (often several customer representatives), the product owner, project manager, business and system analytics, layout designer, front-end and back-end developers, testers. They all have their own views on what they are working on: they want to do something cool (different people have a different concept), project managers want to meet the project deadlines and budget, product owners want to increase all metrics at once, developers write clean code.
What is the likelihood that your vision of the product coincides with the vision of all these people? Zero
If you think that you are a designer, and the appearance of the product is only your patrimony, you are mistaken. A couple of unsuccessful projects and problems in communicating with teams and customers will bring you to your senses or help you understand that it is better to apply your skills in some other field.
At our company, the responsibility of the designer is to make sure that the team and client have agreed on the expectations. It is advisable to do this before the layouts appear. It’s already late and painful to understand how the product should look and work according to mock-ups.
Layouts are just the tip of the iceberg and part of the designer’s work. Behind them lies a lot more questions that the whole team needs to agree on.
Artifacts are a solution to the problem: with their help we discuss business goals and user experience, the designer can rely on them when defending the project as fixed agreements. Other designers and team members can work on artifacts, because mostly artifacts speak a clear, human language, and not the language of graphics, business intelligence or code. I studied artifacts in BHSD and on the blog of UX-designer Nastya Shchebrova (thanks, Nastya!) and actively apply them in my work. Their use saved me a lot of nerves and accelerated the development of many products (although it seems that it should be the other way around).
What is an artifact?
Artifact – a description of the product from a certain point of view in a given format. It helps to negotiate with all participants in the process, but the end user will not see it.
What artifacts are there?
Not all artifacts are generated by the designer: some of the artifacts are made by the product owner or other team members. All that is not a finished product is an artifact, including layouts in Fig, and TK.
A good UX-yer works with such artifacts
Not all existing artifacts can and should be applied to the project. The task is to spend as little effort as possible to clarify the picture for all project participants. With experience, you can appreciate what artifacts you need to use for a specific task. It’s cool to try everything: you will understand what you are comfortable working with, how much time and effort it takes to compile one or another artifact.
For those who have not yet encountered artifacts, I propose a scheme that I have developed for myself: I compose a character or empathy map, prescribe its scenarios, combine scenarios into scenario cards (if the product is new) or lay it out on the user’s travel map (if the product is already in use) . We draw prototypes from them, test them, prototype them again and test them until we are satisfied with the result.
Characters can be described in different ways, but as a rule they consist of:
- user portrait: age, gender, occupation, lifestyle;
- his problems, goals and expectations on the topic of our product;
- description of the environment in which it is located and its actions on the topic of our product.
Characters are made to:
- better understand users: who they are, how they think, why they do what they do – and look at the product through the prism of their interests, needs and limitations, and not their own;
- synchronize the vision of the product within the team. As long as we don’t have a single idea about the people for whom we make the product, we make decisions through the prism of our cognitive distortions. “If it’s convenient for me, then it’s so convenient for everyone,” cannot serve as an argument in commercial development, unless you are making a product for the same designers or developers;
- All team members, including those who don’t communicate with users, remembered who they were making the product for;
- while you draw a character, you understand on which sample of people you will need to test your UX solutions.
A character for a banking service that helps compare VMIs and sell them.
How to create a character:
- Collect hypotheses. Do not rely solely on yourself or the customer in this matter. Get together with the team and the customer and throw the main hypotheses about who we are making the product for. It will take about an hour.
- Test your hypotheses. Find those who are similar to your character (among friends or on Facebook, for example). Conduct a research interview: your hypotheses will be confirmed (or not). The sample for such an interview is 4-7 people. On this lay from 4 hours to 2 days.
- Complete the character and “sell” it to the team. Collect all the insights and complete your characters. There can be several characters if they differ greatly in their desires, goals, and functions. Do not write the character in too much detail: you need to understand his lifestyle, desires and goals. Do not breed too many characters on the product, because you are likely to get confused. I highly recommend printing the characters and hanging them in the office: this way the whole team will think more often about the people for whose sake it works and show more empathy for them. Most likely you can handle it in 2-3 hours.
How long does it take
If you manage to quickly collect respondents and conduct an interview with them, then this will take 1-2 working days of the designer.
There are projects that are aimed at a very wide audience. Then they either have too many characters, or they are difficult to distinguish. For such projects, it is better to use a card of empathy or jobs, bi-dan (I will tell you more about how they differ).
The character method works well when you work with a clear audience and market. But when you need to come up with an advanced product, open up new markets and do things that you have not done before, the character method will lead you to create faster horses instead of a car.
If you do not test the characters and your other hypotheses, you run the risk of miscalculating very much. Remember that any unverified hypothesis is just a figment of your imagination.
“Men and women from 16 to 65 with high incomes who definitely need our product” are not a character, this is a copy-paste of a bad marketer.
Jobs Tu Bi Dan
It is impossible to build products of the future, focusing only on the requests and expectations of users from an existing product. Good metrics and sales are just the current state of the market. What numbers did Apple look at when removing keyboard buttons from their phones? What did Henry Ford rely on when he wanted to make a car at a time when everyone around asked for fast horses? People loved horses and push-button telephones, but nobody needs them anymore. To look for breakthrough solutions, you can use the Jobs Tu Bai Dan.
What is Jobs Tu Bi Dan
Jobs and bi-dan do not think about users and their desires, do not conduct retrospective studies. This is a test of the business hypothesis: now this is not, we are creating a new market. The product that you create solves the problem of the user – “does the job.” Users buy, that is, “hire” your product so that it makes their life a little happier. Conditional Ivan Vasilievich does not buy a phone with buttons, but the ability to be in touch with loved ones, if you dig a little deeper – then with the whole outside world.
Why do we need jobs bi-dan:
- Correctly identify competitors. In real life, users rarely choose between where to eat: at McDonald’s or at Kiefsee. In real life, the user chooses to cook at home, order products with a recipe in a service such as Yandex.Shev, come to dinner with friends, go to a restaurant with his other half, or skip dinner altogether. While we are trying to overtake CFC, we are missing a huge number of people who are looking for solutions to a simple problem: what about dinner?
- Understand user motivation. If the user has a problem, he already somehow solves it. If it does not solve, then there is no problem. We often focus on how the user uses the product, and skip what happens outside of him: how he generally came to use it.
How a user can solve his problem now, and what we need to work with:
- he already has a tool, but he is not happy with it (for example, I use Lusid Chart to make charts. Charts are made, but they look bad);
- he already has an instrument, but a new one is more attractive (I use Lucid Chart, but there is Miro, and my colleagues use it);
- he already has a tool, he is not very happy with it, but is afraid to change it (I use Lusid Chart, my diagrams look bad, but switching to Miro and learning how to use it is pain, time, I resist);
- he already has a tool, he is attached to it and no longer seeks solutions (I use Lusid Chart, I have 100500 diagrams there, I create them in 5 minutes, they look bad, but they do their job).
All these things must be taken into account, and the characters will not help us in this.
Formula Jobs Tu Bi Dan:
When (situation description),
I want (motivation)
Jobs Tu Bi Dan example
Meet Oleg Ivanov. He is 28 years old, he is one of two designers of mobile applications under Agios in a small grocery company. Every morning he drinks coffee, sits down at his MacBook and makes mock-ups (although at first, of course, he thinks through the personas). Sometimes he works in a coffee shop; he goes on vacation 3 times a year. He knows the basics of Swift, studied at the British. He wears cool sweatshirts and colorful socks, goes to mitaps, and on weekends he does calligraphy.
And so Oleg buys a Figma for layouts and Miro for the product roadmap. Why such a set? Why not Photoshop or Sketch plus Lucidchart? Did his love of coffee, colored socks and mitaps influence his choice? No, it was rather influenced by the fact that in Figo and Miro you can work as a team together with a colleague. This “work as a team and simultaneously online” is the job that bi-dan.
If you think more globally, then the designer Oleg Ivanov does not just buy the opportunity to work teamwork on layouts and a road map, but the ability to quickly receive feedback from colleagues and work remotely from anywhere in the world, rather than in the office – that is, more convenient working conditions.
Job tu bi dan example
How to create Jobs Tu Bi Dan
Just like the characters:
- We formulate hypotheses for jobs and bi-dan;
- Test hypotheses in an interview;
- We analyze the data;
- We make jobs tu bi dan;
- We come up with solutions.
Job-bi-dan is best done on innovative products when they have a high degree of suspense, or when characters cannot be distinguished or there are too many of them.
Empathy map is an idea visualization tool that allows you to put yourself in the user’s place and look at the problem through his eyes.
It can be used both as an alternative to characters, and as an addition to them. An empathy map is a diagram in the center of which a representative of a certain user segment is located, on different sides of it there are 4 blocks (“think and feel”, “say and do”, “see”, “hear”). The findings are presented in two additional blocks: “problems and pain points” and “values and achievements”.
Empathy Map Example
- Empathy map will help to make up the character.
- Sometimes it’s difficult to create a character, because it’s difficult to single out a common archetype. Then the empathy map will help: people can be different, but they have one pain and desire.
- In order to check whether the current product solves the problems of users.
How to create an empathy map
- Here I usually start with an interview: pains and goals in people are often not obvious, it is better to ask directly. Based on the collected data, I fill out a map of empathy.
- I think and feel. What bothers the user? What words does he think of the problem? What doubts about? It is better to look for this information where users complain: for example, on forums. If the product has a support service, you should talk with its representatives / read what users write there.
- I speak and do. How does a user behave publicly? What does it say? In what ways does it solve the problem? How does one look for information on it? This information is worth looking for in social networks. Linkedin is especially useful in this regard: it is relatively easy to find representatives of various professions and learn what events / conferences / training events they attend, in which communities they are, what questions they raise, what skills they have, etc. etc.
- I see. What does the user experience look like? What offers and alternatives does your product face? The source of information for this block is the system itself and competing systems, online and offline advertising, articles in professional communities, official reviews, etc.
- I hear. How does the environment in which the user is located affect him? What do colleagues, acquaintances, authoritative sources for him say to him? What media channels have an impact on the user? Unlike the “see” block, the information here is not necessarily true. But the user trusts her. Where to look for information for this block: rumors and opinions on forums (and actually from social networks you can find out what kind of forums are), success stories, stereotypes and even urban legends.
- Problems and pain points. What worries the user? What does he fear? What could be the reason that he abandons your product? Often the “Think and Feel” block becomes a source of information for this. All these fears and doubts will need to be dispelled, and this can be done in a bunch of ways: from the “right” text in the interface to individual consultations.
- Values and achievements. What will help the user get rid of problems and doubts? What product features is he willing to pay for? What values should we transmit? The conclusions from this block affect the product from many different sides: they can entail small changes in the interface or in the text, as well as the addition / exclusion of certain functional features, and sometimes even a change in the positioning of the product.
- Artifacts are a way to understand whether a team is thinking in one direction and agree on the cheapest and most effective way: not in mock-ups, not in code, but literally in words.
- There are many artifacts, you need to select them to fit your needs. They can be dealt with by almost every member of the team, but usually they are a product oouner, analyst and designer.
- At the beginning of the project, it’s great to start with characters, an empathy card, or a Jobs Tu Bi Dan.
- Jobs tu bi dan are good when we have an innovative product or a new market.
- Characters are great for increasing empathy for users for all team members. They can be hung in an office and appealed to their archetypes in disputes.
- An empathy map can help build characters or be a separate artifact if the character is difficult to compose.
In the following articles I will talk about scripts, script maps and user travel maps, mudboards and reference collections, interviews with stakeholders, usability audit reports, comparison of competitors, prototypes, layouts and UI-kits. If you apply them on your product, then you can stand out from other similar products because they allow you to find gaps in the logic.
I will be very glad if you try to work with artifacts in practice and share your results with me in the comments.