1 Understanding the Current Service (As-Is)

Before you start the As-Is phase

Before you start, check you have:

• read the GovStack design principles

• an understanding of the service’s purpose and scope You can describe which service (or part of a service) you are focusing on, and why now. You have the finalised service prioritization to hand

• shared expectations about the ‘As-is’ phase Participants understand that the ‘As-is’ phase is about learning and understanding

• permission to explore end-to-end The team are able to discuss data, responsibilities, and dependencies across teams and organisations

• access to the right people You are able to involve people who understand how the service really works, including offline steps and cross-organisation hand-offs

• the right team You have people to take responsibility for the skills outlined in the table below

---

Skills required for the As-Is Phase

Area of Expertise
Product management	Identify assumptions related to the product’s success.
Delivery management	Manage delivery risks related to timelines or dependencies.
User research	Validate assumptions through testing and research.
Service design or business analysis	Research internal processes and create prototypes for the high-level, to-be user journey.
Technology	Identify technical risks and constraints, and guide technical choices.

---

Criteria for success in the As-Is Phase

This phase focuses on building a shared understanding of the problem space before moving to solutions. The criteria below describe what teams should have achieved, along with examples of evidence that indicate readiness to progress.

Criteria	Evidence
Map the as-is service	End-to-end user journey maps (required) Technical, legal, organisational, and resource constraints are identified and understood Discovering and note down the relevant legislation in the journey map or another document.
Model the domain	A list or visual of key domain concepts (e.g. application, approval, status) A simple service glossary or dictionary A rough domain diagram
Understand users and challenges	User needs statements Lightweight personas Accessibility needs and barriers for diverse users are understood Interview notes, observations, or summaries Documented challenges faced by users, frontline staff and back-office teams
Analyse research data	Themed insights or findings Problem statements or “what we learned” summaries
Prioritise next steps	Prioritised opportunities or focus areas What to explore and not to explore next An initial action plan, such as: quick wins candidate pilots areas needing further discovery or feasibility work Initial KPIs are baselined using Discovery Insights

Moving to the next phase

Discovery is complete when the team has enough shared understanding to decide what to explore next. Before moving into the to-be stage, teams should take a moment to reflect on what they have learned and agree:

• which problems or opportunities are most important to explore next

• which parts of the service are understood enough to move into end-to-end journey exploration

• where confidence is lower and further discovery, research, or testing is needed

If the criteria above have been met and supporting evidence is in place, teams can make an informed decision to:

• proceed to the to-be phase to explore solutions

• continue Discovery to further explore options or reduce uncertainty

• end the work if there is no viable way forward

This decision should be based on confidence and learning, not on pressure to progress.

---

Run an As-Is workshop

Session	Activities	Who to involve
Introduction & framing 60 minutes	Set the objectives Recap the service Discuss the definition of end-to-end services Emphasise why we take a user-centred approach to build empathy	Service owner, delivery lead, policy or programme representatives, all participants
Map the As-is 3 hours	Agree service scope and boundaries. Map the current service end-to-end including online and offline steps. Break into groups to focus on multiple journeys or divide complex journeys. Capture any known relevant legislation either as a row in the map or as another document.	Frontline staff, back-office staff, delivery team, policy representatives, user advocates or proxies
Model the domain 60 minutes	Identify key domain concepts. Clarify roles and responsibilities. Create a shared glossary or service dictionary. Surface unclear ownership and differing interpretations across teams.	Delivery team, subject matter experts, representatives from involved organisations
Understand users and challenges 30 minutes	Using the journey maps to identify actors involved create simple personas to keep in mind through the rest of the design activities	Frontline staff, back-office staff, delivery team, policy representatives, user advocates or proxies
Analyse findings (The facilitator can do this async during a break or before the next session) 30 minutes	Cluster insights from mapping and user work. Identify themes and patterns. Draft problem statements or opportunity areas. Record risks, assumptions, and gaps in knowledge.	Delivery team, facilitator, service owner
Prioritise next steps (This can be moved to the start of the next day) 60 minutes	Prioritise quick wins, near-term improvements, and longer-term changes. Agree what to explore next and what not to pursue yet.	Service owner, delivery lead, policy or programme representatives, technical lead if available