Developed by Laurence Berry (Komo.international), Betty Mwema (Government Digital Service of the United Kingdom), Dr. P. S. Ramkumar (ITU)

Start by understanding the needs and requirements of the solution, including users' needs, expectations, and pain points. Consider the "Person" and the "Role" are not the same. For example, the same person may use a health care application as a doctor and also as a patient but the needs of a doctor's UI/UX are different from that of a patient, and while the doctor may work on the data of multiple patients, a patient can access only self-data. You can find more examples of how to understand user needs in the implementation playbook.

User Research

Understanding user needs begins with user research. This includes techniques like surveys, interviews, user testing, and analysis of usage data. The goal is to understand the tasks users are trying to complete, the problems they face, and the goals and motivations of users in specific roles.

Question Assumptions

Always question assumptions about what users need in specific roles. Just because something is commonly done or seems like a good idea doesn't mean it is what users need. Validate every assumption with data.

Frame the Problem

Before jumping into solutions, make sure you have correctly framed the problem. Ask: What user need is this solving? Why is this a problem for our users? How do we know this?

Prioritise Based on User Needs

Not all user needs are equally important. Use data from your research to prioritise features and improvements based on what users need most.

This document has been developed as guidance to kick-start the design and development of services that use and combine GovStack applications and Building Blocks, as well as other components while maintaining a seamless and consistent user experience.

This guidance supports teams in identifying and implementing the foundations for designing user-centered, accessible, consistent, and technically robust services. Intended to help teams align to the GovStack Design Principles and the Implementation Playbook.

2.1 Current scope

Specifications for how to implement accessible, responsive, multi-modal Building Blocks and provide a consistent service.

• Guidelines for designing interfaces (like meeting WCAG accessibility guidelines).

• Screen flows for common user journeys (like registration).

• Guidance on technical choices (like how to design for low bandwidth, high latency environments, unreliable connectivity, local storage, local persistence of data security using DOMs, etc.).

• Patterns for managing client-side validation.

2.2 Good practice UI/UX guidelines for Service Design

The guidelines act as a template checklist for assuring the quality of a service's design and delivery. Each point in the guideline has/links to additional guidance.

2.3 Service patterns

We chose to define high-level service patterns rather than anything more specific like a design system or user interface components, this is to maintain flexibility to work around each organization's needs and existing design assets and front-end frameworks.

3.1.1 Understand user needs

Understand needs and requirements

Involve others in the design process

3.1.2 Test with users

Test with users

3.1.3 Iterate based on feedback

Share research findings

Monitor performance

Set up analytics

3.1 User-centred design

Continuously improve services to meet the needs of users.

• Understand user needs

• Test with real users

• Iterate based on feedback

3.2 Accessibility and inclusion

Build services that are usable and equitable for all.

• Test for accessibility

• Test your service with diverse users

• Involve users in the design

3.3 Consistency

Create user-friendly services that build trust.

• Use simple language

• Reuse existing styles and patterns

• Provide a joined-up experience

• Share design decisions

3.4 Technology choices

Making decisions based on needs.

• Balance security and usability

• Optimise performance and connectivity

• Design cross-platform

Find opportunities to collaborate closely with users, stakeholders, and other team members with diverse multidisciplinary skills, throughout the design process.

Empower users to take an active role in co-creating and co-designing public services.

Example activities

Engaging Stakeholders:

• Involve stakeholders early on to understand their expectations and objectives.

• Get feedback from stakeholders to review and comment on design decisions and findings.

Collaborating with Team Members:

• Conduct workshops or brainstorming sessions for diverse input.

• Have peer reviews to get the perspective of different roles in the design.

• Emphasise user needs and project goals within the team.

Involving Users:

• Carry out user research activities, like interviews and surveys, to understand user needs.

• Hold co-design sessions with users, for them to participate directly in the design process.

• Conduct usability testing with real users to identify issues and opportunities for improvement.

• Collect user feedback post-launch.

Usability testing allows you to observe firsthand how users interact with your product. You can identify any challenges they encounter and understand the 'why' behind their behaviour. This improves user experience and can prevent costly redesigns later on.

Further reading and resources for usability testing include:

• Nielsen Norman Group’s guide to usability testing

• The UK's Government Digital Services guide to planning research

• The UK's Government Digital Services guide to conducting usability testing

Once you're ready to go live, continuously monitor and evaluate the performance and usability of the service, and iterate the design accordingly to drive continuous improvement and optimise user experience.

Key performance indicators (KPIs)

Determine Must-Have KPIs

At a basic level, all services should be tracking metrics such as:

• User Satisfaction - Overall, how satisfied are users with your service? This can be measured through surveys, feedback forms, or by analysing user behaviour (e.g., how often they return to your service).

• Task Completion Rate - What percentage of users successfully complete the tasks they set out to do on your service?

• Error Rates - How often do users encounter errors or difficulties when using your service?

Identify Service-Specific KPIs

In addition to these basics, each service will likely have specific KPIs relevant to its unique goals and user tasks. Identify what these are and how you can measure them.

Run a session with your team to create a performance framework.

Set Up Analytics

Use analytics tools to collect data on these KPIs. Google Analytics is a popular choice, but there are many other tools available. Make sure to set up your analytics tool to track the specific actions and events that correspond to your KPIs.

Collect satisfaction data at the end of the user journey

Implement a mechanism to collect user satisfaction data at the end of key user journeys. This could be a survey or a simple rating system.

See the pattern for collecting feedback

