Building Internal Systems That People Actually Use

Watch the work before drawing screens

Ask staff to walk through a recent request from start to finish. Follow the forms, messages, spreadsheets, approvals, and handovers. Include people who receive the work, not only those who start it.

GOV.UK's Service Manual recommends learning about users and their needs throughout development. Use direct observation and interviews to check assumptions. For an internal system, this can reveal duplicate entry, unclear ownership, and exceptions that a screen list misses.

• Record the trigger, required inputs, decisions, and final outcome.
• Identify who can approve, change, cancel, or view each record.
• Collect examples of returns, corrections, and incomplete submissions.

Define a small but complete workflow

Choose one task with a clear beginning and end. A purchase request might cover submission, review, approval, return for correction, and a final record. Write down the status rules and the person responsible at each step.

Define acceptance using an observable result. For example: a reviewer can find a pending request, inspect its details, return it with a reason, and see the corrected version. Include the failure path and the handover in the first release.

• Give each status a clear meaning and a next action.
• Keep original evidence and a history of important changes.
• Agree what happens when a request is duplicated, abandoned, or assigned incorrectly.

Make the next action easy to find

Use consistent names for the same records and actions. Show the details needed for a decision near the action itself. Keep forms focused, explain required fields, and retain entered values when validation fails.

Test keyboard use, readable labels, phone layouts, and long real-world names. A compact table still needs enough information to identify a record. Give each error a useful explanation and a recovery action, such as correcting a field or retrying a failed upload.

• Keep search and filters close to the records they affect.
• Use clear confirmation for actions with a significant effect.
• Keep permissions enforced on the server as well as in the interface.

Pilot with staff and realistic records

Use representative sample records in a safe test environment. Ask staff to complete normal tasks and common exceptions without coaching. Record where they pause, choose the wrong action, or return to a spreadsheet.

Run a complete handover between roles. Check that permissions match the agreed responsibilities and that totals and exports agree with the source records. Resolve blockers before adding more modules. Keep a named person responsible for each accepted change.

Measure outcomes after release

Choose a few measures before launch. Useful examples include completion time, returned requests, duplicate records, and support requests. Compare like-for-like tasks, and include staff feedback so that numbers have operational context.

The Service Manual recommends using performance data to improve a service. Review your measures with the team at an agreed interval. Prioritize changes that remove repeated obstacles. Keep training, documentation, support, and a correction process active as the workflow grows.