Desk design system

Teamwork Desk
My role
Lead UI Design, guideline / pattern writing, design system strategy, design system roadmap planning and strategic co-ordination
‍
Serving: 2 designers, 1 product manager, 20+ engineers.
‍
Jan 2022 — present
Design system overview
Teamwork Desk is a help desk and ticketing system designed to easily manage customer emails in one location. Essential to the functionality of Desk is the ability to create, manage and report on tickets through which interaction with the customer and agent is formed.
‍
As part of a strategic objective to achieve more scalable and consistent product development, it was decided to develop it’s own design system to which all components and process would eventually be migrated.
Design system strategy
Setting an overall strategy for the Desk design system was essential in securing strategic buy in from senior stakeholders.

The core aim of the system was to ensure future scalability of feature development through a semantic component library, while vastly improving consistency of features at both a design and development level. Approaching strategy holistically was essential to long term growth.

It was decided to run the development of the design system in an agile manner as its own product. An overarching roadmap would be determined by a strategic audit and in turn, set sprint priorities.
‍
No existing patterns and guidance
The reality of the Desk design system was that it possessed little more than some inconsistent UI components. Developing a comprehensive and semantic library with attached patterns and guidance is essential to future consistency
Limited senior stakeholder knowledge
Gaining senior stakeholder buy-in for a design system faces hurdles due to miscommunication on its value and perceived costs. Clear communication, ROI education, and focus on long-term benefits are essential for approval.
No long term strategy or roadmap
The absence of a defined, clear strategy for the existing Desk design system resulted in inconsistencies and challenges in achieving design objectives and collaborating guidelines and best practice long term.
No team education channels
Desk had no pre-established communication channels for design system updates. The absence of clear avenues for sharing updates, celebrating success or knowledge sharing lead to inconsistent progress in previous efforts.
No semantic component naming
A design system lacking semantic naming standards poses challenges in scaling and and consistency. Updates couldn’t be performed quickly and code submitted to component library was also inconsistent and impossible to scale.
No component contribution process
Existing process wrapped around the design system resulted in a lack of a clear component contribution process. Inconsistencies and duplication of designed components with no QA process hindered the scaling of the library.
Stakeholder buy-in
The process of design system eduction meetings cultivated a shared understanding of the system's value - in both the ease of future scalability and enhanced component consistency. Successful backing of adoption from stakeholders ensured a design system was given priority and resource from a strategic perspective. Once understanding was gained, it was possible to audit what components and documentation were available.


Audit of exiting components

Running a thorough audit of both the existing UI library, built components in storybook and most crucially, synergy with live components was an essential foundation to setting a design system roadmap.

Audits were component lead and allowed clear vision on what was designed, what had consolidated code and what patters, states, guidance and naming conventions existed. From here a prioritised roadmap was set along with the architecture of the system.
A desk design system roadmap
As with product development - strategy via a road map is essential to prioritise growth areas of a product. As we were treating the Desk design system as a product in itself, tasks could be prioritised per sprint alongside long term epics. By setting a roadmap, we also achieved the following process and structure benefits:

1. A plan for strategic growth with proper foundations and standards

2. Full analysis and breakdown of what is needed and the given priority and resource allocations
‍
3. An overview of what the design system will look like over a prolonged period of time
‍
4. An opportunity for the design system to evolve in an an agile manner and be flexible to evolution
‍
5. Ensures the Desk design system could grow alongside features
Semantic naming strategy
Within the Desk design system, a semantic token naming structure was adopted from the main Teamwork design system in order to create a flexible and consistent naming pattern.  Alias tokens were created from global tokens to convey better meaning and reduce duplication error, while component specific tokens allowed for specific values to be added when developing component states.
Core Strategy
A scaleable, documented component library
Case example
Progress indicators
UI components
Case study
Pattern behaviour for loading times over 10 seconds 🥱
Background
For waiting times longer than 10 seconds, we’re going to want to communicate with the user a bit more and offer feedback on what’s happening with loading.

Below are the documented rules and patterns applied to the usability of progress components within the Desk design system.

Patterns were also developer for load times under 10 seconds and over 1 minute.
DS Patterns
Core Strategy
Adoption was crucial to long term scalability
Adoption process
Driving adoption to actively promote the benefits of a Desk design system, addressing problems, and emphasising its value were crucial. Success lay in proactive transparency and team education, paving the way for adoption across teams.

Adoption goals included increased usage of design or coded components in feature work, referencing available usability patterns and offering contribution at the component design level.

Encouraging adoption of new design process was crucial in gaining product design buy in. Designing from, adhering to and contributing to a design system was not a regular work pattern but knowledge sharing sessions allowed for designers to be educated on the consistency benefits of a component and pattern library.

Designers and developers on Desk were championed with specific contrition roles which were celebrated in specific DS release meetings every sprint. Open communication of the design system and acknowledgement of progress within meetings helped the Desk team to feel part of a new design process.
Driving adoption
So, why not take a look at my next case study?
Made in 2024