Background
A design system was build but rarely adopted by engineering and designers couldn't figure out how to use it in figma or even find documentation to know what to do.
Designers often felt unheard or unsupported in building components and features.
Approach
Through weekly recurring meetings, 1:1 interviews and conversations I helped designers, product managers and devs navigate figma and be a part of roadmap planning, prioritization and contribution.
I and one of my designers updated the design system to use the latest features, layouts, and naming conventions for figma.
Outcome
Designers had a higher level of trust that they are being heard and had the assets they need to do their best work. Transparency and communication between cross-functional teams drastically improved. Components and documentation were created and updated using the latest features and work released to internal and external users sped up.
One of the first things I did when hired was to schedule 1:1 meetings with each designer, Product manager, and Dev lead to get feedback about what is and what isn't working currently with the system.
Designers were unable to find and utilize components made to use in their designs. They were lacking education and how to effectively design and use components.
Lack of adoption of the design system among multiple siloed product teams due to lack of knowledge, resources and proper documentation.
Taking a look at the beginning
Too Complex
I base my design systems off of Brad Frost’s Atomic Design. Most of the system had more complex pieces and needed to be broken down to accommodate more re-usable components.
Starting with design
I interviewed designers from throughout the company. I asked what they like, what they don’t and how they use and leverage the system. This brought up a lot of actionable items that could be low hanging fruit to get this back on the right track.
Updates and structure
About the same time as I joined Meltwater, Figma launched a slew of updates, including the use of variables. This was a great time to revisit and refactor some of these components to utilize the use of variables.
Designers
Designers can’t find assets
From organization of libraries to naming, tagging and adding descriptions to various assets making it easier for designers to find. Even basic colors and typography needed to be set.
Training and education
I set up a weekly meeting to showcase the value and how to use the assets that had been re-factored. I also set up open office hours where I and one other designer would help other designers with anything they need or want to learn how to do.
1:1 working sessions
I and another designer scheduled one-on-one time with each of the other designers from time to time to help get their files in working order, utilizing the design system to speed up their workflow.
Product Managers
Roadmap
I worked with product managers and owners to help align team roadmaps and establish goals to include design system changes and enterprise utilization.
Evangelizing
I helped product in leading out the evangelizing initiative to get other product leaders and key stakeholders to not only buy into furthering the design system work, but support it resources, time and attention.
Developers
Prioritization
Feature requests from product owners and designers alike needed a place where requests would come in and be prioritized. Using Trello, I helped create a place for requests and a funnel to work with Engineering to prioritize work that needed to be done.
Shared Resources
The design systems team not only worked on design system requests, but occasionally loaned out to handle requests from other teams as needed. This sometimes slowed down the work and needed to work with other teams to help contribute features and maintain various assets used throughout the products.
Documentation
Documentation was segmented and split into two systems. It also focused on an engineering solution. By joining the documentation together using “Usage”, “Code”, and “Accessibility” in the same place helps paint a better picture regardless of who is reading it.
Usage
When it comes to a design system, guidelines are extremely important to maintain proper behavior and consistency. Do’s and Don’ts, different variations, and how they are applied to various sections help communicate intention and user familiarity across the suite of products.
Code
Having real code examples that can be visualized and dissected is helpful for how to implement the component and show the intended interactions. We leveraged Codepen to provide an all-in-one place to experiment and see the code. This is helpful for dev teams introducing the design system into their own team as well as new developers to the team.
Accessibility
Accessibility is an area that, for many companies, hasn’t been a real priority until recently. As we designed and built a lot of these components, we continued to keep accessibility in mind, but also felt that documentation was lacking and needed more transparency.
Outcomes
Designers Trust & Contribution
Many of the designers began to contribute assets and overall support for the system. As they learned about the process and saw I was tying to help them reduce the amount of work they were doing they began to trust me and work with their individual product teams to further integrate with the design system.
Transparency
Transparency between teams significantly improved after implementing an effective design system. This provided a centralized source of truth that can be accessed by everyone involved in a project, including designers, developers, and stakeholders. With everyone working from the same set of guidelines, we saw a reduction in misunderstandings and miscommunications.
Open Communication
With a shared design language and clear documentation, teams can collaborate more efficiently, resulting in a smoother workflow and fewer delays. The design system allowed teams to identify and resolve issues more quickly, ensuring that everyone was on the same page and working towards the same goals.
