Design An App moves through seven stages: problem definition, journey mapping, wireframes, a clickable prototype, usability testing, visual design, and design handoff.
The order matters more than the tooling. Each stage produces one artifact that the next stage consumes, so a weak problem statement shows up later as a confusing screen, and a skipped journey map shows up as a prototype that testers cannot navigate. The sequence below keeps those dependencies visible.
- Define the problem — produces a one-sentence problem statement and a named target user.
- Map the core user journey — produces a step-by-step path from entry point to completed goal.
- Sketch low-fidelity wireframes — produces screen layouts with content blocks and no visual styling.
- Build a clickable prototype — produces linked screens that respond to taps or clicks.
- Test with five to ten target users — produces a ranked list of observed friction points.
- Apply visual design — produces a styled interface and a reusable component system.
- Prepare design handoff — produces annotated screens and states for whoever builds the app.
How to design an app. the seven stages in order
The seven stages above are sequential for a reason. Problem definition and journey mapping are cheap to change and expensive to skip. Wireframes and prototypes are cheap to throw away. Visual design and handoff are the point where changes start costing real build time, because a colour or spacing change ripples through every screen that shares a component.
That split is the practical answer to how to design an app without over-investing early. Decisions made in stages one and two are reversible at almost no cost. Decisions made in stages six and seven are not, because they are already expressed in a component system that a developer will implement.
Stage 1: Define the problem the app solves
A problem statement is useful only if it names a specific person and a specific moment of friction. "People find it hard to book services" is too broad to design against. "A customer who has already chosen a service cannot see which time slots are free without calling" points directly at a screen.
Write the statement in one sentence, name the user, and name what they currently do instead. That last part matters because the substitute behaviour is the real competitor. If the current workaround is a phone call that takes two minutes, the app has to beat two minutes, not beat nothing.
This stage also sets the minimum viable product boundary. An MVP is the smallest set of screens that lets the named user complete the named goal. Anything that does not serve that goal belongs in a later release, however obvious it seems.
Stage 2: Map the core user journey before any screen
A user journey is a written sequence, not a diagram. It starts at the entry point, lists each decision the user makes, and ends when the goal is complete. Writing it as text forces the gaps into the open, because a missing step cannot hide behind an arrow.
Keep the first version to a single journey. Apps that try to map every path before building anything tend to stall, because the map grows faster than the decisions. One journey, one goal, one path.
Two things usually surface here. The first is an entry point the team had not considered, such as a user arriving from a shared link rather than the home screen. The second is a decision the user cannot make without information the app does not yet show. Both are cheaper to fix in a sentence than in a prototype.
Stage 3: Sketch low-fidelity wireframes
Wireframes show layout and content priority, not appearance. Boxes, labels, and placeholder text are enough. The purpose is to answer what appears on each screen and in what order, before anyone debates colour.
Sketching on paper first is faster than opening a design tool, and it keeps the conversation on structure. A wireframe that takes two minutes to draw is easy to discard. A polished screen that took two hours is not, and that sunk cost quietly shapes decisions that should be made on evidence.
Wireframes also expose the states that a happy-path journey hides: empty states before any data exists, loading states, error states, and the state where a user has partial information. Each of these needs a wireframe, because each is a screen a real user will see.
Stage 4: Build a clickable prototype
A clickable prototype links wireframes so that tapping a button moves to the next screen. It does not need real data, real logic, or visual polish. It needs enough fidelity that a tester can attempt the core task without being told where to tap.
This is the stage where the journey map gets tested against reality. If testers consistently tap the wrong element, the problem is usually the journey or the wireframe, not the prototype. Fixing it here costs minutes. Fixing it after visual design costs days.
Keep the prototype to the single journey mapped in stage two. A prototype that covers every feature takes longer to build and produces muddier feedback, because testers spread their attention across paths that were never the priority.
Stage 5: Test with five to ten target users
Usability testing at this stage is about observation, not opinion. The protocol is short enough to run in a single session per participant.
- Give the participant the goal in plain language, without naming the screen or the button.
- Ask the participant to think aloud while attempting the task.
- Record where the participant pauses, backtracks, or asks for clarification.
- Note the task outcome. completed unaided, completed with a hint, or not completed.
- Repeat with the remaining participants before changing the prototype.
Running all sessions before making changes matters. Changing the prototype between participants means the later sessions test a different design, and the results stop being comparable. Five to ten participants is enough to surface repeated friction; the value comes from the pattern across sessions, not from any single comment.
Separate what participants did from what they said. A participant who says the flow was easy but tapped the wrong element three times has given two different signals, and the behaviour is the more reliable one.
Stage 6 Apply visual design and a component system
Visual design starts once the structure survives testing. Type scale, colour, spacing, and iconography get applied to screens that already work. Doing this earlier means restyling screens that may be cut.
A component system is the reusable set of buttons, inputs, cards, and navigation patterns that the app is built from. It exists so that a change to the primary button happens in one place rather than on every screen. Building it during visual design, rather than after, prevents the drift that appears when similar elements are styled separately.
The trade-off is real. A component system takes longer to establish than styling screens individually, and for a very small app with a handful of screens the difference may not pay back. For anything expected to grow, the cost of retrofitting consistency later is higher than the cost of defining it now.
Stage 7 Prepare design handoff
Design handoff is the transfer of decisions to whoever builds the app. A handoff that consists only of finished screens leaves the builder guessing about states, spacing rules, and behaviour. Annotated screens, the component system, and the tested journey together remove most of that guessing.
Handoff is also where the earlier stages pay off. A builder who receives a tested journey, a defined component system, and documented states spends time implementing rather than interpreting. A builder who receives a folder of screens spends the first week asking questions that stage two already answered.
Where the process commonly stalls
Most stalls happen at one of three points. The first is an unresolved problem statement, which shows up as endless debate about features because there is no agreed goal to measure them against. The second is a prototype that grows beyond the core journey, which delays testing and dilutes the feedback. The third is visual design starting before testing, which locks in screens that testing would have changed.
A fourth, quieter stall is treating the process as linear when it is not. Testing findings send the work back to wireframes or the journey map, and that is the process working as intended rather than failing. The stages are ordered by cost of change, not by a rule that each one is visited exactly once.
For teams in Malaysia building a first app, the practical constraint is usually attention rather than tooling. The stages that require the least equipment — a written problem statement, a text journey, paper wireframes — are the ones that prevent the most expensive rework later.
Blackstone Intelligence, a Kuching-based AI systems and digital growth agency operated by Blackstone Consultancy Sdn Bhd, works across AI automation, web systems, and software development, and its public case studies include AI-supported course development for University Technology Sarawak and local SEO work for Eyonic Sdn Bhd and Sinar Saredah Sdn Bhd. Those projects show the same delivery pattern this article describes: define the workflow, structure the information, then build and refine against feedback.