Start with the workflow, then build the application.

1. Who needs to do what?

List the people involved and the action each person needs to take. A patient submitting information, a staff member reviewing it, and a coordinator arranging a next step have different needs. Treat those as distinct experiences.

2. Where does the workflow lose clarity?

Look for duplicate entry, missing information, unclear ownership, and handoffs that depend on someone remembering to act. Describe the problem in concrete terms before deciding whether a new application is the answer.

3. Which information needs to move?

Map what comes in, where it goes, who can access it, and how long it needs to be retained. Identify existing systems and the interfaces available. These details shape the integration and data-handling scope.

4. What would a useful first release include?

Choose a small, complete workflow that can be reviewed by the people who will use it. A first release should make a defined task clearer or easier, with the necessary boundaries and operational responsibilities understood.

5. How will the team know it helps?

Agree on practical evaluation criteria before implementation. These might include task completion, staff feedback, the number of handoffs, or time spent on a defined administrative process. Establish a baseline rather than assuming an improvement.

Turn the answers into a plan.

The output is a workflow map, prioritized requirements, integration questions, and a first-release scope. That gives design and engineering a shared starting point.