Links

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

  1. 1.
    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.
  2. 2.
    Submit the SNC to the digital system team by filling out the new component form and submitting it through the feedback channel
  3. 3.
    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:
  1. 1.
    Define Objectives: what are the main goals/priorities of the new version, what needs are being solved with this version.
  2. 2.
    Execute: add new components, modify existing components/styles based on testing or data, or remove components that are not used or performing poorly
  3. 3.
    Validate: every new update meets defined criteria to ensure usability, consistency and quality (ie. states, behaviours, actions, scalability)
  4. 4.
    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

  1. 1.
    Form a multi-disciplinary 'Digital System Guardian' team
  2. 2.
    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
  3. 3.
    Define and communicate the governance and versioning workflow—everyone should know it