Users

Who the solution is for & why they should use it

A solution without a defined user is a solution nobody is responsible for making good: knowing who it is for and why they would use it shapes every other decision.

Users are not an abstract category. For a first AI-assisted solution, the user is usually a specific person or a small, describable group doing a specific kind of work. The closer you stay to a real person with a real problem, the more useful the solution will be when it ships.

Why a user would choose this solution over their current method is a harder question than it looks. Most people already have a way of handling the problem, even if it is slow or annoying. The solution needs to be noticeably better, not just technically capable. That means understanding what the current method actually costs them in time, attention, or frustration.

For AI-assisted solutions, there is also a trust dimension. Users who do not trust the output will not act on it, even if it is good. Knowing that about your users early means you can design in the review steps and transparency that trust requires, rather than adding them after the fact when skepticism shows up.

Make it visibleIdentify one real person who would be the primary user of this solution. Spend fifteen minutes with them (in person, on a call, or in a message thread) describing the solution and asking what would make them trust it enough to act on the output. Write down what they say and use it to adjust the design before you build.

Why AI needs this

Each part of your work matters to AI in a specific way. Some of it is context a tool needs before it can help, some of it is work a tool can take on, and some of it is judgment that should stay with you.

Who reviews the output

AI output almost always needs a human to decide whether to use it. Naming the user makes it clear who that reviewer is and what standard they will apply.

Adoption is not automatic

A solution that works technically but does not fit how its users actually work will not get used. Understanding the user's real workflow before you build is cheaper than redesigning after launch.

Trust by design

If users are skeptical of AI, that is a design input, not an obstacle. Building in transparency and control for users who need it is a feature, not an afterthought.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

Can you name a specific person who would use this solution today, and describe what their workday looks like?
What does the user currently do instead, and what would make the solution clearly better than that?
How much does the user need to trust the output before they act on it, and what would give them that trust?
Does the user have the skills, access, and time to use the solution as you have designed it?
Who else is affected when the user uses the solution, and do they need to be involved in the design?

Readiness traps

Building for a fictional average user instead of a real, specific person almost always produces a solution that does not quite fit anyone.
Assuming users will change their behavior to fit the solution is a recurring trap: the solution needs to fit the user's existing work pattern, especially for a first version.
Users who are not involved in the design tend to find the gaps immediately after launch: even one conversation with a real user before you build will catch more issues than any amount of internal review.