Workday’s ‘Design System Council’ - service design to steer design governance.
Workday provides cloud-based responsive and mobile software for human resources (HR) and financial professionals (FIN) to simplify workforce management tasks such as payroll, scheduling, employee onboarding, time tracking, learning, talent management, and performance evaluations. Workday has ~12,000 global clients and employs ~18,000 people worldwide.
Overview.
Summary.
Workday’s central design system (Canvas) needed to increase the relevancy of design system tools and documentation for use by product teams, while also increasing design system visibility into what’s being designed at product levels. We needed to better understand how design system tools are being applied in products, and to govern quality and cohesion of design system output across product teams.
We defined, delivered and operate a Design System Council model that has 100% representation across internal design teams at Workday and which is equipped with decision making, vetoing, governance and voting powers.
The key objectives of the council are to strengthen Workday’s consolidated design point-of-view. To support internal Workday production teams to make better design decisions. To increase the value and relevance of design system tooling and documentation. And to ultimately ensure the experiences which get released across Workday products are more cohesive and intuitive experiences for end users.
Project roles.
My role.
Council co-founder, service design lead, council administrator, council facilitator.
I currently co-lead, facilitate and administrate this Workday internal design council (2025).
Size of the project team.
- 2 co-founders
- 4 administrators
- 2 facilitators
- 48 design council members
- 1 executive sponsor
Initial project duration.
6 month trial phase (Q1/Q2 2024)
(Design System Council is now an ongoing Workday internal design mechanism)
Details.
Problems to solve.
Relevancy of design system tools and documentation. What gets designed and released by the central design system is not always what’s timely and most needed by product teams. Product designers have closer access to research data on what customers are saying and what end users need. These needs are not always sought, or readily available when design system priorities and roadmaps are being determined.
Design system visibility into what is being designed at product level and how design system resources are being used in product solutions. Central design do not always have access to data on how our tools and services are being taken up by teams, and if there are improvements that we need to make to increase usefulness and relevance.
Quality and cohesion governance of design resources. Different standards and structures for documentation, assets and maintenance across repos lead to varied levels of quality. The central design team need to increase their awareness of these in order to work with product teams to improve cohesion of repos.
Confidence and knowledge in applying design resources. Variety of quality standards and maintenance processes between repos lead to uncertainty for users that they have all the info they need to hand. This reduces confidence and siloes knowledge.
Key Objectives.
Scale a unified Workday design point-of-view by increasing use of existing and approved design system tools and documentation.
Increase efficiency of production cycles by reducing ad-hoc duplication of product solutions.
Reduce churn during production cycles due to uncertainty over which design solutions to apply.
Increase user confidence in quality, relevance and usefulness of design system resources.
Reduce current culture of over-reliance on slack reach outs and 1:1 design queries across product teams.
Users we’re solving for.
Workday Designers. People within Workday design orgs with ‘designer’ in their role title and who need to use design system tooling and documentation every day in order to complete their project tasks successfully and on time.
Workday PMs, Engineers, all design decision makers. Anyone at Workday who needs to use design system tooling and documentation to make design decisions as part of their role (PMs, Functional Architects, Developers, Brand, etc), when designer support for their product isn’t readily available.
Delivery Method.
Phase 1: Executive sponsorship.
Achieve executive sponsorship and resource allocation to deliver our service vision for a Workday design system council.
Phase 2: Defining council roles and permissions.
Define user roles, permissions and JTBD.
Create service blueprints and user journeys for Team Reps, System SMEs and Council Admin roles.
Phase 3: Creating Council object models.
Design governance model and a service participation model.
Stakeholder and project team workshops.
Content strategy for identifying and prioritising council topics.
Phase 4 : Project planning.
Roadmapping, Gant charting, effort estimations, resource allocation, Jira Epics.
Phase 5 : Stakeholder communications and commitment.
Presentations and roadshows to managers and leaders of design teams to achieve their commitment for representatives from their teams to participate in the Workday Design System Council.
Phase 6 : Participant communications and upskilling.
Communication strategy implemented to target nominated council Team Reps: Solution roadshows and live Q&A sessions, written comms in user targeted slack channels and email lists.
Phase 7 : Council launch.
Organised monthly Council events with topics sought from all design team participants.
Phase 8 : User testing and iteration.
Initial 6 month trial model (Jan-Jun 2024) to gather research data from participating teams to iterate and improve the Council service model and key objectives.
Phase 9 : Evolving and scaling.
Workshops and feedback mechanisms with stakeholders and Council participants to continue to improve the service offering and value being delivered.
Outcomes.
Measuring success.
100% of design teams at Workday are represented on the Design System Council via the Team Rep roles and permissions model.
Design System Council has to date actioned 100% of topics brought through the Council mechanism.
90% of design team council reps say they find the Design System Council to be a valuable mechanism for communication, governance and decision making cross-product and with central system teams.
Council members have so far given federated design input into 28 ongoing design system projects.
Lessons learned.
Having a content strategy in place to prioritise monthly council topics helps to keep us all focused on the key objectives.
Interactive topics where live feedback is sought during council sessions resonate well with participants and boost engagement.
Keeping design managers and stakeholders updated regularly on progress and decisions made in key to continuing support and sponsorship.
Providing regular opportunities for feedback and retros reduces the risk of disengagement and frustration from Team Reps and SMEs concerned over additional workload.
What to change going forward.
Rotations for Team Reps. Set up a formal structure to give people the opportunity to cycle out and nominate a replacement after 6 months. Currently this is happening ad-hoc which causes unnecessary overhead for council admins.
Compile and send newsletter summaries of governance decisions made and votes taken by the council to executive product and design leadership to keep them in the loop.