Building Design-Driven Product Development at Portfolio Scale

Context

Inovalon is a healthcare data and analytics company whose platform processes billions of medical events annually for payers, providers, and life sciences organizations. The company had over 30 products across multiple business units, but its strength had always been analytics, not experience design. Data was king. The company had never needed consumer-facing mobile apps or polished commercial websites; the value proposition lived in the depth and accuracy of the analytics beneath the surface.

The challenge was that as the market matured, the gap between what Inovalon's analytics could do and how well the products communicated that value to users was widening. Product interfaces were functionally sound but lacked the usability, consistency, and design rigor that clients increasingly expected. Product owners were doing their best with the tools they had, but they hadn't been given formal training in user research, usability testing, or human-centered design methods. There was no shared design system, no component library, and no UX standards connecting the product suite.

The company had also grown rapidly through a series of major acquisitions spanning clinical operations, life sciences, pharma, and provider services. Each acquisition brought its own product suite, engineering culture, and approach to building software. The result was an increasingly fragmented portfolio where product teams operated in silos, sharing neither users, research, design patterns, nor a common understanding of their customer base.

The Origin Story

The seeds of the design practice were planted before it had a name. While leading the payer-provider analytics portal (detailed in a separate case study), I had hired UX designers to support the product work. One of them pushed for formal training, and together we pursued Nielsen Norman Group UX Management certification. He attempted to establish a "Design Center of Excellence," an early precursor to the practice that would come later. The effort didn't gain broad traction beyond my own product work and a parallel application redesign, but it demonstrated enough value that our CPO recognized the company needed a dedicated design function with more senior leadership.

In late 2019, the CPO recruited an AVP of Design Strategy to build that function. For months, progress was slow. Product leaders across the organization didn't see the need for design support, and many viewed it as an unnecessary addition to their established workflows. The prevailing assumption was that design was a cosmetic concern, something applied after the important decisions were already made.

I had been at Inovalon for nearly a decade and had watched this dynamic play out firsthand. I was already practicing design thinking intuitively through my product work, applying field research, user observation, and iterative testing without recognizing it as a formal discipline. When the new AVP arrived, I recognized that the methodology he was trying to build was exactly what the organization needed. He had the design and innovation expertise and formal training. What he needed was someone with deep institutional knowledge, executive relationships, and the cross-functional credibility to open doors.

The Real Question

The mandate was to bring design thinking to the product organization. But the deeper challenge was one of culture change: how do you establish a design-led practice inside a company that has never had one, where the people you need to influence don't report to you, and where you must demonstrate the value of design before you can practice it at scale?

Every workshop, every research project, and every successful engagement served dual purposes: it was both a deliverable that created value for the business and a proof point that built the case for continued investment in design.

What We Built

The Internal Consultancy Model

One UX designer from my previous team was already embedded in product work and stayed on as the design practice formalized. We hired an additional design strategist to round out the team, giving us specialists who could operate as internal design consultants deployed across business units. The model was deliberately structured like a boutique design firm: a small team allocated to the highest-impact engagements across the portfolio.

The strategic challenge was that we couldn't simply run projects. We had to simultaneously build the systems that would make design sustainable beyond any individual engagement. That meant operating on two tracks: leading high-visibility, high-impact projects that demonstrated value to skeptics, while building a repeatable methodology that enabled product owners to apply design practices independently.

The Design Intake Process

We designed a formal intake system to replace informal requests. The process evaluated every potential design engagement against clear criteria: Does the project impact the customer experience? Does it drive top-line revenue or meaningful cost savings? Can design methods meaningfully de-risk the outcome?

Projects that met the criteria were assigned one of three engagement levels:

This tiered model was critical. It allowed a team of five to influence dozens of products simultaneously, scaling through coaching relationships rather than headcount.

The Design Services Catalog

To operationalize the intake process, we created a service catalog organizing our capabilities into clear tiers:

Building the Movement

We started with champions: a handful of product owners and junior associates who were open-minded and willing to try a different approach. As their projects succeeded, their enthusiasm became contagious. Each early adopter who saw better outcomes from research-informed decisions became an advocate who helped us reach the next group. We let their success radiate outward through the organization to fuel a broader movement, rather than trying to mandate adoption from the top down.

The Training Program

