Just-Enough Research for Solo Designers

The Context Nobody Gives You

The phrase "just enough research" comes from Erika Hall's book of the same name, which treats research as a short cookbook of methods anyone on the team can learn and run. Hall wrote that for a world where most designers had at least one researcher somewhere nearby, which is not the world you and I are in. Mule Books

In 2024, 14% of surveyed organizations had zero dedicated researchers, double the prior year and the highest rate since 2020. A fifth of companies had laid off researchers in the prior year, and 62% of organizations reported no ResearchOps function, up from 50% in 2023. Mid-level designers are suddenly doing research they were never really taught to do, on timelines they do not own, with no one watching for mistakes. user interviews

At the same time, 80% of researchers and designers running research now use AI tools, up more than 20 percentage points year over year. As someone who has helped teams wire AI into research workflows, I can confirm the tooling floor has dropped a lot: solo designers now have AI-moderated interviews, automatic synthesis, free behavioral analytics, and unmoderated testing tools that simply were not practical a few years ago. user interviews CleverX

So the question is not "should we research." It is "how do we do enough, given the team and calendar we actually have."

The Core Problem With Doing Research Alone

Before you pick a method or open a testing tool, solo designers run into one big structural problem. No one is around to push back on your interpretation.

On a two-person team, every hot take about what a user "meant" can get challenged by someone who watched the same session. When you are alone, your starting hypothesis usually survives the whole process, unless the evidence is so obvious that it punches through your story about the design. Most research evidence is not that dramatic. User Intuition

Studies in design and cognitive psychology show that both disconfirming and neutral information get misread as confirming what we already believed, especially when we are tired or personally invested. If you built the prototype and ran the test, you are actually in the worst position to interpret what broke. Not because you are bad at your job, but because you are human. Guerilla Girl ScienceDirect St. Jude

The more time and pride you have sunk into a prototype, the harder it is to accept that the core flow is off. I have watched teams (including my own, in past lives) cling to a flow for weeks longer than the data justified.

So the starting problem for solo work is not "how do I find participants" or "which method is cool." It is "how do I keep myself from believing the first story my brain wants to tell about this data."

The Three Structural Gaps Solo Research Faces

The "Just Enough" Principle, Sharpened

Hall's core idea still holds. Just enough research means "enough to make this specific decision with acceptable confidence, given what it costs to be wrong."

The move that saves the most pain is boring but powerful: clarify your goal before you touch a method. Mule Design has a nice way of putting it: know how and when you will use the insight before you plan any research. Write down your research question before you pick activities. A lot of solo research dies quietly because the question was fuzzy, so the findings could support absolutely anything. Mule Design

A simple 2×2 helps you right-size effort. Plot your current question by:

• Problem clarity: How well do you understand what people actually need?
• Risk of being wrong: What happens if you ship the wrong thing?

Most solo designers I talk to (and work with) default into "high-fidelity prototype and evaluative testing" regardless of the quadrant, because that is the muscle they have. The 2×2 is just there to interrupt autopilot. UX Collective UXR Guild

The Zero-Budget Arsenal

Let us talk about the fun part: doing real research with roughly the budget of two coffees and a bus fare. I have run a lot of these setups with teams that had "no budget" written in bold italics on their roadmap, including some case studies you can find on abseth.com.

Guerrilla Testing

Guerrilla usability testing is walking into public spaces like coffee shops, libraries, coworking spaces, or campus lobbies with a laptop or phone and asking strangers for 5-10 minutes. No scheduling, no incentives, no lab. Maze

Its job is to catch serious usability issues before engineers spend a week baking them into production. It is not meant to be your sole research practice, but it is miles better than shipping based on your own gut. Thinking Design

How to run a coffee shop test without feeling like a street magician:

