Initiated by the plans to update the SDG Digital Investment Framework: Framework 23Q3 Proposed Outline

Use Case

A Use Case defines the steps that an individual or system will undertake in order to achieve a business objective.

Workflow

A WorkFlow is a generic business process that can be applied to Use Cases across multiple sectors.

Building Blocks

Building blocks are enterprise-ready, reusable software components providing key functionality facilitating generic WorkFlows across multiple sectors.

Use Case

A Use Case defines the steps that an individual or system will undertake in order to achieve a business objective.

Building Blocks

Building blocks are enterprise-ready, reusable software components providing key functionality facilitating generic WorkFlows across multiple sectors.

Are we reinventing the wheel for each use case?

Drawbacks and challenges of not using workflows:

Lack Of Standardization: Without workflows, there may be inconsistencies in how different services are designed and implemented. Each team or project might approach the development process differently, leading to a lack of standardization. This can make it difficult to maintain and update services, potentially resulting in increased development time and effort. Without a workflow it is challenging process to see where and which BBs will be involved in the service.

Inefficient Development: Without workflows, developers may spend more time figuring out how to design and connect various components to each use case specifically, resulting in slower development cycles. This inefficiency can lead to higher costs and delays in delivering services to clients.

Increased Complexity: As our use cases expands and offers services to multiple governments, the complexity of creating these services will grow. Without workflows, it may become challenging to handle the interdependencies and interactions between different components.

Difficulty in Collaboration/Communication: Workflows act as a common language and framework that facilitate collaboration among different teams (Country Engagement/BB Teams/ Sandbox etc) within GovStack. They provide a shared understanding of how services are designed and implemented. Without workflows, collaboration and knowledge sharing between teams may become more challenging, potentially leading to siloed efforts and reduced efficiency.

Main problem that we see

Workflows are solely utilized within the DIAL catalogue as a conceptual framework. Consequently, they do not have a tangible presence for any teams within the GovStack.

Proposal:

Let’s rework on the workflow concept and make it tangible and usable for each team.
Let’s create something that can bridge the gap between BBs and the Use Cases but also between different teams.

“Service Blocks” replacing the Workflows

References/ Examples:

Hypothesis:

By identifying common patterns within the existing use cases, we will be able to develop new ways of delivering the same types of experience for different services, connect the technical layers (such as BBs) with functional layers (such as Use Cases), improving communication between teams, the user experience and streamlining the work that is required to run the service.

Goal:

Creating a vertical binding kit between functional (such as Use Cases) and technical layer(such as BBs) of the GovStack with the generic patterns that is visible on various services.

Creating service blocks not only should include BBs integration or possible user flows, but services (Processes/Functions) in general for bridging the gap between BBs and Use Cases. This may allow:
Making things quicker while working more effectively, by reusing existing tools and avoiding duplication of work,
Implementing services that provide a consistent experience and flow
Enabling building services on various sectors
Developing the tangible vertical patterns for different groups/teams which can also unfolds communication within the vertical level.
Readability and communication between different teams (not only technical) but also between Use Cases and BBs
Easy communication with the clients from the countries.

What is Service Block?

A service block is a generic service patterns that can be applied to use cases across multiple sectors/governments.

A Service Block can include
Generic services (such as registration of a person) and explanation
UI/UX Design Patterns (UX/UI group working on this)
Generic User Flows within the services
Generic User Roles within the Service
BBs involvement with a clearly statement on role during the flow/service
Generic integration of the different components within the service

A Service Block should be:

continually iterated to reflect changing environments and technology
Part of the Implementation Playbook
they should be validated to show they can work in the real world
They should involve BBs and design patterns and possible other components.
they should cover all necessary parts of a service, but not be too broad
they should be flexible enough to use in different contexts
There should be a team that co-ordinates them
There should help to easen the assessment and prioritization of the whole service landscape and its roadmap.

Service Blocks for

1. Country Engagement Team

“We can showcase the Service Block library to countries and their use cases for implementation and use these service blocks as an example related to their use case.”

2. BB Teams

“We can utilize the Service Block library to showcase and document the BBs within the various generic business processes while communicating/unfolding the integration within the different BBs and design teams.”

3. Design Teams

“We can use service block for showcasing UX/UI design patterns in related generic business processes and these patterns can be used for countries to develop and design their own services “

4. Sandbox Team

“We can create example use cases while using different service blocks to test and play with it. “

A Use Case

Example Construction Building Permit Use Case

