Build for one real person first.

Start with the person, not the feature list

Most people come to AI asking, “What can this do for my productivity?” Some of the best projects start with a different question: “What does this one person need, and what gets in their way?”

Building for one real person means you design around their priorities, their abilities, and their day, instead of an imaginary average user. Before choosing any tool, I ask:

• What movement or action is reliable for them?
• How long can they keep it up before they get tired?
• Which choices matter most to them?
• Which language are they comfortable in?
• What causes fatigue or confusion?
• Who will set it up and support it when something goes wrong?

Here's an everyday version. Picture an older relative who finds their phone stressful. The icons are tiny, there are forty apps, and one wrong swipe opens something they don't understand. You could teach them the whole phone. Or you could ask what they actually want to do. Maybe it's three things: call their daughter, see photos of the grandkids, and check the weather. Now the job is clear: one screen, three big buttons, nothing to get lost in. The same goes for a teammate's one awkward daily task: build for their exact workflow, not “everyone in the office.”

Write the needs in their order, not yours. For my girlfriend, the top of the list was basic communication like yes, no, comfort, and the people who matter. Not the tracking tech I was excited about.

Pick the easiest input that works every time

An input is how the person tells the tool what they want. The rule I follow: choose the lowest-effort input that works reliably for them. In order of simplicity, that might be touch, a single switch (one big button), head tracking, a hand gesture seen by a webcam, or eye gaze, which a professional should evaluate. “Reliable” can change from day to day as fatigue and recovery change, so a good tool supports more than one input.

Then test something tiny before adding more: a handful of large, high-contrast buttons. Give control over dwell time, which is how long you rest your gaze or pointer on a button before it counts as a press. Show a clear confirmation before the tool speaks a choice. Short one-word options reduce mental effort, but they also remove nuance, so the person must always be able to reject, correct, or expand a choice.

Measure what matters to them, and keep a way out

The right success measure was never lines of code. It was whether she could get her message across with less effort and fewer misunderstandings. Whoever you build for, measure the things they feel:

• Accuracy: did the button they meant get pressed?
• False activations: how often did something trigger by accident?
• Fatigue: how tired were they after ten minutes?
• Recovery: when it froze or lost calibration, how fast could a helper get it running again?

Always provide a non-AI fallback, like a printed paper board, and a clear, obvious way to stop the system. Never route anything urgent through an experimental tool without it. For the phone example, that's a printed card with three phone numbers.

Privacy and consent are part of the design. A camera pointed at someone's face is sensitive. Prefer tools that process on the device, store as little as possible, protect any API keys (the passwords your code uses to reach an online service), and ask for consent.

Bring in qualified people early. For communication tools, that means an occupational therapist, speech-language pathologist, or assistive-technology professional. AI can help you document and adapt. It must not replace their assessment. Not medical advice: evaluate any assistive setup with qualified clinicians and the person who will use it.

Where AI actually helps

AI didn't design the tool. Her needs did. What AI did was shorten the path from research to a working trial. In the waiting room, ChatGPT helped me customize and simplify the board. Later, an AI coding assistant helped me connect existing open-source tools and wrote small setup scripts. That turned my research into something we could actually test.

But a prototype is not the same as dependable support. Someone has to calibrate it, charge it, clean it, fix it, and update it for as long as it's needed. Prototype cost is not lifetime support cost. If you're turning a trial into real software, build it one proven slice at a time.