Governance
In our experience developing digital systems for large organisations, the governance process is what allows the system to scale while maintaining consistency and room for innovation. It is fundamental to define before launching the system.
Before we get into the method we use to standardise the workflow, below are a few parts that are critical to this success:
Digital System Team
A team of designers and developers that analyse new components to be added. This team should consist of designers (UX, UI) and developers that are assigned to projects and represent different channels and business units. There will be ongoing meetings between the 'system guardian team' and new project teams to review designs and components. Their job is not to approve design, but provide a holistic view of the Digital System and its use across all teams.
Feedback Channel
An easily accessible communication channel is crucial in order for design teams to submit feedback and new components. The channel can be a contact page on the digital system web, or can also be a more manual email address. Whichever it is, it should be easily accessible and communicated to all teams working with the system.
New Component Form
A submission form will standardise the process for local design teams to create and suggest new components to add to the system based on their project needs. In order for the Digital System team to be able to efficiently review and respond, it is best that all submissions follow the same template and include the following items:
Team and project
Touch point (web, app, business unit)
Need for new component
New component, designed
Any additional context to review and analyse component (why do they need it, full page design, user flow if new component impacts UX)
Sprint delivery date
Digital System Communication
A bi-weekly newsletter to all product teams provides a constant connection to the teams using the system and provides additional information like:
System updates (new components)
Upcoming updates/components with dates
Usage guidelines
Important reminders
Workflow
New component request
It is very probable that product teams will identity new component needs that are not covered by the system. There are two scenarios:
A similar component already exists. The current library contains the necessary component, or one very similar, to cover this need and therefore should be used.
The current library does not have a component to cover this need and so one needs to be created. In this instance, the product team should follow the next steps.
Steps for creating a new component
Design a "suggested new component" (SNC) using the systems guidelines that solves the design need of that component, contextual to the product it is meant for.
Submit the SNC to the digital system team by filling out the new component form and submitting it through the feedback channel
If it is a group of components or one that is more complex, an in-person meeting between the project team and the digital system team should be scheduled to share additional context, resolve any questions and make the final decision
Once the new component is reviewed, the digital system team can determine what tier the new component should live—tier 3 "local system" where only the project team has access or tier 2 "platform system" where all teams would be able to access and use the new component. In order to make this decision, they should keep in mind:
The reuse of the component in other tools and products
The impact of the component within the digital system
The technical complexity of the component
Versioning
As we previously stated, the digital system is a living document that will be constantly updated. The digital system team will need to create and communicate new versions of the system on a consistent basis. To do this in a controlled and effective way, we suggest the following flow:
Define Objectives: what are the main goals/priorities of the new version, what needs are being solved with this version.
Execute: add new components, modify existing components/styles based on testing or data, or remove components that are not used or performing poorly
Validate: every new update meets defined criteria to ensure usability, consistency and quality (ie. states, behaviours, actions, scalability)
Close version: publish new version to Figma/Sketch and begin implementing changes in the digital system web platform
It is important to document what changes were made as each version is closed. There are plugins that can automatically extract this information and create a change log for developers and designers to easily reference.
Action
Form a multi-disciplinary 'Digital System Guardian' team
Define the different ways any member of the organisation can get in touch with the system team, for questions or when they submit a new component
Define and communicate the governance and versioning workflow—everyone should know it
Last updated
