Case Study · FinTech Product Design · Concept Sprint

Equity Event
Management

Startup founders spend hours every funding round reconciling cap table entries, chasing legal sign-offs, and manually verifying compliance — across tools that were never designed to talk to each other. This is the design process behind a unified equity event system that turns that chaos into a single, audit-ready workflow.

Concept sprint project — a self-directed design exercise in the context of a private equity administration platform for startup founders. Research, design decisions, and prototype are original work and do not represent employment at any named company or a shipped production feature.

FinTech Product Design Complex Workflow UX Private Markets B2B SaaS AI-Native UX Compliance-Aware Design Multi-Persona System
PLATFORM CONTEXTPrivate equity admin · Startup tooling
PROBLEM AREAEquity events · Cap table accuracy
USERSFounders, legal counsel, employees
ROLELead Product Designer
TOOLSFigma · Miro · HTML/CSS/JS
PROCESSDiscovery → Prototype · 5 weeks
Phase 01 — Discovery & Problem Definition

Where do founders lose control of their cap table?

Before sketching anything, I spent the first week in research mode: four founder interviews, two sessions with startup attorneys, and a deep audit of where equity events actually fail in practice. The findings reframed the problem completely.

01
User Research — Founder Interviews & Legal Stakeholder Sessions
I interviewed four Series A/B founders and two startup attorneys who regularly handle equity events — option grants, SAFE conversions, secondary transactions, and pro-rata rights exercises. The most consistent finding: founders understood their equity structure at closing but had no reliable way to track it between events. The cap table was always "correct as of last time we checked."
VERBATIM RESEARCH FINDINGS · DIRECT QUOTES
"I have no idea how many shares are authorized right now. My lawyer knows. My CFO knows. I don't." — Founder, Series B, SaaS
"Every time we do a round, we're reconciling three versions of the cap table. One in Excel, one in the 409A tool, one in DocuSign." — Co-founder, Fintech
"I got hit with a compliance issue on a secondary because I didn't know an investor had transferred shares. No one told me." — Founder, Marketplace
"Option grants are the worst. Someone gets the wrong strike price because the 409A wasn't updated before we issued." — General Counsel, 60-person startup
"I want to know: if I close this SAFE today, what does my cap table look like after dilution?" — Founder, pre-Series A

CORE TENSION Accuracy lives in documents, not in any single interface
SECOND TENSION Two users, one event · Founder approves, lawyer executes — no shared visibility
THIRD TENSION AI opportunity · Founders don't know what they don't know — proactive compliance surfacing is the unlock
KEY INSIGHT
The cap table wasn't wrong because the data was lost. It was wrong because equity events were processed in siloed tools — DocuSign, 409A platforms, spreadsheets — with no single system tracking the chain of cause and effect. The design problem was integration and sequence, not data entry.
02
Problem Statement & Design Principles
From synthesis, I defined the core problem as a sequencing and visibility failure, not a data problem. Every design decision was evaluated against three principles that came directly from research, not from product assumptions.
DESIGN PRINCIPLES · PRIORITIZED
PRINCIPLEIN PRACTICEPRIORITY
Event as the unit of truth Every equity event — grant, conversion, transfer, exercise — is a first-class record with a complete audit trail. The cap table is a computed view, not the source of truth. Events drive it. Critical
Compliance must be proactive The system surfaces compliance risks before an event is executed, not after. A 409A that's 60 days stale before an option grant issues is a problem the system catches — not the founder or legal counsel. Critical
Shared surface, dual persona Founders and legal counsel must operate in the same event record without separate interfaces. One workflow, progressive disclosure of role-specific fields and actions. High
AI explains dilution, doesn't hide it AI-generated dilution modeling shows the math, not just the answer. Founders who understand their post-money cap table make better decisions. Opacity breeds distrust. High
03
Persona Mapping — Founders vs. Legal Counsel
These two personas share the same equity events but arrive at them with completely different mental models, risk tolerances, and decision frameworks. Any system that doesn't honor both will fail both.
PERSONA CONTRAST MAP
NEEDFOUNDER / CEOLEGAL COUNSEL
Primary question"What does my cap table look like after this event closes?""Is every document correctly executed and properly filed?"
Time horizonCurrent round, next 12 months of dilutionCurrent event, regulatory deadline, audit trail
Key anxietyUnexpected dilution, investor surprises, 409A errorsMissing signatures, stale valuations, SEC filing deadlines
Decision typeApprove, model scenarios, communicate to boardDraft, execute, file, verify, archive
AI usefulnessPost-event dilution previews, investor notification draftsCompliance flag detection, document completeness checks
Audit needBoard-ready cap table at any point in timeFull legal audit trail with timestamps and signatories
DESIGN DECISION
The shared surface is the event detail panel — both personas see the same event record with the same timeline. Role-specific depth (compliance flags for legal, dilution modeling for founders) is surfaced contextually in the AI insight card based on user role, not a mode switch. This preserves one mental model while serving two workflows.
Phase 02 — User Flow Mapping

