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.

3.3.1 Use simple language

Use simple language

3.3.2 Reuse existing styles and patterns

Implement a consistent style guide

Use design patterns

Use a frontend framework

3.3.3 Provide a joined-up experience

Interoperability

Use integrations where possible

3.3.4 Share design decisions

Work in the open

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.

\

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.

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.

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

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.