The problem of non-persistent memory

I’ve spent the last while building side projects with a mix of AI tools — different models, different interfaces, sometimes several in the same project. Whichever tool I picked also picked where my AI assistant/agent’s memory had to live.

Build something inside Lovable, and the project context stays inside Lovable. Work in Cursor or VS Code, and it lives in local folders or on GitHub. Claude alone splits across Claude Chat (Cloud), Cowork and Code (Local), and only Chat is accessible from Mobile. Google’s Gems are meant to give Gemini a unique identity, but it was not clear to me how to manage its memory.

Every tool had its own version of “remembering me. You change tool or device — you need to start over!

I wanted to chat with my assistant and update my agent’s context from anywhere — on the train, in a meeting, on a different device, in a different tool.

I also wanted to be in control of how the identity of my agents evolves. So far, the identity of my assistants lived in Claude’s or Gemini’s black boxes.

Delegate or Augment?

Ethan Mollick’s Co-Intelligence proposes a distinction between working with AI as a centaur — clean human/AI division of labour, hand things off, get results back — and working with AI as a cyborg, where the work is more intertwined, and you switch back and forth fluidly.

Persistent shared memory would allow you to do both or either, depending on your context. If your memory and the agent’s memory live in different places, it takes twice as much work to manage them.

I was already using Notion as a content storage tool to extend my memory. What if the agent’s memory lived there too — same database, same notebooks, same place I’m going every day anyway?

AI memory is just well structured notes for context. If you store it in a tool that both you and AI can read and edit comfortably, you merge your memory with your agent.

Today, Claude has the cleanest Notion integration through MCP — the protocol that lets AI tools talk to outside services. OpenAI and Google don’t have great Notion support yet. Obsidian could also be used for a fee, but I have not tested it.

The landscape — three families of AI memory

Based on my research, AI-memory experiments cluster into three families.

A. Vendor-native memory. Claude Memory, ChatGPT Memory. Toggle on, it works. The vendor decides what to keep and how to retrieve it. You can’t really see what’s stored, you can’t easily edit, and it doesn’t follow you anywhere else.

B. Engineer-built memory layers. Open-source projects that give you full control if you write Python.

MemPalace is a local-first system designed by Milla Jovovich with Ben Sigman of Libre Labs. It stores conversations verbatim in a local vector database, organised by the ancient memory-palace metaphor — Wings, Halls, Rooms, Drawers. The headline benchmark is impressive, though a careful analysis on Medium points out the score is mostly measuring embedding quality rather than the palace structure itself. Setup: pip install mempalace, Python, CLI.

Mem0 is a more mature memory layer with hybrid storage (vector, graph, and key-value). Free tier and paid hosting. API-driven, not no-code.

Both are serious tools. They assume you’re comfortable writing code.

C. Notes-tool-as-memory. The pattern people like me are converging on: take the tool you already use for your own notes, and let the agent read and write the same pages.

The Obsidian camp is going local — Markdown vaults with folder structures and a CLAUDE.md orchestrating things. See Obsidian + Claude Code as a second brain (Pillitteri, 2026) and OpenClaw + Obsidian (Blink, 2026). Same idea, hosted on local files instead of cloud pages.

I went to Notion for three reasons.

1. Cross-device sync is built in — no Dropbox or iCloud dance to get my phone talking to my laptop.
2. Notion’s database properties give me a structure I understand.
3. And the most important factor is that I was already using Notion for remembering things.

Notes tool for shared memory

This is what I was experimenting with and what worked the best for me so far.

The setup has two parts. There’s a small entry-point — a short instruction wherever your AI tool expects one — , and there’s a shared note-taking space (Notion), which holds everything that matters.

The entry point is the same text in every tool. The only thing that changes is where you paste it. In Claude Code it lives in a CLAUDE.md file. In a Claude.ai project, it goes in the project instructions. In Cursor, it goes in .cursorrules. In Gemini, it goes into system instructions. Same template, different slot. The text says, "before you start, fetch these Notion pages."

Notion is the actual context layer. It holds three things stacked together: a memory system, an agent identity, and a set of reference pages with the domain detail.

• Agent Config. The hub. Holds the agent’s identity (what this agent is, who I am, how it should behave), the environment it works in, the rules I want it to follow, and pointers to everything else. Wherever the entry point lands, it sends the agent here first.
• Memory Index. Current state of the world, plus a short decision log. The agent reads it at session start, and updates it in-line when decisions get made.
• Reference pages. Domain detail. For my smart-home agent, the rooms, devices, and integrations. For my finance agent: my transactions, my savings, my holdings, my budget — all in the same notes I’d be checking myself anyway. The agent only loads these when the topic requires them.
• Sessions DB. The long-term log. One entry per session, written automatically at session end.

A session runs like this.

The agent fetches Agent Config and Memory Index via Notion MCP. Got its identity, memory and all context. We work. After meaningful decisions, it updates Memory Index. At the end, writes a Sessions DB entry and prunes anything out of date in Memory Index.

Example of agents that adopted this approach:

• Design System Assist helps me to research, build, and manage the company’s design system elements
• Jira Assist helps to log, prioritise, and manage Jira tickets
• Home Assist helps me to manage my smart home through Home Assistant — automations, devices, debugging.
• Fin Assist is a personal finance assistant, a bigger system with its own scripts, scheduled jobs, monitoring app, etc. The agent inside it uses the same Notion pattern. The complexity sits in the app; the memory pattern stays the same.

Advantages and limitations

Advantages

• Platform-agnostic. The memory is not stored on the LLM provider’s servers. You can switch from Claude to anything else with the MCP to your space access.
• Device-agnostic. The memory is in the cloud. Edit a page from your phone the agent sees the change next session on your laptop.
• Easier to understand. It’s Notion pages. No vector database, no embeddings, no opaque retrieval pipeline.
• Easier to manage. When the agent gets something wrong, you open the page and fix it. When the index drifts, you can tidy it. You see and decide what the agent knows and remembers.
• Same mental model as your own notes. If you already structure your knowledge in Notion, the agent’s structure feels familiar — you don’t have to learn anything new to read or edit it.
• Self-maintaining at the basic level. The agent updates its own memory at session end. You review; you don’t curate. The agent can maintain and clean outdated entries (if you instruct to do so)

Limitations

• Probably higher token cost. Every session fetches Agent Config and Memory Index. The overhead is unmeasured and unoptimised.
• Latency at session start. A few-second delay while the agent loads pages.
• Self-pruning is v0. The Memory Index drifts unless tidied occasionally. Compressing entries into the Sessions DB is still partly manual. But this can be optimised by correct initial instructions.
• Integration is uneven across vendors. Claude’s Notion MCP is solid. OpenAI and Google don’t have equivalents yet. The convenience today is Claude-shaped.

Setup guide with Notion

Setup overview

• Notion account
• Notion MCP token
• A short instruction block in whatever AI tool you’re using that says “before you start, fetch these Notion pages.” Build from there.

Steps to Setup

1. Create the Notion pages. In your Notion workspace, make four things: a page called Agent Config, a page called Memory Index, a parent page called References for your domain notes, and a database called Sessions. Leave them mostly empty — the agent will help you fill them once it can read them.

2. Get a Notion MCP token. Go to notion.so/profile/integrations, create a new internal integration, and copy the token. Then in Notion, share each of the four pages above with that integration so it can read and write them.

3. Connect Notion MCP to your AI tool.

• Claude Code / Claude Desktop: run claude mcp add notion and paste the token, or edit ~/.config/claude/mcp.json directly.
• **Claude.ai project:** open the project, go to Connectors, and enable Notion with the token.
• Cursor: Settings → MCP → Add new server, paste the Notion MCP config.
• Gemini / other clients: add Notion via the tool’s MCP or extensions panel.

4. Seed Agent Config. Paste in (a) who you are, (b) what this agent's role is, (c) the rules it should follow, and (d) Notion links to Memory Index, References, and Sessions. This is the page everything else hangs off.

5. Paste the Agent Instructions block (see below) into your AI tool. This is the tiny entry point that points the tool at Agent Config. Replace the placeholder link with the real URL of your Agent Config page.

• Claude Code → CLAUDE.md at the project root
• Claude.ai project → Project settings → Custom instructions
• Cursor → .cursorrules at the project root (or Settings → Rules for AI)
• Gemini → system instructions field in the Gem builder
• Any other MCP-capable client → its system / pre-prompt slot

Before you start any task, fetch these Notion pages in order:

1. Agent Config — your identity, my context, and the rules you follow. <paste your Notion URL here>
2. Memory Index — current state of the world and recent decisions. <paste your Notion URL here>

After meaningful decisions, update Memory Index inline.
At the end of every session, append a new entry to the Sessions DB
and prune anything outdated from Memory Index.

Only load Reference pages when the topic requires them — they are linked
from Agent Config.

6. Run a first session. Ask the agent to read Agent Config, then Memory Index, and introduce itself back to you. If it can quote what's on those pages, the loop is closed.

7. Create your own pages and have fun. Below are examples of mine for “Fin Assist”

Your AI-Assistant Identity

Identity, in the way most of us experience it, is a structured collection of memories — what we’ve done, what we’ve decided, what we care about, who we’ve worked with, what we’ve learned along the way. That’s true for people, and it’s increasingly true for the agents we build to work alongside us. Whoever owns the memory effectively owns the identity.

Anthropic, OpenAI, and Google will eventually ship comprehensive memory features. They’ll be slick, they’ll work well inside their ecosystems, and they’ll probably keep that memory mostly inside a black box you don’t get to see.

