Drift Detection

Moving from manual intake to automated workflows, Slack review triggers, and cross-platform drift detection.

TEAM SUPPORTED
35+ designers · 6+ product managers · 10+ local developers · hundreds of remote developers

FOCUS
Design system governance, workflow automation, and drift detection

OBSERVED OUTCOME
Clearer support routes, fewer spontaneous questions, and more focused time for the system team

OVERVIEW

Making support predictable at scale

At Alight, design system support depended too much on people finding the right person to ask. We needed a dependable way to get answers and bring work into review, while giving the system team clearer context and more focused time.

I used our shared intake process to identify recurring coordination work, then built Slack workflows for feedback requests, council preparation, and sprint updates. We also built an API-based drift detector to surface component inventory differences for review. Together, these addressed two recurring needs: getting work to the right place and seeing where our system sources were out of sync.

My contribution combined process design and hands-on implementation. I mapped opportunities in the workflow, built the Slack automations, and used LLM assistance to help develop the Python inventory comparison that informed the dashboard.

CONTEXT & CHALLENGE

Support depended on finding the right person

Without a shared route for getting support, designers had to decide whom to ask and where to raise a request. Questions arrived through different channels, interrupting the design system team and making it harder to give consistent guidance.

Some requests reached review without user stories, acceptance criteria, or enough context to evaluate them. The team had to chase those details before work could move forward. Council preparation and sprint carryover also needed a consistent way to collect updates.

The goal was to make support predictable: clear places to ask, a consistent way to submit information, and regular opportunities for review. That would help designers keep moving while giving the system team a clearer basis for prioritizing and responding.

PROCESS & DECISIONS

Map the work, then choose what to automate

We used the intake process as the basis for our work. Mapping it in Miro made the handoffs visible, from component decisions and ticket submission to council review and the backlog. I used that map to identify recurring steps we could streamline.

I focused on reminders, structured information collection, and component inventory comparisons. Each had a defined job within the existing process. Slack supported the team’s recurring updates, Miro supported shared review, and the comparison script surfaced potential gaps across system sources.

The boundary mattered: automation could gather information and flag differences. People still needed to assess requests, agree on priorities, and decide whether a flagged difference required action.

The intake process: component decisions, ticket submission, council review, and backlog planning.

Explore the full intake workflow ↗

Pull component inventories → Compare names → Identify gaps → Review in the dashboard

AUTOMATED GOVERNANCE

Surface potential drift for human review

To reduce recurring inventory-checking work, we used APIs and a Python script to compare component names from Figma and Storybook. I used an LLM through Ollama to help develop the script. The comparison identified components that appeared in one inventory but were missing from the other.

Those findings informed the dashboard view: a shared place to see the sources being checked, review differences, and decide what needed a closer look. The view brought Figma, Storybook, and Zeroheight together; the comparison described here checked the Figma–Storybook inventories.

A naming difference was a signal to investigate. It did not establish whether two components looked or behaved the same, and it did not replace visual, interaction, or accessibility review.

The dashboard view brought Storybook, Figma, and Zeroheight together. The Figma–Storybook inventory check informed how we surfaced missing components.

PROCESS AUTOMATION

Make the next step clear

I built Slack workflows around the rituals we already needed: preparing for council meetings, requesting feedback, and flagging work carrying into the next sprint. Scheduled reminders and forms made those steps repeatable without relying on someone to remember to prompt the team.

The workflows collected the information needed for a conversation or review. They supported the team’s decisions rather than making those decisions for them.

Knowing what would carry over

Before the next sprint, a scheduled reminder asked the team what would carry over. A designer could flag a task, add its link and context, and share the update back to the channel. That gave the team a consistent place to see carryover before planning the next sprint.

Scheduled prompt → task details → shared update.

codex-clipboard-17e0152f-d79f-40f4-84d9-7f5d45bae544

Getting ready for review

The governance reminder asked council members to update the Miro board before we met. Gathering questions and updates ahead of time gave the group shared context for the review.

Prepare in Miro → bring the context into council review.

codex-clipboard-547511cc-0f63-4015-aa1d-40ae145a40c3

Giving feedback requests more context

I used a questionnaire to collect the requester, project, area of feedback, and a specific question with context. It gave the team a consistent starting point for understanding the need and directing the request.

A structured request made the support needed easier to understand.

codex-clipboard-6859c4e2-a7cb-4637-a74d-04c6b69a573a

OBSERVED OUTCOMES

A clearer way to get support

The clearest change was in how people got support. Teams had shared places, regular rituals, and resources to turn to. Designers no longer had to work out their own route to someone who might have an answer.

For the design system team, fewer spontaneous questions meant more focused time. Requests arrived with clearer context, helping us give more useful direction and explain what support we could provide. These were observed changes in how the team worked; we did not quantify time savings here.

The inventory comparison served a different purpose: it surfaced potential gaps for review. Its value was giving the team a starting point for investigation, rather than treating a mismatch as proof that a component was wrong.

LEADERSHIP PERSPECTIVE

Strategic takeaway

Governance needs to work for both the teams using the system and the people maintaining it. Clear support routes and structured requests made the work easier to coordinate. Bounded automation handled recurring steps while leaving review and prioritization with the team.

For a next iteration, I would measure request completeness, time to the first useful response, and the proportion of flagged inventory differences that led to action. That would help us see where the workflows were helping and where they needed adjustment.