A task and state model
Proposed output: the main journeys, permissions, inputs, results and important failure states.
Division 04 / Turn a task into a usable product
The task comes before the feature list.
App development starts with a person trying to do something. Describe that task, its context and what a useful first version needs to make possible.
01The work in context
Start with the task someone needs to finish.
An application becomes difficult to scope when every idea looks essential. A clear user task helps separate the first useful release from features that can wait.
01 / PERSON AND TASK
The task
Who uses the app, where they use it and what they need to complete. Include what happens when a step fails or information is missing.
02 / FIRST RELEASE
The first release
Define the smallest coherent experience, its data needs and its dependencies. Platform choice follows those constraints; no stack needs to be assumed at the first inquiry.
03 / EVERYDAY USE
The operating reality
Discuss access, updates, ownership, support and any distribution requirements early. A working interface is only part of a usable application.
02 / Define the engagement
Proposed scope · Awaiting business confirmation
Make the deliverables part of the conversation.
An agreed application release
Proposed scope: implementation of the defined first version on the platforms confirmed for the engagement.
A release and handover record
Proposed output: acceptance checks, known limitations, configuration guidance and responsibilities for the next release.
These are proposed scoping topics, not a fixed package or a delivery promise. Methods, outputs, responsibilities, timing and fees need to be confirmed before an engagement.
03 / A useful first message
Start with what you know.
- Who will use the app, and what task will they complete?
- Where does it need to work, and what must it connect to?
- What belongs in the first useful release?
Keep the first message high-level. Do not include passwords, access tokens or confidential records.
04 / Questions worth asking
A few things to know.
Should this be an app or a website?
Start with the user’s context: devices, access, frequency of use and required behavior. The appropriate form follows the task and constraints. You can make an inquiry before deciding.
Can I bring an early idea?
Yes. Explain who it is for and the task it should make possible. A useful scope discussion identifies the uncertain parts as well as the features you already understand.
Which platforms and technologies are available?
The platform and technical scope need to be confirmed for the engagement. Include any required devices, operating systems or integrations in your inquiry so feasibility can be considered before a proposal.
Is app-store approval guaranteed?
No. Distribution requirements and external review are separate from implementation. Any work involving a store needs an agreed submission scope and the correct account ownership.
Who owns ongoing updates and support?
Those responsibilities need to be defined in the engagement. Release ownership, source access, operating costs and support arrangements should be clear before handover.
Related perspectives
The next question may sit nearby.
The next conversation
Bring the problem into focus.
An outline is enough to begin. Tell us the situation and the decision you need to make.
Discuss an app project