1. Pick your spot. Go where people linger. Independent coffee shops and libraries beat train stations nine times out of ten. Please also do not test your very niche B2B compliance dashboard on random students unless they actually look like your users. Bitovi
2. Approach like a human. Give people a minute to settle, then say something like: "Hey, I am working on a new app and I want to see if it makes sense to regular people, not tech folks. Would you have five minutes to click through it? There are no wrong answers. I am testing the design, not you." That last bit matters more than it should. Koji
3. Ask for tasks, not opinions. Give people something to do: "Can you try to sign up for a free account?" is good. "What do you think of the design?" is how you collect vague opinions that age poorly in Figma comments.
4. Use think-aloud. Ask them to say what they are thinking as they go. You will hear all the "Wait, where is X?" moments in real time. This protocol is still the best free research tool out there. Racoonn
5. Aim for 5-10 short sessions. Ten would be great, five is usually enough to surface the loudest problems for a solo designer on a tight day. Thinking Design

One important caveat. Guerrilla participants are a convenience sample. They do not stand in for domain experts, or highly specific users, or people with particular access needs. Guerrilla testing tells you whether a flow is fundamentally broken, not whether it is the best fit for your exact audience. Maze

Hallway Testing

Hallway testing is the indoor version of guerrilla. Instead of leaving the building, you stop a colleague, visitor, or in-office customer who has not seen the work and ask them to do a task while you watch.

It costs nothing and reveals obvious problems quickly, but coworkers are also unusually good at trying to guess the "right" answer. Use hallway tests to catch glaring issues like broken entry points, unreadable labels, or completely invisible buttons. Do not use them as your only signal for whether a product concept is good.

A simple rule: if someone looks confused or starts asking you questions within the first 10 seconds, something in the setup is off. You do not need a 30-minute session to confirm that.

Support Ticket Mining

Every support inbox and review feed is a research dataset that most teams barely touch. I have done "ticket mining" projects that uncovered more actionable UX issues in two hours than a month of scheduled interviews.

A lightweight process:

1. Pull the last 50-100 tickets or reviews.
2. Make a simple spreadsheet with columns for category, frequency, and source.
3. Tag issues and sort by frequency.
4. Treat the top three to five recurring categories as your highest-priority UX problems for now.

These issues come from people who cared enough to say something instead of quietly leaving, which is its own kind of filter.

If you work on B2B tools, also scan G2, Capterra, and Trustpilot for your product and competitors. Negative reviews are basically "jobs-to-be-done, but angry."

Competitor Teardowns

Use three to five competitor products and document where people will likely struggle and where the product does something surprisingly nice. The patterns that show up across tools are the mental models your users are already trained on.

When you ignore those patterns, your product feels broken before your onboarding has even started. When you lean into them, you feel "intuitive," which is often just a fancy way of saying "familiar."

This exercise also gives you a benchmark: where you are already stronger than the market and where you are not. You can see examples of this teardown style in a few breakdowns on my site, abseth.com.

5-Second and First-Click Tests

For digital interfaces, 5-second tests and first-click tests are the online cousins of guerrilla testing. They are great for quick "Does this land?" checks.

• Tools like Lyssna give you 5-second and first-click tests on a free tier with limited but useful responses.
• ValidateThat.io lets you upload a screenshot, give people a task, and see where their first click goes.
• Plain Figma and Google Meet is still one of the most underrated free stacks for quick remote tests.

In a 5-second test, you show a screen for five seconds, hide it, then ask what they remember and what they think the product does. If people cannot tell what you do or who you are for, that is useful information before you pay for fancy illustrations.

Online Community Testing

Recruiting without a panel budget is very doable, especially for consumer products.

Some reliable places:

• r/samplesize for general consumer products.
• Domain subreddits like r/personalfinance or r/webdev for more specific tools.
• LinkedIn messages framing things as "5-minute feedback" instead of 45-minute interviews.
• Slack and Discord communities with research or domain channels.
• Your own email list and in-app prompts.

The single strongest pattern I have seen: emailing your users with a clear subject ("5-minute study on billing page"), repeating the time commitment, and being honest about what you are testing. Vague "we would love your feedback" invites mostly get archived.

Microsoft Clarity

For behavioral analytics, Microsoft Clarity is currently the most generous free option I recommend to teams. Unlimited traffic, session recordings, and heatmaps, with extra signals such as rage clicks and dead clicks.

The practical move is to install it once on your live product or staging environment, let it run quietly in the background for a week or two, and then look at rage and dead clicks before you schedule any user sessions. You will often discover problems that would have eaten half your interview guide.

Clarity does not have surveys or interviews built in, which is fine. It is there to show you what people actually do, not what they say they do.