Collect feedback throughout the user journey

Do not wait until the end of the journey to collect feedback. Implement feedback mechanisms at key points throughout the user journey. This could be feedback forms on individual pages, live chat options, or proactive prompts asking users if they need help.

See the pattern for collecting feedback

Regularly review and act on data

Set a regular schedule to review your KPIs and user feedback. Use this data to identify issues and opportunities for improvement, and take action accordingly.

1. Cloud-Based Analytics

The cloud-based analytics solution, such as Google Analytics, is a straightforward and easy-to-setup method that offers robust data about your users' behavior. It's a beneficial choice for those who want to get started quickly and without much technical setup.

Setup: Begin by creating an account on the platform of your choice. You will then add the tracking code they provide to your website. Ensure this code is embedded on each page you wish to monitor.

Configuration: Within the platform, you'll set up goals or events that align with your Key Performance Indicators (KPIs). This allows the software to track specific user actions that are of interest to your business.

Monitoring: Once the setup is complete, you can start monitoring user behavior data through the platform's dashboard.

Remember to respect user privacy throughout this process, which involves informing users about the data you collect, why you collect it, and offering an option to opt out.

2. Self-Hosted Analytics

Self-hosted analytics, such as open-source platforms like Matomo or Plausible, offer more control over your data and are often favored by businesses that place a high emphasis on data privacy and security. This is particularly important if you value keeping data in-country due to regulatory or compliance requirements.

Setup: You'll need to set up these platforms on a server, which could be owned by you or rented from a hosting provider. After this, you'll add the platform-specific tracking code to your website.

Configuration: As with cloud-based solutions, you will need to define the events or goals that align with your KPIs.

Monitoring: Once configured, you can use the platform's dashboard to track user behavior and monitor your KPIs.

Server space considerations for self-hosting depend on several factors, including the amount of traffic your website receives and the level of detail in the data you are tracking. As a starting point, 1GB of space could handle over a million simple page views, but more complex tracking would reduce this. Consulting with a server or IT professional could provide a more accurate estimate based on your specific needs.

3. Start with cloud

It is also possible to start with a cloud-based solution for quick setup and immediate insights, then transition to a self-hosted solution as it's being set up. This allows you to benefit from analytics data right away, while your more robust, privacy-centric solution is being prepared.

Accessibility is important because it allows services to give equal access to all citizens, comply with legal requirements, foster inclusivity, enhance user experience, avoid discrimination, and contribute to government credibility, cost savings, innovation, and international reputation.

3.2.1 Test for accessibility

There could be significant interdependencies between UI components for different accessibility requirements. The World Wide Web Consortium and Web Accessibility Initiative have developed standards for considering the needs of developers (WCAG, ATAG, UAAG), authoring tools, accessibility evaluation tools, and guidelines on how to make user agents (browsers, browser extensions, media players, readers) accessible to users.

Test for accessibility

3.2.2 Test your service with diverse users

Involve a diverse user group in the design

Support multiple languages

Foster a culture of inclusion

Check WCAG Compliance

Make sure that the implementation of the Building Blocks and the overall digital government service meets the Web Content Accessibility Guidelines (WCAG) standards for accessibility.

WCAG provides a set of internationally recognised guidelines for creating accessible web content. Familiarise yourself with the guidelines to ensure your service meets the necessary accessibility requirements.

Web Content Accessibility Guidelines (WCAG)

Test with Accessibility Tools

Test the service using accessibility tools to identify and address any accessibility issues. These tools help simulate the experience of users with disabilities and uncover potential barriers.

Consider using screen readers, keyboard navigation, and colour contrast checkers, among other tools, to ensure your service is accessible to all users.

Service manual from the United Kingdom's Government on how to test for accessibility.

Seek Expert Assistance

If you encounter complex accessibility challenges or require specialised knowledge, consider seeking expert assistance or consultation. Accessibility experts can provide guidance and support in ensuring your service meets the highest accessibility standards. They can help identify and address accessibility issues specific to your service and provide valuable insights throughout the design and development process.

Further reading:

• Dos and don'ts on designing for accessibility

Involve diverse users in testing and feedback

Ensure your user testing and feedback collection includes a diverse range of users. Include users with disabilities and those from various backgrounds and experiences. This approach helps identify potential accessibility and inclusivity issues that might be overlooked by individuals without these experiences.

Inclusive Design Toolkit from Microsoft

Understand user capacity and identify barriers to access

To create a service that caters to all users, you must understand their unique capacities. Consider factors like:

• Time available

• Financial situation

• Ease of access to an interface (device or person)

• Interface capability and confidence

• Service process-related confidence

• Awareness of the service, its purpose, and access options

• Ability to comprehend information

• Mental health/emotional capacity

• Trust in service robustness, security, reliability

• Ability to provide required information

• Willingness to use the service, at all or in the most cost-effective way

With this understanding, identify the potential barriers users might face when accessing and using the service. These barriers could be,

• Physical: Disabilities that affect a person's ability to interact with interfaces.

• Technological: Limited access to high-speed internet, up-to-date devices, or the latest software.

• Cognitive: Cognitive impairments, learning disabilities, or language barriers that make the service hard to understand or use.

• Economic: Economic limitations that restrict access to necessary technology or internet access.

• Geographical: Limited internet access in rural or remote areas, or cultural or language differences in different regions.

• Privacy and Security: Concerns about personal data usage or protection.

Design for inclusivity

