Before you build a mobile app, decide what the first version must prove

An app idea often begins as a list of features. Customers will have profiles, messages, bookings, payments, rewards and a dashboard. The list sounds complete until somebody asks what the first user needs to accomplish and whether they can do it without the rest. The first release should make one useful journey work from beginning to end. This gives the business something real to test and a basis for deciding what deserves development next.

Name the user and the job

Who is the app for? A customer booking a service, a worker recording a site visit and a member accessing information have different needs. Choose a primary user for the first version. Write down the situation that brings them to the app and the result they want before they leave it. Talk to a few people who do this task now. What do they use instead? Where do they lose time or information? If the proposed app solves a problem nobody describes in their own words, pause before paying for a large build. A simple prototype can test the idea without pretending the product is finished.

Follow one complete journey

Sketch the screens from start to successful action. Include account creation only if the task really requires it. Decide what happens when a user enters the wrong detail, loses a connection or wants to return later. An attractive first screen is not a product if the person cannot finish the task. For a booking app, the complete journey may be selecting a service, seeing availability, confirming a time and receiving a useful message. For a field app, it may be opening a job, recording observations offline and submitting a report. The first release should be judged by that finished journey.

Decide what happens behind the screen

Who maintains the data the app displays? Will it connect to an existing system? Who approves changes or handles a failed payment? A mobile app usually has an administrative side, even if the public only sees the phone interface. Include that work in the scope and budget. Consider privacy, permissions and support early. Ask how account access works, where information is stored, how it can be exported and who responds when a user gets stuck. The answers will affect architecture and ongoing cost, not just the design.

Test before expanding

Use a clickable prototype with people who resemble the intended users. Give them a task and watch without guiding them. If several people cannot find the next step, change the flow before writing more code. Later, trial a working version with a limited group and collect feedback on the action you chose to prove. Success may mean staff complete a job accurately, customers make a booking without help or a process takes fewer handoffs. Define the measure before launch. A download count by itself says little about whether the app solved the problem.

Ask for a staged quote

A useful proposal separates discovery, design, first build, testing, release and support. Clarify app store accounts, code ownership, hosting, updates and future feature work. Leave room to learn from users instead of fixing every later idea into the first price. Ask what can be delivered as a web application if installation on a phone is not essential.

Decide when a web app is enough

People often say 'mobile app' when they mean a service that works well on a phone. If users need only to open a link and complete a task, a responsive web application may be easier to launch and maintain. If offline use, device features, store distribution or frequent use matters, a native or cross-platform app may be justified. Ask the developer to explain the trade-off against the actual user journey and budget before committing to a platform. True Blue designs and develops mobile apps and web applications for Territory organisations. If you are looking for app development in Darwin, bring one user journey and the decision you want the first release to prove. It will make the initial scope more useful and the quote easier to compare.

Where to next. Planning something similar? See web design and app development in Darwin, or read about the mobile apps we have built. When you are ready, send a project brief and we will reply within one business day.

✦ End of piece