IDEXX DesignOps: Building a System for Designers

 
 
 
 

OVERVIEW

IDEXX is a global leader in veterinary diagnostics and software. Over the past five years, the company, particularly the VetSoft organization, has significantly grown. As the company scaled, primarily through the acquisition of new products, our design team grew. While designers were creating excellent work within their product-specific teams, this growth resulted in a natural divergence of processes and presentation styles.

Our internal DesignOps team is a volunteer group of four UX designers from different product groups. We spearheaded this initiative to create a centralized component library for designers.

 
 
 
 
 

CHALLENGE

Our design team is incredibly talented, with each product group creating high-quality, tailored work. However, because each designer works on their own product and many of these products were acquired, each came with its own successful design process and visual style. When presenting to leadership or handing off to engineering, this divergence created challenges.

Our core challenges were not about quality, but about cohesion:

  • Divergent Storytelling: Presentations, while individually strong, varied significantly in structure and narrative. This diluted the perceived impact of our design organization as a whole, as we lacked a single, recognizable "design brand."

  • Varied Handoff Artifacts: Designers on different products used different handoff formats. This meant that team members working across multiple products had to learn a new documentation style for each project.

  • Siloed File Structures: File organization was optimized within each product team. This made it difficult for new designers to onboard or for designers to collaborate across product lines, as there was no shared "source of truth" for operational files.

 
 
 

PROBLEM STATEMENT

How might we create a unified operational toolkit that respects our diverse product portfolio while establishing a cohesive, professional 'design brand' for all stakeholder interactions and internal processes?

 
 
 
 
 

OPPORTUNITIES

The challenge was clear: we needed to elevate our collective presence. By standardizing the operational work that was repeatable (e.g., presentation slides, handoff templates), we could unite the team's best practices into a single, powerful system.

Our hypothesis was that by creating a simple "meta" design system, we could:

  • Accelerate Speed: Drastically reduce the time spent building decks and spec sheets by providing ready-made, polished templates.

  • Elevate Our Brand: Ensure every design artifact felt like it came from one unified, professional team.

  • Improve Collaboration: Create a "system-in-a-box" that made onboarding and cross-team collaboration seamless.

Our Design Process & Role

As the design leads and ambassadors for DesignOps, our process was as much about people and change management as it was about pixels.

 
 
 

DISCOVERY

We started by "designing for our designers." We first sent out a survey to our whole design team (about 15 people) to understand their tools and processes for file organization, developer handoffs, and stakeholder presentations. From the survey, we were able to distill the insights into a few key topics:

  • Development and product handoff

  • Design file security and permissions

  • Versioning

  • Reference to design history

  • General Organization

With these topics as a guide, we held a "Rose, Bud, Thorn" workshop with the design team. We asked designers to provide specific insights into what was working well (Rose), what wasn't working (Thorn), and areas of opportunity (Bud) for each topic.

Key Insight: Our designers, working correctly within their acquired product silos, had optimized for their specific workflows. The opportunity was to unite these best practices into a single, shared system to elevate the entire team's presence.

 
 
 
 
 

DEFINE & STRATEGIZE

We summarized the findings from the "Rose, Bud, Thorn" workshop and held a brainstorming session with the DesignOps team to come up with solutions to address the challenges.

Using this data, we prioritized the highest-friction, highest-value assets to build first. The strategy was not to reinvent the wheel. We would leverage our existing product design system (fonts, colors, icons) as a foundation, but build entirely new components tailored for operational tasks.

 
 
 
 
 
 

SOLUTION

Based on our brainstorming, the most high-impact solution was clear: we would create a centralized Figma component library focused on our internal operational tasks. This library would provide standardized components for design handoffs, which would help create a standard for all project handoffs.

From this core component library, we also decided to create a master presentation template. This would allow designers to simply "plug-in" their content, dramatically decreasing the time spent on creating stakeholder presentations from scratch and ensuring a consistent, professional brand for the entire design organization.

 
 
 

DESIGN PROCESS

With the solution defined, we built the version 1 component library in Figma, focusing on three key areas:

  • Stakeholder Presentations: A full kit of slide components (titles, footers, annotations, table of contents, and headers).

  • Engineering Handoffs: Standardized developer spec handoffs with standard components like annotations and notes.

  • Design File Organization: A thumbnail component for design files with standard title formats, designer names, and status trackers to ensure consistency among design teams.

 
 
 
 
 
 
 
 
 

Pressure Test & Refine

Before a full launch, we released the beta library to four key designers representing different product teams. We let them use it in their real-world workflows for one month. After this period, we held follow-up sessions to hear their thoughts, observe pain points, and gather new needs. This feedback was crucial; we iterated on the library to improve component flexibility and clarify documentation. This led to key improvements, such as adding components for version history and a clear way to link dev handoff files to Jira epics and stories.

 
 
 
 
 

DOCUMENT

Once we had a refined, battle-tested first version, we held an official kickoff meeting with the entire design team. A system is useless if no one uses it, so this phase was critical. We hosted a workshop to walk designers through the new tools. We also celebrated early adopters and showcased their work (e.g., "Look how quickly Jane built this beautiful deck!") to drive organic adoption.

The Impact: Measurable & Meaningful Change

The new DesignOps library was adopted by more than 60% of the design team within the first few months.

  • +20% Consistency: We achieved a 20% improvement in design artifact consistency (measured by a quarterly audit of handoff files and stakeholder decks against a quality rubric), establishing our unified brand.

  • Time Saved: A follow-up survey showed we saved an estimated 3-4 hours per designer, per week—time that was immediately reinvested in things like user research, design exploration, and prototyping.

  • Improved Partnerships: Engineering leads reported that handoffs were "clearer and more predictable," reducing churn and build errors.

  • Higher Morale: Designers felt supported and empowered, with one quoting, "I feel more confident sharing in progress work with stakeholders, since I can just throw designs into the presentation template and write some annotations."

 
 
 
 
 
 

Improved order tracking and readibility

 
 
 
 

Robust filtering, self-service capabilities, and key actions

 
 
 
 

Order tracking, in-house diagnostic alert, and action menus

 
 

Mobile concepts

 
 

LEARNINGS

  • Adoption is garder than creation: Building the system was the easy part. The real work was being dedicated "ambassadors"—answering questions, and championing the new process. You can't just "build it and they will come."

  • Solve the "boring" problems: The biggest wins came from standardizing the most mundane work (file naming, handoff specs). Nailing this foundation is what gives designers the freedom and time to be creative.

  • A system is a living product: The library is never "done." We have continued to make improvements as we receive feedback from the design team and fix any bugs or issues they have with components. A design system requires dedicated, ongoing maintenance.

 
 
 
 

Add-on testing, courier scheduling widget, request a medical consultation

 
 
 

NEXT STEPS

The version 1 library was a huge success, but it's just the foundation. Our next steps for version 2 would be:

  • Expand to Research: Build out a new wing of the library dedicated to standardizing research artifacts like user personas, journey maps, and competitive analysis reports.

  • Integrate with Engineering: Explore a tighter integration with our developers to create a 1:1 link between our design handoff components and the requirements from engineering.

  • Measure & Iterate: Continue to measure adoption and designer satisfaction, treating the system as a product with its own roadmap and user base.