Does your business need an app or a web application?

Describe the task before choosing the platform.

A customer finding a service for the first time has different needs from a staff member checking jobs throughout the day. Write down what each person needs to complete, what information they need and what happens after the action.

A public website may be enough to explain the business and receive enquiries. An account-based web application may be needed when people manage records or follow a workflow. A mobile app may fit a recurring mobile task, particularly where device interaction and the on-the-go experience are central.

• Who is the primary user: a visitor, a returning customer or a staff member?
• Where does the task happen: at a desk, in a shop or on site?
• How does the user discover and return to the product?

Compare access and device requirements.

A browser-based product can be reached through a link. A mobile app adds installation or distribution arrangements, app accounts and release preparation. Consider whether those steps suit how your users will access the service.

Camera use, location, notifications and offline behaviour need specific investigation. Some requirements can be supported in a browser, while others may suit an app better. Check the required behaviour on the target devices before treating one platform as the answer.

• List the device capabilities the task actually needs.
• Describe what must happen when access or connectivity is unavailable.
• Include the platform differences and testing needed for your audience.

Separate the interface from the business system.

The choice is not always one platform for everyone. Customers may book through a website or app while staff manage requests in an office workspace. Those interfaces can use shared services, with access rules appropriate to each role.

Plan the data and handovers as well as the screens. Identify where records are created, who may update them and whether an existing business tool needs to remain the main source. This helps avoid treating each interface as a separate product with unrelated information.

Define one complete journey for the first release.

An initial release should let the intended user complete a useful task from beginning to end. For a service request, that may include selecting a service, submitting the request and understanding its status. The office needs a workable way to receive and process it too.

Decide which extra features can wait. An app, a customer website and a full administration system do not all need to be developed at once. The first stage depends on what is already available and which parts can be reused.

• Sketch the main journey, including errors and unavailable options.
• Identify the information shared with other people or systems.
• Agree the first-stage boundaries and how the result will be reviewed.

Bring the uncertainty into the plan.

You do not need a settled technology choice before discussing the project. A short description of the users, main task, required device behaviour and existing systems is a useful starting point. Where an important capability or integration is uncertain, include a focused assessment before committing to the wider build.