Hero image
Skyrizi design system
Summary:
We created a design system of complex components and libraries in order to improve consistency across screens and sections of the app for the client (Skyrizi). This included conducting design audits, analysis of existing softwares and systems used, interviews with the design, product and development teams. The design system/component library we created improved not only design consistency of the components used but also efficiency in approvals, handoff to developers and their development process but also led to faster deployment to the sales associates and medical professionals who are the prime users of the app.
My role:
Digital Designer
Project timeline
2-3 months
Skill & softwares
  • Design system
  • Prototyping
  • Research
  • UI Design
Project outline
IntroDesign auditFindingsPlanning & StratergyCreation & ExecutionDesign systemConclusion
Context:
Skyrizi is a pharmaceutical brand under the AbbVie company that distributes medication for various diseases. We design the app (Klick Health), which is distributed to product sales associates who demo the product to potential doctors. The app is further verified by Medical Editors who ensure it is medically and legally accurate.and approved by FDA.
Why did we need a new Design System?
The need for a design system stemmed out of the need to have consistency and efficiency in the designs which was being ported out from Photoshop/Sketch to Figma and having a central location for designers and developers. During migration, the sizing differentiation from the previous apps to figma which was being designed by several creative designers created consistency issues with components which was flagged by QA and increased dev time. There was also a lack of UI pattern libraries and reusable components. This created inefficiencies for each team, as well as inconsistencies within our product.
Challenges:
There were several categories of the product which had different components, libraries, buttons, icons, graphs as well as some designs which were not yet migrated to Figma. This introduced the challenge of auditing each category and cataloguing the assets that were used. Another challenge was to ensure that this newly created Design system did not break consistency with already approved designs from the FDA.
Research and design audit
To better understand the different problems with the design, we conducted interviews with people from different teams (Creative designers, Production designers, Front end developers, Product managers, etc.)
‍
After speaking to them we discovered that we need to:
  • Identify all the design issues and inconsistencies in our products
  • Define and identify all the different categories where these components are repeated.
  • The need to create a central library where all the elements would live.
  • Build a base template to ensure each category is same as the rest.
1. Visual Analysis
We started by auditing our products, identifying and list out all instances of particular components commonly used (Buttons, headers, footers, graphs, charts, fonts, background elements, colours, etc.). Besides this we also consulted the designers that were hands on creating these buttons, where they would copy them from and how the developers were now creating them on the newly migrated Figma platform.
We used Figjam to post and collaborate our findings.
Key Findings
1. Inconsistency issues
There were several inconsistencies in colours, components, fonts, buttons and components which can have detrimental effects on the overall experience, the brand image and increase time taken for developers to adjust as well as for Quality Assurance to find issues with the design and resolve them. Most of the issues would not be noticeable on a single page but over multiple variations there would be minute pixel differences which was something were looking to iron out.
2. Multiple Iterations
Since the content within the app was constantly being iterated in order to meet new variations in the product as well as medical and legal requirements, there were design updated being constantly done with very short time frame. Additionally, components had to match previous versions in order to pass automated QA checks. This increased the risk for consistency errors and misalignment.
3. Redundancy
For designers, not having a library of components means they have to create repetitive design work to create those pages and having to go back and forth to ensure sizing accuracy. This also applies to the approval and implementation part, where product teams and developers would have to spend more time to analyse designs and more effort to code new elements and components every time there was a revision in the product.
Building the UI Inventory
For our application, we referred existing design and brand guidelines that were being used in these components. We started with the basics - type styles, colours, logos, styles into a rough Figma file and then proceeded to add common elements like buttons, copy, header, footers, graphic elements, images to name a few.

Since the components were spread across Photoshop and Sketch, we took screenshots of all the main design assets and add them to a fig jam file, segregating them into their own "Sections". We then collaborated and identified a lot of inconsistencies in our design assets which only proved the need for creating a design system and maintaining it.

Below is an example of the components we took screenshots of:
Creating components
For the creation part, we ensured that each component is:

1. Accessible: For that, we evaluated the combination of text and background colours based on WCAG guidelines. Good contrast ratio helps users who are partially or completely colour-blind to see differences between certain colours. The app also has a complicated design and is modified depending on what the category is and the content required to be showcased to the potential clients as well for legal usage.

2. Similarity: One of the key requirements for creating the components was that we had to ensure each component is consistent to existing approved designs by the medical team and the FDA. Any drastic difference would mean having to resubmit the product for approval which could result in delays to pushing it live.

3. Categorization : The app had its own categories for various medications. This meant that the library would be extemely large, and designers would have to search for the component they were looking for. We created sections within the figma library, for each type of component: Colours, Type, Logos, Images/Backgrounds, Buttons/Icons/Toggles, Graphs/Charts/Tables, Modules, Modals. Within each section we used frames and sections to organize different categories making it easier for the designer to find the component they were looking for.
Execution: Using the new Design System
We used the variations feature to showcase various variants of buttons, font styles, graph elements, icon packs which would easily enable designers to choose various options as well as helped developers code better knowing what variant was to be used.
To use components, the designers simply had to use the assets tab in Figma, or drag drop a component of their choice into the design. Some components were rigid, while some were more flexible due to the nature of the product and it having its own catergory of medication products.
Review & Documentation
Reviewing was a crucial part of this process. With so many complex components and its own state, we needed to ensure these components worked flawlessly when they were dispatched. We conducted tests across design and dev teams, using slack channels, gaining feedback, iterating and squashing any bugs. (there were a lot!) This allowed us to collect everyone's perspective and bridge gaps between design and engineering.

For our documentation, this was one of the last pending agenda on the list. While a documentation for the size would take more resources, for now, we utilized the description feature in figma to inform designers what the components are for and where to use them. We also wrote short description of the components directly above them in their respective sections.
What some of the final designs of a different product categories looks like after using the new libraries we created. On the right side are screenshots from the extensive components we created with separate pages within the library for different types of components.
Final design
Design system component and library
Colour Styles
Type styles
Icons/Buttons/Toggles/Nav Icons, etc.
Subnavigation and template
Header/Footer/Popup template
How can we validate the design system?
User Perspective:
The users here were our very own team. The component and design library streamlined the workload, made it easier for designers to grab components, maintain consistency and made the life of developers and QA teams easier.
Business Perspective:
The teams were able to push out projects faster, developer teams were able to pull components directly from the library as well as use dev mode to code better. It also made QA faster and this in turn meant we could push the end product out for approval and launch much faster and streamlined than before.
What I would do next time
The design system is an ongoing project. We iterated, changed and learned a lot in the process. So far, we have managed to categorize all the common components used, teach the design and development teams how to use these components and overall reduce the time it took to make design changes.

It took considerable time and resources to put it together. For when there is more resources available, I would plan to create a more in-depth documentation, explore further into the newer variables features figma, continue to grow the library and update it as per the needs of the team, cultivate processes and best practises for maintaining the library and documentation and create an simplified naming convention.