A lightweight UX process for app builders

Most app projects don’t go wrong in the build. They go wrong before it, when nobody checked what users actually needed and months went into a polished answer to the wrong question. The fix isn’t a six-month UX engagement. In our agency we run a deliberately lightweight process you can complete in a day or several days, and the results show up directly in the product: easier to use, more intuitive, and far more likely to keep users coming back.

A lightweight UX process is a compressed sequence of research and design steps — a quick survey, a competitor analysis, problem definition, information architecture and userflows, finished with a usability test — that gets you roughly 80 per cent of the value of a full UX engagement for a fraction of the time and budget.

Start with a short survey

Surveys are the workhorse of qualitative research: quick, inexpensive, and easy to run with a tool like Google Forms. Structure matters more than volume.

Open with a short introduction that screens for the right people (“We are conducting research for a UX design project. This survey is relevant if you are a graphic designer working as a freelancer”) and a reassurance that answers are solely for research and will remain anonymous. If your app serves two audiences, say people posting jobs and people seeking them, run two separate surveys. Close with demographic questions (age brackets, gender, location) purely to confirm the data isn’t skewed to the wrong crowd.

The questions themselves should probe the user’s current reality:

• How do you currently solve this problem, online or offline? Hearing how people solve it offline today reveals both strengths and problems of a digital version.
• Do you currently use other platforms, for this problem or adjacent ones?
• What are your favourite existing tools, and which features make them good? Which are your least favourite?
• Which features are genuinely important for completing the task, not just pleasant?
• What are the biggest challenges in completing the task? A home loan application might take so long that people have to leave and come back. Those pain points are gold.

Phrasing is where most surveys fail. Avoid closed questions (“Do you like or dislike this tool?”, “Are you satisfied with the current experience? Yes or no”) and questions that assume familiarity (“How do you like the ordering experience of Uber Eats versus Blue Apron?”). Ask instead: “What made you choose the solutions you used along the way?”, “How satisfied were you with the experience?”, “Walk me through the last time you ordered.” Open-ended questions produce rich answers without steering the respondent.

Share the survey where your audience gathers: social networks, closed Facebook groups, forums. A LinkedIn post like “We’re doing UX research about what makes a strong portfolio site: if you hire freelancers, could you take five to ten minutes to complete our survey?” targets exactly one side of the market. And you don’t need hundreds of responses: ten to fifty is great, especially when consistent themes emerge. If a handful of responses each tells a different story, gather more or redesign the survey.

Turn responses into findings

Analysis means separating the quantitative from the qualitative. Numerical data goes into tables and simple charts (a bar or pie chart is usually enough). Qualitative data is about themes: read the open-ended answers, pull out quotes, group them visually in FigJam, and label the clusters. That sticky-note board doubles as a reference for quotes illustrating each theme.

As an example, research into what makes a strong freelancer portfolio surfaced themes like these: hiring managers want it comprehensive (bio, skills, experience, case studies, contact details all present); case studies matter, but showing the person’s own work, not just contributions to a team project; it must be succinct, because a five-thousand-word case study gets skimmed in the three to five minutes a manager will actually spend; they want a sense of vibe; contact details must be easy to find; and some social proof is reassuring. You can also present ranked importance with counts: twelve respondents put portfolio first, work experience second, testimonials third, while bio photos and formal education barely registered.

Interviews and focus groups yield deeper insight through the same open-ended approach, and you may only need three to ten interviews before themes repeat; the constraint is time and budget, since five one-hour sessions plus synthesis can consume days. Keep interviewing while new themes appear; stop when they don’t. Either way, consider summing it up in a one-page user persona (name, age, job title, traits, wants, needs, pain points) or an empathy map: a visual answer to “what does a typical user look like?”.

Steal your competitors’ research

Competitor analysis is secondary research, and it punches far above its cost. Look at direct competitors (products solving the same problem) and pseudo competitors (similar products in adjacent markets, useful when your own market is thin), asking four things: what’s happening in the space, what features each has built, what their business models and price points are, and where their strengths and weaknesses lie.

The big idea: companies with bigger budgets have already paid for the research, and by studying how they’ve approached the same problems you borrow their learnings for free. Focus on what’s relevant to UX rather than their marketing: information architecture, userflows, layouts, colours, fonts, icons, how many words they use, which features they offer and where the gaps are. And keep a critical attitude: just because a competitor does something doesn’t mean they do it well, or that users like it.

Present the findings as a table: each competitor down one axis, with overview, key features, strengths and weaknesses. A feature-comparison variant works well too: does each platform have a resume builder, on-platform messaging, a social aspect, personalised content? We build these in FigJam (Miro and Lucidchart are fine alternatives), zooming out over the whole research landscape and back in to a single observation like “the site looks empty, there are only two testimonials” or “you can’t get in without providing a credit card”.

Present the research

Before moving to design, compress everything into a summary stakeholders can absorb and you can refer back to. After the research you should be able to: describe the target demographics and user personas; understand the industry; say what competitors do well, badly, and not at all; classify features as essential, important or unimportant; name the pain points users hit in reaching their goals; describe the users’ limitations (an app for elderly or vision-impaired users carries real accessibility constraints); and assess the competitors’ UX and UI, from confusing-or-easy down to their icons, layouts and navigation structure.