If your agent’s memory lives inside a vendor, the agent is, in a real sense, theirs. You’re using their assistant with some context loaned in. If the memory lives in your own space — Notion, Obsidian, whatever you already keep your own notes in — the agent becomes yours. The vendors and the models stop being identity holders and become what they should be: interchangeable interfaces into a context you own. Chat, voice, IDE, mobile, whatever ships next; you bring your agent to it.

I was already using Notion as my own extended memory. Once I let my AI-agents use the same pages, I felt the context gap between us decreased.

Our AI-agents’ memory should belong to us, not AI-companies that provides LLM capabilities

“What” users do and “Why” — Part 2

What is a fundamental difference between Qualitative and Quantitative user research? I like the following definition:

A QUANTitative research shows us WHAT users do, whereas QUALitative helps us to understand WHY

Understanding causation is important for sure, but sometimes it’s better don’t have insights rather than have misleading ones. I believe that incorrect data is much more damaging than no data at all.

“WHY”- insights is a theoretical part of a user study. We can easily dive into a rabbit hole and speculate here. We rely much more on our own interpretation when we need to write research outcomes. When eliciting these insights we are more vulnerable by many cognitive biases. On the other side “WHAT”- insights are self-explanatory more often, they are more specific and we usually need less interpretation here.

There is no reason to argue that we need to do both, but in reality, we don’t have enough time to do both properly and usually prioritize a more theoretical “WHY” over a more practical “WHAT”.

This is the second part of the subject in which I provide some tips and tactics on how to build a more data-driven design process around a user that hopefully can eliminating some biases. If you missed it for some reasons, you are welcome to read Part 1 firstly

Please note, I don’t recommend blindly trust numbers and don’t talk to your users at all. The goal of this subject is to bring data closer to designers and show how we can benefit from it.

Part 1

1.1. Introduction to the problem

1.2. How talking to customers makes us biased

• Issue I — Fake Environment
• Issue II — Tendency to Satisfaction
• Issue III — First Random Patterns
• Issue IV — Information Availability

Part 2

2.1. Fighting biases by changing the focus

• Principle I — Past over Future
• Principle II — Problem over Solution
• Principle III — Real Context
• Principle IV — Real Content

2.2. Adding more data insights to the design process

• A. Database (SQL)
• B. Behaviour Analytics
• C. Event Analytics

2.1 Fighting biases by changing the focus

How can we eliminate biases and be more objective in our research? I am afraid it’s impossible to remove it completely (biases help us to survive and kind of need to exist) but there are some ideas that might help you to reduce its influence. My design philosophy consists of the 4 following principles:

• Past over Future
• Problem over Solution
• Real Context
• Real Content

Principle I — Past over Future

Yes, we want to predict how users will behave and interact with our design, but we can’t, sadly. People are really bad at predictions. Daniel Kahneman in his book “Thinking fast and slow” revealed many good examples of how we fail at predictions again and again, but still, continue to believe in our ability to forecast.

We need to kill a “fortune teller” inside us and nurture an “analyst”. Switch the focus from thinking of *What will happen* to understanding *What happened*.

In practice, it means we need to do less complex design projects (where we try to predict all potential issues and cover all use cases).

Big projects are more risky and require more planning, upfront thinking and prediction. Approach the design step by step and learn fast, release after release.

Don’t overthink, focus on what events did happen, what actions a user did, what pages a user visited, etc. That’s when analytics and A/B tests come in handy.

Principle II — Problem over Solution

We can be less prejudiced if we don’t spend too much time assuming what will work better, hence designing our initial solutions. We become emotionally attached to our solution (or to a favourite one). The more time we spend on our solution the more we believe in it. Which perfectly feeds our confirmation bias described in Part 1.

Usability testing is good, but it will unlikely change the design drastically. It’s more about tuning. On the other hand, just imagine how your solution could differ from a current one if you looked at your problem from a different angle.

Instead of spending more time designing a solution, just spend more time understanding a problem upfront, analyze available user behaviour insights, analytics, and the whole problem area prior to any hypotheses are being made.

(A) Problem -> (B) Assumption -> (C) Hypothesis -> (D) Solution

When we are focusing on a problem the probability we end up with a good solution increases. It makes an early validation in a fake environment less valuable and we can validate how a solution works in a real context just after the release.

Principle III — Real Context

In Part 1 we discussed that capturing insights in a fake environment is risky since a user in a natural setting would normally solve a problem differently. Always keep the context in mind. The more real context the more reliable results of a study.

We have the only one real context — it’s a production.

In practice, it means we should aim to interfere less into a user flow or a journey while studying. If we are able to isolate ourselves from a user’s eyes in research (as an actor/moderator/evaluator/researcher) it can eliminate not only our but a user’s social biases as well.

While an unmoderated usability study can remove some pressure from an interviewer, a passive observation would work the best. Contextual research is expensive but watching video recordings in tools like Hotjar is super affordable and insightful.

Principle IV — Real Content

The last principle is about the content itself. The whole point of digital design is to facilitate a content presentation. Don’t underestimate the importance of the text data on your site or application. It might play a significant role in understanding what visual form to apply, how to construct the page.

Always look at the real data that will be displayed after your design goes live. In practice, it means you might check the real content and its distribution directly in your database or maybe in other analytical tools where you gathered it.

For example: If we need to display a text introduction provided by a user in UI — how long is an average one? If we need to display a number of items (icons/labels) based on some criteria a user provided — what criteria they selected the most and how many they selected on average?

When we use “Lorem ipsum” in a design mockup it means we don’t understand the real content, which means we might mismatch the form, which means our design might not work well.

Never use “Lorem ipsum”!

2.2. Adding more data insights to the design process

There is no limitation on how we can use data insights, and what sources we should look from. I believe the more we search for evidence from the real data on production the better we understand what is happening. Sometimes you can be surprised by discovering issues you would never think of. Your database and analytics are good sources to validate your assumptions early on, before making any hypotheses. Do many users have a problem you are studying? Is that even a problem? What do numbers say?

I usually do the following 3 studies every time before I need to work on a new design challenge. It can be as quick as 1 hour per study or much longer depends on the project.

AContent / What data users provided / SQL queries in tools like Metabase, BiqQuery or explore the data in tools like Looker

BContext / How users interact with UI / screen recording and heatmaps in tools like Hotjar, Inspectlet

CFrequency / How often different events occurred / event tracking in tools like Amplitude, Google Analytics, Mixpanel

A. Content: Database

The most valuable skill I gained for the past few years was SQL. It allowed me to apply fast ad-hoc analysis and be much more independent from software engineers, product managers, or data analysts. The below are a few examples of research questions that can be easily validated just by writing a small SQL query in tools like Metabase or BiqQuery:

• What are the most popular options users select in a chosen feature? (if UI has dropdown menu/radio buttons/checkboxes)
• What text input users provide in a chosen feature? (if you need to display any text data in UI)
• How many users opted into a chosen feature? (if you need to understand how different settings are being used)
• How many users provided specific data? (if something is optional to provide in your UI)
• How many users have specific criteria? (if you capture more user data in addition to generic demographics that can be monitored in other analytical tools)

Making ad-hoc SQL analysis we can see a bigger picture of the real content and it’s distribution. It ensures that we apply the more appropriate form, making sure that design supports a content rather than a form dictates the focus

Let’s take a look at the real example and see how answering some of those questions could change the way how UI looks and UX works.

Currently, I am working at the product company that is afterschool-nanny marketplace, so my examples will be in this context.

Say we need to design a nanny profile preview card and present hundreds of nannies on the search result page so a user can browse and choose which one matches their requirements the best. The space on a card is limited and we need to understand how the real content will fit this card:

Instead of asking users what they want to see on a nanny card, there could be loads of insights already in the data to validate quickly our assumptions:

• What are the most common filters/requirements a user selects? (i.e. to make sure we reveal the most useful information)
• Once we know the most common filters/requirement, do we have enough nannies that match that filters? If we have too many then we could allow filtering by it and maybe do not display it on a nanny card, if we have not too many then maybe it’s better to remove the filter and present it as a competitive advantage badge/icon? (i.e. a nanny has own car)
• How long is a text introduction an average nanny has? If too long then we could collapse it by default into “Read more”, if not too long then maybe we reveal the full text straight away.
• How many days an average nanny can work per week? Can majority of nannies work all 7 days per week or they have a very different schedule? If a schedule is not the same then we could create new UI component, a visual differentiator, if a schedule is almost the same we don’t need a repeating component that attracts too much attention.
• How many users have pets? And how many nannies are not happy with pets? If too many nannies are happy with pets then it doesn’t make sense to have a repeating “Happy with pets” icon. If too many nannies are not happy then we should not position the icon too prominent just to avoid a negative feeling of all nanny cards. If a distribution is equal then maybe we could display both concepts as icons. But if only a few users have pets then maybe we need to remove this information completely from the preview.
• How many nannies selected they can speak an additional language? What about 2 or 3 languages? It helps to understand whether we need to promote it as a competitive advantage or it’s just additional criteria to display. (i.e. we could display it prominently as an icon or as a simple text label to reduce unnecessary noise and don’t attract too much attention)

Having text data in place we could also use SQL to create a CSV file in order to check for some patterns in word cloud generator. Which is how we can quantify our qual data. In the example below, we were looking for some patterns of what skills and activities nannies mentioned in text data.

B. Context: Behaviour Analytics

Whereas a database helps us to understand the “content” behaviour analytics shows us insights in the real “context”. I can’t recommend enough to watch video recordings of real user sessions.

By watching video recordings we learn a true user flow in context and timing where all other distractions exist and interfere into a user experience

I personally love Hotjar and use it at every place I work. Surely there are many alternatives. Here is a list of typical insights you will get:

