What a 14-week product engagement actually looks like.
A 14-week engagement is not 14 weeks of screen design. It is a sequence of decisions: understand the problem, test the risky parts, build the system, then hand over something a team can use.
“We need an app designed in 14 weeks” sounds like a schedule. It is really a question about what has to become true before development can begin with confidence.
Weeks 1–2: make the problem smaller
We start with the people, the business goal and the constraints. That means stakeholder sessions, existing evidence, the technical realities and a clear definition of the primary user task. Not a giant requirements list. The part that matters.
Weeks 3–5: find the risky path
We map the journeys that can make or break the product — onboarding, booking, checkout, approval, whatever the product asks people to do. Early flows and rough prototypes expose missing decisions before they become expensive screens.
The quickest route to a polished wrong answer is starting in high fidelity.
Weeks 6–9: test and decide
We put the risky journeys in front of people, learn where the language or order fails, and revise. Research does not need a laboratory. It needs real tasks and permission to change the work.
Weeks 10–12: build the system
Once the direction holds, we create the UI system: components, states, responsive behaviour, accessibility rules and the awkward edge cases that make a design usable outside a presentation.
Weeks 13–14: make handover usable
The final stretch is not a file dump. Development handover needs annotated flows, prioritised scope, decisions recorded and a working relationship with the people building it. The timeline changes with the project. The order usually should not.
