Introduction

When a change is introduced to the design system, it should undergo a number defined steps. The length of time required for each step may vary depending on the complexity of the change. For simple or obvious changes, a quick community validation may suffice. However, for more complex changes, several workshops, rounds of communication with the community, and iterations of discovery may be necessary.

By following this process, requirements and issues can be identified earlier, allowing the design system to evolve effectively and the changes to be robust and future-proof.

Proposal

The RFC (request for comments) is a process where gaps in the design system are identified. It is encouraged that everyone participates in commenting and contributing to a Proposal. With sufficient community involvement, a pattern may emerge, allowing the team to identify and articulate the problem they are interested in solving.

If there is significant community interest in the proposed change or the change has complexities, workshops can be an ideal way to bring stakeholders together. These workshops can help identify priorities, provide the opportunity to deep dive into related problems, and share any relevant experience, research, and business logic.

Creating a Proposal

Individuals who contribute to Nucleus have the ability to create a Proposal in the GitHub repository.

It is recommended that a Proposal is created only after all other options have been explored using what is currently available in the design system.

Discovery

Once a problem has been identified, the team begins researching potential solutions. They create a loose outline of the scope they will tackle and prioritise proposals based on their urgency and importance. When a proposal is chosen, the team creates story tickets based on the deliverables required to solve the problem. If multiple deliverables are needed, then multiple story tickets are created to ensure that each task is properly tracked and completed.

User testing

At this stage, testing plays a key part in discovery. Testing potential solutions can be done in a variety of ways:

• A/B or multi-variant tests
• Remote or lab based usability testing
• Guerrilla testing

Refining and defining

The design and engineering teams work together to conduct the majority of the discovery process. They provide feedback to the rest of the team, which results in a clearly defined scope for the task.

By taking a vanilla first approach, they gain an understanding of the starting point of the solution, which in turn helps to define the desired outcome of the work.

Delivering the development spec and discovery

The conclusion of the discovery is added to the story ticket and an initial development specification for the change is outlined. This update to the story ticket is to be announced in the Proposal by the team to keep the open conversation going with the community.

Design

From here a more finessed and detailed design will be created. With more decisions about branding, interactions and responsive behaviour.

Time will be spent looking at how these changes interact with all parts of the design system and the context in which it belongs. This should follow the digital design process and code of conduct.

Development

The creation of the changes to the design system will now commence and will be delivered through development. The team will follow their digital development process and code of conduct at all times.

Documentation

Taking what has been learnt from each part of the process, the relevant documentation is then produced. Any changes that have been introduced during development must be added or updated in the documentation. The documentation is a team effort and relies on everyone’s contribution, review, and feedback.

Testing

The change that has been made should be reflected in the tests. It should be ensured that any modifications haven’t affected accessibility, browser and device compatibility, or the user experience.

Testing should also be conducted using functional, regression, behaviour-driven development, and visual regression tests.

Releasing

When everyone is confident with the changes, these can be released following the ‘SemVer’ semantic versioning convention.

Then the news about the changes can be shared through the channels to inform the community and gather feedback on usage.

It’s important not to forget to take the time to celebrate accomplishments and congratulate people for strengthening Nucleus.

Contributing

If someone would like to contribute to the design system, either with a change or if they are looking for something new, then they should read Contribute to Nucleus.