• How users interact with your UI
• What causes confusions or blocks the flow
• On what UI component a user spends too much time
• How often a user is interrupted from the flow
• After what actions a user drops, etc

Although video recordings are probably the most insightful feature in Hotjar there are a bunch of others like Funnels, Surveys, etc.

A heatmap is a great solution to quantify your users’ clicks if there is no event tracking in place yet:

• Do your users click where they are supposed to click?
• Do your users click where they are not supposed to click?

In the example below, we realized that 10% of users were clicking on an avatar while the system doesn’t support a full-size picture preview. So it a clear indicator of users’ needs

C. Frequency: Event Analytics

Lastly, event tracking allows us to see what happened and how often. It helps to prioritize problems and identify users’ needs. This is also crucial to know in order to define the proper visual hierarchy on a page, improve the navigation and onboard users across the journey, prompt, and display the relevant component.

The next example will be in the same nanny marketplace context. One of our key engagement metrics was # of invites a user sends to a nanny, which increases the probability to have a successful match eventually. So we were always looking for how to improve conversion to this action. Having CTA like “Invite to chat” was a no brainer for us, so we displayed it on the search result page straight away.

However, having event tracking in place (in our case it was Amplitude) we noticed that most “invites” users send not from the search page but from a nanny profile page.

In addition, we captured a handy heatmap which proved that users want to discover more information about a nanny before inviting a nanny to chat. You can see below that users click “Read more” button the way more often than “Invite to chat”

Having these insights we assumed that maybe forcing a user to “invite to chat” was a bit premature. A user probably needs to visit all necessary pages upfront before making a commitment and press our key button. So maybe we can save a user’s time and boost a decision-making process by adding an extra step to the funnel instead of removing it. Therefore we launched an ABC test which proved our hypothesis and improved the conversion eventually.

Depending on your company size and your budget there are plenty of options available on the market. It can be a more expensive tool like Mixpanel where you can have event tracking super easy without any additional engineering hassles or Amplitude where you would need to send some events with engineering help.

But you can actually have a pretty powerful combination of Google Analytics + Google Tag Manager + Google Optimise for free and create not only your events without engineers but also run your own quick A/B tests.

Alternatively, you can also use your database to track all events and store everything in your tables which sometimes is handy but more expensive to maintain.

P.S.

To summarise,

In a fast agile environment, many product designers don’t have enough time to conduct a proper qualitative study and eliminate all biases. As result, we easily satisfy our prepared design solutions applying a false validation by using fake content in a fake context.

Looking at numbers helps us to be a bit more objective and see what is really happening rather than guess what will happen. We are less vulnerable to cognitive biases. Also, we can identify the real problem earlier. It might save us the time we spend on a solution when we are tackling a wrong or even a non-existing issue. These days it’s easy to employ the data and it’s often pretty much accessible.

I hope this subject was useful and you learn something new. Cheers!

“What” users do and “Why” — Part 1

- So, Andy, tell me what did you think the first time when you used our site …

- Oh, it was great, really like it. I thought such a cool idea to put a monkey on a homepage

Andy didn’t really remember what he thought back then, but a monkey picture was the first thing he could easily retreat from his memory…

Many product companies these days want to be customer-focused and user-centred. Businesses started to appreciate design as a function and keen to build a design process around a user. That’s great, right? But one thing needs to be balanced better I believe. It’s a ratio between Qualitative and Quantitive research designers do.

Conducting user interviews by myself and observing how my colleagues do that, I noticed, although it’s not that often we get many good insights in outcomes, but we always feel right, satisfied, and reassured after doing that. On the other hand, the quantitative side of user research is underestimated and really lacking among designers.

There is a way more product designers who can talk to users rather than understand what users really do

This trend is also supported partially by many companies and design recruiters. Talking to users is highly demanded as it’s being shown in a description of many roles with titles like Product or UX designer.

Here are my 5 cents about why qualitative research should be not overestimated as it is, and how designers could be better informed by the quantitative data that is already in place.

Part 1

1.1. Introduction to the problem

1.2. How talking to customers makes us biased

• Issue I — Fake Environment
• Issue II — Tendency to Satisfaction
• Issue III — First Random Patterns
• Issue IV — Information Availability

Part 2

2.1. Fighting biases by changing the focus

• Principle I — Past over Future
• Principle II — Problem over Solution
• Principle III — Real Context
• Principle IV — Real Content

2.2. Adding more data insights to the design process

A. Database (SQL)

B. Behaviour Analytics

C. Event Analytics

1.1. Introduction to the problem

These days usability testing and user interviews are very popular techniques in the design process, especially in comparison to studying the real content and employing already captured user data prior to making any assumptions. Quantitative data seems like a prerogative of a data analyst, business analyst, or product manager. However, these roles would more likely to monitor business metrics like conversion to registration or key engagement metrics rather than diving into UI issues or user interaction details.

On the other hand, it’s challenging and sometimes even unrealistic for a designer to get real content or/and understand true user experience in a fake lab environment or during an interview. Worth noticing a few exceptions when a qualitative study is still crucial though:

A. When it’s a newly born product and knowledge about your customers is too limited. In this scenario, you can discover and prioritize the most important UX issues to be tackled pretty fast

B. When a mature product team wants to understand a very specific problem and has enough time and resources to allocate to the issue. Ideally, a qualitative study is performed by a professional researcher who can plan it properly and eliminate all the unconscious biases

Unfortunately between A and B, there are many young products with already defined key customer issues to solve but who still overuse user interviews since it’s known as a good practice to follow regardless of anything. The problem is that when we work in an agile way we don’t have enough time to do that right.

Having too limited time for a qualitative study we often end up with something like Guerilla testing or a small number of user interviews just enough to satisfy our original design assumptions so we are happy about our solutions.

Let’s discuss how it works.

2. How talking to customers makes us biased

People evolved to be a dominant force on the Earth by gathering around abstract ideas like Company, Country, or Nation. It helped us to design amazing and powerful things like mobile phones or spaceships. Communication between people is key in this progress. One person isn’t able to create such things in isolation.

To learn and adapt faster we access our previously gained knowledge and new environmental signals without spending too much time analyzing it. Our unconscious system does the work and saves us some time. As a downside, we encounter mistakes that are hard to recognize in a form of unconscious biases, cliche, and stereotypes, especially in social interactions.

Issue I — We analyze in a fake environment

A user interview (or a moderated usability session), as a format, puts users in a position where other people are observing them and will evaluate the responses afterward.

a user is unlikely would react or solve a problem in a fake environment the same as in real life

because of 2 things:

1. MOTIVATION: when a user solves a problem in real life there is a completely different reason that drives their behaviour.
2. TIME: in a fake environment a user has a setting with a different time to solve a problem, which highly affects their actions or answers.

“We are not testing you, we are testing the prototype” they say. The problem is this doesn’t change the way we think. Even though you are aware that McDonald’s put tasty food on their billboards to make us hungry, it will still make us more hungry when we see the picture (if you are not a veggie).

Here are a few thoughts that might affect how a user could respond to you knowing that you are going to evaluate their answers:

• I am not stupid, so I need to answer A …
• I could answer B, but I want to be helpful, so I answer A…
• It’s more normal to answer A than B…
• Most people would do B, but I am different so I do A…
• Not sure, but A (the first appropriate answer) fits well, it feels safe and I don’t want to think too much about this…

[Framing bias]

In addition to the pressure that comes from a limited testing time and the presence of the evaluator/moderator, there is another fundamental bias likely to occur in a fake environment. Since we are responsible for creating a test, we set up our own borders and present the task in a context that doesn’t exist in a real life. We play a significant role in the outcomes of the study.

Framing bias occurs when users’ responses are influenced by context — by the way information is presented to them, as much as by the information itself.

a way how we set up a test significantly affects how participants will respond or accomplish a task

According to a study performed by Nielsen Norman Group, 31% more UX practitioners agreed that a search function should be redesigned after seeing a task-failure rate, compared to practitioners who saw the exact same information expressed as a success rate.

Issue II — we want to be proven right

Although the following biases might occur also when we working with numbers or need to interpret any quantitative data they are much more likely to occur when we are conduction a qualitative study. Simply because we are much more flexible to design a study and set up questions in a way we like.

In social life it’s crucial we prove ourselves as smart and important individuals so we search for any possibilities on how to validate we are right, even though we are not.

It’s difficult not to have any expectations before a user interview if you are a designer of a presented solution. Because we spent time and made efforts to design it we are emotionally attached to it usually. It’s super easy to hear what we want to hear during user testing.

[Confirmation bias]

Daniel Kahneman, who first introduced this concept, said that confirmation bias exists “when you have an interpretation, and you adopt it, and then, top-down, you force everything to fit that interpretation.”

We unconsciously lead a participant to a preferable for us path just by being a moderator or an interviewer during a study

Confirmation bias makes us search and choose evidence that supports our existing beliefs. At the same time, we tend to avoid anything that distracts us from it.

[Observer-expectancy effect]

According to the Oxford Dictionary of Psychology, it is a particular type of experimenter effect in which the expectations of the experimenter as to the likely outcome of the experiment acts as a self-fulfilling prophecy, biasing the results in the direction of the expectation.

Think about a placebo effect, once you started to expect something you are already biased

In a series of classic experiments carried out by the German-born US psychologist Robert Rosenthal (born 1933) in the early 1960s, the effect was induced by telling experimenters what kind of behaviour to expect from laboratory animals. In one experiment published in 1963, 12 psychology students were each given five laboratory rats of the same strain, but six were told that the rats had been bred for maze brightness and the other six that they had been bred for maze dullness. The students were given the assignment of running the rats in a maze-learning experiment, and the rats believed to be bright performed significantly better than those believed to be dull.