Having understood user capacity and potential barriers, you should design your service to be as inclusive as possible. This could involve simplifying processes, offering alternative access methods, or providing additional support where needed.

Consider non-digital alternatives

While digital public services offer many benefits, they may not be suitable or preferred for all users. Some users may lack the necessary technology or digital literacy, while others may simply prefer traditional methods. In these cases, consider offering alternative mechanisms for accessing the service, such as phone support or physical locations.

Consider Gender Equality and Social Inclusion (GESI)

In all aspects of your design process, ensure principles of Gender Equality and Social Inclusion (GESI) are adhered to. It means your service should be accessible and fair to all users, irrespective of their gender, age, ethnicity, disability status, income level, etc.

Example

In a public healthcare service, implementing GESI principles led to the development of a more inclusive appointment scheduling system.

It was noticed that many women, especially from lower-income backgrounds, were unable to attend appointments during standard working hours due to their caregiving responsibilities. By extending service hours to evenings and weekends, and providing childcare services, the service became more accessible to this demographic, significantly increasing attendance rates.

Further reading:

• GESI Qualitative Framework by Oxford Insights

• Design Justice principles

Identify the languages users speak

Analyse user demographics data to determine the languages spoken by your users. This data can be obtained through user surveys, usage data analysis, or from market research. You may also find legislation for languages the government must support.

Read more about using data to make decisions.

Make a plan for multilingual support

Consider the feasibility and utility of providing multilingual support. This includes the translation of key content, interface elements, instructions, and forms into the most commonly spoken languages of your user base. Automated translation services can be a cost-effective starting point, but human review is essential to ensure cultural appropriateness and accuracy.

Use simple language

Even in the primary language of the service, avoid using complex jargon and technical terms. Use plain, simple language that can be easily understood by a broad audience. This will also facilitate more accurate translations.

Language Detection and Preferences

Implement language detection based on the user's browser or system settings and offer the option for users to manually set their language preferences.

Use the Accept-Language HTTP header to detect the language preferences set by the user in their browser or device settings. This can give you a default language to serve to the user initially.

Store the user's language preference (in cookies or user profiles) so that you can load the website or app in their preferred language in subsequent visits or sessions.

Clear Language switching options

Options to switch languages are clearly visible and easily accessible across all pages of the service. Users should not have to search or dig deep into settings to find this option. See the design pattern for switching languages.

Support for right-to-left (RTL) languages

If you're offering support for languages that are read right-to-left (like Arabic or Hebrew), make sure your user interface can handle that transition seamlessly. This is not just about text direction; UI elements and navigation should also mirror to offer a consistent RTL experience.

Read more about using frontend frameworks.

3.3.1 Use simple language

3.3.2 Reuse existing styles and patterns

3.3.3 Provide a joined-up experience

3.3.4 Share design decisions

The notion that citizens expect governments to use formal language may not be entirely accurate. Using consistent, simple, and clear language is a core principle of user-centric design.

By adopting simple language:

• You enhance accessibility - Not everyone has the same reading level. Using simpler language makes your content accessible to a broader audience, including those with learning disabilities or for whom English is a second language.

• You improve clarity and understanding - Using complex or technical language can be a barrier to comprehension. Simpler language ensures all users can understand the information being communicated.

• You save time - When citizens can quickly understand the information they're reading, it reduces the time spent on misinterpretations and questions, leading to a smoother user experience.

Research exercises like highlighter testing have shown that simple language is more effective for comprehension. In these tests, participants highlight parts of the text they find difficult to understand, revealing areas where simpler language could improve comprehension.

Following guidelines like the United Kingdom's government Content Design guidance can assist in creating accessible and easy-to-understand content. Simplicity in language is a tool that enhances inclusivity and usability, reflecting a government that values its citizens' diverse capabilities and time.

Further reading: Testing for UX writers - know when your words are working.

GovStack Patterns - A Strong Foundation

GovStack offers a robust set of well-tested patterns for common user journeys. These can serve as a foundational structure for your services, presenting an outline for the necessary pages within your user journey and providing guidance for the content on each page.

View the design patterns

Beyond Coded Components

While these patterns offer a solid starting point, it is important to note that they do not provide coded or designed components. For implementing these aspects, refer back to our guidance on setting up a front-end framework.

Use a frontend framework

Consistency and Testing

Whether employing GovStack patterns or creating your own, maintaining consistency across your government services is key. After establishing your patterns, make sure to test the end result with users. This will ensure that your service is not only consistent but also user-friendly and effective.

Test with users

Foster a culture of inclusivity within the team and encourage ongoing education and awareness of inclusivity and diversity's best practices. [resource on co-design]

Everyone benefits

Accessible design isn't just for users with disabilities - it enhances usability for all users. Simple features like captions or clear language can help everyone.

Temporary/situational disabilities

Accessibility isn't just about permanent disabilities. Users may experience temporary or situational impairments, like a broken arm or a bright environment, where accessibility features can improve their experience.

Ageing population

Accessible design is particularly important for older adults who may experience changes in vision, hearing, and motor skills. Designing with accessibility in mind ensures your service is user-friendly for all age groups.

Legal/ethical duty

In many places, accessibility is not just an ethical duty but also legally required. Providing accessible services ensures everyone can use your service, regardless of their abilities.

Future-proofing

Accessible design often results in more robust and flexible services. By prioritising accessibility, you make your service more resilient to future changes and adaptable to different technologies or platforms.

Overhead cost

