Evolving a style guide to a design system
Veeva Design System
2020
Overview
When I first joined the team at Veeva, their design system for iOS was in its infancy and was in need of curation. In need of an evolution. I was part of the team that established the design system squad that would create components and see them implemented throughout the product.
But first, developers were having a hard time finding components and not fully understanding how design used them. They were essentially guessing how it needed to be built, over and over again.
I set out to give a template for others to digest the component - how it was built, it's different states, and how it needed to be implemented.
Role
Designer working with developers to create and define design guidelines. Support and review junior designers on how to contribute to source.
End Goal
Provide a source of truth for designers and developers to reference for components and patterns.
Existing product & issues
Developers get a mockup and build it out. Common elements, like buttons, would be built out over and over again. Each build was different, would take additional time and cause unnecessary bloat to the back-end. The same requirements were being repeated for each hand-off.
There needed to be a more efficient way to communicate requirements that were established. Devs needed somewhere they could grab the same elements to start with to save time. We needed a source of truth for both of us to reference.
Past Experience
Qualitative research
Having the current product at hand was great to play with and understand the ins and outs but I needed to understand why users dreaded creating and painting events. I wanted to see where they hesitated or avoided certain interactions.
So I worked with a product manager to setup some 1:1 time with direct users, not just customers. Some key interviewees were GSK, Novartis, and Alexion.
I found that most users forget the steps to take to get an event running and are unsure what items need to be updated in order to move forward.
Comparitive research
The initial style guide was good to see where previous designers were identifying as areas they needed to explain multiple times over and where developers needed a bit more guidance .
I took a look at other design systems in place to gather inspiration and how information was organized - Microsoft, Atlassian, Google, and Apple.
I realized that documentation was breaking up information by component rather than trying to group everything together. I wanted to follow suite to make it simpler and less overwhelming for people to digest.
Design decisions
I started looking in our app and documenting each item, how it was used, and where.
Individual, specialized sections to show fellow designers and developers the anatomy, behavior, and usage of each component.
Improved collaboration where any team member can edit and contribute without having to wait.
Introduce 'best practices' so those creating designs or initial components would understand how it would be used and its limitations.
Beginning conversations with developers during dedicated blocks of time to convey importance of design systems and how to implement in product.
CONTRIBUTION
A better breakdown.
Showing the anatomy, variants, and modes of each component cut down on the back-and-forth we were experiencing between designs and dev. We had an understand on both ends how each component would be built out. We defined it together.
Unsure about behavior? No more!
Sometimes it wasn't clear on how components should behave - everyone had a different idea based on the product area. Establishing best practices on usage gave everyone a clear base. It also allowed for an evolution if needed.
Better conversations.
Collaboration with developers became so much easier and allowed for better ideas to surface. We were all able to add in our two cents and build better, more efficient experiences because of this.
Where we are now
As new software and products get released, the design system must migrate in order to better serve us all. The design team is in the process of transferring and rebuilding components while developers eagerly await this transition.
I had set out to define and create a space for all of us to contribute to. It's exciting to see it live, grow, and mature without me - it is thriving with the help of the teams. I have done my job.