LogoLogo
Give FeedbackGovStack Home
25Q2
25Q2
  • GovStack
  • Contributing
  • Architecture and Nonfunctional Requirements
    • 2 Introduction
    • 3 GovStack Architecture
    • 4 Building Block Design Principles and Considerations
    • 5 Cross-Cutting Requirements
    • 6 Onboarding Products
    • 7 Standards
    • 8 UX Switching and Handover
    • 9 Other Resources
  • Security Requirements
    • 2 Description
    • 3 Terminology
    • 4 Security Management
    • 5 Cross-Cutting Requirements
    • 6 Standards
    • 7 Authorization Services
    • 8 Additional Security Modules
    • 9 Other Resources
  • GovStack UI/UX Guidelines
    • 1 Version History
    • 2 Description
    • 3 Service design good practice guidelines
      • 3.1 User-centred design
        • 3.1.1.1 Understand needs and requirements
        • 3.1.1.2 Involve others in the design process
        • 3.1.2.1 Test with users
        • 3.1.3.1 Share findings
        • 3.1.3.2 Monitor performance
          • 3.1.3.3 Set up analytics
      • 3.2 Accessibility and inclusion
        • 3.2.1.1 Test for accessibility
        • 3.2.2.1 Involve a diverse user group in the design
        • 3.2.2.2 Support multiple languages
        • 3.2.2.3 Foster a culture of inclusion
      • 3.3 Consistency
        • 3.3.1.1 Use simple language
        • 3.3.2.1 Implement a consistent style guide
        • 3.3.2.2 Use design patterns
        • 3.3.2.3 Use a frontend framework
        • 3.3.3.1 Interoperability
        • 3.3.3.2 Use integrations
        • 3.3.4.1 Work in the open
      • 3.4 Technology choices
        • 3.4.1.1 Choose the right level of security
        • 3.4.1.2 Design for privacy
        • 3.4.2.1 Optimise load times
        • 3.4.2.2 Account for connectivity issues
        • 3.4.3.1 Test across platforms
        • 3.4.3.2 Design cross-channel
    • 4 Design patterns
      • 4.1 Service patterns
      • 4.2 User flows
        • 4.2.1 Register
        • 4.2.2 Authenticate
        • 4.2.3 Asking users for feedback
        • 4.2.4 Find a service
        • 4.2.5 Check a users eligibility
        • 4.2.6 Make an application
      • 4.3 Page templates
        • 4.3.1 Feedback
        • 4.3.2 Perception survey
        • 4.3.3 Satisfaction
        • 4.3.4 Before you start
        • 4.3.5 Service sheet
        • 4.3.6 Asking users for consent
        • 4.3.7 Task list
        • 4.3.8 Asking users for information
        • 4.3.9 Check answers
        • 4.3.10 Outcome
    • 5 Use-case examples
    • 6 References
    • 7 Other Resources
  • Building Blocks
    • About Building Blocks
    • Cloud Infrastructure
    • Consent
    • Digital Registries
    • E-Marketplace
    • E-Signature
    • Geographic Information System (GIS)
    • Identity
    • Information Mediation
    • Messaging
    • Payments
    • Registration
    • Scheduler
    • Workflow
    • Wallet
  • Use Cases
    • Reference Use Cases
  • Public Administration Ecosystem Reference Architecture (PAERA)
    • PAERA
  • Tools
    • Sandbox
  • Release Notes
    • 23Q4
Powered by GitBook

Apache-2.0 license

On this page
  • Understanding style guide, frontend framework, and design system
  • Steps to create a style guide
  • Including style guide in a supplier's Request for Qualifications (RFQ)

Was this helpful?

Export as PDF
  1. GovStack UI/UX Guidelines
  2. 3 Service design good practice guidelines
  3. 3.3 Consistency

3.3.2.1 Implement a consistent style guide

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.

Was this helpful?