Start here.
Choose one kind of user and one useful job. Build the complete journey for that job, including the unglamorous parts: access, saved work, errors, and a way to get help.
- Describe a real user and the job they need to finish.
- Separate a complete first journey from features that can wait.
- Decide how you will learn from the first people using it.
Start with a person, not a feature list
“A platform for everyone” is hard to scope. “A studio owner sends an invoice and sees whether it has been paid” gives you screens, data, and a result to design around. Be specific about the first user, even if the eventual product serves more people.
Write the journey in ordinary language. What starts it? What information is needed? What happens next? What tells the user they are finished? That description is more useful than choosing frameworks before you understand the work.
Build one complete journey
A small release still needs to feel dependable. Someone should be able to get access, do the main task, leave, and return to their work. Empty screens, failed requests, and permission boundaries belong in the first version when they affect that journey.
For a collaboration product like our own MixPass, uploading a version without a way to listen and respond would leave the job unfinished. A smaller complete feedback loop is more useful than several disconnected features.
- Essential: required to finish the first job.
- Next: improves a journey that already works.
- Later: serves a different user or introduces a new job.
Choose the surface around the work
A web app is often a good starting point for workflows people use at a desk or need to access through a link. A mobile app can make sense when the job depends on the camera, notifications, frequent use on the move, or device features.
You don’t need both on day one. The right choice depends on how people will use the software, what it needs to connect to, and the budget available. We can work through those tradeoffs during discovery.
Agree on how you will learn
Before building, choose a few questions the first release should answer. Can people complete the task without help? Do they come back? Where do they stop or repeat work? For an internal tool, ask the people doing the job whether the new process actually fits.
Release planning should include time for feedback and fixes. Write down who will support users, what happens when something fails, and who decides the next improvement. Those responsibilities are part of launching an application.
A brief that helps us start
You don’t need a specification before talking to us. These four things give the conversation somewhere useful to go.
- Who
- The first person who will use it, and what their day looks like.
- Job
- What they need to get done, from the first action to a useful result.
- Today
- How they do it now, including tools, workarounds, and frustrations.
- First release
- What must work at launch, and what can be learned or added later.
A couple of common questions.
Do I need a detailed specification?
No. Bring the problem, the people involved, and examples of how the work happens today. We can help turn that into a scope and a plan.
Can an existing app be the starting point?
Yes. A first engagement might improve one part of existing software rather than create an entirely new product.