Incorporating accessibility from the start of the design process is efficient. Retrofitting accessibility features later can be more time-consuming and costly. Make accessibility a foundational part of your design process, not an afterthought.

A frontend framework, also known as a CSS framework, is a package consisting of pre-written, standardised code in files and folders. They give developers a base to build upon while still allowing flexibility with the final design. Essentially, a frontend framework provides a structured, reliable, and reusable template.

Benefits of a frontend framework

1. Efficiency: They save developers a significant amount of time by providing a foundation.

2. Consistency: By using the same framework, teams can maintain consistency across projects.

3. Responsiveness: Most frontend frameworks are built to be fully responsive right out of the box.

4. Community: Popular frameworks have a large community, which can offer support, additional tools and plugins to extend functionality.

Setting Up a frontend framework

Setting up a frontend framework largely involves downloading the framework's files and incorporating them into your development environment. The specific steps may vary depending on the chosen framework.

Choosing a frontend framework

Considerations for choosing a frontend framework include the framework's community support, ease of use, performance, and compatibility with your project's requirements. One crucial aspect to consider is the level of support for accessibility and right-to-left (RTL) language support.

Here's a comparison of three popular frameworks:

Use the framework as a foundation for your design system

Choose a frontend framework fitting your needs as the foundation for a reusable design system. This system, combining the framework's technical foundation with your specific visual styling and design guidelines, will ensure uniformity and accessibility across projects within your organisation. Regular updates to this living system will accommodate evolving needs and interaction patterns, solidifying an efficient and inclusive digital experience throughout government services.

\

Share research findings with team members, senior members or strategic leaders, and even the general public whenever practical.

The aim is not just to share information but also to generate dialogue and collaborative action based on the findings.

Organise Your Findings

Begin by grouping your user insights, key takeaways, and suggestions. This could be grouped by themes, user groups, and stages in the user journey.

Create a Simple Presentation

Document your findings. Each slide could represent a key finding or insight. Remember to use clear, simple language and include visual aids where possible to increase understanding.

Schedule a Playback Session

Invite team members and stakeholders to a meeting where you'll share your findings. Make time for discussion.

Document and Share

Share the presentation along with any additional notes from the discussion. This ensures that everyone has access to the information and can refer back to it in the future.

You might even consider publishing findings openly through a blog or similar format.

The benefits of working in the open

• Transparency: Working in the open allows stakeholders, other teams, and even the public to understand how decisions are made and progress is tracked. This transparency can build trust and enable informed discussions.

• Collaboration: By making your work accessible, other teams can provide input, learn from your approach, and possibly contribute, fostering a collaborative ecosystem.

• Reusability: Openly sharing your work means other teams can reuse and adapt your processes, tools, or code, avoiding duplication of effort and accelerating development across the board.

• Feedback and improvement: Working in the open invites feedback from a wider audience, which can bring different perspectives and promote continual improvement.

Practices to consider

• Open source your code: Where possible, and with the necessary security considerations, share your code repositories publicly. This allows other developers to learn from, reuse, or contribute to your code.

• Share your processes and decisions: This can be done via blog posts, open meetings, or shared documents that detail your working practices, decision-making processes, and project progress.

• Invite feedback: Provide channels for feedback on your work, whether that's through comments on a shared document, feedback on a blog post, or interactions on a code repository.

• Promote open standards: Adhere to and advocate for open standards in your work. This not only aids in compatibility and interoperability but also supports a wider culture of openness.

By working in the open, government services can not only build more efficient and user-centric digital services but also foster a culture of collaboration and learning that extends beyond individual teams or projects.

Consider potential integration points and interoperability requirements early in the design process, involving relevant stakeholders, including the Building Blocks development team.

• Identify functionalities that can be provided by other services, for example, departmental registries.

• Integrate these services using their APIs.

• Test the integrations to ensure they work correctly.

• Be prepared to handle any downtime or changes to these services.

3.4.1 Security and privacy

Choose the right level of security

Design for privacy

3.4.2 Optimise performance and connectivity

Optimise load times and page performance

Account for connectivity issues

3.4.3 Design cross-platform

Test across platforms

Design cross-channel

Understanding style guide, frontend framework, and design system

• Style Guide: A style guide is a reference tool that establishes design and writing standards. It includes branding elements (logos, colour schemes), UI components, and coding standards, ensuring consistency across a product or set of products.

• Frontend Framework: This is a structured package of standardised code (HTML, CSS, JS documents, etc.) that forms the foundation for designing a website or web application. Examples include React, Vue.js, and Angular.

• Design System: A design system is an overarching guide that includes the style guide and coded UI components (often from a frontend framework). It houses design principles, visual design rules, coded components, and other standards guiding the creation of a range of products or services.

Creating a style guide is a crucial first step in building a comprehensive design system. It defines the visual aspect of the system which can later be expanded to include coded components, UX patterns, and more.

Steps to create a style guide

If a style guide does not exist already, here are the steps for its creation:

• Audit Existing Designs - Review current services to identify common components and styles.

• Create and Document Components - Develop reusable design components (like buttons or headers) and write clear guidelines for their use.

• Define Visual Styles - Document your colour palette, typography, grid system, spacing, and other visual styles.

• Ensure Accessibility - Incorporate guidelines to ensure your digital services are usable by all citizens, for example, colour contrast between text and backgrounds.

Including style guide in a supplier's Request for Qualifications (RFQ)

