Internal tools are often requested as dashboards, portals, or shared databases. Those descriptions say little about the working day they need to support. Begin with a specific process and the people carrying it out. The right interface can then emerge from the work rather than from a list of familiar software features.
Follow one real request
Trace a typical request from arrival to completion. Note where information is added, checked, or passed to someone else. Look at actual examples with the team where possible. These details reveal the work that a general process diagram can easily overlook.
Name the decisions at each stage
Ask what someone needs to know before taking the next action. A large table of information may be less helpful than a clear list of items needing attention. Organise the interface around those decisions and make the current owner or status understandable.
Choose the first operational slice
Identify a portion of the workflow that can be used from beginning to end. Agree what remains in existing systems and what the new tool will own. A clear boundary is especially useful when the team must continue operating while the new experience is introduced.
Review with the people doing the work
Try the proposed flow using realistic requests, including an incomplete or unusual one. Invite the people who handle those cases to explain what they need. Use their observations to refine the first release and document any temporary workarounds that remain necessary.
