Designing the nervous system for enterprise Customer Success.

Velora is an enterprise Customer Success and Sales Operations platform I led as Lead UX Designer from initial discovery through General Availability. The mandate was direct: give Customer Success Managers, Sales Directors, and Support leadership a single operational surface, built on Salesforce Lightning Design System 2 (Cosmos), that replaces a patchwork of Service Cloud views, spreadsheets, BI dashboards, and email threads CSMs were stitching together by hand to answer one question: "which accounts need me today, and why?"

The platform ships as a single cohesive application spanning 25 functional views, Home, Accounts, Leads, Opportunities, Renewals, Cases, Customer Health, Renewal War Room, Deal DNA, AI Insights, Playbooks, Forecast, Reports, Analytics, Meetings, Knowledge Base, and supporting admin surfaces, unified under one design language and one navigation model.

• Sole Lead Designer of record for the 0-to-1 build; owned UX strategy, IA, interaction design, design system architecture, and accessibility compliance.
• Directed one mid-level product designer (visual systems, illustration) and a part-time content designer; partnered with two contract researchers for discovery and validation.
• Embedded with a cross-functional pod of 8 engineers, 1 PM, and a Salesforce Platform Architect through twice-weekly design/eng syncs and a shared Figma-to-code handoff pipeline.
• Reported design decisions and trade-offs directly to the VP of Product and, for the AI transparency and RTL scoping decisions, to the CPO.

• Greenfield build, but constrained to SLDS 2 global styling hooks, no freelance visual design; every token had to trace back to an approved Cosmos primitive or a documented, governed extension.
• Primary launch market: UAE and GCC, which added currency localization (AED-first, multi-currency), Hijri/Gregorian dual-calendar display, and Friday–Saturday weekend conventions as hard functional requirements, not nice-to-haves.
• AI features (Agentforce-powered health scoring, churn prediction, "Deal DNA" win/loss pattern analysis) needed to ship with visible confidence scores and a reversible action model, leadership was explicit that an opaque AI recommendation a CSM couldn't question would not survive the first bad recommendation.

Customer Success at the target account profile, 100–2,000 seat B2B SaaS customers, had scaled headcount faster than its tooling. CSMs owned portfolios of 35–60 accounts and were expected to catch renewal risk early, drive expansion, and close support loops, but their actual operating model was five disconnected systems and a personal spreadsheet:

• Salesforce Service Cloud for case history, but no rollup of account health.
• A shared Google Sheet, updated manually every Friday, that functioned as the de facto "at-risk account list."
• A Looker dashboard, six weeks stale on average, for ARR and renewal date tracking.
• Zendesk for live support signal, invisible to CS unless a support agent manually flagged an escalation.
• Email and Slack for anything involving another human, stakeholder changes, QBR notes, renewal negotiation context.

The cost of this fragmentation was not a UX inconvenience, it was P&L-visible. In stakeholder interviews and a 6-week contextual inquiry (Section 5), we quantified that the average CSM spent 6.4 hours per week manually compiling account status, and the average at-risk account was flagged only 11 days before contract expiry, too late to run a save play with any leverage. Net Revenue Retention had plateaued at 104%, well below the 112% board target, and churn post-mortems repeatedly cited "we didn't see it coming" as a root cause, when the underlying signal (usage decline, support ticket spike, champion departure) had in fact been sitting in three different systems for weeks.

Six disconnected sources of truth, manually reconciled, collapsed into one.

✓ full support · ± partial / bolt-on · ✕ not supported. Based on the tools documented in Section 5's research; category labels are anonymized per Velora's fictionalized-portfolio framing.

Actual product: Renewal War Room

The gap that mattered most: detection window

Point-solution BI tools showed ARR and renewal dates, but never why an account was at risk. Generic CS platforms scored health but couldn't explain the score. Velora's War Room leads with the number that changes behavior, at-risk ARR by urgency lane, with an AI-suggested next action inline, so triage and action happen in the same glance instead of a dashboard-then-spreadsheet-then-Slack relay.

app.velora.io/renewal-war-room

