CHG HealthcareCross-functional Leadership

Designing the people systems around the work

How I created feedback loops between designers, researchers and engineers—and helped a distributed product organization get better at designing software together.

Role: Senior → Principal Product Designer
Timeframe: 2020 - 2023
Scope: Design, Research, Front-end Engineering
Collaborators: Designers, Researchers, Engineers and Leads
Sessions: 66 UX Weekly Meetings, 23 UI CoP Meetings
Components: 126 Prioritized, 35 Documented

04.01I kept finding problems that didn’t belong to any single product

Most of my initial work at CHG was attached to provider-facing software. But over time I kept noticing another kind of UX problem: the organization around all the design work was producing inconsistency.

Nine designers were spread across five products. Researchers were developing their skills separately. Designers and engineers were making overlapping decisions without always knowing what other teams had already created. Front-end quality had to compete with business logic, back-end architecture, technical debt and delivery pressure, so it rarely received sustained strategic attention.

Then COVID sent everyone home and many of the informal conversations that had connected the UX team disappeared overnight.

All of those factors would degrade the user experience from within. If designers couldn't see one another's work, patterns diverged and we reinvented the wheel. If researchers rarely watched peers work, they had fewer chances to get better at interviewing. If design and engineering didn't develop shared vocabulary, implementation would got harder. If every product solved the same component differently, both design debt and technical debt would compound.

I started spending more of my time designing the people systems around the product work, not just the product itself.

Five CHG product teams and the organizational problems across them: isolated designers, limited researcher development, overlapping decisions, inconsistent front-end quality and design systems, and a lack of collaboration.

04.02When remote work broke our design feedback loop, I rebuilt it

Before COVID, the designers worked physically around one another. They could see what others were doing, ask questions, get informal feedback and learn simply by being in the same place.

Remote work erased most of that overnight. Designers still met with their individual product teams, but they weren't seeing one another anymore. I could see the inefficiency and costly repetition across their work, so I asked our manager if I could create a weekly UX feedback meeting.

Every Monday we met for about 90 minutes. The first part became “last week, this week.” Everyone explained what they had just worked on and what was coming next. That gave the group enough context to help one another with priorities, notice overlapping projects and understand what was happening across products.

Then we moved into critique. At first I simply asked for volunteers. Eventually people stopped volunteering, so I changed the system rather than accepting that critique had “stopped working.” I began tracking what everyone was designing, reviewing current design files before Monday, and bringing work that could produce a useful discussion.

During critique I'd start with what I thought was working, then pose questions to the group rather than positioning myself as the person with all the answers.

The meeting became something people reliably showed up for and engaged in. I ran 66 UX Weekly sessions between 2021 and 2023.

UX Weekly video meeting with designers sharing their previous and upcoming work, creating a regular feedback loop and helping the team stop designing in isolation.

04.03I created a similar learning loop for research

We could talk about interviewing technique all day, but watching another researcher conduct a real interview revealed things a checklist never could: where someone followed a useful thread, where they accidentally led a participant, when they talked too much, when they missed an opening or how they recovered from a difficult conversation.

So I started research peer-review sessions. We would watch roughly 20–30 minutes of someone's actual research recording and spend the rest of the hour talking about it together.

I deliberately put my own interviews up for review too. If I expected other people to expose unfinished or imperfect work to peers, I wanted to demonstrate that I was willing to do the same thing.

My goal was not just to tell people how to research better. It was to give them an environment where they could watch one another work, talk about their work and improve together.

Research peer-review meeting where the team watches a recorded interview and discusses interviewing techniques, including giving participants more time to think before responding.

04.04I went outside design when the UI issue was an engineering problem

Our engineering model relied heavily on full-stack developers. Functionality, architecture, database work, technical debt and delivery pressure were all competing for their attention. From my perspective, the UI layer wasn't receiving enough sustained attention and I knew that’d eventually hurt the user experience regardless of how good our Figma drawings were.

In September 2020 I started a UI Community of Practice that brought the designers and front-end engineers together to spend focused time on the UI. I wanted the people who understood that layer best to finally have a place to think and work on it together.

