Pride: Establishing a Shared Product System Under Delivery Constraints

Clinton Harman · Product Design Manager · AliveCor Focus: Product-system strategy, investment advocacy, cross-functional alignment, and implementation direction

Overview

Following a substantial workforce reduction, our product workload remained unchanged. We needed to support multiple products with fewer people, while teams were still repeating design decisions and maintaining separate versions of similar components.

I led the initiative to establish Pride, a shared design system and a more consistent way for design and development to work together. That involved defining the approach, building the business case, securing support over six months, and leading the design decisions that made the system usable in active product work.

The 12L recording application provided a practical pilot. Pride was also adopted in the desktop application used to review ECGs and manage work, and in Cardiac Care, a separate health-focused client. The shared foundation supported different needs across the product ecosystem.

Process at a glance

• Define the problem: Identified repeated design and implementation decisions that were consuming capacity across products.
• Build support: Developed the shared-system approach and business case, and worked through product and technology stakeholders over six months to secure support.
• Make decisions reusable: Used MUI as a foundation and led the design work on shared components, behavior, and documentation that developers could implement.
• Apply and refine: Used the 12L recording application as a pilot, responding to changing data requirements and practitioner feedback while supporting different product needs.

The foundation developed alongside active delivery. Pride was adopted in 12L, the desktop ECG review and management application, and Cardiac Care; the financial projections remain estimates of potential benefits.

The business problem: capacity was being spent on repeated work

The problem showed up in the interface, but it began in how work was organized.

Development often started from a product requirements document and a deadline before design was ready. Designers and developers could end up presenting their work at the same time. Decisions about behavior, data, and interaction were therefore being made during implementation, under deadlines that did not account for that work.

Previous design-system work existed, but independent versions had diverged without dependable shared maintenance. Similar components could behave differently across products. A change meant finding and updating separate implementations.

Turnover added another maintenance problem. When the explanation for a component lived mainly in its developer's head, the next person inherited the code without necessarily understanding its data requirements or intended behavior.

With fewer people and the same delivery demands, continuing to resolve those questions independently was a poor use of the team's capacity.

The strategic choice: make shared decisions reusable

My goal was to put design and development knowledge to work where it was most valuable. That meant agreeing on common behavior, documenting it, and making it reusable so people could concentrate on the product problems that still needed their judgment.

We selected MUI as a starting foundation because it supplied component code and detailed documentation. Using an established foundation let us focus custom work on our products rather than recreate basic controls.

The library was one part of the approach. We also needed a common method for defining components, communicating their logic, distributing design updates, and supporting implementation. Pride connected web and mobile design work through shared principles and resources while retaining platform-specific needs.

We had to build that foundation while products were still going out. Planning how to introduce the shared approach alongside delivery was part of the initiative, not something we could leave until the library was finished.

Securing support and defining my remit

I spent six months advocating for the initiative, revising the proposal and working through development and product stakeholders. I worked with the Chief Technology Officer and Chief Product Officer on the strategy and the approvals needed to proceed.

The formal prioritization request connected repeated work to development effort, maintenance, and delivery. It identified the resources needed, including evaluation time, implementation capacity, templates, and licenses. It also addressed technical compatibility and modeled potential financial benefits.

Those projections helped explain the investment. They were not realized savings.

As Product Design Manager, I led the design decisions and the shared-system approach. Product and technology leadership were involved in prioritization and approval; developers implemented the product behavior. My design responsibility did not give me control over every team's adoption decisions.

The approach depended on shared decisions and coordination across those responsibilities.

Turning the strategy into working practices

We moved from designing pages independently to defining components and the rules governing them. Team decisions became a shared reference rather than another question for each designer or developer to resolve.

The specifications covered the data a component needed, its default and interaction states, and how it should respond when the available data changed. Shared Figma components and variants made those configurations explicit. Standard components referenced MUI documentation; custom components linked to Confluence specifications and annotations.

Designers received shared component updates. Developers had a clearer account of what to build, and the explanation was available to someone joining the work later.

One data component was needed in seven places. Making it reusable gave those locations consistent behavior and a common documented reference, rather than seven independently maintained interpretations.

This was the operating change behind the component work: settle a shared decision, make it accessible, and let the team move forward.

Testing the approach in active product work

The 12L device and application supported ECG recording in the field or in examination rooms. The desktop review application served a different part of the workflow: in-depth review of incoming ECGs, workload management, and customer management. Cardiac Care was another health-focused client that adopted Pride.

The 12L measurements module gave us a concrete test of the approach. Its data requirements changed repeatedly during development. The modular presentation allowed the team to adjust the supplied data and API flow for those changes without redesigning the component each time.

Practitioner feedback also shaped the product. We clarified the primary-action hierarchy and provided a setting that reduced labels for users who wanted more room to focus on the data. Corresponding Figma variants communicated those presentation choices.

The shared system could accommodate these specific needs. It did not remove the need for research or product judgment; it gave those decisions a consistent way to reach implementation.

Results across the product ecosystem

Pride was adopted across the 12L recording application, the desktop ECG review and management application, and Cardiac Care. Developers responded positively to the clearer behavior and documentation, and the 12L pilot was well received.

The system gave these products a common foundation while allowing each to support its own users and workflows.

The demonstrated changes were reusable components, explicit behavior, shared documentation, and examples of accommodating changing requirements without redesigning the presentation each time. Reducing technical debt was a central objective, but the available estimates do not establish a measured reduction in cost, delivery time, or organization-wide technical debt.

Pride brought the investment case and implementation approach together. I identified where repeated decisions were consuming capacity, secured support for a shared foundation, and led the design work that made it usable by others. The result was a shared approach used across recording, review, and health-focused product work, with documented decisions that teams could build on.

See AliveCor’s current Kardia 12L product (opens in a new tab). The live product provides present-day context; it does not document the historical Pride components described in this case.