Issue III — we are anchored to first random patterns

How many user interviews are enough? If something clearly doesn’t work as expected we probably will find this only after a few sessions, it’s true. But on the other hand, if we conduct only a few usability sessions and our solution has no major issues our brain would search for any insights.

For example, an experienced UI designer might more likely to predict and eliminate any big interface issues before the testing. Then, if nothing interesting comes during a study he or she can overvalue everything that looks like a pattern and misinterpret the cause.

[Clustering illusion]

The clustering illusion refers to the natural human tendency to “see patterns where actually none exist.”

A simple way to understand this illusion is to imagine casting ten pennies in a one foot square space. Unless all of the pennies fall in an exactly even distribution, which is extremely improbable, some pennies will be closer to each other than others and seem to form a cluster or group solely from the random distribution.

What if 3 from 10 users were confused by a button X? Would it mean that 3000 from 10 000 other users will be confused or it was just a random fact that these 3 users had a Nokia smartphone with an unusual UI they used to see every day?

What if 4 from 5 users didn’t have a problem finding a page Y and liked the navigation? Would it mean that 80% of all your users will easily find a page Y or it’s just because 4 users from those 5 were our friends, they had similar interests as we and they used to visit another site with similar navigation like the one we designed?

[Anchoring bias]

We tend to rely too heavily on the first piece of information seen. Anchoring occurs when we see the initial piece of information and use it to make subsequent judgments.

In 1974, the psychologists Amos Tversky and Daniel Kahneman asked each of their study participants to calculate one of two different mathematical expressions:

1x2x3x4x5x6x7x8

or

8x7x6x5x4x3x2x1

Because participants were given only 5 seconds to solve the problem, they estimated the answer as opposed to actually performing the multiplication. The solution to both problems is the same number: 40,320. But people made very different estimates for each mathematical expression. For the group which was presented with the 1x2x3x4x5x6x7x8 problem, the median estimate was 512 — meaning that half the participants came up with a number smaller than 512. For the group presented with 8x7x6x5x4x3x2x1, the median estimate was 2,250, or more than 4 times bigger. Not a negligible difference — created by simply presenting the stimulus in reverse order.

In a rapidly changing agile environment (especially in startups) designers often don’t have too much time and resources to conduct a proper, complex, and expensive study. Eventually, we often end up with small sample size or test our design on our friends and colleagues.

A small sample size of users during usability study makes us see patterns where none exist. Our brain connects it to the studying problem, we are anchor to it and overvalue our early findings

Issue IV — we get insights only from users who want to give it

Have you ever thought that all users who attended a user interview or a usability test have one thing in common — all of them agreed to participate. We should not underestimate this common user’s characteristic since it is directly connected to their motivation to provide insights, it changes the way how they think and what they do during our test in comparison to solving the same problem in a real life. We are limited by this segment of users who are available. So our insights can be only valid to this very particular segment of users, it’s not a random sample.

The issue is that regardless of a recruiting method you chose (email, in-app, phone call), it’s unlikely that your conversion from an invitation to a participant will be more than 50%, usually, it’s less than 10%.

Users who agreed to participate in our study are always represent a minor and very particular segment of our userbase.

But how can we test on users who don’t want to participate in our test? Sadly it’s impossible unless it’s a real environment on production.

[Survivorship bias]

Survivorship bias is the logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility.

For example, when these days we see only stone castles it’s easy to assume that “Most castles were made of stone” however a truth could be that “Most castles were made of wood but were destroyed by fire”

Another example (a famous one): during World War II, the US military examined the damage done to aircraft that had returned from missions and recommended adding armour to the areas that showed the most damage.

However the statistician Abraham Wald took survivorship bias into consideration and suggested the opposite. He noted that the military only considered the aircraft that had survived their missions; any bombers that had been shot down or otherwise lost had logically also been rendered unavailable for assessment. The holes in the returning aircraft, then, represented areas where a bomber could take damage and still return home safely.

[Availability heuristics]

The availability bias is the human tendency to think that examples of things that come readily to mind are more representative than is actually the case. The availability bias results from a cognitive shortcut known as the availability heuristic, defined as the reliance on those things that we immediately think of to enable quick decisions and judgments.

For example, since we saw more cases in the news or in movies when a shark killed a person we tend to think that a shark is a deadlier animal than a horse. In reality, the statistics say the opposite. (Which are deadlier: sharks or horses?)

Psychologist Gerd Gigerenzer conducted a study that showed in the months following September 11, 2001, Americans were less likely to travel by air and more likely to instead travel by car. However, highway travel is far more dangerous than air travel. More than 40,000 Americans are killed every year on America’s roads. Fewer than 1,000 people die in airplane accidents, and even fewer people are killed aboard commercial airlines.

I hope you enjoy reading so far. This was Part 1 in which I introduced the problem but didn’t suggest what to with it. If you keen to read more and explore how I personally tackle this problem you are welcome to read Part 2

2.1. Fighting biases by changing the focus

2.2. Adding more data insights to the design process

Continue reading >

Система линз в дизайне пользовательского опыта взаимодействия

Это методология, которая помогает структурировать данные, полученные с UX анализа, а также фокусировать максимальное количество выявленных фактов на определенном решении по улучшению UX/UI продукта.

Другими словами каждое UX решение желательно пропускать через призму разных составленных утверждений на базе собранных данных (проверенных опытным путем на рынке или после подтверждения своих гипотез)

Такой подход помогает избавиться от своей предубежденности как специалиста, а также находить наиболее оптимальные решения для разных зон пересечения продукта с “А” — Бизнесом (Владельцем), “В” — Аудиторией (Пользователем), “C” — Рынком (Тенденциями) и т.д.

Как это работает?