Mapping the critical equity paths

I mapped three critical workflows: the full option grant lifecycle (the most common and error-prone event type), how SAFE conversions ripple through the cap table, and what happens when a compliance issue blocks an in-progress event.

04
Primary Flow — Option Grant Lifecycle
Option grants are the highest-frequency equity event for any startup with employees. They're also the source of the most common compliance failures: wrong strike price from a stale 409A, missing board approval, or incorrect vesting schedule. The flow had to make compliance checkpoints visible and non-bypassable without making them feel like bureaucratic friction.
FLOW DIAGRAM · OPTION GRANT · HAPPY PATH
Founder initiates grantEmployee + share count
→
AI checks 409A freshnessAuto-validates strike price
→
Board approval gateRequired pre-execution
→
Legal drafts grant agreementDocuSign auto-triggered
→
Cap table updatedAI previews dilution
EXCEPTION PATH · STALE 409A BLOCK
409A age > 60 daysOr recent material event
→
Event flagged — blocked⚠ compliance hold
→
AI surfaces two pathsOrder new 409A or proceed with risk note
→
Founder decides + logsDecision recorded for audit
→
Event re-queued or unblockedCompliance note attached
05
Equity Event State Machine
Every equity event moves through a defined set of states. I mapped the state machine before designing a single component — this is the pattern that prevents the common SaaS failure where status labels are invented screen-by-screen and become meaningless over time.
STATE MACHINE · EQUITY EVENT LIFECYCLE
STATETRIGGERVISUAL ENCODINGNEXT STATES
DraftFounder initiates eventBlue pill · No urgency signalIn review, Compliance hold
In reviewLegal counsel has claimed the eventAmber pill · Age clock startsPending execution, Compliance hold
Compliance holdAI detects an issue (stale 409A, missing approval, etc.)Red pill + red age text + ⚠In review, Cancelled
Pending executionAll documents drafted, awaiting signaturesPurple pill · Deadline visibleExecuted, Compliance hold
ExecutedAll signatures received, cap table updatedGreen pill · SLA clock stopsReopened (exception only)
WHY THIS MATTERS
A consistent state machine means every status pill, age indicator, and compliance flag follows the same encoding logic. Founders and legal counsel build a shared vocabulary once — they don't re-learn it for every event type. Consistency is the difference between a designed system and a patchwork of feature screens.
Phase 03 — Information Architecture

One surface, two mental models

The navigation had to work for both a founder checking on a pending SAFE conversion before a board meeting and a startup attorney verifying that option grants are fully executed. I mapped the full IA before touching visual design.

06
Navigation Architecture — Sidebar Structure
I designed around a workspace-first model: top-level navigation items represent the founder's decision contexts, not feature categories. Equity Events is the primary entry point. Cap Table is the output view. Compliance is the early-warning system. Modeling is where founders explore scenarios before committing.
IA MAP · SIDEBAR HIERARCHY
NAV ITEMPRIMARY USERBADGE LOGICDISCLOSURE LEVEL
Equity EventsBothCount of in-progress events; red if any on compliance holdFull — always visible
Cap TableFounderAmber if not up-to-date (pending event uncommitted)Full — computed view
StakeholdersFounder / LegalNone standardFull
DocumentsLegalCount of pending signaturesFull
ComplianceLegal / FounderRed if any open compliance itemsProgressive — summary by default
ModelingFounderNone — exploratory toolProgressive — scenario detail on demand
07
Page-Level Hierarchy — The Equity Events Queue
I established four explicit information zones for the event queue, each with a distinct visual weight. The failure mode in complex B2B tools is everything being rendered at equal weight — which means nothing is actually actionable on first scan.
VISUAL HIERARCHY MAP · EVENT QUEUE
TIERZONEVISUAL TREATMENTRATIONALE
T1 · PrimaryKPI strip (Active events, Compliance holds, Pending signatures, Cap table lag)Largest type, full-width, always above foldSituational awareness before triage — founders need global portfolio context before they drill into any single event
T2 · SecondaryEvent list with compliance dots + age + status pillsPriority dot · Event name · Status pill · Age coloringTriage surface — the primary work zone. Items compete only with other events, not chrome
T3 · TertiaryTab filters (All, My events, Compliance hold, Pending signature)Mono labels, understated unless activeNarrowing tools — available but must not compete with the event list itself
T4 · On demandEvent detail panel (AI insight, compliance status, fields, timeline)Slides in over list — detail replaces scanningProgressive disclosure — revealed only when the founder has committed to a specific event
DESIGN DECISION — SLIDE-OUT VS. DRILL-IN
Side panel over separate page: founders frequently compare two or three in-progress events when preparing for a board meeting. A slide panel lets them open an event, review the AI dilution preview, close it, and open the next — without stack management. Drill-in navigation would add 2–3 clicks to a workflow that recurs every funding cycle.
Phase 04 — Component Design & System Thinking

