Skip to content

Add Vision doc#26

Open
andrewHEguardian wants to merge 2 commits intomainfrom
ahe/vision
Open

Add Vision doc#26
andrewHEguardian wants to merge 2 commits intomainfrom
ahe/vision

Conversation

@andrewHEguardian
Copy link
Contributor

What does this change?

Adds a Vision doc for Stand. The contents of this document were collaborated on by a wider group in a session, and synthesised in this PR.

Here follows the doc:


Challenges:

  1. A large estate of tools has been built using a variety of UI frameworks and patterns. This inconsistency creates a steep learning curve for users using those tools and engineers developing them.
  2. The designs and implementations of many tools are old and may not meet modern accessibility standards.
  3. There is no clear path for how to develop UI or implement UX when building new tools, especially with limited design support.
  4. There is unlikely to be a team dedicated to maintaining a design system long term.

Vision:

The goal of Stand is to provide a single design system that creates consistency within Guardian tools, ensuring clarity and reducing friction while being inclusive by design, so that everyone can use and contribute to our tools.

Clarity

End users should immediately understand the purpose, state and consequence of Stand components.

Each component defines when designers and engineers should use it. Its behaviour, interactions, logic and design decisions are explicit and documented.

KPIs:

  • User feedback.
  • New UI is built using Stand
  • Existing UI migrated to use Stand

Consistency

Stand components should work universally across tools. Components should increase efficiency by reducing friction in user interactions and improving delivery speed for engineers and designers.

Stand should provide clear defaults to reduce repeated design decisions and avoid one-off customisations that increase maintenance costs. Their design should feel familiar but distinct across tools. Components should be modular and composable.

There should be a source of truth that is easy to find. This should mitigate issues from divergence between design and code.

KPIs:

  • Adoption of Stand
  • Stand components used instead of custom components built
  • If a new component is required, it should be implemented within Stand first and then used within the consumer (there might be a better way of phrasing this)

Inclusive by design

Accessibility in Stand is not optional. Designs should meet our accessibility standards. All colleagues should be able to work effectively in tools, regardless of role, ability or context.

Components should be well documented so designers and engineers can adopt them quickly. There should be contribution guidelines for extending the system.

KPIs:

  • Number of engineers contributing to the design system
  • Passes accessibility testing

@andrewHEguardian andrewHEguardian requested a review from a team as a code owner March 11, 2026 16:36
@andrewHEguardian andrewHEguardian added documentation Improvements or additions to documentation maintenance Departmental tracking: maintenance work, not a fix or a feature labels Mar 11, 2026
@github-actions
Copy link

github-actions bot commented Mar 11, 2026

Dependency Compatibility Matrix

React Emotion TypeScript RAC Typecheck Unit E2E Build Overall
17 11.11.4 ~5.0 1.13.0 ok ok ok ok
17 11.11.4 ~5.0 1.15.1 ok ok ok ok
17 11.11.4 ~5.1 1.13.0 ok ok ok ok
17 11.11.4 ~5.1 1.15.1 ok ok ok ok
17 11.11.4 ~5.9 1.13.0 ok ok ok ok
17 11.11.4 ~5.9 1.15.1 ok ok ok ok
17 11.14.0 ~5.0 1.13.0 ok ok ok ok
17 11.14.0 ~5.0 1.15.1 ok ok ok ok
17 11.14.0 ~5.1 1.13.0 ok ok ok ok
17 11.14.0 ~5.1 1.15.1 ok ok ok ok
17 11.14.0 ~5.9 1.13.0 ok ok ok ok
17 11.14.0 ~5.9 1.15.1 ok ok ok ok
18 11.11.4 ~5.0 1.13.0 ok ok ok ok
18 11.11.4 ~5.0 1.15.1 ok ok ok ok
18 11.11.4 ~5.1 1.13.0 ok ok ok ok
18 11.11.4 ~5.1 1.15.1 ok ok ok ok
18 11.11.4 ~5.9 1.13.0 ok ok ok ok
18 11.11.4 ~5.9 1.15.1 ok ok ok ok
18 11.14.0 ~5.0 1.13.0 ok ok ok ok
18 11.14.0 ~5.0 1.15.1 ok ok ok ok
18 11.14.0 ~5.1 1.13.0 ok ok ok ok
18 11.14.0 ~5.1 1.15.1 ok ok ok ok
18 11.14.0 ~5.9 1.13.0 ok ok ok ok
18 11.14.0 ~5.9 1.15.1 ok ok ok ok
19 11.14.0 ~5.0 1.13.0 ok ok ok ok
19 11.14.0 ~5.0 1.15.1 ok ok ok ok
19 11.14.0 ~5.1 1.13.0 ok ok ok ok
19 11.14.0 ~5.1 1.15.1 ok ok ok ok
19 11.14.0 ~5.9 1.13.0 ok ok ok ok
19 11.14.0 ~5.9 1.15.1 ok ok ok ok

Columns show granular outcomes for each dependency set: ok = passed, fail = failed, skip = upstream failure prevented running later stages. Overall: ✅ all passed, ⚠️ only skips (no hard fails), ❌ at least one fail.
Last updated: 2026-03-12T11:57:57.866Z (commit 5cac4bc)

@bryophyta
Copy link

Nice! This is looking great so far 👍 I've added a couple of initial thoughts inline

Co-Authored-By: Andrew Howe-Ely <114918544+andrewHEguardian@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation maintenance Departmental tracking: maintenance work, not a fix or a feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants