1. What problem should the app solve?

Describe the situation in everyday terms before describing a screen. Who is doing the work, what is difficult today and what would a useful improvement look like? A clear problem makes design decisions easier to evaluate.

2. Who will use it, and where?

An app used occasionally by customers needs a different experience from one used all day by staff. Consider device choice, connectivity, accessibility and the information people need at the moment of use.

3. Which systems does it need to connect to?

List the sources of data and the systems that must receive changes. Clarify who owns each system, which interfaces are available and how errors should be handled. Integration assumptions are worth testing early.

4. What belongs in the first release?

Choose a small, useful path through the product. Separate essential tasks from ideas that can wait, then agree how you will assess the first version. A prototype can make those conversations more concrete.

5. Who owns the product after launch?

Agree responsibilities for support, content, access, updates and future development. A useful app is a continuing product, not just a delivery milestone.

See the thinking in practice

Nodavox and MotorLoop are two apps in the etech ecosystem. They serve different needs, but both illustrate why the user’s task should shape the product. Explore our product directory or talk to us about your own idea.