Summary
To support the continued growth of the Design team, we are establishing shared foundational princples and gudielines for our workflows. The goal is to create a consistent, scalable way of working that improves collaboration, quality, and efficiency across design without removing individual creativity or problem-solving approaches.
These standards will define how we work together rather than how we design. By documenting shared practices, we can reduce ambiguity, improve onboarding, increase consistency across projects, and create stronger alignment between Design and Engineering.
This Epic will act as the umbrella for all Design Ops documentation and principles.
Objectives
- Establish shared standards for the design team's ways of working.
- Improve consistency across Figma files, documentation, ticket writing and design delivery.
- Reduce onboarding time for new designers.
- Increase collaboration between Design and Engineering.
- Create documentation that can evolve alongside the team and Visual Framework.
Project Phases
Phase 1 — Research & Discovery (Current Phase)
The current focus is research rather than documentation.
Each Design Ops category will be reviewed to:
- Audit our existing processes and documentation.
- Identify gaps, inconsistencies and pain points.
- Research industry best practices from an array of sources.
- Produce recommendations and suggested improvements.
- Discuss proposals with the wider design team before agreeing on standards.
Deliverable: A set of agreed recommendations for each Design Ops category.
Phase 2 — Documentation & Rollout
Once recommendations have been reviewed and agreed, we will move into writing the Design Ops documentation.
This phase will include:
- Creating clear, maintainable documentation.
- Publishing documentation in the agreed location (WebDev Drive).
- Updating existing resources where required.
- Introducing documentation to the wider team.
- Iterating documentation based on feedback and future improvements.
Deliverable: Published Design Ops guidance that becomes the team's shared source of truth.
Success Criteria
- Design Ops categories have been researched and reviewed.
- Team consensus has been reached on proposed standards.
- Documentation is written, published and accessible.
- Documentation becomes a living resource that evolves with the team.
Notes
This Epic covers the overarching Design Ops initiative only.
Individual research areas (e.g. Figma Components, Accessibility Principles, Ticket Writing, File Organisation, etc.) will be tracked as separate child issues.
Research should prioritise recommendations over implementation. Documentation writing will begin once the research phase has been completed and proposals have been reviewed by the team.
Summary
To support the continued growth of the Design team, we are establishing shared foundational princples and gudielines for our workflows. The goal is to create a consistent, scalable way of working that improves collaboration, quality, and efficiency across design without removing individual creativity or problem-solving approaches.
These standards will define how we work together rather than how we design. By documenting shared practices, we can reduce ambiguity, improve onboarding, increase consistency across projects, and create stronger alignment between Design and Engineering.
This Epic will act as the umbrella for all Design Ops documentation and principles.
Objectives
Project Phases
Phase 1 — Research & Discovery (Current Phase)
The current focus is research rather than documentation.
Each Design Ops category will be reviewed to:
Deliverable: A set of agreed recommendations for each Design Ops category.
Phase 2 — Documentation & Rollout
Once recommendations have been reviewed and agreed, we will move into writing the Design Ops documentation.
This phase will include:
Deliverable: Published Design Ops guidance that becomes the team's shared source of truth.
Success Criteria
Notes
This Epic covers the overarching Design Ops initiative only.
Individual research areas (e.g. Figma Components, Accessibility Principles, Ticket Writing, File Organisation, etc.) will be tracked as separate child issues.
Research should prioritise recommendations over implementation. Documentation writing will begin once the research phase has been completed and proposals have been reviewed by the team.