If you do not have a consistent style guide across government the creation, usage and, contribution to a common style guide should be included as a requirement for suppliers. This ensures the supplier's work aligns with the existing style guide and contributes to its improvement or expansion, leading to a more collaborative, efficient, and cohesive design ecosystem. As part of the RFQ:

• Include a copy of the style guide if it exists - Make sure that suppliers have a copy of the existing style guide to understand its current state and requirements.

• Require adherence to the style guide - Suppliers should demonstrate an understanding of the style guide and show how they will adhere to it.

• Encourage contributions - Request that suppliers identify potential improvements or expansions to the style guide during their work, and include a process for proposing and implementing these changes.

Choose proportionate security to control and monitor your technology programme. Security should protect your information technology and digital services, and enable users to access the data they need for their work. GovStack offers specific guidance for designing a secure system.

Steps

1. Evaluate the sensitivity of the data you're handling.

2. Based on the evaluation, choose appropriate encryption methods and robust user authentication systems. Use the OWASP Cheat Sheet Series as a guide:

   • Authentication Cheat Sheet: This provides guidance on implementing secure authentication systems, which is a fundamental aspect of security.

   • Session Management Cheat Sheet: This covers the best practices for handling user sessions securely.

   • Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet: CSRF is a common web application vulnerability that your users should be aware of.

   • Cross-Site Scripting (XSS) Prevention Cheat Sheet: XSS is another common vulnerability, and this cheat sheet provides guidance on how to prevent it.

   • Transport Layer Protection Cheat Sheet: This covers how to use SSL/TLS, which is vital for encrypting data in transit.

   • Input Validation Cheat Sheet: Input validation is an essential measure for preventing many types of attacks.

   • SQL Injection Prevention Cheat Sheet: SQL Injection is a common and dangerous vulnerability, and this cheat sheet provides guidance on how to prevent it.

   • HTML5 Security Cheat Sheet: If your users are using HTML5, this cheat sheet covers many of the new security considerations that come with it.

3. Implement the security measures in your system.

4. Test and adjust the security measures to ensure they provide the needed protection without overly impeding usability.

Make sure citizens’ rights are protected by integrating privacy as an essential part of your system.

1. Define the data you need to collect for your service.

2. Use the Privacy by Design framework to integrate privacy controls into your system.

3. Create a transparent privacy policy that outlines what data you collect, why you collect it, and how it's used and stored. You can use the privacy policy design pattern.

4. Ensure compliance with any applicable data security and privacy protection laws.

5. Refer to GovStack's security and privacy guidelines document (ISO27K compliance)

In many contexts where GovStack Building Blocks are being used, internet bandwidth may be slow, therefore it is essential to optimise load times and minimal data transfer.

1. Use Google Lighthouse to test your web application's performance.

2. Identify areas for improvement based on the test results.

3. Implement improvements such as using compressed images, optimising front-end code, leveraging CDNs, etc.

4. Retest and continue to optimise as needed.

5. From a design perspective, only use necessary images, optimise images for the web, use CSS and SVG instead of images where possible, minimise the use of different font families, and optimise font loading if custom fonts are used.

6. Use AJAX/Fetch mechanisms for asynchronous and partial updates of the UI.

Account for connectivity issues in different regions, considering the deployment options provided by the Building Blocks.

1. Assess Connectivity Conditions and User Needs: Understand the network conditions under which your users will be accessing your service.

2. Optimise Web Performance: Minimise the size of your resources and fix performance issues.

3. Implement Progressive Loading: Design your service so that it loads the most critical content first.

4. Use a Content Delivery Network (CDN): If your users are spread across a wide geographical area, using a CDN can speed up load times.

5. Utilise Service Workers for Offline Functionality: Service workers can intercept network requests and serve cached responses. Google's Workbox can help with this.

6. Choose the Right Caching Strategies: For instance, you might cache static resources for faster loading and implement a "network first, then cache" strategy for dynamic content.

7. Implement Local Storage: Consider storing some data locally on the user's device.

8. Test Under Low-Connectivity Conditions: Use browser developer tools or network throttling tools to simulate various network conditions.

Test the service, verifying its compatibility with different devices, browsers, and assistive technologies

1. Identify the range of devices, operating systems, and browsers your users may use.

2. Use testing tools like BrowserStack or LambdaTest to test your service on these platforms.

3. Make necessary adjustments to ensure compatibility across platforms.

4. Continuously test new versions of your service on these platforms.

Design the service to work well with other government services, systems, and platforms.

Identify potential integration points within your journey. Collaborate with relevant government agencies and stakeholders to align with broader interoperability initiatives and Building Block recommendations.

Follow established standards and guidelines for multi-modal design, ensuring consistency and usability across different interaction modes.

Consider user expectations and preferences for different interaction modes, ensuring inclusivity and accessibility for all users.

Account for potential limitations and constraints of different platforms, systems, and devices, while maintaining interoperability and multi-modality.

Make sure your technology, infrastructure and systems are accessible and inclusive for all users.

1. Identify the various channels through which users will interact with your service (for example, web, mobile, SMS, call centre, physical location, etc.).

2. Consider the strengths and limitations of each channel. For instance, certain tasks might be more easily accomplished on a desktop than on a mobile device, or vice versa.

3. Design your service so that users can easily switch between channels as needed. This might involve making certain data or functionality available across multiple channels, or designing the service so that progress made on one channel can be saved and continued on another.

4. Consistency is crucial across all platforms. Keep a consistent design language (colours, fonts, layouts) and user experience (navigation, interaction patterns) across all channels.

