Start with context
Describe who is trying to do what, in which moment, and what makes that moment difficult today.
Mobile product field notes
Plan the app before the pixels.
Jovemuraki is a calm, practical place to shape a mobile product: clarify the problem, decide what belongs in a first release, and learn through a prototype before the plan hardens.
Frame name the useful change
Shape make the first slice clear
Learn observe a real task
Make choices visible
Turn the vague “app idea” into a small set of flows, assumptions and trade-offs a group can discuss.
Learn in the moment
Use a lightweight prototype to see whether a person can recognize, understand and complete the intended task.
A better starting point
A product is a promise about a moment in someone’s day.
Mobile planning improves when it begins with a human situation rather than a feature list. A clear situation gives design, engineering and stakeholders something concrete to examine together.
“When I’m trying to ___, I need a way to ___, so I can ___.”
The planning path
Four moves to make a first release intelligible.
These are not gates. They are recurring conversations. Move back when a new observation changes the direction.
Keep the artefact small enough to change.
Early plans work best when they invite useful disagreement instead of locking a group into a polished answer.
Frame the situation
Collect the trigger, the setting, the workaround and the consequence. Write down the words people actually use.
Choose the smallest valuable loop
Identify the beginning, the meaningful action and the evidence that the person has reached an outcome.
Sketch the decision points
Map choices, states and edges in plain language before debating screen treatments or implementation details.
Put a prototype in the task
Ask someone to work through a realistic prompt. Notice where their expectations and the product’s wording diverge.
Planning lenses
Look at the same idea from more than one side.
A balanced plan holds a user’s task, a product decision and a buildable shape in view at once.
Task
The person’s path
What starts the task? What has to be understood? What lets a person know they are finished?
Decision
The product’s point of view
What is the app choosing to make simpler, safer, more visible or easier to revisit?
Shape
The first release
Which focused loop should be coherent now, and which ideas should wait until there is more evidence?
Questions worth keeping
Use these lenses to deepen the conversation.
01
Situation
What changes in the person’s environment when this task begins?
02
Confidence
What needs to be clear before someone is comfortable moving forward?
03
Recovery
How does a person regain their place when attention is interrupted or a choice changes?
04
Boundaries
What should the first release deliberately leave out so the central loop stays understandable?
Work at the right altitude
Different questions need different planning artefacts.
Switch the horizon to see what each conversation is trying to make clear.
Intent & context
Use a short situation statement, a map of the current workaround, and a record of uncertainties. This is where teams name the change the product is meant to support.
A specific moment, not a generic audience.- The practical consequence of the current problem.
- Questions that need observation rather than debate.
Flow & interaction
Use a task path, simple states, and a prototype. Keep the focus on what someone needs to recognize and decide at each moment.
- One clear primary path through the task.
- Words that match the person’s mental model.
- A recovery path for a pause, mistake or changed mind.
Release & learning
Use an explicit first-release boundary and a learning plan. This turns “what is next?” into a small number of useful observations.
- A description of what is intentionally absent.
- A safe, realistic prompt for a prototype session.
- A note-taking plan that separates seeing from interpreting.
Prototype with purpose
Test an assumption, not a performance.
A useful early session is an observation of someone trying to make sense of a realistic task. It is not a test of the person, and it does not need a finished interface to be revealing.
Set a small promptGive the person a situation and an outcome, not a prescribed sequence of taps.
Watch the interpretationNotice labels, hesitations and questions before stepping in to explain.
Capture what changedTurn observations into decisions, then revise the prototype for the next conversation.
A shared readiness check
Before detailing screens, make the core agreement visible.
Use this local checklist to surface gaps in a planning conversation. It does not score a product; it simply shows what the group has named so far.
First-release clarity
0 / 5 namedThe product brief
A useful brief is an invitation to inspect the work.
Keep a brief short enough to revisit. It should make intent, boundaries and open questions available to the people shaping the product.
One-page starting brief
Situation
What moment are we trying to improve, and for whom?
First loop
What action and outcome must feel coherent in the first release?
Constraints
What boundaries or responsibilities shape the solution space?
Learn next
What could change the direction if we observed it?
Common questions
Make room for the questions behind the request.
Planning becomes more useful when uncertainty has a place to live.
Start with one recent, concrete moment. Ask what a person was trying to do, what they did instead, and what made the experience difficult. A narrow account is more useful than a long list of possible features because it gives the team a situation to examine and improves the quality of the next question.
Describe the smallest end-to-end loop that produces a meaningful outcome for a person. Then name what the loop does not include. The boundary is not a promise that the omitted ideas never matter; it is a way to protect a coherent learning conversation before the product tries to cover every possible path.
A prototype should answer one or two specific questions, such as whether a label is understood, whether a sequence matches expectations, or whether a person can tell what happens next. It does not need to represent every state. Explain the context, give a realistic prompt, and observe the person’s interpretation before offering help.
Separate observations, assumptions and decisions. A person may disagree with a decision, but that conversation is clearer when everyone can see what was observed and what remains uncertain. Keep the artefact small, record the next question, and return to the shared task instead of treating a screen as the entire product.