1. Есть список вопросов (UX Questions), которые должен задавать специалист изучающий UX дизайн продукта (можно воспользоваться моим списком https://goo.gl/Df7RJD, а можно составить свой). Вопросы поделены по категориям, например “А” Бизнес, “В” — Аудитория, “С” — Рынок.
2. Во время изучения вопросов, все полученные ответы, находки, мысли и т.д. заносятся в соответствующую категорию (можно использовать блокнот или любой удобный инструмент для заметок).
3. После всех заметок рождаются “Гипотезы”, идеи, которые должны проходить валидацию или тестирование и превращаться в “Факты” (во время исследования могут быть обнаружены уже проверенные на рынке факты)
4. “Факты” формируют четкие “Требования” для улучшения UXD (на картинке выше это UX issues). Требования могут быть как ко всему продукту, например “Элементы интерфейса должны содержать параметр Х”, так и к отдельным фрагментам “Должна быть возможность регистрации через Facebook”.
5. При разработке нового модуля UXD и UI, специалист должен находить такие решения, какие будут удовлетворять все выявленные требования или наиболее приоритетные из них. Приоритеты зависят от фактов и задач в целом, можно использовать различные техники, например dot voting. Также процесс формирования требования и приоритетов может отличаться от размера команды и ролей.

Пример списка вопросов тут https://goo.gl/Df7RJD

Изучая опыт пользовательского взаимодействия, еще до составления каких-либо идей и рождения гипотез, мне приходилось делать огромный кусок исследовательской работы. От проекта к проекту многие вопросы, которые я задавал себе или клиенту повторялись. Некоторые прочно сидели у меня в голове, а некоторые вылетали. Иногда бывало так, что только после сдачи проекта, замечал что-то действительно важное и возникали мысли “как я мог про это забыть?”. Так родилась идея создать такой список вопросов, который смог бы максимально перекрыть все, о чем нужно думать во время UX-анализа.

В подборку вошли вопросы затрагивающие эвристическую оценку, юзабилити, дизайн-паттерны, принципы графического дизайн, бизнеса, рынка, мотивации пользователей и многое другое.

Статья разбита на 2 части:

• Первая часть содержит вопросы с объяснениями (для начинающих UX специалистов, а также “не дизайнеров”, кто заинтересован в улучшении продукта). Я поделил вопросы на 8 групп: Бизнес, Рынок, Аудитория, Процесс, Графика, Управление, Коммуникация и Мотивация.
• Вторая часть дублирует список вопросов без объяснений для (для Copy+Paste и создания своего собственного чек-листа, на базе этих вопросов).

1. Что самое важное в продукте? (MVP, core features, flowcharts) Никогда не стоит забывать о самой основной задаче продукта. В проектировании нового опыта взаимодействия нужно максимально ей способствовать на всех этапах. Для того чтобы постоянно держать это в голове, можно нарисовать простые блок-схемы, на которых будет отображен процесс решения основных задач.
2. Что нужно владельцу продукта? (goals, issues, KPI) Четкое понимание целей владельца, желательно в измеряемых параметрах, поможет строить более эффективное взаимодействие с системой на всех этапах использования.
3. Как продукт будет зарабатывать? (monetization) Если задача продукта не только brand awareness но и заработок, важно сразу понимать как именно он будет это делать. Общая стратегия, поможет вам создавать тактики. Даже если сейчас продукт не монетизируется, понимание будущих целей избавит вас от неприятностей, когда внедрить монетизацию, не потеряв уже часть лояльной базы пользователей, будет очень сложно.
4. Как продукт будет продвигаться и позиционировать себя? (positioning, marketing strategy, promo channels) Все взаимодействие с продуктом нужно подстраивать под образ, который должен складываться у пользователей. Желательно усиливать этот образ теми или иными действиями внутри системы. Например, понимая с каких каналов будет идти основной трафик можно правильно построить приветствие и первый опыт взаимодействия, а понимание позиционирования поможет укрепить образ продукта в голове потребителя.
5. Как на продукт могут влиять другие заинтересованные лица? (stakeholders, actor map) Понимание всех заинтересованных лиц поможет находить такие решения, которые будет проще реализовать, так как они будут подходить большинству или наиболее заинтересованным лицам.
6. Как построены бизнес процессы? (business processes) Кроме пользователей важно видеть всю картину взаимодействия с продуктом, понимать всех, кто участвует в процессе, например сотрудников компании. Построив комфортную среду для тех, кто обслуживает пользователей, вы сможете повысить качество этого обслуживания.
7. Какие еще объекты компании могут влиять на пользователя? (customer journey map) Важно представлять весь процесс взаимодействия, не только внутри продукта, но и за пределами. Например, на пользователя еще может влиять support-service или социальные странички продукта.
8. Где пользователь может испытывать негативные эмоции вне продукта? (customer experience map) Определив поведение и пути пользователей вне продукта, важно выявить те места, которые негативно влияют на восприятие продукта. Исправление таких мест поможет пользователю быть лояльным к продукту и улучшит опыт его взаимодействия с ним.
9. Как продукт может взаимодействовать с другим бизнесом владельца? (global business) Возможно у владельца есть еще офлайн бизнес или другие цифровые продукты. Как они повлияют на продукт или как продукт повлияет на них? Будут ли дизайн решения дискредитировать другой бизнес владельца или наоборот помогут адаптироваться пользователям? Четкое представление про весь бизнес владельца поможет заложить фундамент всей системы взаимодействия межу текущими и будущими продуктами.

1. Кто аудитория продукта? (target audience, market research) До детального изучения пользователей и персон важно четко понимать с каким сегментом аудитории нужно будет работать. Определение такого сегмента поможет собрать много полезных данных про нее с рынка.
2. Какие основные проблемы будет решать продукт для своей аудитории? (consumer needs) Решение этих проблем должно быть всегда в приоритете при построения опыта взаимодействия.
3. Знает ли сама аудитория про эти проблемы? (consumer needs) awareness Бывает, что аудитория не осознает существующие проблемы. Понимание “осознанная” или “неосознанная” проблема поможет построить правильную коммуникацию внутри продукта и определит инструменты для анализа пользователей. Например, решение неосознанных проблемы не следует искать с помощью прямых вопросов фокус-группе.
4. Какие второстепенные проблемы озвучивает эта аудитория на рынке? (consumer needs, market research) Чем больше проблем можно будет выявить и решить для аудитории, тем крепче можно связать аудиторию с продуктом. Но при этом не стоит усложнять продукт тогда, когда нет достаточного количества ресурсов. Реализовать новые модули нужно таким образом, чтобы это не мешало основному процессу MVP, быстродействию или визуальному восприятию продукта.
5. Как все эти проблемы решает аудитория без текущего продукта? (consumer patterns, market research) Понимание типичных процессов решения таких проблем поможет не разрушать паттерны аудитории и быстрее превращать ее в лояльных пользователей. С одной стороны, вы сможете адаптировать уже существующие решения в сам продукт, а с другой понять, от каких точно следует отказаться в пользу более эффективных.
6. Какие группы пользователей можно создать из аудитории продукта? (user stories, personas) Составление персон поможет вам точнее понять запросы и процесс использования продукта конкретными людьми, специалистами, психотипами и т.д. И соответственно вы сможете построить правильный опыт взаимодействия как для всех вместе, так и для каждого отдельно.
7. Кто ваша ключевая персона? (key persona) Фокусируйте все свое внимание сначала на ней и только потом решайте задачи для остальных. Очень сложно удовлетворить 100% всех запросов и проблем широкой аудитории.
8. Какие желания могут быть у разных персон? (empathy map, feelings) Эмпатия поможет построить эмоциональную составляющую в опыте взаимодействия и направить ее куда нужно. Желательно не только понимать, что хочет пользователь, но и сопереживать ему.
9. Кто является платящим пользователем? (paying user) Ответ вам поможет проанализировать различая в поведении платящих пользователей и не платящих. Особенно важно при построении опыта взаимодействия в freemium моделях монетизации, где 1% пользователей приносит 99% дохода.
10. Какие особенные проблемы и желания у платящего пользователя? (paying user) Изучение поведения и желаний платящего пользователя поможет оптимизировать и максимально эффективно настроить процесс покупки.
11. Проработана ли локализация и адаптация языка для разной аудитории? (languages) Освоение продукта должно быть максимально комфортным. Язык для многих пользователей является принципиальным при принятии решения пользоваться продуктом или нет.
12. Что может оскорблять религиозные или политические чувства аудитории? (religion politics) Некоторые пользователи могут принципиально не пользоваться продуктом, в случае обнаружения вещей в продукте, которые будут противоречить их идеологии.

1. Кто конкуренты у продукта? (market research) Выявление продуктов, которые выполняют похожие задачи поможет определить уже существующие успешные практики для улучшения продукта.
2. Какие группы успешных конкурентов можно создать? (competitors analysis) Например по высокому заработку, по хорошим отзывам, по популярности и т.д. Это поможет правильно понимать в какую группу для решения каких задач можно обращаться за данными. Например, наиболее мотивирующие могут иметь хорошие отзывы, а наиболее богатые могут иметь эффективно построенную монетизацию и user flow.
3. Как построен UI в успешных конкурентов из разных сегментов? (competitors analysis) Анализ наиболее успешных продуктов поможет определить уже существующие эффективные UI и IA решения, а также обнаружить потенциальные проблемы при определенном решении UI задачи.
4. Как построен UX у конкурентов? (competitors analysis) Психологические трюки, уловки, а также любые выявленные решения UX задач у конкурентов помогут построить цепляющий продукт, увеличить user engagement и retention. Можно черпать идеи начиная от построения первого опыта взаимодействия до контента в письмах по почте. С другой стороны можно выявить общие черты успешных конкурентов и остальных и сделать из этого правильные выводы.
5. Что показывает статистика поведения пользователей у конкурентов? (market research, target audience) Зафиксированные данные, факты и цифры уже проведенных исследований на рынке помогут понять предпочтения, проблемы и привычки аудитории-пользователей конкурентов.
6. Какие отзывы пользователей о продуктах конкурентов? (user reviews, social media) Анализ отзывов и обзоров других похожих продуктов поможет с одной стороны понять проблемы аудитории и не допускать такие же ошибки при разработке взаимодействия, а с другой определить, что очень нравится пользователям в таких продуктах.
7. Есть ли статистика или результаты редизайна конкурентов за последнее время? (case studies) Статьи, кейсы, анализ закачек, изменения оценок, изменение дохода и другие факты после редизайна помогут понять на сколько он был успешен. Что можно взять как хороший пример, а какие ошибки лучше не повторять.
8. Какие UX\UI тенденции на рынке похожих продуктов? (trends) Тренды формируют паттерны восприятия и поведения аудитории. Поэтому важно за ними следить, а еще лучше уметь предугадывать. Это поможет обезопасить новые UX\UI решения от провала через короткий промежуток времени.

1. За что любят, а за что не любят продукт? (PROs, CONs) Основной задачей является выявить самые большие препятствия во время использования продукта, раздражающие факторы. Также важно видеть самые сильные стороны. На этих вещах нужно фокусироваться и уделять им больше внимание. Например, один из методов определения этого является Break up/Love letter.
2. Что говорят реальные пользователи? (user reviews, user feedback, support request) Комментарии и обзоры помогут выявить наиболее тревожные моменты или успешные решения в продукте. Но не забывайте, что отзывы могут быть не настоящими, не честными, мотивированными и т.д. Поэтому используйте эту информацию разумно.
3. Что отвечают реальные пользователи? (user interview, surveys) Подготовив вопросы и проанализировав ответы непосредственно самих пользователей можно лучше понять их проблемы, желания и эмоциональное состояние во время взаимодействия с продуктом, а также определить пути улучшения.
4. Что пользователи чувствуют выполняя разные задачи внутри продукта? (user interview, user testing, session capture) Во время взаимодействия с продуктом будут встречаться места, где пользователи будут себя чувствовать не очень комфортно. И не всегда пользователь сможет сказать осознанно что не так. Например, где-то может плохо влиять графика, а где-то процесс загрузки или анимация будет немного раздражать. Наблюдая, как меняется эмоциональное состояние пользователя (например, мимика) можно выявить такие проблемные зоны для последующего улучшения.
5. Что показывает встроенная аналитика? (analytics) Аналитика поможет определить сценарии взаимодействия, потоки пользователей, хорошо и плохо работающие UI элементы, конверсию и многое другое. Важно то, что все эти данные будут собраны в реальной среде. Для качественного анализа нужно создавать “цели” и “метрики” по которым можно будет проверять гипотезы и тестировать разные варианты улучшения.
6. Что показывает внешняя аналитика? (analytics) Используя такие общеизвестные ресурсы как Similarweb или AppAnnie, вы сможете узнать много полезной информации. Например, какими девайсами чаще пользуются, какой возраст пользователей, география и т.д. Это поможет создать портрет (портреты) пользователя, определить приоритеты в разработке улучшений и т.д.
7. Какие сценарии использования продукта для разных персон? (user scenarios) Составление идеальных сценариев достижения цели и сопоставление их реальным (из тестирования или аналитики) поможет определить препятствия и оптимизировать взаимодействие с продуктом. Например, перестроив определенным образом визуальные приоритеты в интерфейсе или изменив содержание элементов.
8. Какие действия пользователи выполняют для достижения целей в разных сценариях? (use cases) Четко определив все элементы взаимодействия и их порядок во время выполнения сценария, можно понять что нужно оптимизировать, как можно упростить или улучшить этот процесс, в чем разница взаимодействия разных персон и т.д.
9. Как отличается поведение разных персон? (persona analysis) Понимание различий в поведении поможет построить в определенных местах компромиссные решения, которые будут удовлетворять максимальное количество пользователей. С другой стороны, можно определить тактически важные места для каждой из групп пользователей и улучшать исходя из выявленного поведения.
10. Какие маршруты проходят пользователи внутри приложения? (user flow) Понимание реальных и идеальных маршрутов поможет выстроить более удобный и эффективных пусть пользователя к целевому действию, например “платеж” или “регистрация”.
11. Какие ключевые маршруты? (red routes, storyboards) Удаление препятствий и создание более комфортного и мотивирующего окружения на этих маршрутах является одной из приоритетных задач. Именно этот путь проходит большинство пользователей для выполнения своих основных задач.
12. Какие параметры можно выставить по умолчанию? (default settings) Исследуя взаимодействие с продуктом, можно определить некоторые параметры, которые будут одинаковыми почти для всех. Такие параметры желательно сразу выставлять по-умолчанию.
13. Какие действия можно автоматизировать? (automation) Если замечено характерное повторение одних и тех же действий, даже если они отличаются у разных пользователей, можно попробовать их автоматизировать сразу или предлагать автоматизировать после достижения определенного количества повторения.
14. Помогает ли система выполнять определенные действия? (automation) Помимо предустановленных настроек и автоматизации некоторых процессов система может помогать выполнять различные действия во время непосредственного взаимодействия. Один из таких примеров это “авто-заполнение” во время ручного набора на клавиатуре.
15. Если ли у пользователя возможность исправить ошибку? (mistakes) Пользователи будут ошибаться и захотят исправлять свои ошибки, помните это. Поэтому желательно предоставлять им такую возможность. Например редактировать текст или изменить случайно выставленный параметр.
16. Есть ли возможность передумать и отменить? (cancel, go back) Должна быть возможность вернуться на несколько шагов назад или отменить действие. Например когда пользователь нажал кнопку “удалить” а потом передумал, желательно предоставить ему возможность восстановить объект нажав на кнопку “назад” или восстановив из корзины.
17. Есть ли возможность сохранить результат? (save) Используя продукт у пользователей часто может появляться необходимость сохранять прогресс, настройки или добавленный контент. Иногда уместно делать авто-сохранение (например при вводе текста), а иногда давать возможность пользователю самому что-то сохранить (например установки рабочей области)
18. Нет ли проблемы выбора? Бывает что действие не совершается по причине раздумий над выбором. Иногда, когда пользователю нужно выбирать, а различия для него не сильно важны, лучше показывать всего несколько вариантов чем множество.
19. Как часто пользуются продуктом? Понимание сколько раз в день, неделю или месяц пользователь открывают продукт и как часто они им пользуются поможет лучше понять, как нужно строить некоторые модули интерфейса или какие сообщения выводить пользователю.

1. Расставлены ли визуальные приоритеты? (visual hierarchy, eye-tracking) Важно управлять вниманием пользователя и подталкивать его к действию или маршруту. Выделять более важные объекты (размер, цвет, порядок и т.д.) и скрывать менее важные. Таким образом вы поможете пользователю быстрее добраться до цели, и в то же время сможете построить выгодный для вас маршрут.
2. Правильно ли используется контраст и акцент? (visual hierarchy, visibility, contrast) Не создавайте очень много контраста. Используйте несколько или один контрастный цвет (цвет-акцент) для элементов частого или целевого взаимодействия, а спокойные и нейтральные цвета для объектов редкого и второстепенного. Контрастный цвет линий разделителей или яркие цвета второстепенных объектов могут отвлекать от целевого действия или маршрута, убивать акцент, усложнять и перегружать интерфейс.
3. Похож ли интерфейс продукта, на другие интерфейсы? (design patterns, intuitivity) Это особенно важно для новых продуктов, которые только выходят на рынок. Пользователи уже имеют много паттернов и часто оценивают удобство нового продукта исходя из своего предыдущего опыта взаимодействия. Это так называемый «синдром утенка» (Baby-Duck-Syndrome). Если вы хотите создать что-то инновационное в интерфейсе, для этого вам уже нужно завоевать доверие и лояльность пользователей, чтобы они смирились с дискомфортом переобучения.
4. Интуитивны ли элементы взаимодействия? (design patterns, intuitivity) Все объекты интерфейса (forms, radio-buttons, checkboxes и т.д) должны выглядеть так, чтобы после взаимодействия пользователь получал то, что ожидает. Использовать узнаваемые элементы и это избавит вас от задачи обучения пользователя.
5. Интуитивны ли цвета и формы? (design patterns, intuitivity) Помните, что уже существуют определенные паттерны восприятия цвета (например “серый” — неактивный, “цветной” — активный) или форм (например “линия” — разделяет или подчеркивает).
6. Читабельные ли шрифты? (fonts, legibility) Убедитесь, что все тексты и цифры хорошо читаются в разной обстановке и на разных устройствах. Не усложняйте восприятие информации непривычными для чтения шрифтами. Можно использовать оригинальные шрифты только для небольшого количества текста. Также не забывайте, что текст всегда должен быть хорошо контрастным с фоном.
7. Последовательна ли подача графики и текста? (style guides, hierarchy, consistency, rhythm) Использование большего количества разных размеров, шрифтов, изображений и цветов плохо скажется на понятности и интуитивности. Для того чтобы продукт проще воспринимался создают логическую графическую структуру с правилами. Таким образом пользователю будет проще запомнить один раз размер, форму, стиль или цвет, чтобы потом воспринимать другой объект с таким же параметром как из такой же логической группы.
8. В одном ли стиле графические изображения? (graphic style) Соблюдение единого стиля поможет создать необходимую атмосферу. Изображение выполненные в другом стиле нарушат порядок, гармонию и восприятие всего продукта.
9. Существует ли порядок в расположении объектов? (alignment, grid) Выравнивание и упорядочивание объектов по четко организованной сетке или правилу упростит восприятие информации.
10. Созданы ли визуальные группы? (gestalt, proximity, unity) Объекты которые находиться рядом или имеют схожие параметры воспринимаются как один (одна группа). Человек привык группировать объекты в одну целостную систему (гештальт-психология). Преподносите информацию соответственно.
11. Используется ли пустое место? (free space, padding) Никогда не забывайте про пустое место. Всегда используйте его для разделения информации, объектов или групп объектов. Если вы видите, что пустого места почти нет, лучше перенесите часть контента на другой экран или следующий шаг. Это поможет избежать перегруженных и сложно воспринимаемых экранов.
12. Не перегружен ли экран информацией? Постарайтесь убрать все лишнее с экрана или хотя бы визуально сгруппировать объекты. Не забывайте что внимание человека ограничено (правило 7+-2). Если у вас много информации, которую надо показать пользователю, показывайте ее фрагментами, постепенно выводя на экран.
13. Настроен ли порядок расположения объектов? Понимая сценарии поведения на одном экране или страничке, можно выстроить расположение объектов так, чтобы на передвижение глаз\курсора затрачивалось меньше времени (закон Фиттса). Например не забывайте про правило чтения слева-направо. Располагайте объекты рядом, если сценарий подразумевает их последовательное взаимодействие.
14. Сбалансирована ли информация и объекты на экране? (balance, composition, proportion) Если это не противоречит другим задачам, старайтесь заполнять экран информацией сбалансировано. Не нарушайте графические принципы композиции, баланса или пропорций, чтобы не создать новые проблемы восприятия всей видимой зоны взаимодействия.
15. Уместно ли используются изображения? (relevant pictures) Изображения, кроме атмосферы, часто выполняет функциональную роль. Например одной из задач, является передача информации. Интуитивные и уместные изображения быстрее помогут адаптироваться к продукту, научат им пользоваться или покажут преимущества. Мелкое изображение должно содержать мало деталей, а крупное много. Не отображайте детализированное изображение на плоскости в несколько пикселей, пользователь просто не поймет что там изображено.
16. Проработан ли микротекст? (microcopy, lorem ipsum) Любой недоработанный микротекст может выбить пользователя из атмосферы показать ему искусственно-созданное пространство. Слова, которые вы используете на кнопке, могут быть инструментом влияния на его решение и логическое продолжения взаимодействия, а могут быть просто словами вырванными из контекста. Никогда не показывайте “lorem ipsum” потребителю, и старайтесь сами его не использовать, даже в команде разработчиков.

1. Как быстро пользователь может добраться до цели? (information architecture, navigation) Желательно чтобы информационная архитектура соответствовала приоритетам в навигации. Пользователь в первую очередь должен иметь быстрый доступ к той информации, которая ему нужна часто и которая важна для него.
2. Интуитивная ли структура для пользователя? (information architecture, navigation) В древовидной архитектуре важно чтобы пользователь с самого начала понимал куда идти, чтобы прийти куда надо. Другими словами, создавая иерархическую структуру, старайтесь чтобы она максимально соответствовала ожиданиям и паттернам пользователя.
3. Последовательно ли сгруппированы данные в системе? (information architecture, navigation) Если пользователь понял логику содержания информации в одной группе, то от второй группы он будет ожидать примерно такой же логики. Поэтому важно соблюдать последовательность в структурировании данных. Например если в группе А он видит А1, А2, А3, то от группы В он будет ожидать В1, B2, B3
4. Настроены ли жесты взаимодействия с продуктом? (gestures, navigation, usage) Чем больше вы дадите возможностей для управления тем большее количество пользователей сможете удовлетворить. У разных пользователей может быть разный опыт взаимодействия с другими продуктами. Некоторые привыкли “кликать”, другие “свайпить”. С другой стороны правильно настроенные жесты сэкономят энергию и время пользователя на выполнение действия.
5. Какое основное устройство для использования продукта? (devices, usage) Это поможет определить приоритет в разработке. Конечно важно чтобы продукт хорошо работал на всех устройствах или платформах, но на основных он должен работать идеально. Также понимание это поможет выявить проблемы, связанные с устройствами взаимодействия, для большинства пользователей.
6. Проработана ли адаптивность/отзывчивость на разных устройствах? (devices, responsive) Очень сложно не только протестировать продукт на всех возможных устройствах но и адаптировать UX под каждое из них. Вы должны разумно подходить к решению этой задачи исходя из времени и имеющихся ресурсов. В любом случае MVP должен хорошо работать на большинстве устройств и процесс выполнения основных пользовательских задач не должен содержать критических UX ошибок.
7. Какая среда использования продукта? (usage, physical environment) Нужно понимать и учитывать пользуются продуктом ночью или днем (яркость и цветовая схема может зависеть от типичного освещения, а сложность управления от усталости пользователя, например после рабочего дня), пользуются ли приложением в транспорте или в кровати (трясется ли устройство или может быть нужно выполнять действия одной рукой) и т.д.
8. Чувствует ли пользователь что все под его контролем? (control) Вся работа системы должна быть под контролем у пользователя. Он должен понимать все что происходит и что он влияет на этот процесс. Например если вы настроили “авто-сохранение”, а пользователь про это не уведомлен, то он может начать волноваться и искать кнопку “сохранить”.

1. Проработан ли процесс погружения и обучения пользователя? (FTUE, onboarding, tutorial) Очень важно сделать первый опыт взаимодействия максимально комфортным, так как после него 80% пользователей принимают решение о использовании продукта. Стройте сразу качественный диалог продукта с пользователем, обучайте его, показывайте преимущества использования, развлекайте его. Старайтесь не просто рассказывать и показывать но и требовать от пользователя действий, чтобы он видел как все работает in use, и в то же время заполнял необходимы данные.
2. Все ли пользователю будет понятно во время исследования новых экранов? (tooltips) Чем сложнее продукт и больше содержит элементов взаимодействия, тем сложнее создать комфортное погружение и обучить его. Разрабатывая первый опыт взаимодействия не следует сразу вываливать на пользователя всю информацию, лучше научить пользоваться MVP. Но в то же время дайте пользователю понять что про “неизвестную панель” можно будет узнать позже или в другом разделе.
3. Можно ли пройти обучение еще раз, если пользователь все забыл? (tutorial) Существует много сценариев, при которых пользователю понадобиться повторное обучение. Дайте ему такую возможность.
4. На понятном ли языке говорит система? (readability) Нужно учитывать не только географию и реальный язык интерфейса, но и стиль языка аудитории. Например с подростками говорить на их сленге, а с преподавателями грамматически правильно. Это сделает коммуникацию более комфортной для пользователя и поможет завоевать его доверие.
5. Реагирует ли UI на действия пользователя? После любого действия с интерфейсом, пользователь должен видеть ответную реакцию. Это может быть изменение внешнего вида элемента, анимация или информационное всплывающее окно. Так пользователь сможет понять что действие выполнено успешно/не успешно и ситуация будет у него под контролем.
6. Объясняет ли реакция UI какое действие произошло? (interaction design, animation) Одним из примеров реакции системы является анимация объектов взаимодействия. Анимация должна не только создавать атмосферу или WOW-эффект но и информировать пользователя про тип действия, который только что произошел.
7. Проинформирован ли пользователь о статусе системы? (system status) После последнего взаимодействия с интерфейсом, даже через время, пользователь должен видеть текущее положение дел и статус системы. Например индикатор загрузки, индикатор офлайн\онлайн, индикатор прочитанного сообщения и т.д. В противном случае пользователю будет сложно понять корректно ли работает система или где-то произошла ошибка.
8. Предугадывает ли система ошибки и пытается ли их предотвратить? (prediction) Определив типичные ошибки, можно постараться их предотвратить, предлагая пользователю более релевантное решение. Например Google говорит “Возможно вы имели ввиду” и предлагает более часто встречающийся запрос. Также в местах распространенных ошибок можно выводить больше объясняющей информации в виде текста или tooltips.
9. Есть ли разделы, где подробно описано как это работает? (help, FAQ) Даже после обучения у пользователя могут быть вопросы. На этот случай должны существовать разделы, куда можно пойти и узнать больше информации. Например такими разделами могут быть разделы How It works, Help, F.A.Q. и т.д. Важно но не только создать такие разделы, но и показать пользователю где они находятся.
10. Соответствует ли сейчас FAQ действительности? (FAQ) Продукт изменяется, изменяется и сама аудитория. Поэтому важно всегда понимать чем чаще всего в данный момент интересуются пользователи. Достаточно ли верно определены самые часто задаваемые вопросы на этом жизненном этапе продукта?
11. Легко ли пользователю связаться с сотрудниками продукта? (support, feedback) Крайне важно дать возможность сообщать про проблему внутри продукта. В противном случае есть вероятность что про эту проблему узнают другие в негативных отзывах на сайте, внешних порталах или магазине, где был скачан продукт. Возможность написать внутри продукта не только понизит риски негативных отзывов, но и даст возможность собрать много полезной информации от самих пользователей.
12. Проработана ли система уведомлений внутри продукта? (notifications, messages, user engagement) Про все ли события, которые могут быть интересны пользователю, сообщает система? Важно не только постоянно уведомлять пользователя но и хранить уведомления, для того что бы можно было просмотреть историю. Сообщения могут быть не только информировать пользователя, но мотивировать использование или определенные действия.
13. Проработана ли система уведомление за пределами продукта? (notifications, messages, user retention) Пуш-уведомления или е-mails должны предоставлять пользователю потенциально интересную для него информацию. Нужно хорошо понимать что и когда писать, чтобы пользователь было хорошо проинформирован и промотивирован вернуться\зайти в приложение, а не воспринимал это как спам. Это могут быть обучающие, мотивирующие, информационные или развлекательные сообщения. Все зависит от контекста.

1. Достаточно ли промотивирован пользователь для основного целевого действия? (target action) Важно понимать обладает ли пользователь достаточным количеством информации про свою выгоду перед тем, как увидит предложение выполнить целевое действие. Чем больше пользователь потеряет энергии или денег во время целевого действия, тем больше нужно его к этому подготавливать. Например, если брать такое действие, как “регистрация”, то часто важно чтобы у пользователя была возможность познакомиться с продуктом еще до того как ему придется выполнять неприятные ему действия, такие как заполнение форм. Если брать кнопку “купить”, то важно понимать сколько до этой кнопки он должен увидеть продающей информации, чтобы принять решение заплатить.
2. Как определить и мотивировать другие полезные действия для владельца? (target action) Важно понимать чего хочет пользователь и что он может за это дать взамен. Взаимовыгодное сотрудничество принесет плоды всем сторонам. Например давать желаемые награды за оценку приложение на AppStore или share в социальных сетях. Помимо того, что такую систему нужно продумать и создать, про такие действия еще нужно напоминать пользователю, показывая выгоду от их совершения.
3. Выполнит ли пользователь следующий этап действий? (steps, progress) Когда пользователь должен сделать много действий (например заполнить много форм) бывает так, что мотивация меньше чем количество энергии, которое пользователь готов на это потратить. Важно определять такие опасные места и строить их по другому. Например можно скрывать все необходимые действия и предлагать их выполнять частями (шаг 1, шаг 2, шаг 3), это уменьшит риск отпугнуть пользователя, а после выполнения одного этапа действий, пользователь уже будет “втянут в процесс” и вероятность завершения всех действий повысится. Люди любят завершать то, что они уже начали делать.
4. Когда пользователь перестает пользоваться продуктом? (updates) Важно понимать жизненные циклы всех пользователей и работать над их продлением. Например обнаружив что некоторые пользователи перестают пользоваться продуктом после решения определенных задач, можно создать новые задачи или предложить им другие награды или преимущества использования. С другой стороны постоянная рутина и отсутствие чего-то нового может заставить пользователя перейти к конкуренту.
5. Осознает ли пользователь все выгоды использования продукта? (awareness) Даже если пользователь решил свои задачи, есть вероятность что он еще не до конца понимает все преимущества использования продукта. Постоянные подсказки и мотивирующие сообщения (например про модули, которые пользователь не использовал) помогут пользователю создать и укрепить осознание помощи, которую он получает от продукта.
6. Видит ли пользователь прогресс и результат? (results, achievements) Видимый результат всегда мотивирует продолжать делать то, что делаешь. Использовать то, что используешь. Поэтому очень важно показывать пользователю этот результат. Например “шкала прогресса” показывает потраченные усилия и сколько еще нужно потратить чтобы добиться определенной цели или бонуса. Достижения, бейджи, трофеи помогают увидеть результат у и мотивируют идти дальше.
7. Поощряется ли использование продукта? (loyalty program, treats, perks) Постоянные дополнительные награды или приятные мелочи хорошо мотивируют продолжать использовать продукт. Это может быть что-то серьёзное (скидки, доступ к другому функционалу) так и не серьёзное (шутки, истории, развлекательные видео).
8. Какие новые вызовы можно создать для пользователя внутри продукта? (objectives, missions, challenges) В основном это касается игр, но тем не менее тут затрагивается психология пользователя, поэтому будет полезно для любого продукта. Суть в том, чтобы создавать дополнительные искусственные задачи, которые пользователь, кроме основных, сможет решать внутри продукта. Помимо самого удовлетворения решения таких задач, пользователя можно награждать чем то полезным или приятным. Один из таких примеров — это “совершение Х-количества определенных действий” в продукте.
9. Комфортно ли пользователю внутри продукта? (comfort area) Чем больше интерфейс будет дружелюбным и человечным для пользователя тем комфортнее и уютнее ему там будет. Речь идет не только про сообщения от системы но и про всю оболочку продукта, всю систему использования. Эмоциональное удовлетворение пользователя необходимо для повышения вовлеченности и лояльности к продукту. Все мы знаем как тяжело выходить из своей зоны комфорта.
10. Внедрен ли элемент развлечения/юмора в продукт? (fun, entertainment, game) Радость и смех, это те эмоции, которые очень благоприятно влияют на пользователя. Когда пользователь эмоционально открыт, доволен и рад, он будет готов совершать больше полезных действий для владельца. Конечно все зависит от контекста, всегда должна быть разумная мера юмора и его уместность. Важно понимать момент, когда нельзя отвлекать пользователя а когда можно его развлечь.
11. Будет ли пользователь ждать? (loading, time) Во время загрузки, ожидания отклика программы или выполнение какого-то процесса системой пользователю придется ждать. Чем больше нужно ждать, тем больше риск что ему это надоест. Как раз в такие моменты можно развлекать пользователя используя разного рода анимацию, юмор, видео. С другой стороны это время можно использовать и для обучения и познания. (обучающие подсказки или интересные факты). Все зависит от того, что ваш пользователь сейчас бы хотел делать больше учиться или развлекаться.
12. Не мешает ли анимация пользователю? (animation) Чрезмерное и не уместное использование анимации, а также ее большой период длительности может мешать процессу, а то и раздражать вообще. Иногда пользователю нужно дать возможность отключать анимацию в меню, или (если это не анимация во время загрузки) прекращать ее воспроизведение после нажатия.
13. Достаточно ли мотивации платить за полученное? (payment) Когда мы говорим про опыт взаимодействия, то мотивацией платить может быть все что угодно. Скорость выполнения задач, комфорт использования, уникальные возможности, неосознанная радость использования и т.д. Наша задача попытаться выяснить за что будет готов платить выбранный пользователь и когда он может принять решение платить. Это поможет простроить правильный процесс погружения в продукт и его flow внутри.
14. Проработан ли социальный статус, самовыражение? (social) Социальное превосходство, желание быть лучше, самовыражение, желание быть замеченным — все это очень сильно влияет на мотивацию выполнять определенные действия внутри продукта. Для этого создают сообщества, рейтинги и дают возможность внутри продукта взаимодействовать с другими участниками процесса.

99 UXQ = Copy+Paste

1. Что самое важное в продукте? (MVP, core features, flowcharts)
2. Что нужно владельцу продукта? (goals, issues, KPI)
3. Как продукт будет зарабатывать? (monetization)
4. Как продукт будет продвигаться и позиционировать себя? (positioning, marketing strategy, promo channels)
5. Как на продукт могут влиять другие заинтересованные лица? (stakeholders, actor map)
6. Как построены бизнес процессы?
7. Какие еще объекты компании могут влиять на пользователя? (customer journey map)
8. Где пользователь может испытывать негативные эмоции вне продукта? (customer experience map)
9. Как продукт может взаимодействовать с другим бизнесом владельца? (global business)
10. Кто аудитория продукта? (target audience, market research)
11. Какие основные проблемы будет решать продукт для своей аудитории? (consumer needs)
12. Знает ли сама аудитория про эти проблемы? (consumer needs, awareness)
13. Какие второстепенные проблемы озвучивает эта аудитория на рынке? (consumer needs, market research)
14. Как все эти проблемы решает аудитория без текущего продукта? (consumer patterns, market research)
15. Какие группы пользователей можно создать из аудитории продукта? (user stories, personas)
16. Кто ваша ключевая персона? (key persona)
17. Какие желания могут быть у разных персон?
18. Кто является платящим пользователем? (paying user)
19. Какие особенные проблемы и желания у платящего пользователя? (paying user)
20. Проработана ли локализация и адаптация языка для разной аудитории? (languages)
21. Что может оскорблять религиозные или политические чувства аудитории? (religion politics)
22. Кто конкуренты у продукта? (market research)
23. Какие группы успешных конкурентов можно создать? (competitors analysis)
24. Как построен UI в успешных конкурентов из разных сегментов? (competitors analysis)
25. Как построен UX у конкурентов? (competitors analysis)
26. Что показывает статистика поведения пользователей у конкурентов? (market research, target audience)
27. Какие отзывы пользователей о продуктах конкурентов? (user reviews, social media)
28. Есть ли статистика или результаты редизайна конкурентов за последнее время? (case studies)
29. Какие UX\UI тенденции на рынке похожих продуктов? (trends)
30. За что любят, а за что не любят продукт? (PROs, CONs)
31. Что говорят реальные пользователи? (user reviews, user feedback, support request)
32. Что отвечают реальные пользователи? (user interview, surveys)
33. Что пользователи чувствуют выполняя разные задачи внутри продукта? (user interview, user testing, session capture)
34. Что показывает встроенная аналитика? (analytics)
35. Что показывает внешняя аналитика? (analytics)
36. Какие сценарии использования продукта для разных персон? (user scenarios)
37. Какие действия пользователи выполняют для достижения целей в разных сценариях? (use cases)
38. Как отличается поведение разных персон? (persona analysis)
39. Какие маршруты проходят пользователи внутри приложения? (user flow)
40. Какие ключевые маршруты? (red routes, storyboards)
41. Какие параметры можно выставить по умолчанию? (default settings)
42. Какие действия можно автоматизировать? (automation)
43. Помогает ли система выполнять определенные действия? (automation)
44. Если ли у пользователя возможность исправить ошибку? (mistakes)
45. Есть ли возможность передумать и отменить? (cancel, go back)
46. Есть ли возможность сохранить результат? (save)
47. Нет ли проблемы выбора?
48. Как часто пользуются продуктом?
49. Расставлены ли визуальные приоритеты? (visual hierarchy, eye-tracking)
50. Правильно ли используется контраст и акцент? (visual hierarchy, visibility, contrast)
51. Похож ли интерфейс продукта, на другие интерфейсы? (design patterns, intuitivity)
52. Интуитивны ли элементы взаимодействия? (design patterns, intuitivity)
53. Интуитивны ли цвета и формы? (design patterns, intuitivity)
54. Читабельные ли шрифты? (fonts, legibility)
55. Последовательна ли подача графики и текста? (style guides, hierarchy, consistency, rhythm)
56. В одном ли стиле графические изображения? (graphic style)
57. Существует ли порядок в расположении объектов? (alignment, grid)
58. Созданы ли визуальные группы? (gestalt, proximity, unity)
59. Используется ли пустое место? (free space, padding)
60. Не перегружен ли экран информацией?
61. Настроен ли порядок расположения объектов?
62. Сбалансирована ли информация и объекты на экране? (balance, composition, proportion)
63. Уместно ли используются изображения? (relevant pictures)
64. Проработан ли микротекст? (microcopy, lorem ipsum)
65. Как быстро пользователь может добраться до цели? (information architecture, navigation)
66. Интуитивная ли структура для пользователя? (information architecture, navigation)
67. Последовательно ли сгруппированы данные в системе? (information architecture, navigation)
68. Настроены ли жесты взаимодействия с продуктом? (gestures, navigation, usage)
69. Какое основное устройство для использования продукта? (devices, usage)
70. Проработана ли адаптивность/отзывчивость на разных устройствах? (devices, responsive)
71. Какая среда использования продукта? (usage, physical environment)
72. Чувствует ли пользователь что все под его контролем? (control)
73. Проработан ли процесс погружения и обучения пользователя? (FTUE, onboarding, tutorial)
74. Все ли пользователю будет понятно во время исследования новых экранов? (tooltips)
75. Можно ли пройти обучение еще раз, если пользователь все забыл? (tutorial)
76. На понятном ли языке говорит система? (readability)
77. Реагирует ли UI на действия пользователя?
78. Объясняет ли реакция UI какое действие произошло? (interaction design, animation)
79. Проинформирован ли пользователь о статусе системы? (system status)
80. Предугадывает ли система ошибки и пытается ли их предотвратить? (prediction)
81. Есть ли разделы, где подробно описано как это работает? (help, FAQ)
82. Соответствует ли сейчас FAQ действительности? (FAQ)
83. Легко ли пользователю связаться с сотрудниками продукта? (support, feedback)
84. Проработана ли система уведомлений внутри продукта? (notifications, messages, user engagement)
85. Проработана ли система уведомление за пределами продукта? (notifications, messages, user retention)
86. Достаточно ли промотивирован пользователь для основного целевого действия? (target action)
87. Как определить и мотивировать другие полезные действия для владельца? (target action)
88. Выполнит ли пользователь следующий этап действий? (steps, progress)
89. Когда пользователь перестает пользоваться продуктом? (updates)
90. Осознает ли пользователь все выгоды использования продукта? (awareness)
91. Видит ли пользователь прогресс и результат? (results, achievements)
92. Поощряется ли использование продукта? (loyalty program, treats, perks)
93. Какие новые вызовы можно создать для пользователя внутри продукта? (objectives, missions, challenges)
94. Комфортно ли пользователю внутри продукта? (comfort area)
95. Внедрен ли элемент развлечения/юмора в продукт? (fun, entertainment, game)
96. Будет ли пользователь ждать? (loading, time)
97. Не мешает ли анимация пользователю? (animation)
98. Достаточно ли мотивации платить за полученное? (payment)
99. Проработан ли социальный статус, самовыражение? (social)

О том, что дальше делать с этим списком вы можете прочитать тут https://goo.gl/hrZO99