Define the service from the user's point of view
Choose a specific service rather than trying to transform an entire institution in one step. Describe who needs it, what they are trying to achieve, what information they must provide, and how they find out what happens next. Include staff who process the request as well as citizens or businesses using the service.
A service might begin online but continue through paper files, telephone calls, or another department. Research should follow that complete journey. Otherwise, a polished portal can hide the same delays and uncertainty that existed before it.
Observe the current work and collect evidence
Combine interviews with observation, document review, and sample workflow tracing. Ask staff to show how a request moves, including what happens when information is missing or a decision needs clarification. Distinguish formal procedures from the practical workarounds that keep the service operating.
Record what is known, what is assumed, and what remains uncertain. Avoid treating a single interview as proof that every department works the same way. A clear evidence record helps decision-makers understand why a recommendation was made and which parts still need validation.
- Where is information copied or entered more than once?
- Which handovers create uncertainty or lost ownership?
- How does a person learn the status of a request?
- Which decisions require human judgment and accountability?
Map responsibility, information, and access
A workflow diagram should show responsibility as well as sequence. Identify who can create, view, change, approve, and export information. Check what another department needs and whether the same information is already held elsewhere.
This is also the time to examine data sensitivity, access controls, record retention requirements, and audit needs with the institution's responsible teams. Those requirements should inform the system design and procurement scope. They should not be added as vague promises after development has started.
Compare realistic options before choosing technology
The answer may be process improvement, configuration of an existing product, a targeted integration, or a custom platform. Compare those options using the same requirements and constraints. Consider internal capacity, hosting responsibilities, existing systems, connectivity, supplier dependencies, and the ability to maintain the result.
Document why an option is recommended and what it does not yet solve. A short options appraisal with clear assumptions is often more valuable than a large technology list. It gives stakeholders a basis for discussion rather than presenting the chosen tool as the starting assumption.
Define a pilot that can be evaluated
A useful pilot has a named owner, a limited service or department, realistic users, and clear acceptance criteria. Establish a baseline before introducing the system where reliable measurement is available. Potential measures include time spent on defined steps, the number of incomplete submissions, or the ability to trace a request's status.
These are suggested measures, not claims about results Digital Matrix has achieved. Select the measures with the institution, explain how they will be collected, and avoid conclusions that the available data cannot support. Include training, support, and a process for responding to user feedback.
Make research a delivery asset
Discovery should leave the institution with practical outputs: a current-state service map, a documented problem, agreed requirements, an options comparison, risks and dependencies, and a phased delivery recommendation. Those materials help the institution assess proposals and maintain continuity when people or suppliers change.
Digital Matrix brings research and advisory work together with software, infrastructure, and training. Our role is to help organisations understand the problem, select an appropriate approach, and build the capabilities needed to use the result.
Common questions
Does every public service need a new platform?
No. Research may identify a simpler process change, an integration, or configuration of an existing system. A new platform is appropriate when the evidence and requirements support that choice.
What should a discovery phase produce?
It should produce an evidence-based account of the service, its users and workflows, agreed requirements, an options comparison, dependencies, and a practical recommendation for what to test or deliver next.
