Gemini Design System

IQVIA wants to unify all of it products to have a consistent look and feel while also streamlining the pipline. The approach we took was to leverage a design system with atomic methodologies.

My role

Product Designer

Manager

Company

IQVIA

Project Duration

6 months

Challenges

The IQVIA Gemini Team wants to close the gaps between product design and development. After a company wide mandate to update all products to one unified look and feel, our department was responsible for creating a scalable design system that would work in most client products within IQVIA.

Note: The lack of screenshots is due to NDAs and HIPA compliance.

My role included consulting leadership on process, consulting designers on component design, facilitating collaboration through cross-functional teams, leading the process for design system creation, design and build components to be used

  1. How can we create a scalable system that will help create consistency across all disciplines?

  2. How do we utilize and create methodologies, workflows, and practices that will help achieve our goal?

  3. How do we make a single source of truth that is scalable across disciplines (UX Design, UI Design, Engineering)?

  4. How do we create a familiar language within our system that works across all disciplines (Design and development?

  5. How can a design system improve our pipeline.

Kickoff

We held a kickoff meeting to gather insights and interview key stakeholders. After that we defined the direction and scope of the project with minimum viable product. Scope includes: Design tokens, Core UI Components, Comprehensive documentation, Cross-functional collaboration, and technical integration guidance.

Phase 1

Discovery & Strategy

Interviews

I interviewed designers, developers, product managers, and leadership from all relevant product teams. Understand their pain points, needs, and expectations.

  • Considering both design and development, interviewed designers and engineers . Without an official process, I asked team leads how they complete their work. The teams mainly used a waterfall method.

  • We identified significant challenges in the current workflow, including widespread design inconsistencies, recurring technical problems, and confusion over roles and responsibilities.

    Designers' Pain Points

    • Difficulty Designing Components: Designers struggled to effectively create components due to a lack of clear understanding.

    • Incomplete & Duplicated Designs: Designs frequently missed essential details and were often recreated due to isolated work (silos).

    • Limited Collaboration: Designers, focused on individual client projects, lacked dedicated time for inter-team consultation.

    • Unstructured Developer Handoff: There was no defined process for designers to collaborate with developers.

    • Absence of Documentation: The lack of documentation for components and patterns led to wasted effort in content delivery.

    Developers' Pain Points

    • Inconsistent Designs: Designs varied significantly across different experiences, even within the same project.

    • Feasibility Gaps: New components were often designed without considering their technical feasibility.

    • Missing Design Details: Designs frequently arrived without critical information needed for implementation.

    • Unclear Component Naming: New components were introduced with missing or inconsistent naming conventions.

    • Redundant Component Creation: New components were often created without awareness of existing, similar patterns.

  • In an effort to figure out the most scalable solution that could be adopted by engineering teams I conducted interviews with customers to find out what tech stacks were being used and interviewed client engineering leads.

  • I interviewed some of our customers and researched IQVIA products and logged the front end systems and libraries are being used.

    1. A high number of customers where using front end libraries

    2. Most customers were using the Salesforce platform

    3. Some customers made custom front end ui

    4. Few had legacy tech stacks

    Most groups were not aware of the importance of UX and UI design in a front end architecture. Almost all groups were made up of Backend Engineers who had to build the front end UI.

Define the problem

Our current product development ecosystem suffers from a fragmented and inefficient workflow characterized by a lack of a unified design and development process, leading to widespread design inconsistencies, technical debt, and confusion regarding roles and responsibilities. This internal disarray is compounded by a significant challenge in scalable adoption for our customers, who operate within diverse tech stacks (e.g., Salesforce, custom UIs) and often lack crucial in-house front-end UI/UX expertise, relying heavily on backend engineers to build UIs. Consequently, delivering consistent, high-quality, and efficiently integrated new experiences across all products is severely hampered.

Hypothesis

If we provide a flexible design system built with commonly used front-end libraries and explicit guidance for integration into diverse tech stacks (especially Salesforce and custom UIs), then customer engineering teams will be able to more easily adopt and implement new design system components into their existing products. This will reduce the burden on design to create custom solutions for each new experience and empower backend-heavy teams to build consistent, high-quality front-end UIs with minimal design dependency, ultimately accelerating product development and improving overall user experience across IQVIA's offerings.

Define Scope

We were able to define scope of work with minimum viable product. We broke down the scope into phases: Design tokens, Core UI Components, Comprehensive documentation, Cross-functional collaboration, and technical integration guidance

Phase 2

Foundation & Core Components

We wanted to keep a fast paced collaborative effort that also addressed knowledge gaps and leverage expertise across professions so we break into fire teams. The goal of fire teams was go meet and collaborate in small cross-functional teams and come out with with a finished component (designed and coded) to be reviewed later.

  • In this phase we wanted to establish the the key building blocks in our system. In a workshop led by the UI team we created a concept for our design system. Once completed I helped define the token requirements that goes beyond design specs including utilities, animation, breakpoints, border, opacity, easing, duration etc.

  • In an effort to maximize efficiency, we broke into small groups consisting of one UX designer and one developer. Each responsible for building out components on the Atom level. This way design could leverage engineer expertise in the design process to help with knowledge gaps. The end of each session resulted in designed and coded components. Once the core components (atoms) were completed and passed review, we opened up the design tasks to all designers to start building molecules and organisms. At this point we really started to see how fast this system worked.

  • To validate our new design system we tested the smaller atomic components in one of two groups of designers working on different products. The group that used the design system and atomic methodology was able to get work done faster based on Jira KPIs. The developers were interviewed and reported less inconsistencies in designs they were handed. The developers were able to focus more on the functional aspects of products and didn’t have to spend as much time working on the look and feel of smaller components. The QA process went smoother in design intake. The developers were able to deliver experiences at a much faster rate based on Jira KPIs.

Phase 3

Documentation

Rather than creating two separate sites for design guidelines and component documentation, I wanted to create a useful way for both engineers and designers to access documentation that lived in one place. I led the design effort for creating the concept for the documentation site using storybook. I took a survey from the engineers and they saw a significant drop in design inconsistencies. The designers found it helpful to have design guidance within context to the actual component and we found that designers were more confident about the designs they handed off to engineers.

The designers were using Sketch at the time but did not have a sketch component library. I created a prototype with a few built components in sketch. I was able to get buy in on UI design creating a Sketch library as their single source of truth. Again we say inconsistencies drop dramatically in design/engineer handoffs.

Phase 4

Adoption

Our pilot program, focused on integrating our new design system with early adopter product teams, yielded significant positive impacts, allowing for rapid adjustments and strong overall feedback.

Here's how it made a difference:

  • Empowered Engineers: We received strong positive signals from engineers, who were freed from the burden of creating and styling components from scratch. This allowed them to focus on core product logic, significantly boosting development efficiency.

  • Streamlined Legacy Integrations: Instead of forcing legacy code teams to build custom component libraries, we provided them with design services and comprehensive documentation through our design guidelines site. This approach met them where they were, ensuring their teams could stay in sync and leverage the design system effectively, again receiving strong positive feedback.

  • Accelerated New Product Development: For teams building entirely new products, the design system proved invaluable. They could easily consult with our designers and leverage a system already compliant with company mandates, leading to product managers reporting notably fast turnaround times for new features and products.