Over the next year we discussed Vue 3, Storybook, visual regression testing, Tailwind, utility classes, atomic-design concepts, component architecture, design tokens, cross-brand theming and gaps between Figma specifications and implementation.

When the engineering leads wanted to stay informed without attending every session, I sent them summaries afterward. When engineers wanted to move toward Vue 3 but didn't have bandwidth to drive the change themselves, I met with engineering leadership to help move it forward.

And when we worked through utility classes and component terminology together, something more basic was happening: Design and Engineering were developing a common vocabulary.

I ran 23 UI CoP meetings from September 2020 through September 2021, and attendance grew over time.

UI Community of Practice video meeting with designers and engineers discussing component reuse over shared code, establishing shared standards and improving front-end quality.

04.05My design-system work gave the conversations a place to converge

Eventually I was asked to focus directly on CHG's design system. We had nine designers working across five software products and no shared design system.

I knew we weren't going to fix years of fragmentation by opening Figma and drawing a perfect button library. We needed a way for designers and engineers to gradually agree on how the system should work.

I studied Atlassian, Salesforce Lightning, and Material, identifying 126 candidate components that our designers prioritized based on actual product needs. I then established a repeatable process of comparing external systems, auditing our products, resolving disagreements, and documenting standards before building reusable Figma components.

These audits continually refined our understanding, sometimes revealing unexpected complexity—like a single text field pattern that evolved into ten distinct components, each with its own rules and guidelines.

The design system became a way of making decisions once, documenting the reasoning and giving multiple teams a shared answer they could reuse.

Design-system meeting reviewing button types and sizes in Confluence, bringing designers together to agree on shared vocabulary, behavior, and documented standards across products.

04.06The design system became a way of making decisions once, documenting the reasoning and giving multiple teams a shared answer they could reuse.

The difficult part of building the design system wasn't drawing components. It was getting agreement. The nine designers had different backgrounds, different products and strongly held opinions about how interfaces should work.

I facilitated two-hour working sessions twice a week. I took live notes so people could see their arguments being captured, brought outside examples into the discussion, audited the actual products between sessions, synthesized what we'd decided and returned with unresolved questions.

Over time I developed a repeatable cadence.

After about a year, I noticed that three or four designers were doing most of the active problem solving while everyone else spent significant time observing.

Instead of continuing the same meetings because they were “the process,” we changed the structure. A smaller core group worked weekly and the larger design team came in periodically for review.

We had moved from nine designers independently solving the same problems in different ways toward an organization with shared language, documented decisions and reusable foundations.

Design-system component tracker showing a repeatable process from team discussion and product audits through documentation, Figma components, and testing.

04.07My goal wasn’t to make every decision but to make the team capable

Looking across these projects now, the connecting thread is that I tend to notice when the system surrounding the work is making good work harder than it needs to be.

Sometimes the missing system was critique. Sometimes it was research feedback. Sometimes it was a place for front-end engineers and designers to solve problems together. Sometimes it was a common component model. And sometimes it was simply making time for another designer or researcher to talk through something they were struggling with.

Mentoring became a substantial part of my time at CHG as well. Some relationships were formal, many weren't. I worked with designers and researchers on research, workshops, product thinking, communication, design-system work and the practical problems they were encountering in their teams.

And I did all of this without being their manager.

That distinction matters to me because this is the kind of leadership I most naturally practice: influencing through the work and through relationships, rather than through reporting lines.

04.08The interface is not the only layer a designer can improve

Earlier in my career I mostly measured my contribution by the screens I drew. At CHG I had an opportunity to operate on another level: sometimes the highest-leverage design work was creating the conditions that allowed a whole group of people to do better work after their leaders left the room.

I still want to design and create great software products. That's the work I enjoy most. But CHG taught me to look for leverage one level above the interface too: the feedback loops, relationships, shared language and reusable decisions that determine whether good product work can keep happening.

Three ways to improve the systems around design work: create a shared component model, establish recurring peer feedback, and bring designers and front-end engineers together to develop common language and priorities.