A twelve-page report can end in five lines. One of ours concluded: most platforms operate in favour of the employer; freelancers want as much project detail as possible; both sides want to communicate off-platform at some point; people prefer their own networks; and freelancers consistently feel marketplace platforms devalue their skills. Findings like that shape the whole design phase.

Define the problem

Research without a problem statement just produces endless building with no destination. There’s a classic cartoon about a tree swing: how the customer explained it, how the analyst designed it, how the programmer wrote it… and, in the final panel, what the customer really needed. Without a shared definition, everyone is having a stab in the dark.

Two techniques fix this. User stories, from the agile world, are business-facing sentences everyone can align around: as a [type of user], I want to [complete a task], so I can [outcome]. For a portfolio site: “As a hiring manager, I want to quickly understand the candidate’s skills, so I can determine if they are suitable for the position.” Write as many as it takes to break the problem into sub-problems; on larger projects we’ve written full lists per user type and imported them straight into Jira alongside tasks and epics.

Jobs to be done is the sibling technique, centred on the task: when [situation], I want to [motivation], so I can [outcome]. “When I’m looking for a freelancer, I want to find a person with the right skills, so I can get them to build my app.” Use whichever your team aligns around.

Map the information architecture

Information architecture is organising, structuring and labelling content in an effective and sustainable way, adding structure and navigation that simplify complex information for users.

Think of a house: rooms with distinct functions, each with its actions and things. Living room: chill, watch TV; sofa. Kitchen: cook, eat; pots. Products are the same. A recipe app has a search page, browse pages (by popularity, by cuisine), a checkout handling payments and orders, and a profile holding payment methods and user details.

We map this hierarchy in FigJam as a site map, drawing on the competitor analysis to learn how others structure the same information. The payoff is focus: a nav menu with eight or nine options overwhelms people, while two to four scannable options with sub-options underneath is easy to navigate. On our own academy site, the landing page links to courses, mentoring, blog and support, with payments and an application form sitting beneath courses.

Information architecture then flows into the interface as a hierarchy of importance. Squint at a good landing page: the primary call to action (“Tell me more”) is the most prominent element; the contact button in the top-right corner reads as secondary; the nav links are tertiary. The same discipline applies to everything on the page, from headings down to the micro captions beside inputs, and that hierarchy is what makes an experience intuitive: visitors immediately see the most likely actions, and everything else sits where they’d expect.

Draw the userflows

A userflow is a diagram depicting the path a user takes to complete a task while interacting with a product, focused on the user’s needs and the most efficient way to meet them.

A signup form seems straightforward: sign up, land on the homepage, done. Except it isn’t. There’s onboarding after signup. Existing users need a login variant of the screen. Failed logins and incomplete signups loop back until they can progress. Users move between signup and login in both directions, and then there are social logins and password resets. What looks like one arrow is actually a small network of paths, and drawing it exposes every barrier and loop before you build.

Document the main flows your product needs, using a simple key: user, decision, action, screen, notification, back-end process. A typical flow reads like a story: the user lands, clicks the create-an-account call to action, registers, fills in their profile step by step, hits a decision (ready to publish?), loops back to edit or publishes and succeeds.

The whole process, in seven steps

1. Survey. Keep it simple, aim for more than ten responses, and summarise the results.
2. Competitor analysis. This one is critical: at least three companies, preferably five or six, analysing features, strengths and weaknesses.
3. User stories or jobs to be done, to pin down what you’re building and why.
4. Information architecture. Draw a site map showing primary, secondary and tertiary priorities. This matters even for a single-page app: one page with sixteen unranked options is still a navigation failure.
5. Userflow. Diagram the happy path: where users arrive, give inputs, hit validation or decisions, trigger back-end processes and accomplish their task.
6. Wireframes, the draft UI designs for your app.
7. Prototype and usability test. Ask at least three people to use the design in Figma or Bubble, find their pain points, and iterate.

Four principles keep it honest. Don’t lead the users: ask open-ended questions and observe, because you’re gathering data, not selling. Exploit the fact that big companies have already done the research, the 80/20 rule in action. Focus on usability and ease of use, not on being cool; heavily art-directed sites with layered animations and parallax effects are frequently the hardest to navigate. And keep UX research-guided, not a creative free-for-all built on your own assumptions.

Try it yourself

Run steps one to five for something small: a personal or business landing page is ideal (it’s exactly the homework we set in the free bootcamp). Present the findings in a single FigJam file: survey themes, competitor table, user stories, site map, one userflow. You could go deeper in every area, or employ a UX team for six months; this process gets you 80 per cent of the way, and you’ll be surprised at the products people genuinely engage with as a result.

This skill in the AI era

AI has collapsed the cost of building, which makes this process more valuable, not less: when Claude Code can produce a working app in an afternoon, the scarce skill is knowing what to build, and a day of surveys, competitor analysis and userflows is the cheapest insurance available. We run exactly this process before building apps with AI for Sydney businesses, because a well-defined problem is the best prompt there is: the research becomes the spec, the user stories become the acceptance criteria, and the machine does the typing. It’s the pattern we saw coming when we moved from Bubble to AI-assisted coding: definition is the work; construction is increasingly free.