I ran the engagement against the Double Diamond, not as a wall poster, but as the actual gate structure for what could move forward. Each diamond has an explicit divergent phase (go wide, resist the urge to solve) and a convergent phase (commit to one direction and defend it). The Problem Statement in Section 2 is the output of the first diamond closing; the shipped product in Section 22 is the output of the second.

The gate that mattered most in practice was between Discover and Define: I held the team in "we don't know yet" for four weeks longer than the original schedule wanted, over real pushback from engineering leadership who wanted to start building. That delay is why the Horizon 1 "consolidation before intelligence" strategy in Section 13 was defensible with data instead of being a designer's hunch.

Design objectives were derived directly from the FY26 operating plan the CPO and CFO co-owned. I insisted on tying every major design decision back to one of these five objectives during design reviews, it kept scope discussions grounded in outcomes rather than aesthetic preference.

Design was accountable for the product experience that made these numbers move, not for the numbers themselves. I made that boundary explicit early: engineering owned data pipeline latency, data science owned model precision for churn scoring, and design owned whether a CSM could see, trust, and act on what those systems produced inside a single, coherent surface.

Research ran in two waves: a 6-week discovery phase before any design artifact existed, and a continuous validation cadence (bi-weekly, 3–5 sessions) through build. I partnered with two contract researchers; I personally moderated roughly a third of discovery sessions to keep design decisions grounded in direct exposure rather than secondhand synthesis.

We did not run field research with support agents directly, we relied on CSM-reported pain and a lighter desk review of Zendesk escalation data. I flagged this trade-off to the PM at the time; it is revisited honestly in Section 30.

I ran structured 45-minute interviews with nine executive and cross-functional stakeholders before finalizing the IA. The goal was less "gather feature requests" and more "find where the organizational incentives disagree", because those disagreements, left unresolved, become design ambiguity later.

The CPO's comment on AI overridability became a hard design constraint carried through the entire AI Integration strategy (Section 19), every AI-surfaced insight in Velora ships with a visible confidence score, a one-line rationale, and a reversible dismiss action with undo, never a silent auto-action.

Four personas anchored every design review. I deliberately kept the set small, a fifth "Executive" persona was proposed and cut, because in practice the Executive Dashboard is a read-only rollup of the same data the VP persona already consumes; adding a separate persona would have fragmented design decisions without changing them.

In the product, these personas map onto permission sets: Omar to CS Standard, Rashid to Sales Manager, Farah to Support Standard and Priya to Executive. The access model also includes Sales Standard (Account Executive) and System Admin, which are permission sets rather than personas (see Section 12).

Personas describe who a user is; empathy maps describe what a specific moment of using the old tooling actually felt like. I built these directly from contextual-inquiry transcripts, every line in each quadrant below is a paraphrase of something a real CSM or Sales Director said or visibly did during a shadowing session, not an invented placeholder.

Farah's map is deliberately thinner than the other three, it reflects the CSM-reported and desk-review research documented in Section 5, not direct shadowing like the other personas, and I'd rather show that gap honestly than pad it with unvalidated detail.

I synthesized the empathy maps, stakeholder interviews, and contextual inquiry into five pain points, ranked by how often they surfaced across interviews and how directly they traced to the P&L cost documented in Section 2. This ranked list became the rubric against which every subsequent feature decision was tested, if a proposed feature didn't move one of these five, it didn't ship in Horizon 1.

I used JTBD statements as the bridge between persona empathy and IA structure, every top-level navigation item in Velora maps to at least one JTBD statement below, and I could trace every one of the 25 views back to a specific job. Where a proposed feature didn't map to a job, it got cut or deferred (see Section 26, the Pinned Accounts / widget-collapse reversal).

The emotional arc mattered here as much as the functional one: in contextual inquiry, CSMs described the "diagnosis" stage as the most stressful part of their week, the feeling of not knowing what they didn't know. Compressing that stage from ~35 minutes of manual cross-referencing to a single consolidated view was the single highest-leverage design change in the product, and it's the one stakeholders cite most often in QBR retros.

This journey exposed the sharpest cross-functional seam in the business: a lead converting to an opportunity lost 40% of its qualifying context in the old process because Sales and CS used separate systems with no shared object model. Velora's Opportunities and Renewals views share the same account and stakeholder data model, so a converted lead's discovery notes, competitive context, and stakeholder map carry forward automatically into the renewal motion 12–18 months later, closing a handoff gap that RevOps had flagged as a forecast-accuracy risk for two years running.

The left navigation is organized into four functional groups rather than a flat list, a decision that came directly out of card-sorting with 11 CSMs and Sales Directors, who consistently grouped items by "what job this helps me do" rather than by object type (which is how the underlying Salesforce data model is organized). Fighting the data model's natural grouping in favor of the user's mental model was a deliberate, and occasionally contentious, IA decision with engineering.

Two IA decisions worth defending explicitly:

• Renewal War Room and Deal DNA are separate views from Renewals and Opportunities, despite overlapping data, because they serve a distinctly different cognitive mode, triage and pattern-recognition rather than record management. Merging them (an early proposal from engineering, for reuse efficiency) tested worse in card sorts because it forced two different mental tasks onto one screen.
• The Executive view sits inside "Intelligence," rather than as a separate top-level destination: usage data from the beta showed VP-level stakeholders opened it from a shared link far more often than from navigation, so it didn't need the visual weight of a primary nav item.

The map above is the whole product. What any one person sees is a subset of it. Six permission sets (CS Standard, Sales Standard, Sales Manager, Support Standard, Executive and System Admin) decide which screens a role can open, and each screen is either full, read-only or unavailable. Three rules shaped how that shows up:

Screens a role can never use disappear entirely, not just from the sidebar. In-page shortcuts and search results drop them too, and a navigation group left with nothing in it disappears along with them. A CSM's sidebar shows 15 of the 20 destinations; Executive only shows up for the Executive and System Admin sets, Admin only for System Admin.

A screen the role can see but not edit stays put, and says so exactly once: a banner names the permission set and links to a request for edit access, and the write actions on the page are disabled with a tooltip instead of failing silently after someone clicks them.

The harder case is a role that reaches a screen it was never supposed to see, by typing the URL directly or clicking an old bookmark. That gets a real screen, not a blank page: the reason, the permission set the role is on, who does have access, and two ways forward, back to its own landing screen or a request to the administrator.

No access: CS Standard opening Deal DNA

Read-only: CS Standard opening Opportunities

Each state is announced, not only styled: the banner is a status region, disabled actions carry aria-disabled, and the no-access screen moves focus to its heading.

Admin: one matrix, two outputs

A single access matrix drives the sidebar, direct navigation, in-page shortcuts, global search and write actions. The same matrix generates the Screen Access table in Admin, so what the documentation says and what the product does cannot drift apart. The Executive set, for example, is read-only on Accounts, Opportunities, Renewals, Cases, Forecast and Deal DNA.

app.velora.io/admin

I framed the strategy around three sequenced horizons rather than a single "vision deck," because the CPO explicitly wanted to know what was safe to promise in the first release versus what required the AI model maturity we didn't yet have.

Replace the five-system patchwork with one operational surface. No new capability, the win is entirely in surfacing existing signal faster. This was intentionally the least glamorous phase and I fought to protect it against pressure to lead with AI features, because the research was unambiguous: the fastest, most measurable win was just stopping the manual cross-referencing.

Layer AI-driven health scoring, churn prediction, and Deal DNA pattern-matching on top of the consolidated surface, but only once the confidence-score and override interaction pattern (Section 19) had been validated in usability testing. We held this back deliberately rather than shipping AI and UX simultaneously; conflating "does the surface work" with "do people trust the model" would have made either failure impossible to diagnose.

Move from "here is what's happening" to "here is the specific next action, pre-populated", Playbooks maturing from suggested reading into one-click, reversible workflow execution. Detailed in Section 32.

Every row below traces directly back to a ranked pain point from Section 9. I used this table in design reviews as a forcing function, if a feature request couldn't be placed in the right column, it was either speculative scope or a solution looking for a problem, and got parked for Horizon 2 or 3 rather than shipped at GA.