The Free Stack, In One Table

Here is what a realistic zero-budget stack looks like for a solo designer or tiny team:

The combo of Clarity, Google Forms, Google Meet, and you with a notebook covers the full loop from behavior to decisions. Everything else is comfort and speed.

The Methods Ladder for One Person

Once your free tools are in place, you can scale effort based on decision stakes instead of vibes.

Building Bias Checks Into Solo Work

If you do not deliberately design for bias control, your research will quietly support whatever you believed last week. Here are a few small systems that help.

Confirmation Bias

• Write down your hypothesis and its opposite before you start.
• Tally evidence for and against both during each session.
• Schedule one "disconfirmation" pass over your notes to check for contradictory data.
• Ask yourself, "What would I need to see to change my mind?" and be specific.

Leading Questions

• Have someone else skim your script and circle anything that sounds like a hint.
• Replace "How would you get to settings?" with "What would you do next?" type questions.
• Shuffle question order occasionally to avoid anchoring everything around your first prompt.

Treating N=3 as a Finding

• Treat single quotes as "interesting signals" that might deserve more attention, not as data you build a whole recommendation on.
• Phrase findings with counts: "Three of five struggled to find notifications" instead of "People find navigation confusing."

Stopping Too Early

• Decide your minimum sample size before the first session.
• When you feel done, check whether you are stopping because patterns converged or because your calendar did.

A Solo Research Stack for 2026

When you are ready to add a bit of budget, this is how I usually see stacks evolve:

For most solo designers I work with, the first genuinely game-changing upgrade is a participant recruitment platform. Tools are cheap; reliable humans are not.

AI saves time on synthesis, but it is still worth scanning raw transcripts before reading the summary. The messy parts often contain the story you really need for stakeholders.

Continuous Discovery, Solo Edition

Teresa Torres's continuous discovery model was built for product trios, but there is a lightweight solo version that actually works: one conversation per week.

This does not have to be a full-blown study. A 20-minute chat with a user, customer support rep, or sales engineer where you ask about their world (not your latest design) is enough. Take one to three notes and tag them in your log. Twelve weeks of doing that quietly changes how you design.

The trap to avoid is turning every conversation into a stealth validation session for your current feature. These are for widening your view of the problem, not proving your solution is right.

When It Is Fine to Skip Research

You do not need a study for every pixel. A simple lens:

• If the decision is urgent and reversible, ship and instrument.
• If it is urgent and hard to reverse, do a tiny amount of research instead of none (Levels 1-2).
• If you have already spoken with dozens of users in this area recently, small low-risk tweaks probably do not need more research.

Skip research when no one will act on the findings, when the real decision was made weeks ago, or when the primary goal is political cover. Life is short.

A One-Person Research Repository

Most solo designers have "insights" scattered across docs, decks, screenshots, and their own memory. Future you will not remember where any of that is.

Three simple habits:

1. After each study, spend 30 minutes logging the brief, method, top 3-5 insights with quotes, and tags for product area, segment, and theme.
2. Keep insights small and falsifiable: "New users skip the settings icon because it looks decorative" beats "Users find settings confusing."
3. Add dates and product versions and assume anything over a year old needs a quick check before it drives a big decision.

There are fancier repository setups (I break down one on abseth.com), but even this minimal approach pays off quickly.

Selling Research When You Are the Only Researcher

In low-trust environments, "research is important" is a weak pitch. "Research saves us money and embarrassment" is better.

Some lines that tend to land:

• "The last time we fixed a similar flow after launch, it took three weeks of engineering. A one-hour test this week is cheaper."
• "We have [volume] users in this flow. A one percent lift is worth about [dollars]. A half-day guerrilla test costs us coffee and time."
• "If this launch goes poorly, the remediation cost is easily 100x a small study right now."

Also, write things up. A short page with findings, quotes, and a one-sentence recommendation is something people can link and argue with. An undocumented test is just a story you tell in a meeting.

The Escalation Table

Here is a quick way to match decision type to method:

You do not need research to be grand, expensive, or beautifully branded for it to be useful. You just need it to be honest about what it can answer, sized to the decision at hand, and recorded well enough that someone else can see how you got there.