An online form, a new dashboard or an app can be a sign of movement. It does not yet tell us whether the work has improved. Digitization earns its value when someone can feel the difference: a requester is less confused, an employee repeats less work or a decision rests on clearer information. This article begins a path that approaches change through the problem, rather than a list of tools.
The form changes, but the waiting does not
Imagine an organization replacing a paper leave request with a web form. This is a hypothetical example, not a project report. The employee can complete the form more easily, but still has to message two people and call to find out the result. The request is in the system, yet nobody knows whose decision comes next. The screen is new; the experience of waiting is much the same.
The problem is not necessarily poor software. The approval sequence may be unclear, responsibility for replying may be unassigned or missing information may send the request back and forth. A notification could help. But if it only says ‘under review’, the central uncertainty remains. Before commissioning another feature, ask which part of the work has not actually changed.
Technology is part of change, not its definition
The OECD Digital Government Outlook distinguishes designing digitally from the outset from adding technology to existing structures. Applied to a business, that distinction prompts a useful question: has the new tool helped reconsider how work happens, or merely given the old arrangement a new surface?
Separate three things when examining that question: the tool, the way work is done and the outcome that should improve. Buying software concerns the tool. Clarifying responsibility and removing duplicate entry concern the work. Reducing the time someone spends without an answer concerns the outcome. They depend on one another, but they are not interchangeable.
People experience a journey, not departments
The GOV.UK standard on solving a whole problem for users recommends designing around user needs, not a preselected technology. That does not require fixing everything at once. Small changes should contribute to a coherent journey, even when different teams are responsible for its parts.
In the leave-request example, submitting the form is not the employee’s final goal. They need to plan and understand when a decision will be clear. If administration, the manager and the system each consider their own part successful, nobody may own the complete experience. Meaningful improvement brings those gaps into the discussion instead of asking the employee to learn the organization’s internal structure.
A small start with something observable
Starting does not require rebuilding the entire process. Follow one actual request from the first step to its outcome. Where does it stop? What information is repeated? Who has to wait for someone else before proceeding? Then choose a limited change, such as assigning responsibility for a reply and displaying a meaningful status. Its effect should be assessable independently of the appeal of its appearance.
Also ask whose work has become lighter or heavier. If submitting is faster but staff must re-enter the same information, the burden has moved rather than disappeared. Moving from paper to a screen can be a worthwhile step. It is not necessarily the end of the journey. The next step is to clarify which problem is worth solving.