Sciene / Companion · 2025-2026
From noise to signal.
I designed Sciene’s alerting workflow to help customer success teams identify accounts needing attention. After the first version overwhelmed users, we refined which alerts appeared and how people acted on them.
Sole Product Designer · Web App (Enterprise SaaS)
Live in production, used daily by hundreds of CSMs and directors
Every account looked urgent.
CSMs at Sciene's enterprise clients each manage 10 to 20+ accounts. Their day starts with the same question: what's on fire? Without a system to answer it, critical issues, sales drops, ad spend spikes, listing suspensions, delayed payments, only surface when the client calls angry. Teams patched the gap with an external dashboard sitting outside the product ecosystem, useful, disconnected.
Companion is Sciene's suite for Customer Success operations, spanning three modules: Account Flagging, an AI Email Hub, and a Meeting Hub. Account Flagging is the foundational one, the daily first look CSMs open every morning, and the anchor point everything downstream relies on.
Understanding how the morning really starts.
Six weeks of interviews: 12 CSMs across account tiers, plus 3 directors. I mapped how they actually scan for problems, which data they trust, and when they escalate. I started from the workflow and let the UI follow from it.
The first version created more noise.
The first prototype surfaced every alert the system could generate. It looked comprehensive. In testing with CSMs, it was noise. The AI insights layered on top were often technically correct and functionally useless.
I built a Claude artifact hooked to Databricks that pulled acknowledgment data from v0. Within a week the pattern was clear: only 34% of alerts were being acknowledged inside 24 hours. Two-thirds were being ignored, snoozed indefinitely, or drowned. The AI was doing exactly what we had asked of it, surfacing everything the data allowed. That was the problem.
The reframe: fewer alerts, each one worth stopping for.
I sat down with CSMs and their directors to define what "meaningful" meant, threshold by threshold. Then worked with the AI engineers to encode that back into the alerting logic. The design and the model met in the middle.
v0 · Surface every alert
Comprehensive alerts, but difficult to prioritize. Only 34% were acknowledged within 24 hours.
v1 · Prioritize what matters
Thresholds refined with CSMs and engineers, context for each alert, and explicit follow-up states.
Fewer alerts. Clearer reasons. Explicit actions.
Prioritize what matters
Categories and filters reflect how CSMs triage their morning.
Explain the reason
Frequency, historical context, and metrics help people interpret each signal.
Close the loop
OK, snooze, and resolved make follow-up explicit.
For layout exploration, I generated four or five rough React prototypes in Cursor and tested them with CSMs the same day. Threshold logic was co-authored with the AI engineers, I'd prototype an alert rule, they'd stress-test it against production data, we'd iterate until the false-positive rate was liveable.
From individual triage to team oversight.
v1 gave individual CSMs their morning triage. v2 gave directors their team.
The Director Dashboard surfaces MRR under alert across all CSMs, resolution rates, help-requested loop, and priority ranking by workload. Every metric traces back to the same alerting system.
CSMs can flag an account as "asked for help." Directors see the ask surface in their view; the CSM sees it acknowledged in theirs. Solo dashboard, two-role system.
A shared foundation for growth.
Account Flagging was the first of three surfaces. Companion spans three modules, so the alerting patterns had to hold up across an AI Email Hub and a Meeting Hub, both also designed by me.
I built the design system from zero alongside v1: tokens, a component library, accessibility standards, and handoff documentation, adopted across product and engineering. Alert states, severity treatment, and acknowledgment controls became shared primitives every module could pull from. That is why v2's Director Dashboard shipped without redesigning anything from scratch.
What changed—and what I learned.
The pivot changed how I think about AI in product design. Surfacing more was never the hard part. Deciding what to hide was, and v1 works because we let the model bury most alerts and then made sure the ones that survived were worth a CSM's attention.
AI is what let this project move quickly. The judgment stayed mine, and this is where I first proved that to myself, on both sides of the screen.
How I used AI throughout the project
Interview synthesis
Instead of transcribing 12 hours of interviews by hand, I used Claude to cluster transcripts into pain patterns. What would have taken most of a week took an afternoon, and let me spend the rest of it pressure-testing those patterns against the raw source.
A system agents can read
The system was documented for two audiences: people and AI agents. Semantic token names, component descriptions written as usage rules, and states enumerated in predictable structures mean an LLM assistant can compose valid product UI from the library the same way an engineer does. The docs double as the prompt.
Documentation
Developer handoff docs and Figma annotations were drafted alongside the design work with Claude, while the decisions were still fresh. That kept the spec in sync with the prototype and cut handoff friction to near zero.