Five principles, written after discovery and stress-tested against every major design debate that followed. I kept this list short deliberately, a twelve-point principles doc gets cited by nobody in a live design review.

Velora is built on SLDS 2's Cosmos theme using global styling hooks end to end, every color, spacing, radius, and typography value in the product resolves to a documented SLDS 2 token (for example, brand blue resolves to --slds-g-color-brand-base-50, error states to the error-base-40 semantic ramp). This was a non-negotiable constraint from the Salesforce Platform Architect stakeholder interview, and I treated it as a feature rather than a limitation: it meant every visual decision had a governance trail and every future SLDS release could theoretically be adopted with a token remap rather than a redesign.

Light theme

Dark theme

Every screen ships in both themes from the same token set, no parallel dark-mode stylesheet to maintain, and no contrast regression risk when a new component ships.

• Zero bespoke color decisions, every semantic state (success, warning, error, AI/Agentforce accent) traces to an approved token ramp, which made accessibility contrast auditing mechanical rather than case-by-case.
• A density-aware spacing scale (4-pt grid for spacing, 8-pt for sizing) that let us support a "Compact" density mode for power-user CSMs managing 60-account portfolios without a second design system.
• Icons sourced directly from the official SLDS utility icon sprite (v2.264.0) rather than hand-drawn approximations, a mid-project correction detailed in Section 26 after an internal audit found visual drift.

The two genuinely new visual patterns in Velora, the Renewal War Room's urgency lanes and the Deal DNA win/loss pattern bars, were built from existing SLDS card, badge, and data-table primitives recomposed, not new components. I treated "can I build this from existing tokens and primitives" as the first question in every design review, and required a written justification in the component library (Section 17) whenever the answer was no.

I ran component strategy as a build-versus-extend-versus-invent decision tree, reviewed at each sprint's design crit. Of roughly 60 distinct UI patterns in Velora, 4 required genuinely new components, everything else is a composition of existing SLDS blueprints.

The AI confidence badge is worth calling out: once we validated it on Customer Health, we reused the identical component, same anatomy, same interaction, on Deal DNA, AI Insights, and the Home AI Daily Digest, rather than letting each surface invent its own AI presentation pattern. That consistency is what let CSMs generalize trust across the product instead of re-learning "how AI works here" on every screen.

The Kanban board, the one genuinely invented pattern

No SLDS 2 kanban primitive exists, so this is the clearest example of "invent, governed" from the table above. Every visual property, card shadow, column background, badge shape, still traces to an existing SLDS token; only the drag-and-drop column structure itself is new. Deal-stage percentage, close date, and owner avatar are shown directly on the card face, a deliberate choice so a Sales Director can triage the whole pipeline without opening a single record.

app.velora.io/opportunities

AI here is scoped to exactly the pain points in Section 9 that a static rollup could never solve on its own: risk that only reveals itself as a pattern across signals, and forecasts that need a model's help to hold up under scrutiny. Section 19 covers the interaction-pattern detail; this section is the map of where AI touches the product and the philosophy that governs all of it.

The rule I held the team to across all six of these: an AI surface is not allowed to ship without an answer to "what does a CSM do when the model is wrong?" That question killed two proposed features outright (an auto-send renewal email, and a fully automatic health-score override) and shaped the confidence-and-override pattern that made it into every other one.

This contract had a real cost: it slowed shipping velocity on AI features by roughly 30%, by our own sprint accounting, because every new AI surface needed the same confidence/rationale/dismiss scaffolding built and tested before it could ship. I defended that cost in front of the CPO twice during the project when engineering proposed shipping a "fast follow" AI feature without the full pattern, and both times held the line, the research finding in Section 5 (CSMs abandoning a prior black-box AI tool) was concrete enough evidence to make that an easy trade-off to defend, even under schedule pressure.

The AI Insights feed, the contract in practice

Every card in this feed follows the four-part contract on the left, priority tier, plain-language finding, confidence percentage, and an account-specific next step, with nothing surfaced silently. The audit log on the right exists specifically so a CSM's dismiss or override is never lost, it's the mechanism that makes "human commits" (rule 4) checkable after the fact, not just a design promise.

