Design System Initiative
From creation, update, documentation, and maintenance I owned the design system on behalf of the UX Team, by collaborating with UX team members, UI & Product Teams. Multiple Frameworks, Multiple Products, Merger of two brands, & UX styles. Created and evangelized the Design System UX architecture & website.
My reflection on working on a couple of design systems, an article on "Design System Roadblocks"
Related Casestudies: ML Based Maps Interface | Feature Updates for Data Visualization
My Role
Lead UX Designer
My Responsibilities
Created Design System Website
Update & Maintain Components & Documentation
Team Management
Our Team
Lead UX Designer (me)
Sr. UX Designer - 3
Junior UX Designer - 1
UI Developer
Project Manager
100% adoption in 2 + Products
2 Branding styles merged
40+ Components designed
90% Implemented in Products
8 + Products for UI Inventory
Highlights of the Design System
Design System Documentation
I created a Sharepoint Website for Design System Documentation, bringing the standards together, instead of being lost in various sources. This was shared with Product Managers, UI front-end Developers, Testers, and Stakeholders.
Collaborative Team:
Instead of the handoff of every design and going back and forth, we had a collaborative dev & design team and did paired review.
Merger of two branding styles :
Successfully combined two branding styles - some components are in progress: One full-fledged branding style guide with components were merged with another in progress style guide.
100% adoption in new projects :
New projects uses 100% of the Design System components. This made design iteration take less time and gave more time to create new solutions quickly.
Why Design System is important to me?
Why we needed a design system?
Design System Roadmap
Problem faced while on this roadmap
My reflection on working in a couple of design systems, and the problems faced while on a design system roadmap is given here in my article :
Design System Roadblocks
Coming soon..
Merger: After working on the Design System for one year, while we followed the roadmap and started to release components to products, the organization had a merger, which challenged our roadmap. Now the design system team had only me. Later after the merger, it grew into a 4 people team, which I led the design system activities. We continued the design system journey.
UX in the Organisation
To start work on the Design System we needed time, resources, and budget which we tried to find out from the Management. For that to happen we needed to find out where UX is in the Organisation structure. After many discussions and team meetings with the UI team, we found out UX as part of the Core Development Services - a team of leads from every core service.
Design System Structure
During the initial stages, while identifying the overall design system resources, we discussed with various teams to help with the design system process. A UI Developer whose contribution to the design system is important, we discussed the overall structure of the design system with the Development/Application/Product team and identified the deliverables mapped to resources and teams.
Key Constraints
Constraints/Challenges finding a place UX in the Org and getting a buy-in
UX Maturity Level
The UX maturity of the organization was still at the low level between Stage 2 to 4, which made UX deliverables invisible and less important to the Product Development Teams.
Management's Interest
Even though management had an interest in UX, their focus was on the whole product and looking for ways to enhance the UX.
Roadmap Commitment
Even though we had a plan to execute the design system, we didn't have a workable schedule or a deadline about when and what to deliver on the design system. We did it on a need basis and whenever we had time out of the project.
Merger
After working on the Design System for one year, while we followed the roadmap and started to release components to products, the organization had a merger, which challenged our roadmap.
Reflections/Learnings
My reflection on overcoming the challenge and proceeding further
UX Maturity Level
To prevent being overlooked, to make UX more visible, we determined to show the difference between before and after of existing UX work. We showcased the UI inventory and its gaps and inconsistency.
Management's Interest
Our leaders were interested in delivering good experiences for enterprise software and were determined to help our small UX team.
Roadmap Commitment
This happened only during the initial stages when we started showing progress with just two of us in the team, and when we had a junior and a senior designer as part of the team, we saw more progress in spite of the project work.
Merger
After the merger, the Design System team had only me. The Applications team still wanted to continue with the Design System and provided with new resources. We grew into a 4 people team and still continued the design system journey.
UI Inventory
To start laying the groundwork for a design system and to show evidence of inconsistency and convince the management, we started collecting the interface inventory. This way we were able to see the gaps in all the products.
Key Constraints
Constraints / Challenges in doing Interface Inventory
All components
Not all components were accounted for because the work is not one man's job, we needed more resources and access to all the products.
Not a one man's job
I tried to collect as many components categories however with the project work doing a UI inventory for all the components was very hard.
Compiling Interface Inventory
When my teammates did the inventory, there were repeated capture of the same component.
Access to all products
Due to licensing, we had issues with access to the products
Reflections/Learnings
Solutions/Learning in overcoming the challenges
All components
For the components which we didn't do a UI inventory when we started to design, it was a bad surprise so we did a UI inventory at that time.
Not a one man's job
We needed more resources for design system effort.
Compiling Interface Inventory
We shared the components among us, and later shared about each component in a discussion.
Access to all products
We managed to get access to all products by letting the management know the work we are doing
Dedicated Website/Space for Design System
Before: Design System Documentation in Word, OneNote, Slack Channel, Emails
Before: Design System Documents in the form of Word Document & One Note. Some of the standards were also in the Slack channel & in emails.
Key Constraints
Challenges /Constraints faced in identifying and designing a single location for documentation.
Identifying a Documentation Tool
As a team we had many options identified as a documentation tool. Invision Design Manager, Confluence & a Custom website.
Sharepoint feature for Design System
Insufficient features, such as template-based layouts restricted in formatting the content. Adding images instead of filling colors was a major pain.
Source code feature
There were separate URLs maintained for source code of the components, but we wanted to have it as part of the documentation, which wasn't available in Sharepoint.Whenever a component changed in our main codebase, we had to remember to actually update the documentation.
Version Control
Version control of the documentation was easy, however, relating it to the component was in a different URL
Reflections/Learnings
My reflections/learning and solutions in documentation as a single source of truth.
Identifying a Documentation Tool
Due to budget constraints we settled with using Sharepoint as our documentation tool.
Sharepoint feature for Design System
We found a workaround until we were able to get a budget for a good documentation tool, the amount of work to be transferred to the new tool has to be considered.
Source code feature
So to avoid back and forth between the code and the documentation, we were constantly in communication and checking the documentation periodically.
Version Control
Sharepoint stored previously published pages, so we had a previous version of the documentation to go back.
Design System Team
From a two-member team, and into the merger, our Design System team has been changing. Each member of our team spend 30-40% of their time in the Design system activities and work on the project work rest of the time. We worked with the product team as part of the SCRUM team and in designing and updating and maintaining the design system components. The skillsets we had are visual design, interaction design, information architecture, and knowledge of HTML CSS skills. Some of the team members had research, SEO & Branding skills.
We shared the design system activities, as our team grew our team decided to pick up the components they wanted to work.
Team Communications
As a Design System Team, we communicated: Internally with the team members, With the developers about the release, With the product team for features. We used various channels for this. Also, Design System is itself a communication for many audiences - developers and product teams.
Design System Team Communications Channel
Key Constraints
Challenges faced forming a Design System Team & Communicating to various audiences
Design System Communications
We wanted to add the Status update for components, release history. Since we didn't have a planned delivery we did not update the status page even though we had one. So it was difficult when a new UI developer came to our Design System team to understand the status of the components.
Too many messages to track
Sometimes it was overwhelming by the number of messages we communicate to different people through different channels. Keeping track of all the communication was difficult. For example, when person A was designing a component, and person B brings up a valid point in another channel, it will not be communicated to person A. It has to be brought only through meetings or indirect means.
Roles & Responsibilities
Everyone in the team was new to the design system, so we were still figuring out roles and responsibilities
Part of one portion
We were only part of one portion of the organization which had many products, we still had many other teams who needed design system usage however it was on the surface level.
Reflections/Learnings
My reflection in overcoming the constraints/challenges in working with the Design System Team
Design System Communications
Since it was a small team, we were constantly in communication of what was the status of the components, later after the merger, I updated the page continuously.
Too many messages to track
Even though we had many channels, we brought in all the topics which needed attention even though it was discussed in slack or any other channel. It was a repetitive task, but we touched on the topics. Also these meetings helped in easy design decisions by the concerned.
Roles & Responsibilities
As we spent more time on the design system activities, we were able to determine the responsibilities of the team member for receiving any updates, or inform the design decision to the team or inform about each deliverable and who does what. It wasn't a solid description but we had an understanding.
Part of one portion
Even within the AAET domain, there were siloed applications and products which needed to be brought to adoption, Hence we wanted to focus on this first.
Components
Components List
I created a list of components from the UI inventory and mapped it under categories to get an idea of what is it we are dealing with. Also, it formed as an information architecture of the documentation website. We started to add all aspects of the design system documentation and components.
Components list mapped to categories, which is also information architecture for the design system website
Design, Redesign Process
Design System Process
Component Status
Tools used
UI Kit - StyleGuide
I consolidated the components from various sources into one single UI kit and maintained versioning for it. Our UI Kit evolved with the addition of new components & mergers. It provides the core objects needed to build new applications or update existing applications. It was used by designers for their basic behavior, which could be customized to match specific needs.
Latest UI Kit
Latest UI kit which I maintained and shared with the UX teammates for reference
Evolution of UI Kit in 2 years
Before: Design System Documents in the form of Word Document & One Note. Some of the standards were also in the Slack channel & in emails.
Designing Components
I owned the below components design & updated and maintained in the design system. Other components were designed by my teammates. As a team, we shared our work in designing and updating the components. We picked up components to work on and if there is a need to work on the other components we discussed what work needs to be done with the teammate.
Tables & Grids
Evolution of Tables - AG Grid
Buttons
Evolution of Buttons
Textfield
Evolution of textfield
Left Navigation
Evolution of Left Navigation
Colors
Evolution of Colors in 2 years
Key Constraints
Content Format
As the owner of the component changes every time, they had their own style of content format.
Design Tokens / CSS - Class Names
It was difficult to refer to which blue - light, bright, dark blue. Every time we had to inform codes to the UI developer.
Colors
Provided colors for all components on the color page. It was difficult to go between the component page to the color page to check the color codes.
Reflections/Learnings
Content Format
We cameup with a standard format for the content. - Intro, usage, Specifications, and Class table
Design Tokens / CSS - Class Names
From providing only the color codes, we created the class name for the css for the UI developer.
Colors
Instead of providing the colors and specifications in one page, we provided colors for every component page.
User Testing Finalised Components
When we have a new design or want to test the existing design we did A/B Testing, Preference Testing. Some of the components we tested were the tables, buttons, dialog boxes. We brought major changes in the design and thus we wanted to test it if it is an effective design. I did a test for Tables - after researching a lot, I couldn't find evidence for dark theme zebra stripe tables. Hence wanted to test if users find it easy with zebra stripe or single color in a high data density table.
Example 1 : Zebra Striped vs Single color rows - Preferences test for Tables
Example 2 : Label Position & Animation - Preference test for text field
Invited users for the test - Received around 30% test participants from the total
Release components to Products
Products which needed design system adoption
Conclusion
Just getting started:
The adoption of the design system components was successful with 2 products and there are many other products that require adoption. After the merger, the standardization of the components has just started, it will take some time to release the new brand's components into products.
Measuring Design System Success:
At this stage, the impact is largely anecdotal. We hear stories that the system has helped people make decisions either faster or more consistently, and that it has helped us develop faster. But we need better measures. Need a plan to measure success.