Running an app UX project

Decide what you do not know

UX budgets get wasted researching things you already know and skipping things you assumed.

Write down what you are confident about and what you are guessing at. Who the user is, what problem they are solving, what they currently do instead, why anyone would switch, and what would make them stop. The guesses are the research scope. If everything on the list is a guess, you need discovery before anything else. If almost nothing is, you may need testing rather than research.

Arrange user access before you sign anything

This is the most common cause of a research phase collapsing into stakeholder interviews.

Studios need to talk to people who resemble your users, and finding them is usually the client's job. If you have existing users, get permission and a recruiting route in place. If you do not, agree who is paying for recruitment and screening, since a specialist recruiter is a real line item and finding niche B2B users can take weeks.

Say upfront if access is genuinely impossible. It changes what the engagement can honestly deliver, and a good studio will restructure rather than pretend.

Set the metrics and get the baseline

Agree what improvement looks like before anyone designs anything: activation, retention at day one, seven, and thirty, task completion time, error rate, support volume.

Then measure where you are now. Retrofitting a baseline after launch produces numbers nobody trusts and arguments nobody wins.

Know what your analytics can actually tell you

Most teams discover mid-project that their instrumentation cannot answer the questions being asked. Check now whether you can see funnels, drop-off by step, and behaviour by cohort. If not, fixing that is part of the work and needs scoping.

Match the method to the question

Different questions need different methods, and studios that only ever propose one are applying a template.

Behavioural questions (what do people actually do) need observation, session recordings, or analytics. Motivational questions (why do they do it) need interviews. Comparative questions (which of these works better) need usability testing or experiments. Prevalence questions (how many people think this) need surveys, and surveys are the wrong tool for almost everything else.

Five to eight users per round is usually enough

The instinct is to want statistical significance from qualitative research. That is not what it is for. Five to eight sessions per user type surfaces most serious usability problems, and a second round after changes beats one large round.

If someone internally demands a large sample before believing findings, that is a political problem to solve early rather than a research design problem.

Distinguish generative from evaluative

Generative research explores what to build and happens before design. Evaluative research tests what has been designed and happens during it.

Clients frequently buy one and expect the other. Be explicit about which phase you are funding.

Protect the synthesis time

Research is worthless until someone makes sense of it. Studios that quote a fortnight of interviews and two days of analysis are underscoping the part that produces the insight.

Get flows approved before visuals

Reviewing information architecture and flows in wireframe is faster, cheaper, and more honest than reviewing them dressed in final visual design.

The temptation is to skip ahead because greyscale wireframes are unsatisfying to stakeholders. Resist it. Approving a flow because the visuals looked good is the most expensive kind of approval.

Ask for the states, explicitly

Loading, empty, error, offline, permission-denied, first-run, and end-of-list, for every meaningful screen.

If these are not in the deliverable list, your engineering team invents them under deadline. Put them in scope in writing.

Test the prototype, not the idea

Show people something they can operate. Clickable prototypes at moderate fidelity surface real problems, while concept descriptions surface polite agreement.

Sit in on sessions yourself. Watching a user fail at something you designed changes internal arguments faster than any report.

Feed testing back into design, with time to do it

Testing that happens two days before handoff is theatre. Schedule it early enough that findings can change the design, and budget iteration time explicitly.

Consolidate feedback and separate preference from evidence

“I do not like the blue” and “three of five users could not find the settings” are different categories of input. Say which is which when you send feedback, and rank what matters.

Specification is a deliverable, not an afterthought

If your engineers are building, they need interaction behaviour, transitions, edge cases, validation rules, error copy, and what happens on slow connections. Screens alone leave dozens of decisions to be made by whoever is closest to the deadline.

Ask what the handoff includes and whether the studio is available during the build to answer questions.

Budget design involvement during development

Every build surfaces things the design did not anticipate. A small allocation of design time through the build phase keeps those decisions consistent with the intent. Without it, the shipped product drifts.

Instrument before you launch

Analytics and crash reporting must be live at release or the first weeks of behavioural data are lost, which is exactly the data you need most.

The first version is a hypothesis

Real usage will contradict something you were confident about. That is the research working, not a failure.

Plan a review at four to six weeks: funnel drop-off, where sessions end, what support is hearing, what reviews say. Then a second design round that responds to it.

Watch where people leave, not just how many

Aggregate retention tells you there is a problem. Step-level drop-off tells you where. Session recordings tell you why. All three are needed, and most teams only look at the first.

Read the reviews properly

App store reviews are unrepresentative and still useful, because people describe friction in their own words. Recurring phrasing across reviews usually points at a specific flow.

Rerun testing on the changes

Fixes introduce new problems. A short round of sessions after a significant change is cheap and catches regressions that analytics will not show for months.

Judge on quarters, not weeks

Retention and activation move slowly and are affected by marketing, pricing, and seasonality as well as design. Give the metrics time before drawing conclusions.