app.velora.io/ai-insights

Deal DNA analyzes 148 closed deals to surface win/loss correlations (e.g., "QBR held within 30 days of renewal" correlates with a 68% win rate versus a 31% baseline). Early internal reviews questioned whether showing the underlying sample size and baseline comparison was "too statistical" for a CSM audience. I pushed back and kept it: in usability testing, the baseline comparison was the single detail that made participants trust the pattern was real rather than an anecdote, removing it, in an A/B variant we tested during validation, measurably reduced stated trust in the feature (Section 25).

Accessibility was scoped as a release-blocking requirement rather than a post-launch remediation item, a position I had to establish early, because the initial engineering estimate did not budget time for it. I brought a baseline automated audit (axe-core) to the first roadmap planning session specifically to make the gap visible before scope was locked.

• Colour contrast: corrected two SLDS border tokens implemented against the wrong neutral ramp (neutral-90/80 instead of the spec'd neutral-80/40), which was failing AA contrast on card borders and secondary text across the entire product.
• Keyboard operability: the Kanban board's drag-and-drop stage changes had no keyboard equivalent; we added a per-card "move" menu operable via Tab/Enter so screen-reader and keyboard-only users weren't locked out of a core CS workflow.
• Live regions: toast notifications and the AI Daily Digest's dynamic content were wired with aria-live="polite" so screen-reader users receive the same "something changed" signal sighted users get visually.
• Focus management: every modal traps focus correctly and returns it to the triggering element on close, verified in a moderated session with a screen-reader-primary participant, not just automated tooling.

I treat automated tooling (axe-core, 0 critical/serious violations at GA) as a floor, not a finish line. Two of the fixes above, the keyboard-equivalent for Kanban drag-and-drop and the toast live-region, were only found because we ran a dedicated accessibility usability session with two screen-reader-primary participants two weeks before GA, and both fixes would not have been caught by automated scanning alone.

Because Velora extends SLDS 2 rather than forking it, governance had two layers: staying aligned with upstream Salesforce releases, and controlling our own handful of invented components (Section 17) so they didn't silently multiply.

Rather than a static gallery, I want to walk through three shipped screens that carry the most design decision-density in the product, each represents a different category of problem the team solved. These are the actual production screens, not mockups.

Home: the "one glance" dashboard

The home dashboard went through the most public failure of the project (detailed fully in Section 26): the first version scored a Major severity "high cognitive load" finding in our internal heuristic evaluation because it stacked an AI Daily Digest banner, six KPI cards, and a two-column feed of charts, tasks, meetings, and AI insights all above the fold. The shipped version keeps the AI Daily Digest as a calm, low-saturation summary band, deliberately toned down from an earlier bold navy treatment, with KPI cards using the same tinted-icon-chip visual language as Salesforce's own Lightning App Builder cards, so the surface reads as "part of Salesforce" rather than a third-party bolt-on.

app.velora.io/home

Renewal War Room: triage under time pressure

This screen exists because Journey Map 1 (Section 11) showed the "diagnosis" stage was the highest-stress, highest-time-cost part of a CSM's week. It groups at-risk accounts into Critical (≤30 days), Urgent (31–60 days), and Upcoming (61–90 days) urgency lanes with the at-risk ARR value led with, per SLDS numeric hierarchy conventions, and an AI-suggested next action inline on every card, designed so a CSM can complete a full portfolio triage pass in under 5 minutes, down from the ~35-minute cross-referencing baseline.

app.velora.io/renewal-war-room

Deal DNA: making a statistical model legible

The hardest visual design problem in the product: representing a win/loss correlation model without either dumbing it into a meaningless traffic light or overwhelming a non-technical CSM with a feature-importance chart. The shipped pattern, horizontal comparison bars against an explicit baseline, with sample size and win-rate lift stated in plain language, came directly out of the trust-testing finding in Section 19.

app.velora.io/deal-dna

The end-to-end flow a CSM actually runs through Velora on a typical day, from opening the tab to logging an outcome. I used this flow as the backbone for the usability testing script in Section 25, every task in that study maps to one or more steps below.

The Figma prototype used for stakeholder review and usability testing was interactive down to individual micro-interaction states, not just screen-to-screen navigation, a decision that paid for itself directly in Section 25's usability findings, several of which were state-transition problems that a click-through-only prototype would never have surfaced.

Validation ran in three rounds, early concept (paper/low-fi), mid-fidelity Figma prototype, and a pre-GA build-based round using the actual application, plus a dedicated internal heuristic evaluation against Nielsen's 10 heuristics, WCAG 2.1 AA, and SLDS 2 conventions, commissioned specifically to catch issues our own proximity to the product had made invisible to us.

Commissioned as an independent gut-check before the accessibility hardening sprint. Findings were rated Cosmetic (1) through Catastrophe (4):

14 of the 15 non-catastrophic findings were resolved before GA; the RTL finding was the one explicitly descoped rather than fixed, a decision covered honestly in Section 30.

Three iterations changed the product materially enough to be worth walking through as design decisions, not just bug fixes.

The first shipped version of Home scored a Major severity "high cognitive load" finding (Section 25) for stacking an AI Daily Digest, six KPI cards, and a dense two-column feed above the fold. My first instinct was to add collapsible widgets so users could hide what they didn't need, I built and shipped that to an internal beta. It was actively disliked: CSMs described having to "configure their own dashboard" as one more chore, and collapse-state defaults created inconsistent screenshots across support tickets and QBR decks. I reversed course and instead restructured the information hierarchy itself, AI Daily Digest toned down visually and demoted to a calm summary band, KPI cards standardized to the Salesforce-style tinted icon-chip pattern, and the two-column feed reorganized around a clear "act now / plan ahead" split. The widget-toggle feature was fully removed rather than left in as unused surface area.

A mid-project internal audit found the icon set had drifted, early screens used hand-approximated SVG paths that looked close to SLDS icons but weren't sourced from the actual design system, creating subtle visual inconsistency (mixed filled and stroked styles) that a design-literate stakeholder caught in a Salesforce admin review. I treated this as a governance failure rather than a cosmetic one, and required every icon in the product to be re-sourced directly from the official @salesforce-ux/design-system npm package's utility icon sprite, a project-wide sweep across all 42 distinct icons used in the product, cross-checked against duplicate assignments.

Early analytics views (Leads, Renewals, Customer Health, Deal DNA, Reports) shipped with lightweight custom-drawn Canvas visualizations to hit a schedule milestone. Once usability feedback showed CSMs expected to hover a bar or point for an exact value, a baseline expectation set by every other BI tool they used, we migrated the full charting layer to an interactive library with proper tooltips, legends, and accessible color mapping tied to the same SLDS semantic tokens used everywhere else in the product.

Measured at 6 months post-GA against the objectives set in Section 4. I want to be direct about attribution: the NRR and forecast-accuracy movements are shared outcomes with data science, sales enablement, and RevOps process changes running in parallel, design does not claim sole credit for revenue metrics, only for the product experience that made faster, better-informed decisions possible.

The metric I'm proudest of is the least glamorous one: manual reporting time. It has no AI in it, no novel interaction pattern, no portfolio-worthy screenshot, it's the direct, measurable payoff of the Horizon 1 "consolidation before intelligence" strategy in Section 13, and it is the number the VP of Customer Success quotes unprompted in every board deck she's shown me since.

Beyond the NRR and adoption numbers in Section 27, the fragmented-tooling problem had a direct SLA cost: escalations sat unrouted, renewal touchpoints slipped, and QBR prep routinely ran past its internal deadline. Measured the same 6-month post-GA window, against the same baselines.

The escalation-routing number is the one Support leadership cares about most: it's the direct product of the AI Insights live signal feed in Section 18 replacing a manual Slack forward that depended entirely on someone remembering to send it.

Omar's Monday morning, before and after GA. I used this storyboard in stakeholder reviews more than any chart in this document, it's the version of the pitch that made a CFO stop asking about feature lists and start asking about headcount planning.