5. Consider the use of responsive or adaptive design to ensure your service is usable on a variety of screen sizes and device types.

Example service patterns

Apply for a construction permit

Considerations for choosing different patterns

Step-by-step guide to help you pick the right patterns for your service:

• Map the user journey: Break down the user journey into phases like registration, information collection, appointments, feedback, and messaging. Identify the steps users take in each flow. Consider the technology choices available to you.

• Choose user flows: Identify the patterns (task-focused page types) needed for each part of your user journey.

• Select page templates: User flow patterns often include several page templates. Start with existing patterns for user flows. For unique requirements, you may need to mix and match individual templates.

How it works

Registration is useful when you need to give each user a unique identifier in a system or collect their information in one place. This allows users to access, apply for, or meet the requirements for a particular service.

Once a user has been registered, users can log in to their account using their chosen credentials to:

• continue using the service,

• apply for additional services,

• see the services they have used in one place,

• update their information, or

• modify their account settings

When not to use this pattern

A principle of good user design is reducing friction and making processes as seamless as possible for the user. One way to do this is by avoiding the need for user accounts where possible.

Creating and managing user accounts requires a significant amount of effort from both the user and the service provider. For the user, it's another set of credentials to remember. For the service provider, it's a matter of securely storing and managing that user data.

There are many situations where a service can be designed in such a way that a full account isn't necessary. Consider these alternatives:

One-Time GUID Links: If you need to provide users with a way to return to a specific state in a service (like a partially completed form), consider using one-time GUID (Globally Unique Identifier) links. These can be generated and provided to the user, allowing them to return to their session without needing an account.

Token-based Authentication: For some services, you can use token-based authentication. This could involve sending the user a unique token via email or SMS that they can use to access the service.

Third-Party Authentication: For services that require authentication, consider using third-party authentication services (like Google, Facebook, or Twitter login). This can make things easier for users, as they can use an existing account instead of creating a new one. However, be mindful of the potential privacy implications.

Guest Checkout: For e-commerce situations, consider offering a guest checkout option. This allows users to make a purchase without creating an account.

In all cases, the goal should be to make the user's interaction with the service as easy and smooth as possible, while still maintaining appropriate levels of security and privacy.

How it works

To use this pattern you need to have:

• A service information sheet

• A series of simple eligibility questions

• An understanding of what existing data you can integrate with

Service information sheet

Have a web page for your service where people can find the required information about the service. Such as requirements to access the service, actions and steps they need to start using your service. Check an example of a service information sheet.

Ensure to include general rules and information about whether the service can be used such as age limit.

A series of simple eligibility questions

Present the user with a series of simple questions that can determine their eligibility. Use questions when the eligibility criteria for the service is complex and require detailed information to determine if a user qualifies.

Ask the user to provide information such as their age, location, employment status, income level, or other relevant details to your service. Follow the question page pattern.

Automatically check if a user is eligible

the system should automatically process the information provided and determine whether the user is eligible to access the feature or service.

An outcome page

• Eligibility outcome that clearly states whether the user is eligible or ineligible to access the service or feature.

• Reason for eligibility determination such as a clear explanation if the user is found to be ineligible. This can include information such as incomplete or incorrect information provided in the form, not meeting certain age or income requirements, or other criteria.

• Next steps depending on the outcome of the eligibility check. For example, if the user is found to be eligible, direct them to the next step which may be to register for the service. If they are found to be ineligible, direct them to another service or further guidance.

Here are some elements that can be included on the outcome page:

Present an outcome page to users to let them know the result of their eligibility check. The outcome page should provide a clear and concise summary of the user's eligibility status. If eligible, you should let the user know of the next steps to access the service. If the user is not eligible, let them know why and what they should do instead.

• Eligibility outcome that clearly states whether the user is eligible or ineligible to access the service or feature.

• Reason for eligibility determination such as a clear explanation if the user is found to be ineligible. This can include information such as incomplete or incorrect information provided in the form, not meeting certain age or income requirements, or other criteria.

• Next steps depending on the outcome of the eligibility check. For example, if the user is found to be eligible, direct them to the next step which may be to register for the service. If they are found to be ineligible, direct them to another service or further guidance.

When to use this pattern

Services where eligibility criteria can be complex and may vary depending on the specific service or feature being accessed. By using the "check eligibility" pattern, users can quickly and easily determine whether they qualify for a particular service, without having to go through a lengthy application process or wait for manual approval.

Make a simple application

Make a long application

How it Works

Prompt for Feedback

Throughout your service journey, prompt users to provide feedback.

Feedback Form

This could be a dedicated page that opens in a new tab or a modal within the page. Provide a simple text area where users can input their thoughts and experiences. The prompt should be open-ended, such as "Tell us about your experience" or "How can we improve this page?"

Submit Button

Include a clear call to action button for submitting feedback. "Submit feedback" is an effective, straightforward choice.

Success Confirmation

After users submit their feedback, display a success message to let them know it was received successfully. This can be a simple statement like "Thank you, your feedback has been submitted."

Data you might collect

• Page URL: This shows the specific page where the user submitted feedback, giving you context about what their comments may be referring to.

• Referrer URL: This indicates the page the user visited before the current one, which could be useful for understanding the user's journey.

• Device Information: This includes data like the user's operating system, browser type, and screen resolution, which can be helpful for troubleshooting technical issues.

• Timestamp: Recording the time and date of the feedback can help identify issues that occur at specific times.

• Session ID: If your system uses session IDs, collecting this can help you associate the feedback with a particular user session.

When to use this pattern

You should aim to collect feedback whenever possible, it can be helpful in identifying issues or areas for improvement from the user's perspective.

When not to use this pattern

At the end points of the user journey, you should use the satisfaction pattern.

How it works

This page focuses the user's attention on what they need to complete the service in one go. You might list the documents or evidence required or emphasise certain eligibility criteria (e.g., age).

When to use this pattern

When there is a risk that there is more information on a start page than users are likely to read you can break the 'before you start' information onto its own page.

How it Works

Invitation for Feedback

Invite users to provide feedback about their overall experience with the service catalogue. This could be a dedicated page, a pop-up prompt, or an email sent after a certain period of usage.

Survey Form

Create a form to collect user perceptions about the entire service catalogue. Use a mix of open-ended questions and structured items (like ratings or multiple-choice questions) to gather comprehensive feedback.

Submit Button

Include a clear call-to-action button for submitting the survey. A label like "Submit survey" is straightforward and effective.

Success Confirmation

After users submit their survey responses, show a success message to confirm receipt. Something simple like "Thank you, your survey has been submitted" works well.

Data you might collect

In addition to feedback about specific services, consider collecting:

• User ID: If the user is logged in, this can help provide context for the feedback.

• Overall Satisfaction: Ask users to rate their overall satisfaction with the service catalogue.

• Specific Services Used: Understanding which services a user has interacted with can provide context for their feedback.

• Timestamp: Recording when the feedback was provided can help identify any time-related trends.

• Suggestions for Improvement: Ask users what they think could improve their experience with the service catalogue.

Potential Questions for User Survey

To gain a deeper understanding of user experience with the government service catalogue, consider including these questions in your feedback form:

• How did you find out about the government service catalogue? This can give insights into the effectiveness of your outreach and communication strategies.

• Which services have you used? Knowing which specific services a user has interacted with can provide important context for their feedback.

• How easy was it to find the services you needed? This can shed light on the effectiveness of your catalogue layout and search functionality.

• How would you rate your overall experience with the services you used? This gives a high-level view of user satisfaction with your service offerings.

• What improvements would you suggest for the services you used? This open-ended question allows users to provide specific feedback and suggestions for individual services.

• What additional services or features would you like to see in the future? This can help guide your future development efforts based on user needs and wants.

When to Use this Pattern

This pattern is useful when you want to gather feedback on the overall service catalogue, rather than individual services or interactions. This can help identify strengths and weaknesses across your offerings and improve the user experience at the catalogue level.

When Not to Use this Pattern

Do not use this pattern as a substitute for gathering feedback on individual services or interactions. Users' experiences with specific services can be different from their overall impression of the service catalogue, so both types of feedback are valuable.

How it Works

Satisfaction Survey

At the end point of the user journey, prompt users to rate their experience. This should be a simple rating scale (1-5) or a binary satisfied/dissatisfied question.

Open-ended Feedback

Following the rating, provide a text field for users to share more details about their experience. Prompt users with an open-ended question like, "How could we improve your experience?"

Submit Button

Include a clear 'submit' button to finalise their feedback.

Success Message

Display a success message after submission, thanking them for their feedback.

Data you might Collect

• User Satisfaction Score: The user's response to the satisfaction rating question.

• Feedback Text: The user's response to the open-ended feedback question.

• Page URL: The URL of the page from which the feedback was submitted.

• Session ID: Identifies the particular user session, for associating feedback with specific user journeys.

Potential Questions for User Survey

Consider adding questions to your satisfaction survey to gain deeper insights:

• Did you accomplish what you intended to do in this session? Helps understand if the user journey was effective and efficient

When to use this pattern

Use this pattern at the end of a user journey to collect valuable feedback about user experiences. Be aware that user satisfaction is biased to users that reach an end-point of a service.

User flows

How it works

Service name

This helps people understand what your service does and whether they need to use it.

Documents and any fees required

A list of things most users need to know: for example, what your service is, what will happen, what users will get or how much it'll cost. To keep the content concise, do not include details about anything that would be obvious to users.

A call-to-action

There should be a clear call to action button to start the service, usually “Start now”. You should also include a link to “sign in” or “continue journey” if the user is able to continue an existing journey.

Other ways to access the service

You should provide ways for people who can’t access the service online to get support, for example, by phone or text relay. You may also include details for support channels.

When to use this pattern

At the start of a service which involves the user inputting information in order to get something. For example, at the start of an application form.

Related Building Block: .

How it works

Consent covers all activities done for the same reason. If you use the data for more than one reason, get separate consent for each. For example, accessing data to check eligibility is separate from accessing data to make an application.

Use these patterns when you need to:

• To access a user’s data.

• To store, manage or share a user’s data.

• Allow users to manage the data you hold on them.

When not to use these patterns

You do not need to ask for consent when:

• the data is required for a government to perform a specific task or function set out in law, you do not need to ask for consent. For example, terms and conditions — these are required so you do not need to ask for consent.

• a person is simply informed of the processing of the data by the organisation as part of the service provided under contract or by an authority.

• consent does not have to be obtained in a situation where the entity does not identify or cannot identify people with reasonable effort.

Consent page

This pattern allows users to accept or reject a request to access or share data for the use of a service. For example, asking to access data from social insurance records in order to check eligibility for another service.

User journey considerations:

• Consent should be grouped by purpose meaning you may need multiple consent pages.