The components that carry compliance weight

In a system where an incorrectly processed option grant can create legal liability, every component decision carries real stakes. I approach these with the same rigor I apply to any safety-critical UI: redundant encoding, explicit human decision points, and reasoning visible before action.

08
Compliance Signal — Iteration History
The compliance indicator is the most important component in the system. It's scanned dozens of times per day, has to communicate risk in peripheral vision, and must never become background noise. I ran through five iterations before landing on the final pattern.
ITERATION LOG · COMPLIANCE SIGNAL
V1: Status label in a column (HOLD / OK / PENDING) · FAILED — text requires foveal reading, impossible to scan 20 events in motion
V2: Color-coded row backgrounds · FAILED — color bleeding made the list feel uniformly alarming, defeating the signal hierarchy
V3: Compliance column with icon only (⚠ / ✓) · PARTIAL — faster but lost the priority dimension; all warnings looked equal
V4: Priority dot (6px colored circle) · PARTIAL — faster to scan but no severity dimension and no age context
V5: Priority dot + age coloring (red text past 48h threshold for compliance holds) · WINNER — two signals, neither requires focus

Final pattern: DOT for categorical risk level + AGE CELL color for time pressure + PILL for event state
Three signals. Three dimensions. None redundant. All scannable without focus.
09
AI Insight Card — Compliance-First Trust Architecture
The AI insight card in this system carries legal weight. An AI recommendation acted upon without review could result in a compliance violation on an equity issuance. I applied the same trust architecture I use across all AI-assisted financial tools: surface the reasoning before the recommendation, require an explicit human decision before execution.
AI INSIGHT COMPONENT SPEC
ELEMENTFUNCTIONDESIGN RATIONALE
Insight label "✦ Assistant"Source attributionFounders must always know when output is AI-generated vs. system-derived. The ✦ glyph is the AI marker system-wide. No ambiguity about machine vs. human judgment.
Compliance finding proseReasoning, not just flagA founder who understands why a grant is blocked makes a better decision about how to unblock it. "409A is 67 days old — grants issued today may not survive a 409A audit" is more actionable than "compliance hold."
Dilution preview panelQuantified outcome before executionFounders routinely approve equity events without knowing post-event dilution. The AI preview makes the math unavoidable — not intrusive, but present before every execution action.
One-click action buttonsReduce friction to zero for recommended next stepsButtons labeled with the specific action ("Order new 409A," "Request board approval," "Send for signature") — not "OK" or "Proceed." Specificity prevents accidental actions in high-stakes contexts.
No auto-executeHuman always in the loopEquity events are irreversible once executed. No AI action executes without an explicit founder or legal confirmation step. The system makes the path clear; the human walks it.
10
Compliance Health Bar — Communicating Risk Without Alarm
Compliance status is the highest-stakes metric in the system. An interface that renders everything as red stops being useful — founders tune out. I designed a three-state system calibrated to drive action at the right moment, not constant vigilance.
COMPLIANCE ENCODING · THREE-STATE SYSTEM
CLEAR · ALL REQUIREMENTS MET
No action needed. Event can proceed to execution.
MONITOR · ADVISORY — NOT BLOCKING
AI surfaces a note. Founder is informed, event can still proceed with acknowledgment.
HOLD · EVENT BLOCKED — ACTION REQUIRED
Red age text in list + red bar + AI resolution path. All three signals fire simultaneously.
CALIBRATION PRINCIPLE
───────────────────
Green = proceed
Amber = acknowledge
Red = stop and resolve

If every event is red,
red means nothing.
SIGNAL MUST BE RARE TO BE ACTIONABLE
11
Dilution Modeling — Making the Math Unavoidable
Every equity event changes ownership percentages. The design challenge: surface post-event dilution so that founders can't approve an event without seeing it, while not making the math so prominent that it slows down routine grants. I solved this by making dilution a contextual layer in the AI insight card, not a separate screen or modal.
DILUTION PREVIEW · INLINE COMPONENT SPEC
ELEMENTSHOWN WHENDATA SOURCEDESIGN NOTE
Pre-event ownership tableAlways, in event detailCurrent cap table snapshotThree rows: Founders, Employees (ESOP pool), Investors. Simplified intentionally — board-level granularity on demand.
Post-event previewOn any event that modifies share countAI computed against current cap tableColor-coded delta: green for increases (employee grants), red for founder dilution. Unavoidable, not alarming.
Dilution explanation proseWhenever founder dilution exceeds 0.5%AI-generated, human-readable"This grant dilutes your common shares by 0.4%. Your ownership moves from 62.3% to 61.9%." No jargon.
What-if scenario linkAlways in dilution preview footerLinks to Modeling moduleFounders who want to explore alternatives can — without leaving the event or losing context.
Phase 05 — Working Interactive Prototype

