Nimbus Design System user research

Developer interviews (MeetingPlace ART & �Self Service ART) �PI1 2023

​

April 2023

Understanding the dev Nimbus experience

What we knew

• Since its inception and development, the Design Team has championed Nimbus Design System in partnership with the rest of MeetingPlace ART.
• Nimbus is built on three values:
• Efficiency – Nimbus is modular and scalable.
• Simplicity – Nimbus is concise and follows best-practice.
• Inclusive – Nimbus is for everyone, user focused and co-owned by Design, Development, and Product.
• Nimbus has become embedded in design and development practice in MeetingPlace and, as of 2022 has been introduced into the Self-Service ART.

​

Emerging questions

• Much of the Design Team’s focus to now has been on the establishment of the system and on the Design Documents that support our work.
• As we started to wrap up the current iteration of the Design Docs, we wanted to understand better the developer experience of using Nimbus. Especially as other ARTs were using it to implement major features (such as Console Secure).
• We conducted nine interviews with devs who have used Nimbus (4 MeetingPlace, 5 Self-Service) in PI 1 2022.
• We focussed on the dev experience of being introduced to Nimbus, typical usage and trying to understand their challenges and benefits.

​

Efficiency | Simplicity | Inclusivity

2

Key findings 1�Systems and process

Developer processes vary when breaking down designs for development, and many depend on consistent component naming between Figma designs and component naming in the Nimbus UI kit. We heard from multiple devs, particularly from SS-ART, who lost significant time and momentum in locating the correct component to use.

​

​

Findability of components

​

​

​

Lack of standardisation across development docs and UI kits.

Components are being added to the Nimbus UI kit in Storybook with incomplete or non-existent documentation (e.g., radio buttons) that helps define how the component should or can be used by other developers.

Component standardisation

​

​

​

Developers are not clear on what are core components and, what components belong in Nimbus and what don’t.

As a result, components are being added to Storybook UI that does not align with the design documents defined by the Design Team as a point of truth.

What is a ‘core’ component?

​

​

​

Developers observed that some components are inconsistent and out of sync across the Console Core UI kit, project UI kits and Nimbus UI kit.

Largely a result of time pressure on our devs, components may be copied over from Core into Nimbus but then updated in Core as requirements change, and these often do not get synchronised back to Nimbus UI.

Lack of synchronicity

​

​

​

Efficiency | Simplicity | inclusivity

4

“I think the documentation is sort of a bit hit and miss, …. Some, some things are better documented than others.”

5

MeetingPlace dev

Impact on the business

• Developers waste time looking for components that should be easy to find. (Loss of focus and flow is common and extreme cases of whole teams hunting for components were reported).
• Rework by developers and designers when components are not fit for purpose or not working as intended.
• Poor code quality leading to poor performance/security risks.
• Frustration with the relationship between developers & designers with the potential to devolve into a culture of ‘us and them’.
• A perception that design and development are separate, which erodes the working relationship.

Why is this a problem

Efficiency | Simplicity | inclusivity

6

Key findings 2�People & governance

No standard onboarding process exists for new staff to explain how Nimbus works and how to get the most benefit from it.

We heard of a range of strategies, from pointing junior devs at an out-of-date wiki page, dedicated inter-ART information workshops, and side-by-side peering with experienced and junior devs or designers, but nothing that could point to a clear and consistent message of intent and process.

Nimbus relies on consensus rather than a strict rule set, as seen in InfoSec. Still, knowledge about what makes a Nimbus component, when it should be added and what it looks like is not wildly known. The results of an unrestrained process lead to the inconsistency and missing content outlined previously. Guidelines on when and what to contribute, points of truth and managing discrepancies will assist developers and designers in getting the best from the design system.

Onboarding

Governance

Efficiency | Simplicity | inclusivity

7

Developers are time-poor was the most consistent reason why components were not added to the Nimbus Storybook UI kit when created or updated after changes in Console Core.

Feature implementation is the priority but one developer indicated that it is quicker to develop new components in the Console UI kit and copy and paste across to Nimbus if time allows.

Updates are low priority

“Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor.”

Efficiency | Simplicity | inclusivity

8

Impact on people

• Devs and designers don’t understand the roles each plays – which leads to fence chucking.
• Developers don’t understand the big picture. Why does Nimbus exist, and why is it important?
• New staff don’t understand who is responsible for what part of the design system.
• Contribution to Nimbus is infrequent, content is not comprehensive, and quality is inconsistent, as adding to Nimbus comes to be seen as a chore, not a benefit or duty.
• Governance, guidance, and onboarding can all build a shared culture and understanding of the importance of Nimbus and mitigate many of the issues that have arisen. Still, they are applied inconsistently or not at all, leaving developers to figure it out as they go along.

Why is this a problem?

Efficiency | Simplicity | inclusivity

9

Why should we fix it & �What’s next?

Efficient. Simple. Inclusive. Despite the challenges highlighted, developers see the benefits of Nimbus.

“It makes it easy to use components within a component you are making.”

The component library and design tokens are convenient building blocks that “increase productivity” and are seen as “an Investment in future work efficiency for self and business …. reusability!”

Efficiency | Simplicity | inclusivity

10

Opportunity to improve the developer experience. I

Next steps

​