We built and delivered a curriculum called "Design-Driven Product Development" aimed at Inovalon's 50+ Agile product leaders. The goal was not to turn product managers into designers, but to give them fluency in research methods: the ability to identify when design support was needed, participate meaningfully in research activities, and apply synthesis techniques to their own customer interactions.

The flagship module, "The Power of Insights," taught the full research synthesis pipeline: gathering raw data, extracting objective facts through coding and tagging, identifying patterns and themes across interviews, and composing insights that are clear, evidence-based, and compelling enough to drive action.

We also ran recurring sessions: a weekly research synthesis workshop, a lunch-and-learn series on prototyping tools, and practical workshops on UI design principles. All sessions were recorded and added to the training library alongside discussion guide templates, informed consent frameworks, and research methodology playbooks.

The Design System and Platform Migration

The design system had a practical origin. In my previous role as Senior Director of Platform Solutions, I had contracted with an outside design firm to build the UI for a provider-facing portal I owned. That UI became the foundation for the Inovalon ONE design system.

When I joined the Design Strategy team, I advocated for adopting that UI framework as the starting point for a universal standard. One of our senior design strategists did extensive work to iterate on it, extending the component library into a comprehensive system that worked across all of Inovalon's applications. The design system included typography standards, color systems, UI component specifications, responsive layouts for mobile and cross-browser compatibility, and grid standards. We collaborated closely with marketing to ensure consistency with commercial branding and published a universal style guide.

The design system migration also served as a vehicle for a broader infrastructure modernization. In my prior role, I had implemented an enterprise identity and access management solution for centralized SSO and multi-factor authentication. As each application migrated to the Inovalon ONE UI, it also adopted this secure authentication infrastructure. We bundled the features intentionally: applications could not achieve HITRUST certification (the healthcare security standard required by our clients) until they had migrated to the Inovalon ONE platform, which included both the design system and the centralized IAM. This coupling created a compliance-driven incentive for adoption that accelerated the design migration across business units.

The design system reduced front-end development time by an estimated 4-6 sprints per project by giving engineering teams pre-built, pre-approved components. It was adopted across the product portfolio.

Innovation and Post-Acquisition Integration

We served as much of an innovation and design thinking practice as a UX/UI function. A significant portion of our work involved facilitating workshops to identify synergies and innovation opportunities across the products that had come together through acquisitions. Design thinking methods (journey mapping, service blueprinting, collaborative ideation) proved to be powerful tools for helping teams that had never worked together discover overlapping capabilities and imagine integrated solutions.

One example: we ran a cross-functional initiative to map and document user personas across the full Inovalon ONE product landscape. The challenge was that many products shared overlapping buyer and user populations, but no one had a unified view of who those people were or how they moved between products. The result was a comprehensive persona library that served multiple teams: business development used it as a reference during sales conversations, implementation teams used it to understand who they were training, and product owners used it to ground their roadmap decisions in a shared understanding of the people they were building for.

We also facilitated competitive analysis using a customized framework and created service design blueprints that mapped end-to-end service delivery from data ingestion through revenue realization.

Executive Reporting

Because of my background in business intelligence and data visualization, I owned all reporting of design practice progress and outcomes to the Executive Leadership Team. Every report was an opportunity to connect design activities to business impact, demonstrate the value of research-informed decisions, and maintain the executive sponsorship that made the practice possible.

What Changed

Building a design practice inside a company with long development cycles means that many projects initiated during the founding period reach maturity only after the founders have moved on. I want to be transparent about that reality: while the systems, methodology, and cultural change were firmly established during our tenure, many of the specific product improvements those systems enabled were still working through their development cycles when the founding team transitioned to new opportunities in 2021.

What I Would Do Differently

I would push from day one to establish quantitative baselines before starting any design engagement. We knew that design-driven approaches were producing better outcomes, and qualitative evidence supported that conviction, but without rigorous before-and-after measurement, the ROI story relied on narrative rather than proof. This made it harder to advocate for additional investment during budget conversations.

I would also be more deliberate about sequencing early wins. We prioritized projects based on impact potential and executive visibility, which was strategically sound, but some of those high-impact projects had timelines that extended well beyond our tenure. Mixing in smaller, faster-turnaround engagements with clear measurable outcomes would have built momentum and credibility faster.

Finally, I would start the design system initiative earlier and with more intentional architecture. The organic path (adopting a vendor-built UI from one project as the enterprise standard) worked, but a more deliberate approach to design system governance from the beginning would have made adoption smoother across business units with very different product contexts and user needs.