03 — Mobile applications
Designed for the moment it is needed.
In the field or between appointments, an application needs to make the next action clear. Design starts with the real setting: one hand free, an uncertain connection or an interrupted task.
Make every state understandable
An example of submission when a connection may be interrupted.
Entry in progress
The person completes the information and can review what they intend to submit.
Waiting for a connection
The interface explains that submission is still pending and offers a way to resume.
Receipt confirmed
Confirmation appears once the system has established receipt.
If submission fails, the journey should explain the error and allow recovery without confusing a pending item with a received one.
Define the priority journey
Reading a dossier, completing information and submitting an item are different tasks. The prototype should make their starting point, progress, possible errors and result confirmation visible.
Camera access, notifications and offline behavior belong in the scope when they meet an identified need. People should understand the permissions the application asks them to grant.
Plan for interruptions and continuity
A “sent” screen should correspond to an established result. If an operation is waiting for connectivity or needs to be resumed, it should show a distinct state and a useful action. Synchronisation conflicts need an agreed resolution process.
Choosing native development or a cross-platform codebase depends on the devices, interactions and integrations required. Publication and future changes also need to account for the relevant platform accounts, permissions and submission procedures.
A scope to agree together
- Priority journeys and a prototype to examine on a device
- An application for the agreed platforms
- Defined integrations, permissions and recovery states
- Tests on the agreed devices and usage situations
- Preparation for handover and publication steps
Where it can help
- Services supporting work in the field
- Organisations offering mobile access to clients
- Teams extending a web journey with a specific mobile use case
Possible technical choices
- SwiftUI
- React Native
- TypeScript
- The relevant system API
Common questions
- Do iOS and Android need separate applications?
- The decision depends on the target devices, interactions and required features. The brief lets us compare native development with a cross-platform codebase, including their maintenance and publication constraints.
- Can the application work without a connection?
- Some journeys can be designed to do so. We need to define which information remains accessible, its protection on the device, queued actions and how synchronisation or conflicts will be handled.
- How is publication prepared?
- The project needs to identify publisher accounts, required permissions, submission materials and review steps. Building the application alone cannot guarantee acceptance by a platform.
What would you like to make simpler?
A client journey, an internal tool, a document task: tell us about the context and the change you want to make. That first conversation helps define the work ahead.
Discuss a project