The same information is entered into a form, copied into a spreadsheet and sent to someone else by email. A colleague updates their own version. At the end of the month, someone has to reconcile all three.

It is tempting to turn that frustration straight into a brief for a custom application. First, follow one piece of work from beginning to end. The spreadsheet may be showing you where the process needs attention.

Trace one real journey

Choose a completed application, referral or reporting task. Record where it began, who handled it, which information they needed and what happened next.

Include the quiet work: checking a duplicate, chasing a missing document, correcting a date or asking a manager to approve an exception. These steps are often absent from the official process diagram, even though they consume time every week.

Use a fictional or anonymised example when discussing the workflow with people who do not need access to the underlying records.

Decide which problem deserves to be solved first

“We need a dashboard” describes a feature. It does not explain what a team needs to decide.

A more useful problem statement is: “Programme managers cannot see which submissions are waiting for approval without contacting each officer.” That gives a designer something concrete to investigate. Perhaps the answer is a shared status view. Perhaps the existing system can already provide one if the process is changed.

Name the person affected, the task and the consequence. Then agree on a practical sign of improvement, such as fewer duplicate entries or a shorter wait for a particular handover. Establish a starting point before claiming a gain.

Test simpler options honestly

A custom application can make sense when the workflow is distinctive, several roles need coordinated access or existing tools cannot support an important requirement.

It also creates responsibilities. Someone must own updates, user support, hosting, backups and future changes. An application without an operating plan can become another system the team works around.

Compare a custom build with improving the current tool or configuring an established product. Include the cost of training and ongoing administration in that comparison. The right answer is the one the organisation can use and sustain.

Design the exceptions with the ordinary journey

What happens when a record is submitted twice? When a staff member leaves? When an approver is away? When a decision needs to be corrected?

Work through those situations before a build is treated as complete. Define who can view, edit, approve and export information. Decide what needs an audit history and how long records should be retained, with the appropriate people responsible for those decisions.

For sensitive information, bring the organisation’s privacy and security requirements into the brief early. A polished interface cannot compensate for unclear access rules.

Build a small, complete piece of the workflow

A useful first release might cover one submission moving from draft to review to a recorded decision. That is a coherent task people can try in practice.

Test it with the people doing the work, including whoever deals with corrections and support requests. Use their feedback to refine the workflow before adding more modules.

At Text and Hues, we see the interface as part of the working process. The labels, status messages and next steps deserve the same attention as the underlying logic. A good application makes the next decision clearer and helps the team keep moving, even when the day does not go to plan.