The full working interface

This is a production-fidelity prototype of the Equity Events queue. Click any event row to open the detail panel — the AI compliance insight, compliance health bar, event details, and activity timeline are all live and interactive. The sidebar lets you switch between modules to see the full information architecture in action.

Equity Platform · Equity Events · app.equityplatform.com/events
EquityStack
Workspace
Risk & Modeling
⚙  Settings

Equity Events

Active equity events · Series A portfolio

Updated just now
Active events
8
↑ 3 from last month
Compliance holds
2
Action required
Pending signatures
3
Awaiting execution
Cap table lag
0
All events committed
All events
My events
Compliance hold 2
Pending signature 3
Event / company
Type
Status
Age
Owner
Option grant — Engineering batch Q2
#EQ-2240 · 14 employees · 142,000 shares · Seed Robotics Inc.
Option Grant
Compliance Hold
9d ⚠
AK
›
SAFE conversion — Accel participation right
#EQ-2231 · $2.1M SAFE · Pro-rata clause · Seed Robotics Inc.
SAFE Conversion
Compliance Hold
12d ⚠
JW
›
Secondary transfer — Chen to Greenfield Capital
#EQ-2244 · 40,000 shares common · RoFR waiver required
Secondary Transfer
Pending Execution
5d
LR
›
ISO grant — VP of Sales (new hire)
#EQ-2247 · 80,000 ISOs · 4yr/1yr cliff · Seed Robotics Inc.
Option Grant
In Review
3d
AK
›
Board consent — Q1 option grants ratification
#EQ-2238 · Board written consent · 3 directors required
Board Consent
Pending Execution
4d
LR
›
ESOP pool increase — Board approval
#EQ-2249 · +500,000 authorized shares · 10% pool target
Authorization
Draft
1d
AK
›
Series A closing — Founders Fund lead
#EQ-2218 · $12M · 18% post-money · Fully executed
Financing Round
Executed
22d
JW
›
Event Detail
—
✕
Phase 06 — Design Outcomes & Reflection

What this design actually changes

The most important outcome of this design sprint wasn't the prototype. It was the reframing: equity event management isn't a data entry problem, it's a sequencing and visibility problem. The design decisions below follow directly from that reframe.

12
Key Design Decisions — And What They Prevent
Every design decision in this system was made in response to a specific failure mode I found in research. This table maps decisions to the outcomes they're designed to prevent.
DECISION → OUTCOME MAP
DECISIONFAILURE MODE PREVENTEDDESIGN MECHANISM
Event as unit of truthCap table drift — multiple "correct" versions in different toolsThe cap table is computed from events. Events are immutable once executed. No manual edits to the cap table surface.
Proactive 409A check before option grantsOption grants issued with wrong strike price, failing 409A auditAI validates 409A age and material events before every option grant. Grant is blocked, not just warned, if 409A is stale.
Shared event record, role-based disclosureFounder approves event that legal counsel hasn't verified; miscommunication on document statusBoth personas see the same event record. AI insight card surfaces role-appropriate next actions without mode switching.
Dilution preview before executionFounder approves a grant without knowing post-event ownership impactDilution preview is embedded in the AI insight card — always visible before the execution button is reachable.
Compliance hold blocks execution (not just warns)Events executed despite known compliance issues because the warning was ignorableCompliance hold state prevents execution actions from rendering. The path to unblock is explicit and logged.
13
What I'd Do Differently — And What I Learned
Three weeks in, I realized I'd under-invested in the employee-facing side of this system. Founders and legal counsel are two of the three core personas — but employees receiving option grants are a third, with completely different needs (grant status, vesting progress, exercise window) that the current event-centric model doesn't serve well. A follow-on sprint would focus on an employee grant dashboard that surfaces the same event data from a recipient perspective.
BIGGEST LEARNING
Complex equity products almost always start with the institutional persona — the founder, the attorney, the fund administrator. The employee persona is an afterthought. But employees are the reason option grants exist. A system that doesn't serve them clearly leaves real value — retention, engagement, equity literacy — on the table. The best equity platform is one that the recipient can actually understand.