Possible Methodology Draft For Creating Service Blocks (from our perspective as a Service Designer/ UX)

Analyze the existing and planned use cases.
Collect all relevant documents and group them based on the case, documentation and methodology
to-be journeys
sequence diagrams
service blueprints
use case documents
Wireframes etc.
Identify and document common patterns that emerge from the analysis.
Decide on how to identify and document these patterns effectively.
Map out the services from the user's view/flow and from the integration of building blocks (BBs).
Evaluate how certain changes might impact the use cases and their flexibility (e.g., consider the implications of altering user flows for countries and BBs).
Identify similarities and differences between use cases and document them.
Identify pain points and areas where improvements can be made.
Consider the involvement of BBs in the service patterns.
Document the flows, conditions, and any other relevant information
4. Decide the roles, responsibilities and how to document Service Blocks and library (Should start from defining one block)
The content needs to enable people to:
understand what the specific pattern is
what problems it might help solve
make decisions of what patterns and guidelines would be best for a service
use it to help design and implement an interaction/transaction
contribute to its development
Explains where BBs will be involved in what role
Service Block content can include
a description of what it is
when to use it
when not to use it
how to use it
considerations
interdependencies with other patterns
case studies
research and resources

OR

Work on a use case without thinking about service block
For the second use case, try to implement same components that are used in the first use case and document them clearly.
This documentation should include each layer (functional and technical) that are mentioned before
It can be also included fails and analyses of them. (simple methods/ root cause analysis such as five whys can be used to understand the problem)

Keep In Mind

1 - Stakeholders Involvement:
key stakeholders, such as designers, developers, BB teams and country engagement teams, actively participate in the process of analyzing use cases and documenting blocks based on what is existing and their needs.

2- User-Centric Approach:
We should a user-centered perspective when mapping out services and flows. We should consider the needs, goals, and pain points of the users (not just end users but also developers, designers and other teams who are going to use these blocks), and align the service blocks accordingly. This approach can help create intuitive and user-friendly experiences.

3- Documentation Standardization:
We need to establish a consistent documentation format for service blocks. This standardization will enable easier comprehension, knowledge sharing, and collaboration across teams. Consider using visual diagrams, standardized templates, or any other format that works best for your organization.

4- Iterative Improvement:
We should treat the creation of service blocks as an iterative process. Encourage regular feedback and reviews from various stakeholders, and continuously refine and improve the blocks based on the insights gained. This approach will help ensure that the patterns remain relevant, effective, and adaptable to evolving needs.

5- Knowledge Repository:
Establish a centralized knowledge repository or platform where service blocks and related documentation can be easily accessed and updated. This repository will serve as a valuable resource for designers, developers, and country engagement teams, enabling efficient collaboration and knowledge sharing.

EXAMPLE FROM GOV.UK

Only For Service Design / UX/ UI

“What we mean by ‘service patterns’
Registering a birth or death, reporting a problem on the road, applying for a permit or checking your eligibility are very different services that are accessed through many disparate channels. The experiences of citizens accessing them can be quite different, but in reality, many of these different services go through the same kind of building blocks*, like registering, booking, or paying for something. These are the service patterns we have identified and have outlined in this library. “

“The more time we spent mapping services, the clearer the list got. It became very apparent that not all service patterns sit at the same level.”

?Service Block?

Service Pattern (Level 1)
This can be an end-to-end service (e.g. ‘Apply for a school place’) or a specific step of a service (e.g. ‘Booking a registrar for a wedding’). It is typically made up of components (Levels 2 and 3) and will also have interdependencies with other Service Patterns.

?Design Pattern/capabilities?

Component (Level 2)
These are what Service Patterns (Level 1) are made of. They are heavily task-based and are fundamental for Service Patterns to work, but by themselves they wouldn’t mean that someone can complete an end to end service.

?Patches?

Component (Level 3)
We also identified two others that could be called Building Blocks (Level 3), ‘Understand something’ and ‘Get a notification’. We found that these generally exist when triggered by something happening at Level 2. We are not 100% sure that ‘Understand something’ is a Service Pattern, or is more related to information and guidance.

“...after deciding on our approach and tools we got busy with the mapping. Over the past 5 weeks we have mapped 157 transactional services across the council, spanning from ‘book an appointment to register a birth’ to ‘reporting a pothole’.”

*Their Building block is not same as ours

EXAMPLE FROM GOV.UK

Service Patterns

Check Something Service Pattern