• You may need to ask for consent at the start of a service or throughout the user journey.

• You should test your service with users to find the journey that works for them.

Why we ask to share this data

Explain what data you are requesting and the benefit to the user for sharing that data. For example, “Provide your location data so that we can tailor offers relevant to you”.

About the data

Be clear about:

• Why you need it and the benefit to the user.

• How the data will be used and for how long.

Confirm or reject

If you are handling a simple data set, present the data you are collecting followed by a checkbox to explicitly confirm consent.

If you are handling multiple data sets allow the user to choose which data is shared.

Implied consent

If you do not need to ask for consent but you are handling user data this should be specified in the privacy statement.

[Add guidance on when that should be presented to the user]

Handling data beyond the transaction

Managing consent

[Give details for how to manage data if the user changes their mind.]

Delegated consent

In cases where the person giving consent is doing so on behalf of someone else, as a guardian or carer.

[This pattern is in the backlog]

Additional details for information collection

When asking users information during a questions flow consider using progressive disclosure drop-downs or inline content to explain why you are asking for that information and how you will handle the data.

Clearly state why you need the information and how it will be used. For instance, you might need users' information so that you can provide a service, register them for a service, or tailor an experience to meet their needs.

Consider whether you need to ask for the information or whether you can use integrations to get that data from internal or external sources. Check whether you need to ask for consent to ask the questions.

You can use a question protocol to help you figure out what you need to ask. If you ask people for optional information, add ‘(optional)’ to the question. Do not mark mandatory questions with asterisks as these are not accessible.

Question page

Backlink

A question page should have a backlink to help users who may want to go back to the previous question to make any changes.

Question or question heading

When asking people for information, ask for one thing at a time. Helps users focus on one specific thing at a time and provide its answers without overwhelming them with too many demands at once.

This can be one question per page or group-related questions together, for example, contact details. Grouping related questions together can help users understand the context of each question and make it easier to provide accurate responses. When you group related questions together, you will have a ‘question heading’ that will help people understand what is needed for the set of questions.

Hint text

Provide clear instructions to help users understand what is expected of them on each question.

Question field

Use the appropriate question field for the different question types.

Other ways to provide information

Always provide other alternative mechanisms for users to identify themselves or provide their information so that they can access your service. Provide clear instructions on what to do if they encounter any problems.

By allowing users to review, make changes, or confirm their answers, this pattern helps prevent errors in data submission.

The long term benefits of this pattern are:

• users will be confident while using your service as they can visually confirm that all their information has been accurately captured.

• reducing incorrect and incomplete information will result in lower error rates in applications.

When to use this pattern

Use this pattern when you need to capture information from users on a form that spans multiple pages or steps.

How it works

• Use a clear heading that clearly communicates the purpose of the page, such as "Check your answers before sending your application"

• Show the summary of questions and answers given. Ensure the information is organised and easy to scan.

• Consider the type of answers expected from users. For longer answers, utilize a full-width layout to accommodate the content. For shorter answers, a two-thirds layout may be appropriate to optimise space.

• Break content into sections if needed. If there is a large number of questions or if it improves the clarity, divide the content into relevant sections.

• Clearly indicate when a question has not been answered because it was optional. Make it evident to the user that the answer was not provided.

• Provide navigation to edit answers. Offer users a straightforward way to navigate back to previous steps and edit their answers if needed. This can be achieved through direct links or buttons that allow users to easily access and modify specific questions.

• Include a call to action button at the bottom of the page that helps the user take the final action such as submitting their application.

Use clear labels for each step and provide a visual indicator of their progress. Show the order in which the steps should be completed and mark completed tasks.

How it works

• Group similar tasks together and use clear headings to explain what is involved or is needed to complete the task.

• As users complete each step or task, show a label that describes their progress.

  Use visual and written labels to indicate their progress. Avoid relying solely on visual indicators like progress bars or percentages, as they may pose accessibility challenges. Include a text display of progress as well.

• Maintain a sense of hierarchy: If there is a specific order in which the steps should be completed, make it evident to the users. You can indicate the hierarchy by organising steps in a logical sequence or visually nesting them within each other.

• If the form or transaction is long, provide a save feature that allows users to pause and continue later. When users resume the transaction, display the task list page as the first thing they see.

When to use this pattern

In a complex long form that involves multiple tasks, steps or pages.

Outcome page

How it Works

On this page include:

• Details on what will happen next.

• Contact details to provide users with further support.

The good practice guidelines have been influenced by service quality standards like:

• ISO25010

• UK’s Service Standard

• Dubai’s Smart Service Excellence Delivery Model

• OECD Good Practice Principles for Public Service Design and Delivery in the Digital Age

The service patterns have been highly influenced by public sector design systems such as:

• Essex Council and TPXImpact (then FutureGov)

• GOV.UK Design System

• US Web Design System

• Japan Digital Agency

• Helsinki Design Systems.

\

Construction Permit use case

The first end-to-end example using the patterns and guidelines in this document was for the .

You can see how the use case journey works in a demo (add link to demo) by .

9.1 UX/UI switching guidance

Technical guidance for implementers looking to understand how screen level switching between GovStack applications/Building Blocks could work.

9.2 Key Decision Log

A historical log of key decisions regarding this Building Block.

9.3 Future Considerations

A list of users flows and patterns to add to these UX/UI specifications in the future

A list of topics that may be relevant to future versions of this Building Block.

9.4 Out-of-Scope Assumptions

A list of functions out of the scope of this Building Block.