AlayaCare

As the senior product manager and system design thinker on AlayaCare's Connective Tissue team, our job was to make AlayaCare feel like one product instead of a collection of modules. I worked with three front-end developers on a daily basis, and together we shipped the changes that tie the product together.

We didn't own a single clinical or scheduling workflow. We owned what sits between them: the Overview pages people land on, the global navigation that gets them around, the notes they write across the product, and the Design System every team builds with. That work is easy to overlook when it's done well and impossible to ignore when it's not.

This case study covers what I saw, what I did about it, and what changed. The results range from a one-point CSAT gain on our flagship page to early work on making our Design System usable by AI agents.

Problem

Users told us, in different ways, that AlayaCare felt like many products stitched together. I saw it in four places.

The first was the Overview pages. The Client Overview was one of our most visited pages, yet information was scattered across tabs, with status history, risk assessment and contact tracking each living in a separate place. When we measured satisfaction, CSAT sat at 2.7 out of 5. Employee, Facility and Supplier overviews shared the same template, so every inconsistency repeated four times.

The second was global navigation. People had to understand our internal product structure before they could find their work, and reports and data tools lived in different corners of the app.

The third was notes. Client notes, progress notes, care provider notes and visit notes each had their own screens and rules. Some setups had 60+ Care Provider Note subjects. Fragmentation like that added clicks and invited duplicates.

The fourth was newer: our Design System. Product managers and designers had started prototyping with AI agents, but the first draft often invented UI, mixed unapproved components, and disagreed with itself between prompts. Two runs of the same intent didn't reliably look like AlayaCare Cloud. As one of the ADS stewards, I saw that the Design System was built for people reading documentation, not yet for an agent to consume. Every drifting prototype was inconsistency that design and front-end would have to unwind later.

Solution

My approach was to strengthen the connective layer: fix the shared patterns once, then reuse them everywhere. Day to day, that came down to four workstreams.

Improving Overview pages

I started with the Client Overview, because it was our flagship page and our lowest score. I worked with design, engineering and customer success to relocate the scattered tabs, introduce clear cards for client info, contacts, risk and services, bring client, progress and care provider notes into one section, and add pinning for coordinator notes. We used AI-assisted development in Cursor to deliver faster. I planned an opt-in rollout with a CSAT survey and onboarding guide in Pendo, so we could hear from users while we iterated. Because Employee, Facility and Supplier shared a template, the pattern then carried across those profile pages.

Global navigation

I drove a new navigation UI with a collapsible left sidebar, Settings moved out of everyday navigation, and a new Analytics section grouping reports and data tools. I made sure permissions stayed intact and legacy routes redirected safely, so nobody's bookmarks broke. The new UI was introduced across production, development environments and prototypes. Community feedback welcomed the reclaimed screen space and the new Settings placement, and flagged that environments such as UAT needed a stronger visual cue, which we logged as follow-up work.

Unifying notes

I worked to reduce the number of screens and legacy paths for client, progress, care provider and visit notes, starting with one Add Note dialog and a single place to configure note types. That first step was a front-end-only change with no API modifications. I gathered early community feedback and shared it back with the team. People liked limits on free-form subject creation, but a single long dropdown and extra clicks for progress notes needed fixing before general availability, and we created tickets to address them.

Optimizing the Design System for AI prototyping

My principle was that an AI agent can only be as good as the vocabulary we give it. In phase one, I defined the problem and success measures, and with engineering we built a machine-readable ADS package with component docs and tokens, rules that made ADS components the only allowed UI vocabulary, and a check that failed a prototype if it used anything else. Gaps were logged, not faked. We tested it by running the same prompts with product managers and comparing component choices.

I also started a DATAGRID audit of AI-generated tables to find where prototypes drifted from each other, with the goal of building those rules into the prototyping tool so outputs followed them by default. To give agents a clearer picture of what good looks like, we began adding reusable recipes such as a standard filtering pattern. Next, I scoped reusable ADS Blocks, small compositions like a listing page header or a client profile header, so the agent would pick a ready-made block instead of rebuilding it from atoms every time. Alongside the tooling, we added product rituals: weekly product reviews within domains and a monthly prototype demo across domains, so drift gets caught before it ships.

Results

The clearest result was the Client Overview. After the redesign launched in March 2026, CSAT rose from 2.7 to 3.7 out of 5, a full point, which was exactly the goal we set at the start. That told me the page now answered the questions users came to ask without a hunt through tabs. The pattern was then reused across other profile pages, so one investment improved several experiences and gave us a consistent foundation.

Navigation and notes were earlier in their story. The new navigation UI went live across production, development environments and prototypes, which gave us a base for continued routing work. Unified Notes had a clear direction and its first stages were progressing, with a broader migration planned for later. Tickets were in place to address the feedback before general availability in November, and I planned to add a Pendo CSAT rating so I could compare the new notes experience against the old one with real numbers.

On the Design System, the result was about quality of output. When the agent could only draw from ADS components, and a check failed anything else, the same brief produced the same component set instead of an invented screen. Prototypes stayed closer to what we actually ship, so design and front-end spent less time correcting drift. With Blocks, I expected faster prototyping and lower token cost, because the agent would assemble pages from ready-made pieces instead of regenerating them. I planned to measure that against the old approach rather than assume it.

The main lesson I took from this work is that product quality is often decided between features. When users recognize patterns and move confidently from one area to another, the product feels simpler even when the workflows underneath are complex. A Design System that agents can read extended that same idea to how we build.