Jerry Lee | Principal Product Designer
[UPDATED] 08.2026
Designing Complex Systems
People Can Trust.
I'm a principal-level product designer who turns ambiguous, technically complex problems into clear workflows and scalable product systems. I work hands-on across research, interaction design, system architecture, and implementation, especially in enterprise software, responsible AI, and products where trust matters.
Where I Create Value
Complex products shaped through systems thinking, responsible technology, and hands-on delivery.
Domain 01
Responsible AI + Intelligent Products
AI-assisted and agentic experiences that make system behavior visible, preserve human judgment, and earn user trust.
Responsible AIHuman-in-the-loopAgentic WorkflowsDecision Support
Domain 02
Consumer + Community
Customer-facing products where identity, discovery, creation, and community participation shape the experience.
How I designed and built a connected commerce platform that carries a custom product from discovery and live preview through payment, approval, engraving, fulfillment, and shipping.
Designing one connected product system for custom merchandise—from customer intent and live preview through approval, laser production, and fulfillment.
Sole designer + developer20+ user conversations5 user roles3 service integrations8-week delivery
KPop-Swag.com sells personalized, laser-engraved merchandise. A conventional store could list products and accept payment, but customization created a longer chain of uncertainty: customers had to trust the preview, operators had to receive production-ready instructions, and staff had to move the same order through approval, engraving, shipping, and communication without losing context.
My role: I was the full-stack product designer and developer. I conducted research, defined the product model, designed the customer and operational experiences, built the design system and application, integrated external services, and carried the product through testing and deployment.
I treated the experience as a product lifecycle rather than a collection of pages. Each stage contributes information to the same order and design record, so customer intent remains available when the work reaches approval and production.
01Discover
Products, materials, prices, and customization options.
02Design
Artwork, text, side, placement, scale, and orientation.
03Preview
Product geometry, engraving simulation, and protected regions.
04Approve
Saved design state and a shared visual reference.
05Produce
Operator-ready artwork, specifications, and job status.
06Fulfill
Payment, label, tracking, and customer communication.
Research changed the product priorities
More than 20 conversations with K-pop fans at live events helped separate assumed e-commerce priorities from the risks customers actually noticed. I translated those patterns directly into interaction and information requirements.
“What will mine actually look like?”
Customization confidence mattered before checkout. The response was an editable Studio, product-specific boundaries, and a preview that preserves the approved composition.
“How much will shipping add?”
Total cost visibility mattered more than shaving another step from checkout. Shipping estimates and pricing clarity were moved earlier in the journey.
“Can I buy without another account?”
Registration could interrupt a first purchase. Guest checkout became the default low-friction path, with account benefits introduced after commitment.
Four decisions that shaped the system
The highest-leverage design work happened where customer expectations, production reality, operational control, and implementation constraints met.
Make customization trustworthy
Problem
A text field or static mockup could not communicate placement, side, scale, orientation, or material behavior.
Decision
I built a product-aware Studio and interactive 3D preview backed by the same saved render contract.
Result
The customer, approver, and operator reference the same composition instead of reconstructing intent.
Separate work by responsibility
Problem
A universal admin interface exposed irrelevant complexity and increased the risk of sensitive actions.
Decision
I designed focused workspaces for customers, staff, laser operators, and superadmins, supported by route-level permissions.
Result
Each role sees the information and actions required for its next decision without carrying the entire system.
Treat fulfillment as product UX
Problem
Payment, production, shipping, and communication could easily fragment into separate tools and status models.
Decision
I designed the order as a shared stateful record, then connected job queues, approval, labels, tracking, and notifications to it.
Result
Staff can move an order forward without re-entering specifications or losing the customer and design context.
Build consistency into delivery
Problem
An eight-week build could accumulate inconsistent forms, states, validation, and accessibility behavior.
Decision
I created reusable components and behavior contracts while building features, then used the same patterns across commerce and operations.
Result
New workflows inherit established interaction, validation, focus, and visual rules instead of starting from scratch.
Role-specific experiences, shared product state
The platform serves five permission levels, but it does not force them into one interface. Navigation density, available actions, and information hierarchy change with the job being performed.
Customer + guest
Browse, customize, preview, understand cost, and complete a purchase with or without creating an account.
Laser operator
See prioritized jobs with the product, artwork, side, quantity, production notes, and status controls in one working view.
Staff
Manage orders, review customization, generate labels, communicate with customers, and resolve fulfillment exceptions.
Superadmin
Control roles, approve sensitive promotions, manage service configuration, and distinguish test from live environments.
System
Preserve shared state, validate transitions, timestamp operational events, and trigger the appropriate notifications.
Design system
Keep states, controls, validation, accessibility, and responsive behavior consistent across every workspace.
Operational workflows designed as first-class experiences
The work after checkout determines whether a custom product can be produced accurately and delivered efficiently. I gave operational tools the same interaction-design attention as the storefront.
Production queue
Operators receive complete, prioritized job specifications with direct start, hold, and completion actions.
Order workspace
Staff can inspect customer, payment, design, production, shipping, and communication context without changing systems.
Shipping workflow
EasyPost rate selection, label generation, tracking persistence, and customer notification stay attached to the order.
Promotion governance
Coupon rules support product restrictions, BOGO behavior, expiration, and approval when business oversight is required.
Configuration safety
Sensitive service settings use validation, masked values, environment indicators, permissions, and re-authentication.
Failure recovery
Validation and status feedback make incomplete data, integration failures, and blocked transitions visible before they become fulfillment errors.
Quality was part of the architecture
Because I designed and implemented the platform, interaction rules could become system rules rather than handoff notes. Accessibility, validation, permissions, and security controls were defined alongside each workflow.
Accessible interaction patterns
Keyboard operation, visible focus, modal focus management, semantic labels, live status messaging, contrast, and reduced-motion behavior are built into reusable components.
The result is a production-deployed platform that connects customer-facing commerce with the operational system required to manufacture and fulfill personalized products.
8
Weeks to production deployment
5
Role-specific experiences
50+
Reusable components
3
External service integrations
20+
Customer conversations
1
Connected order lifecycle
Customer intent stays intact
The approved design, product geometry, transforms, and constraints travel together from Studio into production.
Operational complexity stays focused
Each role receives the context and controls needed for its part of the lifecycle.
The system can grow coherently
Shared components, contracts, permissions, and state models provide a foundation for additional products and workflows.
What I learned
Design the complete business operation
For custom commerce, the experience continues after payment. Production accuracy, exception handling, and communication are part of the customer promise.
Shared state is a UX decision
A consistent record across preview, approval, production, and fulfillment prevents users from repeatedly translating the same intent between tools.
Hands-on implementation sharpens product judgment
Owning the data model and application behavior exposed edge cases early and allowed design decisions to become durable system behavior.
What this demonstrates: I can frame an ambiguous product opportunity, validate it with users, design the customer and operational systems together, and remain hands-on through architecture, implementation, testing, and production delivery.
Enterprise strategy • Change leadership
Subscription Management
How I led a high-stakes product concept through a major reorganization, using research to reset a fragmented renewals vision and give leadership a clearer basis for investment.
Defining a product Workday was considering entering
Workday was evaluating a subscription-management opportunity while its own renewal teams still assembled the process across Salesforce, quotation tools, spreadsheets, and Word documents. The opportunity was larger than improving an individual screen: it required a clearer operating model for assessing accounts, modeling changes, generating quotes, and preparing contracts.
The stage-gate objective was to reduce strategic uncertainty rather than specify production-ready UI. The team needed enough research, workflow definition, and product fidelity for executive leadership to understand the opportunity and decide whether it warranted investment.
Lead designerdrove concept direction, story, and mockups for the pitch
3 month cadenceresearch, narrative, and concept validation under stage gate
3 day rethinkrebuilt the final story and clickable concept under deadline
Funding outcomeinternal feedback identified the concept as instrumental to the investment decision
My role
I led the design direction and helped shape the story the product team brought to executive leadership. I partnered on research framing, defined the primary persona and journey with the researcher, proposed the core workflow, and built the interactive concept used in the funding pitch.
Concept direction
Led brainstorming, translated early ambiguity into a usable story, and pushed the product narrative toward what users actually needed.
Research synthesis
Worked with the researcher to define personas, journey artifacts, and the points of friction that mattered most in the renewals lifecycle.
Executive storytelling
Built the mockups and flow required to make an emerging product legible and compelling to leadership.
As the business case and leadership input changed, I monitored whether the concept still reflected the research. When the work became constrained by assumptions that no longer served the future workflow, I initiated a reset and rebuilt the story around the evidence.
The renewals workflow was fragmented, manual, and hard to trust
Before the concept work, subscription management was spread across multiple systems and too much of the job depended on manual intervention. Renewal specialists moved across Salesforce, quoting tools, spreadsheets, and Word documents just to create and validate a quote. The process was slow, error prone, and cognitively expensive.
No unified product
Workday did not have a true subscriptions solution, so users were stitching together a workflow out of adjacent tools.
Manual calculations
Pricing logic, adjustments, and contract edits required too much copying, checking, and cleanup.
Too much task switching
Users had to move between systems just to gather context, configure the renewal, and prepare customer-facing materials.
Research and framing
Because this was a new market segment for Workday, recruiting external research participants was difficult. We moved in-house and used Workday’s own subscription operations as a proxy user base so we could learn quickly from a Sales Ops Manager, a Subscription Manager, and a Renewal Specialist.
That research gave us enough grounding to define a primary persona, map the quote-to-renewal journey, and identify where the biggest workflow breakdowns were happening.
Persona
We centered the work around a subscription manager who needed better visibility, faster modeling, and less administrative drag.
Journey mapping
The quote-to-renewal lifecycle made it obvious that the problem was not one screen. It was an end-to-end operational flow.
Vision story
The concept started from an account page, then followed the jobs users actually needed to do: assess, amend, model, and generate a quote.
Resetting the concept three days before executive review
Successive changes to the business case had pulled the concept toward dense tables, excessive navigation, and current-platform constraints. The proposed future state was reproducing the fragmentation uncovered in research instead of resolving it.
Three days before the executive review, I recommended a reset. Working with the researcher, I returned to the journey evidence, simplified the product story, and rebuilt the clickable concept around the future workflow users needed.
Signal
Interaction density was rising while the concept explained the opportunity less clearly.
Decision
I stopped optimizing for current platform limitations and reframed the experience around the intended future-state workflow.
Outcome
The rebuilt concept gave leadership a simpler account-to-renewal story and made the product investment easier to evaluate.
The final concept turned renewals into a clearer, more connected operating model
The reset concept started from a renewals-focused dashboard and then drilled into a more flexible account detail view and a new subscription modeling workflow. The core move was to make the work legible. Instead of forcing users to reconstruct status and intent from many disconnected legacy products, we gave them a clearer view of account health, subscription status, opportunity signals, and the actions needed to move forward.
Renewals dashboard
A high-level portfolio view with actionable KPIs and drillable detail so managers could start from the health of the business, not from a blank process.
Account detail
Customizable views, clearer status, and a product-family structure that made discovery and decision making easier.
Subscription builder
A visual modeler that let users build from an existing subscription, automate pricing logic, and explore what-if scenarios over time.
The visual builder mattered because research showed that time-based subscriptions become hard to reason about when everything is flattened into start and end date columns. By using a timeline model and pairing it with an editable data view, the concept let users reason both visually and numerically without bouncing across systems.
Funding decision and strategic outcome
We completed the rethink and clickable concept in three days. The final walkthrough made the opportunity legible as an end-to-end operating model rather than a collection of features. Internal leadership feedback identified the mockup as a leading contributor to securing investment for the concept.
Leadership clarity
The narrative followed the renewal manager’s work instead of mirroring the existing system landscape.
Investment support
The concept translated a broad market opportunity into a coherent product direction leadership could assess.
Target operating value
The proposed workflow targeted multi-day reductions in renewal processing and fewer pricing errors through automated calculations.
What this demonstrates
I can use design to reduce strategic uncertainty before a product exists: grounding an emerging opportunity in research, detecting when the concept has drifted from the evidence, and giving decision-makers enough product fidelity to evaluate the investment.
Research leadership
I used limited but focused research to ground a new market concept quickly and keep the story anchored to actual workflow pain.
Strategic design judgment
I pushed beyond a weaker, overly constrained direction and reframed the concept around the future product reality users would actually need.
Executive storytelling
The final deliverable did more than look polished. It made a complex opportunity understandable enough to support a funding decision.
The value of the concept was its ability to clarify what the company could build, why the opportunity mattered, and how a coherent user experience could make the future operating model tangible.
Full-stack product design • Design systems • Manufacturing UX
Designing a Trustworthy 3D Engraving Preview
How I translated laser-operation knowledge into a stable preview system that preserves artwork, product geometry, orientation, and manufacturing constraints from design through approval.
Customers were approving an irreversible manufacturing result on a product they could not touch or inspect under changing light. A flat proof could confirm spelling, but not material response, orientation, side, or protected hardware regions.
I framed the product requirements around five approval questions: Is the artwork the right size, on the correct side, upright, legible on this material, and clear of areas that cannot be engraved?
User risk
A visually attractive preview that changes between Studio and approval is worse than a plain proof. It creates false confidence at the moment of commitment.
Operational risk
Wrong scale, side, rotation, or keep-out behavior can turn a software inconsistency into wasted material, manual clarification, and a production error.
The design principle
Preserve the customer's design intent across every representation. The editable canvas, saved draft, 3D modal, approval page, and production record share the same product identity, geometry, and coordinate contract.
A deliberate boundary: design intent vs machine calibration
The experience separates decisions customers can evaluate from controls that require material and machine expertise. This keeps the preview useful without presenting simulation as a production recipe.
Customer intent: placement, scale, crop, rotation, side, relative contrast, and protected regions.Operator calibration: power, speed, frequency, pulse, focus, hatch, and material testing.
UX boundary
Customers control the result they can understand and verify. Operators retain the material- and machine-specific controls required to reproduce it.
Turning shop-floor knowledge into preview behavior
Laser-operation experience became a set of interface and rendering rules, while variables that require physical testing remained in the operator workflow.
Observed in production
The mark's perceived brightness changes with viewing angle.
Dark anodized colors usually create stronger apparent contrast than light finishes.
Fine detail depends on focus, raster strategy, source art, and material response.
A protected band or hardware area is stored as a product constraint rather than left to user memory.
Translated into product behavior
Separate the material surface from the engraving overlay.
Map source luminance into relative engraving strength.
Let Three.js lighting communicate material and angle.
Encode no-engrave geometry into the product definition and saved draft.
Fidelity boundary
I mapped source luminance to relative engraving opacity, preserving contrast, exposure, crop, inversion, transparency, and text shade in the saved design. The browser communicates tonal hierarchy; it does not claim that a gray value equals a fixed laser setting.
From recurring failures to a stable system
The visible defects were different, but they exposed three structural problems. I traced each failure across Studio, saved drafts, and approval, then replaced the local fix with a shared system rule.
The visible bugs were symptoms of missing shared rules for product identity, transforms, and persisted constraints.
01
Page defaults → one source of product truth
Observed lapse
A luggage-tag design could appear correctly in Studio but shrink or inherit business-card dimensions in approval.
Root cause
I found that each module reconstructed product identity, dimensions, and rendering behavior from its own defaults.
Design decision
I defined a versioned render contract containing stable product identity, exact geometry, side state, transforms, and constraints. Both previews consume that contract and the same layer renderer.
Result
Studio and approval reproduce the same saved design; incomplete product state now produces an explicit error instead of a plausible fallback.
02
Independent transforms → one coordinate model
Observed lapse
Scale, crop, rotation, and back-side orientation could change as artwork moved between Canvas, SVG, and Three.js.
Root cause
I isolated transforms at each boundary and found that multiple layers were rotating or mirroring the same design without a defined owner.
Design decision
I kept textures in native coordinates, mirrored in display space, converted only at named boundaries, and rotated the completed 3D product once.
Result
Artwork retains its placement and readable orientation across sides, product proportions, and display rotations.
03
Transient state → one durable handoff
Observed lapse
Protected regions could disappear after saving, while approval could open before the latest edits reached the draft.
Root cause
I traced the gap to temporary browser geometry and navigation that operated independently from persistence.
Design decision
I serialized keep-out geometry as SVG data, rebuilt it downstream, and made Add to Cart await a validated save before resolving the approval draft.
Result
Approval opens the latest committed design with its manufacturing constraints intact.
One contract across the workflow
The saved design became the source of truth. Product geometry, side-specific state, transforms, and manufacturing constraints now travel together from Studio through approval.
The same validated contract and rendering engine resolve different SVG-driven product templates without product-specific renderer forks.
Contract definition
Stable product IDs, exact dimensions, viewBoxes, side state, display rotation, layer transforms, material choices, and keep-out geometry.
Shared renderer
Studio and approval use the same layer composition rules instead of independently rebuilding crop, tone, text, and image placement.
Validation guard
A missing product or invalid contract blocks approval instead of silently substituting business-card geometry.
One engine, many product templates
Product variation is separated from renderer behavior. Cards, luggage tags, and charms use the same authoring, save, texture, and approval pipeline; each product contributes a declarative package centered on SVG geometry.
Card
Tag
Charm
System decision
Configuration instead of renderer forks
Every template inherits the same transform rules, front/back behavior, texture generation, approval flow, and performance lifecycle.
Template supplies
SVG silhouette and holes, physical dimensions, viewBox, display rotation, sides, material options, and optional no-engrave geometry.
Platform supplies
Canvas composition, contract validation, coordinate conversion, 3D extrusion, material rendering, interaction, saving, approval, and cleanup.
Why this matters
Adding a product becomes configuration work rather than feature development. The same constraints that fixed luggage-tag drift now make the catalog easier to extend without reintroducing business-card assumptions.
Three decisions that made the system stable
The hardest work sat between interaction design and implementation: deciding where transformations belong, how physical constraints persist, and when rendering work is actually necessary.
Each space owns one responsibility; conversions happen only at named boundaries.
01 — Give every coordinate space one job
I documented the source, template, display, and Three.js spaces, then assigned rotation and mirroring to named boundaries. This kept front/back artwork readable without stretching the texture.
02 — Store constraints as product geometry
I represented holes and keep-out zones as serializable SVG geometry. The same shape suppresses engraving in Studio, the saved draft, approval, and downstream output.
03 — Treat performance as interaction design
I delayed valid saves until template geometry resolved, initialized textures once, rendered WebGL on demand, and disposed observers with the modal. High-DPI devices do only the work required for the current interaction.
Guardrails at the points of failure
Validation now sits where state crosses a boundary: template to draft, draft to approval, and modal to device. Incomplete data is stopped before it becomes a convincing but incorrect preview.
BOUNDARY
IMPLEMENTED GUARD
USER-FACING BEHAVIOR
Template → draft
Stable product IDs and exact side dimensions are required by the render contract.
Add to Cart awaits the draft save and resolves the draft ID after persistence succeeds.
Approval opens from the latest committed design.
SVG → saved contract
SVG primitives and viewBoxes are serialized and rebuilt in approval.
Protected regions remain visible and unengraved across modules.
Studio → approval
Shared layer composition and one versioned contract drive Studio and approval.
Crop, scale, rotation, side, and tonal adjustments remain consistent.
Modal → device
Textures initialize once, frames render on demand, and renderers and observers are disposed with the modal.
The preview remains responsive on high-DPI and slower devices.
What changed in the product
The preview became one product system rather than a set of page-specific effects. Customer intent, product geometry, and production constraints now remain connected from authoring through approval.
1
Versioned render contract
2
Sides preserved independently
1×
Initial texture generation
For customers
A more coherent approval experience with clearer expectations about placement, orientation, relative contrast, and protected regions.
For operations
A saved design that carries the product geometry and constraints needed to interpret the order consistently.
For engineering
Explicit interfaces, stable IDs, versioned geometry, deterministic transforms, and errors that surface missing data instead of hiding it.
For the product
A scalable template system for adding products through SVG geometry and metadata without re-solving dimensions, side behavior, or preview synchronization.
Full-stack ownership, carried through implementation
My role connected the customer mental model to the data contract, rendering engine, failure states, performance lifecycle, and manufacturing handoff.
Framed the experience
Defined which decisions customers could evaluate, which remained operator-owned, and what the preview needed to communicate before approval.
Designed the system
Defined the versioned render contract, product template package, coordinate boundaries, side model, constraint geometry, and explicit error states.
Tested the same drafts across products, sides, Studio, and approval, then traced mismatches back through saved state and rendering boundaries.
Result
The preview operates as one product system across Studio and approval. New templates inherit the same rules, customer intent remains stable across modules, and production constraints are represented in the saved design.
Process design • AI workflows • Full-stack delivery
Designing a Responsible AI-Augmented Workflow
How I use AI to reduce mechanical overhead while strengthening design judgment, technical understanding, focus, and quality discipline.
8-week production cycle
Process design•AI workflows•Quality systems•Full-stack design
Designing the process behind AI-assisted delivery
Designing a Responsible AI-Augmented Workflow
A full-stack design case study in using AI for efficiency without outsourcing understanding, judgment, or accountability.
AI could generate work quickly, but speed alone did not make the output dependable. Ambiguous inputs created invented assumptions, repeated corrections, and code that appeared complete before it had been tested against the product.
I treated AI usage as a workflow-design problem. The goal was to define what AI could generate, what the system could verify automatically, and which decisions had to remain human.
Ambiguous input
Vague requests allowed the tool to invent APIs, states, and interaction rules that did not match the product.
Expensive rework
Corrections made only in code did not improve the source instructions, so the same mistakes returned in later components.
False completeness
Syntactically plausible output could still fail accessibility, security, business rules, or the intended user experience.
A controlled path from intent to production
The workflow makes design intent explicit before generation, rejects detectable errors early, and reserves contextual decisions for human review.
Responsible-use principle: AI can reduce repetitive effort, but I must understand, evaluate, and take responsibility for anything that influences the user experience or reaches production.
01 · HUMANSpecify
Define behavior, states, data contracts, tokens, accessibility, and edge cases.
02 · AIGenerate
Draft implementation, documentation, test cases, or research groupings from the specification.
03 · SYSTEMValidate
Run syntax, linting, accessibility, integration, and security checks.
04 · HUMANDecide
Review architecture, usability, business rules, edge cases, and production risk.
05 · PRODUCTShip
Commit the validated result and update the specification when the design changes.
When review uncovers a gap, the correction returns to the specification so the next output inherits the decision.
Source of truth
Specifications constrain generation
Markdown records component APIs, states, data contracts, accessibility requirements, tokens, and usage examples in a format both people and AI can follow.
Fast rejection
Automation catches mechanical errors
Syntax checks, linters, audits, and integration tests reject detectable defects before they consume human review time.
Accountability
Humans retain consequential decisions
Architecture, security-sensitive behavior, research interpretation, business rules, interaction quality, and final approval remain explicit human gates.
How failures shaped the workflow
The methodology developed through real lapses in functionality. Each incident changed the process so the same class of error became harder to repeat.
01
Prompt corrections → specification changes
Observed lapse
A generated component could look complete while inventing props, omitting states, or applying patterns inconsistently.
Root cause
I found that corrections were happening in the output while the original instructions remained ambiguous.
Design decision
I moved component behavior, states, accessibility, tokens, and edge cases into reusable Markdown specifications.
Result
Corrections became durable product rules that guided later components instead of one-time prompt fixes.
02
Manual checking → validation at every edit
Observed lapse
An AI-assisted bulk transformation across more than 25 PHP files corrupted syntax in multiple locations.
Root cause
The transformation was efficient, but validation still depended on remembering to inspect every changed file.
Design decision
I added a post-edit hook that runs php -l automatically on modified PHP files and blocks broken output from progressing.
Result
A failure became a permanent quality gate rather than another instruction to remember.
03
Generated synthesis → evidence with human interpretation
Observed lapse
Automated grouping could surface recurring phrases without understanding the concert context, user motivation, or business consequence.
Root cause
Pattern detection and interpretation were being treated as the same task.
Design decision
I separated AI-assisted transcription and clustering from human correction, contextual interpretation, persona definition, and product prioritization.
Result
AI accelerated the evidence review while research conclusions remained traceable to interviews and human judgment.
Application 01: accelerating research synthesis
For KPop-Swag.com, I conducted more than 20 interviews with fans and operators at live K-pop events. AI accelerated transcription, categorization, and cross-interview pattern discovery; I retained control of context, interpretation, and product decisions.
Human · Gather
Capture firsthand evidence
I planned and conducted the interviews, followed unexpected responses, and recorded the setting and behavioral context around each answer.
AI · Accelerate
Process the corpus
Transcription, initial categorization, repeated-theme detection, and draft persona structures reduced the mechanical synthesis workload.
Human · Decide
Interpret and apply
I corrected the source material, tested patterns against interview evidence, defined the personas, and connected findings to product behavior.
20+
Interviews synthesized
2–3 days
Synthesis cycle
4
Evidence-based personas
Research outcome
The synthesis produced four working personas—fan, laser operator, staff administrator, and superadministrator—used to distinguish customer, production, and administrative workflows in the product.
Application 02: scaling a documented component system
Building more than 50 components during an eight-week product cycle required repeatable contracts. The specification became the bridge between interaction design, generated implementation, validation, and documentation.
Implemented artifact: the autosave specification connected status messaging, persistence behavior, recovery, accessibility criteria, and implementation.
Specification
The state model preceded the interface
The document distinguishes saving, local persistence, server persistence, connection failure, and storage failure before defining animations or visual treatment.
Human refinement
Implementation remained accountable to the behavior
AI assisted with the module and documentation, while I defined the messages, timing, recovery paths, save destinations, and criteria for an accessible non-interruptive status update.
System effect
Once component contracts and patterns existed, later components inherited the same states, tokens, accessibility expectations, and documentation structure. AI increased throughput because the product rules were already explicit.
Quality gates matched to the type of risk
Automation handles deterministic checks. Human review concentrates on decisions that require context, product judgment, or accountability.
Implemented artifact: deterministic checks reject mechanical defects; contextual review remains an explicit human responsibility.
Boundary
Implemented guard
Human decision
Generated code → review
Syntax checks, linting, formatting, and static analysis.
Does the implementation express the intended interaction and remain maintainable?
Component → interface
ARIA checks, keyboard paths, focus behavior, states, and design-token validation.
Is the experience understandable, forgiving, and complete across edge cases?
Integration → application
Request and response contracts, database behavior, authentication flows, and dependency checks.
Does the integration respect domain rules, permissions, and failure recovery?
Application → production
Regression tests, security review, and explicit approval before commit or release.
Is the remaining risk understood and acceptable for users and operations?
Efficiency without surrendering the craft
The workflow assigns work by the kind of reasoning it requires, not simply by whether AI can produce an answer. Repetitive work is accelerated so more attention can go to framing, making, testing, and learning.
Use AI to accelerate
Patterned, reviewable work
Drafting from an approved component or API specification
Applying established tokens and repeated code patterns
Transcription, categorization, and candidate research themes
Documentation and test-case drafts
Mechanical transformations with automated verification
Keep human-owned
Contextual, consequential work
Problem framing, prioritization, and research interpretation
Interaction quality, mental models, and edge-case behavior
Architecture, permissions, and security-sensitive decisions
Business rules and operational consequences
Final approval and accountability for the shipped result
Responsible-use example: AI helped organize scenarios and implementation detail; the promotion meaning, edge cases, customer disclosure, and acceptance criteria remained human-owned.
Understanding remains required
I do not ship generated work I cannot explain, maintain, or evaluate in the context of the product.
Efficiency creates capacity for research, edge cases, interaction refinement, accessibility, and testing—not simply more output.
What the workflow delivered
The methodology was used while taking KPop-Swag.com from concept through production as a solo full-stack design and development effort.
8 weeks
Concept to production
50+
Documented components
20+
Interviews synthesized
4
Working personas
3
API integrations
Solo
Design through deployment
Speed came from reusable decisions
Specifications, component patterns, and automated gates reduced repeated explanation and made corrections persist across later work.
Quality came from explicit ownership
AI accelerated production tasks, while product intent, research meaning, architecture, risk, and final approval remained human responsibilities.
Full-stack process design, carried through delivery
My contribution was not access to an AI tool. It was designing and implementing a system that made AI-assisted work more focused, disciplined, inspectable, and accountable while keeping me responsible for the craft.
Framed the operating model
Separated generation from decision-making and defined where research, design, engineering, security, and release judgment belonged.
Specified the product
Created component contracts, interaction states, data expectations, accessibility requirements, design tokens, and edge-case rules.
Built the workflow
Connected specifications to generation, automated checks, post-edit hooks, integration testing, documentation, and release gates.
Validated the output
Reviewed generated work in the running product, corrected usability and architecture decisions, and fed those decisions back into the source specifications.
Result
AI became one component in a broader product-development system. It increased efficiency and focus without transferring ownership of customer experience, technical quality, learning, or production risk.
Maker platform • Trust systems • Domain-led design
LaserMark DB
Designed a machine-aware settings and verification product that helps laser users find credible starting points, preserve context, and turn successful tests into reusable community knowledge.
LaserMark DB is the trusted community-driven settings and verification layer for laser workflows. In plain language, it helps people answer a question that usually sits behind trial and error, wasted stock, and scattered notes: What is a credible starting point for this machine, this material, and this result?
I created LaserMark DB as a self-directed product, owning the design, product definition, requirements, and prototype/build decisions. The functional product is preparing for beta and includes machine-aware settings search, settings detail, photo verification, project repositories, Q&A, moderation, and export support.
Solo ownershipdesign, requirements, and prototype/build
3 core trust layerscontext, verification, and safety
1 key workflow betreduce setup friction with material prefill
Beta preparationfunctional workflows undergoing final validation
My role
This was a self-directed product project. I owned the research framing, product definition, UX, requirements gathering, information architecture, feature prioritization, and prototype/build. I also drew from direct experience as a user of both fiber and CO2 lasers, which helped me recognize where laser workflows break down in practice, not just in theory.
Product design
Defined the interaction model for settings discovery, evaluation, verification, and moderation.
Product definition
Shaped feature scope, workflow priorities, and the behavioral rules behind trust, evidence, and review.
Prototype and build
Used lightweight development to test ideas directly and tighten the product requirements as the workflows took shape.
The project demonstrates how I move from ambiguous domain problems to a concrete product model, while the same systems thinking supports alignment and tradeoffs in larger enterprise teams.
The problem was finding settings and knowing whether to trust them.
Laser workflows are sensitive to machine type, lens setup, material composition, thickness, finish, and intended result. The product requirements describe this as a trust, waste, and safety problem: people deal with conflicting advice, scattered project files, outdated manuals, and repeated trial and error.
That matters because laser work is physical. A bad recommendation can waste expensive material, cost shop time, and create safety issues when people work with unfamiliar substrates or bad assumptions.
Scattered knowledge
Users piece together settings from social groups, software forums, support docs, and personal notes.
Weak transferability
A setting that worked once may not translate cleanly across a different machine, material finish, or lens setup.
High cost of being wrong
Trial and error is expensive when the output is physical and the material may be hard to replace.
Research, synthesis, and domain context
I used a mix of community research and direct domain experience to shape the product. That included Facebook chat interviews and group discussions, laser manufacturer support boards, Reddit discussions, laser software support forums, and my own experience using fiber and CO2 lasers.
To move through that volume of input efficiently, I used AI as a synthesis tool, not as a decision-maker. It helped me organize notes, cluster repeated pain points, bubble up correlations across sources, and draft hypotheses worth reviewing. I treated those outputs as prompts, not conclusions. I was responsible for deciding what was credible, what needed validation, and how those patterns should influence the product.
Why my direct use mattered
Hands-on experience with fiber and CO2 lasers helped me separate plausible-looking advice from settings that were actually usable in a shop workflow.
Why AI helped
It made it easier to manage noisy, unstructured research notes and keep the emerging product direction focused without treating generated summaries as truth.
Patterns that shaped the design
A few themes kept recurring across community research, software support discussions, manufacturer support content, and my own laser use. AI was useful for clustering these signals and exposing how often they co-occurred. The design work was deciding what those patterns meant and how the product should respond.
1. Context drives trust
Users could often find settings, but not enough context to know whether those settings applied to their exact machine, material, finish, or intended result. That led me to treat trust as a workflow problem.
2. Setup friction was too high
People were copying product details by hand from disconnected resources, guessing which fields mattered, and normalizing inconsistent parameters manually. That pattern directly led to the material prefill feature.
3. Merchant data is messy
Variant URLs, product names, and material descriptions were often inconsistent. That drove the need for canonicalization, raw-plus-normalized values, confidence, and warning states instead of silent guesses.
4. Safety uncertainty is real
Users wanted fast answers, but some materials and settings require caution. That pushed me toward reviewable outputs, visible warnings, and nulls when the evidence was weak.
5. Reuse depends on structure
People did not only need answers. They needed a way to compare past jobs, reuse successful setups, and understand what changed. That influenced the data model and the decision to keep machine, material, result, and evidence connected.
6. Community knowledge needed stronger signals
Forums and groups were useful for language and pain points, but weak for accountability. That reinforced the importance of verification, attribution, version history, and moderation in the product.
The workflow strategy
From a product standpoint, I wanted LaserMark DB to do two things at once: reduce friction in everyday setup and make uncertainty more visible instead of hiding it. That led to a workflow strategy built around searchability, reviewable context, evidence-backed verification, and careful handling of ambiguity.
Find
Search by machine, material, or keyword, then narrow with filters and visible trust cues.
Evaluate
Review parameters, author context, verification counts, warnings, and linked discussions before applying a setting.
Apply
Export settings to the tools people already use, including LightBurn-compatible formats and standard data exports.
Verify
Turn a one-time result into reusable community knowledge through photos, notes, and visible validation.
Refine
Keep version history and discussion attached so the database can improve instead of freezing bad assumptions in place.
Govern
Support warnings, review, and moderation where the risks are too high for passive publishing.
Featured workflow: material prefill from product URLs
One part of the product I am particularly proud of is the ability to pre-fill material information from a product URL. This came directly from a repeated friction point in the research and from my own experience: too much time was being spent copying details from supplier pages into a settings workflow before any actual testing could begin.
The design challenge was using extraction or scraping technology responsibly and not pretending the system knows more than it does.
What it does
A user pastes a public product URL and LaserMark DB attempts to pre-populate core product and material fields such as image, product name, description, dimensions, material family, and related attributes.
Who it helps
It helps hobby users and shops reduce repetitive setup work, especially when they are testing new material sources or documenting a result for reuse.
Why it matters
It reduces manual entry without pretending the system knows more than it does. Review, evidence, and ambiguity remain visible parts of the experience.
Extraction prioritizes structured product markup first, then page metadata, visible page content, URL signals, and site-specific adapter rules. It returns normalized values and raw source values, field-level evidence, warnings, and confidence rather than collapsing everything into a single unreviewable answer.
The deeper product work was in edge cases where machine variants might not represent a meaningfully different machine. Material language is messy, especially when commercial names, substrate families, finishes, and sizes are mixed together. The spec handles this with canonicalization rules, variant retention rules, a layered material taxonomy, and explicit warning conditions when the evidence is weak or conflicting.
Design principle
Unknown values should stay unknown. Nulls are better than confident-looking guesses when the source data is weak.
Workflow principle
Pre-fill should speed up setup, but the user should still understand what came from the source page and what needs judgment before reuse.
Verification turns a database into a trust system
The product requirements make verification a first-class workflow. Users can test a settings sheet, upload photo evidence, rate the outcome, and add context that strengthens the record for the next person. For shared knowledge to be useful long-term, the system has to make attaching and reading proof feel effortless.
Evidence
Photos and notes turn opinion into something more inspectable.
Attribution
Author identity, reputation, and version history help users evaluate not just the setting, but where it came from.
Feedback loop
Verification improves future confidence and helps the database evolve instead of remaining static.
What this demonstrates
I gave a messy, credibility-sensitive workflow structure through direct domain experience, community research, product thinking, lightweight development, and responsible use of AI.
Systems thinking
I designed the product as a connected workflow, not a stack of isolated screens.
Practical product judgment
I focused on reducing friction where it mattered while keeping provenance, review, and uncertainty visible.
Technology used responsibly
I used AI and lightweight development to move faster and stay organized, but the design, prioritization, validation, and final decisions were mine.
The product requirements and extraction specification make the system's real constraints, ambiguity, provenance, and accountability visible.
Enterprise platform redesign • Financial planning
Adaptive Sheets
Led the redesign of three enterprise planning models into one coherent interaction system, preserving expert speed while modernizing the platform foundation.
This was a platform redesign, not a visual cleanup
Adaptive Sheets was one of the most important features in the product. It's where planners and financial analysts spent their time building budgets, comparing periods, reviewing anomalies, and getting through close. But over time the experience had become inconsistent, harder to learn, and harder to trust.
Our goal was to rebuild the Sheets platform on a stronger foundation. The work unified standard, modeled, and cube sheets into one clearer interaction system while modernizing the product for HTML5 and JavaScript. I was the lead product designer on the program, so while the work was absolutely collaborative, I drove the interaction direction, the quality bar, and many of the product decisions that shaped what shipped.
8 monthsplanned as a longer program, shipped early
3 sheet typesstandard, modeled, and cube
35%reduction in sheet-related support calls
27%faster month-end close for large customers
We had to solve product pain and platform risk at the same time
The old experience had real usability issues. Actions were hidden in context menus, navigation changed from page to page, and similar tasks behaved differently depending on which sheet type you were in. That made the product slower to learn and more stressful to use during high attention work.
At the same time, the underlying technology was aging out. Cube sheets in particular depended on third-party technology tied to Java applets, and that foundation was being shut down. We couldn't keep layering fixes on top of it. We had to rebuild the product on a modern architecture while still supporting the people who depended on it every day.
Inconsistent experience
Actions, menus, and navigation patterns shifted too much across contexts.
Legacy foundation
Java applet dependency and other aging platform choices forced deeper rework.
Trust gap
Many planners still fell back to Excel because it felt faster, clearer, and more familiar.
Research changed the strategy, not just the screens
We went into the project with a few assumptions that didn't hold up. One of the biggest was that people mainly wanted to work in Excel and then move their data into planning. This was a common ask at Adatpive Live and in our support cases but after digging into it more with customers, we found that the reason wasn't because they liked the workflow, it was because the workflow was painful and this was their cure.
What they really wanted: people wanted to stay in one workspace because switching tools introduced friction, errors, and wasted time.
We also learned that formatting mattered, but not for decorative reasons. Users cared about structure, comparison, totals, decimals, and whether the sheet made sense under pressure. That shaped the redesign in a very practical way.
One workspace mattered
Users wanted to do more inside Sheets instead of bouncing to Excel or separate reports.
Formatting meant trust
Totals, variance, and layout cues helped users read and validate data quickly.
Comparison was a real need
Historical context inside the workflow helped users make better planning decisions.
Guidance beat guesswork
Drag and drop, filters, and parameters needed more visible cues to feel learnable.
Entry needed focus
Inline graphs were interesting, but they added noise in planning workflows.
Small details mattered
Things like double lines above totals and direct formatting were not cosmetic requests.
We weren't trying to make planning feel flashy. We were trying to make it feel dependable.
What I drove, and what we did as a team
This was a team effort, and I want the case study to reflect that. We had designers, doc writers, research support, product, engineering, QA, and an agency partner contributing to the program. My role was to lead the product design work and keep the system coherent as the work scaled.
What I drove
I led the interaction direction, look and feel, navigation, page taxonomy, branding decisions, and component behavior. I also worked directly with product and engineering leadership to turn research into the roadmap.
What we did together
Research planning, production, engineering implementation, documentation, QA, and rollout planning were collaborative. The final product is the result of that combined effort.
Where I pushed hardest
I pushed to make accessibility foundational, not a remediation project. I also partnered closely with engineering on the cube-sheet architecture and the tradeoffs needed to rebuild it the right way.
How I worked
I tried to keep the story honest, the decisions grounded in evidence, and the team aligned around what mattered most for users rather than what's easiest to explain in a review.
One product system had to support three very different models
The hardest design problem wasn't visual consistency by itself. It was creating one coherent experience across three different planning models that each had real differences in structure and behavior.
Standard sheet
Classic budgets, forecasts, and financial statements where people review or enter values across time and organizational levels.
Modeled sheet
Object-based planning for people, projects, assets, and contracts where each row behaves more like a business object.
Cube sheet
Multidimensional planning across things like product, customer, scenario, region, and time.
Our goal wasn't to flatten those differences. It was to make the shared parts feel familiar while letting the specialized parts show up only where the data model really demanded them.
The real design work was the interaction architecture
The most important thing we designed wasn't a single screen. It was a reusable interaction system for moving, editing, formatting, comparing, and understanding state across the platform. That's what made the redesign feel coherent instead of fragmented.
We standardized toolbars, menus, side panels, formula workflows, and core feedback states. That mattered because people using financial software do repetitive, high-attention work. If they have to keep reinterpreting the UI, they lose speed and confidence.
Predictable menus and states
Users no longer had to relearn where actions lived each time they changed context.
Shared editing patterns
Formatting, entry, save behavior, and state cues became much more consistent.
Expert speed preserved
We kept the product legible without sacrificing the muscle memory power users relied on.
We had to make real tradeoffs, especially around cube sheets
One of the most important parts of this story is that we didn't pretend we could do everything at once. Cube sheets were tied to third-party technology that was being shut down, so we needed to rebuild that experience on a new foundation. That meant making some hard calls about what to prioritize now and what to delay.
We communicated those tradeoffs directly to customers. We focused first on the things that most affected trust, efficiency, and long-term stability, even when that meant delaying lower-priority features or cosmetic requests.
Foundation over feature completeness
We chose to rebuild the cube-sheet architecture correctly instead of chasing parity with every legacy behavior right away.
Clarity over surface polish
We prioritized structural cues, formatting, and workflow trust over heavier theming and customization requests.
Focus over novelty
We moved inline graphs and other noisier ideas out of core entry workflows because they distracted from planning work.
Those choices weren't always easy, but they were intentional. They helped us deliver a product that was more stable, more scalable, and more honest about what it could support well.
Accessibility became part of the foundation
Accessibility wasn't something we wanted to patch after launch. We used the redesign as a chance to change the process itself. I pushed to make accessibility requirements part of components, branding, and interaction rules from the start.
Product impact
The product became easier to use for a wider range of people, especially in keyboard-heavy workflows.
Business impact
Accessibility improvements also helped in federal RFQ situations and strengthened the company's position with customers.
Process impact
Instead of treating accessibility as cleanup, we treated it as a standard for new work.
The work changed how the team operated too
The redesign also changed how the team worked. We clarified approvals, component documentation, and collaboration across design, engineering, and QA. Over time, design moved from just-in-time delivery to operating roughly two sprints ahead.
Mentorship
I coached junior designers on documenting work for engineers, spotting accessibility gaps, and presenting ideas more effectively.
Better handoff
Shared rules and cleaner component thinking made implementation smoother and less ambiguous.
Quality rituals
We introduced stronger habits around usability, accessibility, and tech debt so quality became part of the process across the team.
What changed for customers, the team, and the business
The redesign shipped in 8 months and gave the product a stronger foundation to build on. Support burden dropped, close workflows got faster for large customers, and the team got more consistent about quality and delivery. The product also became more credible with customers who had been relying on Excel because they didn't trust the old experience enough.
100%of the redesign shipped in 8 months
35%sheet-related support calls down
27%month-end close time down for large enterprises
2 sprints aheaddesign and development alignment improved
"You've made me a better father and husband. I don't have to stay late anymore and I get to spend more time with my wife and kids!"
The comment connected the product metrics to a human outcome: less stress, fewer late nights, and more confidence during critical planning work.
Research signals that mattered
Practical insights and observations shaped the design decisions throughout the project.
Users built reports monthly, but ran them daily
That made day-to-day readability and speed much more important than one-time setup polish.
Excel remained the common output method
Direct formatting and familiar structure still felt easier to many users.
Double lines above totals mattered
Small structural cues carried meaning and couldn't be dismissed as visual preference.
Visual aids made drag and drop learnable
When the interface showed what would happen next, the interaction made sense much faster.
Filters and parameters were too hidden
People expected more direct, spreadsheet-like manipulation.
Themes were not the main request
Users cared much more about trustworthy formatting and workflow clarity than appearance controls.
Used pattern design, dependency mapping, and a high-risk proof of concept to show that a proposed UI migration would not resolve the underlying platform problem.
Recommendation prevented a high-risk migration
Enterprise UX•Platform strategy•Decision quality
Enterprise SaaS + platform strategy
Workday Task Wizard
Using one component rethink to expose the limits of a much larger business process platform
Product designPattern redesignBusiness process UXCross-pillar alignmentRecommendation driven
Using design to test whether the organization should build
Task Wizard started as a pattern and platform usability effort. The immediate goal was to improve how users moved through complex Workday business processes by replacing a shallow, inflexible wizard with something more scalable, more navigable, and more accessible.
What made the work more interesting is that it turned into something bigger than a component enhancement. Once we applied the pattern to a deeply connected business process and started tracing dependencies, we uncovered that the real challenge was not just the interface. The underlying platform, business process ownership model, and uptake path were all working against a clean migration.
Design leadowned UX direction and cross-team requirements mapping
80+ dependencies foundacross related business processes and orchestration points
300+ BPs affectedif Workday chose to move forward with full uptake
Key outcomeevidence-backed recommendation to stop the proposed migration
My role
I led the design effort. That included reviewing research findings, translating them into requirements, identifying cross-pillar dependencies, defining functional gaps, shaping scope with product management, and presenting recommendations back to leadership.
Pattern design
Redesigned the Task Wizard model to support grouped steps, deeper hierarchies, better validation behavior, accessibility, and more resilient navigation.
Systems mapping
Worked across product pillars to document business process requirements, dependencies, and uptake blockers that were larger than the component itself.
Strategic recommendation
Helped define adoption scenarios and the final recommendation based on UX evidence, engineering realities, and organizational readiness.
The component group had limited design capacity, so I also owned detailed states, edge-case coverage, and engineering-ready redlines, while mentoring another designer on buildable documentation.
The product problem and the platform problem were tangled together
For end users, business processes were hard to navigate, easy to get wrong, and too rigid to fit the way different companies actually operated without heavy customization. For developers and platform teams, the same processes were difficult to scale, hard to configure, and buried under legacy code, security constraints, and interdependent logic.
User pain
Processes were long, brittle, and cognitively heavy. Even when people knew what they needed to do, the flow often fought them.
Developer pain
Legacy code, orchestration dependencies, and functional gaps made migration and ongoing support expensive.
Org pain
Any real uptake required commitment from many product teams, not just a local UI improvement.
That combination made this a strong example of a design problem that looks like a workflow issue on the surface but turns out to be a platform strategy question once you trace it far enough.
The design response was to make complexity more manageable, not to pretend it did not exist
The original wizard only supported a single level with up to five steps. Research made it clear that five steps was rarely enough. I proposed a more flexible model with grouped steps, progressive disclosure, non-linear navigation, clearer validation states, expand-and-collapse rules, keyboard support, and accessibility improvements including RTL and double-byte language considerations.
Deeper hierarchy
Grouped steps helped users understand the structure of a process instead of facing a flat list that quickly broke down at scale.
State clarity
Validation, current step, saved return states, and expand or collapse behavior were explicitly defined rather than left vague.
Accessibility built in
Keyboard navigation, updated color treatment, localization needs, and accessibility review were handled as first-class requirements.
We used a hard proof of concept to test whether the pattern could really hold
To pressure test the idea, I applied Task Wizard to one of the most complex business processes at Workday: Change Job. The thinking was simple. If the new model could hold up there, it had a chance of becoming a broader replacement pattern. If it broke, it would tell us where the deeper constraints were.
That proof of concept became the inflection point. It helped us identify more than 80 related business processes and a large set of orchestration dependencies. It validated the value of the UX changes, but it also proved that the migration path would be extremely costly and politically hard to execute.
Why this POC mattered
It let us test assumptions against a real, highly connected business process instead of an idealized sample flow.
What it exposed
Functional gaps, sequencing dependencies, ownership ambiguity, and the real cost of uptake across the platform.
What it proved
The UI could improve perception and navigation, but it could not fix the platform’s structural issues on its own.
Evidence supported a no-go recommendation
We presented three uptake scenarios and recommended that Workday stop the replacement as originally scoped. Reaching parity required multiple release cycles; a complete transition required retiring the existing orchestration model, redirecting legacy development, and sustaining commitment across participating product teams for three to five years.
Platform readiness
Security, functional gaps, and legacy dependencies made the near-term migration risk greater than its expected value.
Organizational dependency
Successful uptake required sustained commitment from hundreds of process owners and participating product teams.
Required capabilities
The evidence pointed toward an automation engine, visual process builder, task manager, and scheduler rather than a wizard replacement alone.
A no-go decision can be a product outcome
The assessment mapped the business-process platform at a level the organization had not previously assembled. It converted distributed concerns into evidence, aligned experts around the same constraints, and gave leadership concrete investment options before committing to a costly migration.
Research that changed the conversation
More than a year of investigation converted intuition and local complaints into an evidence-backed platform assessment.
Cross-team alignment
We pulled more than twenty product experts into the same conversation and got them aligned on the actual problems.
Clearer next moves
The question stopped being “what is broken?” and became “when are we ready to do the bigger work?”
This work demonstrates design's role in decision quality: testing the proposed experience deeply enough to reveal structural risk before the organization commits to delivery.
Consumer safety • Search UX • 0-to-1 product
RecallSeeker: From POC to V1
Evolved recall discovery from a rough proof of concept into a faster, more visual, trustworthy, and action-oriented consumer experience through research and testing.
A product for people who usually hear about recalls too late
RecallSeeker is a bootstrapped stealth-mode 0-to-1 startup with a team of five and was started with a simple but important challenge. Product recalls affect millions of consumers, yet most people do not actively monitor them. Public recall systems are often slow, text-heavy, and difficult to browse. Even when the data exists, the experience of finding a relevant product, understanding the risk, and taking action is harder than it should be.
This case study tracks how the product evolved from proof of concept to a stronger V1 direction. The work moved beyond proving that recall data could be surfaced. It became about trust, speed, and clarity. How do you help consumers identify the right product quickly, understand what matters, and feel confident enough to act?
90+% fasteraverage page-to-page performance vs CPSC browsing
60 to 80% fasterrecall identification in a 20-person visual A/B test
WCAG AA targetsaccessibility treated as a product requirement
POC to V1driven by testing, research, and workflow refinements
My role
I served as a founding designer partnering with a senior quant/data analyst, Sr UX researcher, Sr AI/ML engineer, and SR product manager to shape early product direction. I used survey research, personas, process mapping, low-fidelity exploration, A/B testing, and working product screens to understand how consumers think about recalls and where trust breaks down. That informed both the consumer experience and the human-in-the-loop direction behind the product.
Research and framing
Developed surveys, interpreted behavior patterns, and translated findings into personas, journey maps, and product priorities.
UX evolution
Designed and compared dashboard, search, registration, and recall detail concepts across mockup, proof of concept, and V1 states.
Trust and interaction
Explored how AI-assisted recall workflows could stay transparent by using approvals, verification steps, and better communication patterns.
The interface decisions followed the product strategy: understand what users fear, what information they lack, and what evidence they need before they can act.
The experience depended on awareness, recognition, trust, and action
Consumers and organizations face millions of recalls annually, but manual review is slow, error-prone, and difficult to scale. Public recall experiences often behave like research tools instead of action tools, asking people to scan dense text and decode product names with little visual confirmation.
That creates a UX problem as much as a data problem. Users do not trust automation without transparency, and they do not act quickly when the interface makes product identification feel uncertain.
Low awareness
Many consumers are passive and only learn about recalls by chance, long after a better notification or registration system could have helped.
Weak discoverability
Text-heavy search and inconsistent naming make it harder to match the recall to the real product in a consumer's home.
Low confidence
If the system does not clearly show what is affected and what to do next, users hesitate, ignore the issue, or postpone action.
Passive discovery
Busy consumers rarely monitor recall databases, so relevant safety information is often discovered by chance.
Research made the opportunity much clearer
The research phase combined quantitative survey work with persona development, process flow mapping, and iterative testing. One of the clearest findings was that the majority of consumers were passive rather than proactive. They were not monitoring recalls regularly, they were not consistently registering products, and they were more likely to rely on chance exposure through news, social media, or store postings.
Awareness gap
49.6% of respondents were only somewhat aware of recalls and 25.6% were not aware, which showed a major gap between risk and attention.
Action gap
Only 37.2% had ever acted on a recall, which reinforced the need for clearer identification, stronger trust signals, and easier next steps.
Notification preference
Email emerged as the most preferred channel, which shaped how proactive communication should work inside the product.
That process work mattered because RecallSeeker was not merely a searchable database. It was trying to bridge registration, detection, communication, and remediation in a way that felt consumer-friendly while still respecting the complexity behind the scenes.
The product got better when it became more actionable and less abstract
The dashboard evolution tells the story clearly. The earliest mockup emphasized watchlists, overview metrics, and a brand safety monitor. Users appreciated the clean layout, but the surface did not support the real job they wanted to do, which was understanding whether they owned recalled products and what to do next.
The proof of concept and V1 shifted toward product registry, clearer status grouping, stronger default filters, tighter layouts, and a more explicit focus on products with recalls. That was the turning point. The dashboard stopped being a passive overview and started acting more like a control center.
Default to urgency
Products with recalls deserved stronger visual priority than safe products or generic monitoring metrics.
Reduce noise
Mixed views of safe and recalled products diluted attention and made it harder to see what needed action.
Support peace of mind
Users wanted a real-time check now capability, not just nightly matching, because trust is partly about immediacy.
Search became a product differentiator
One of the strongest improvements in the product was the move from text-heavy recall browsing to a more visual and intent-aware search experience. Users cared more about recognizing a product than reading a reference number. That meant image-forward cards, clearer titles, simpler actions, and less cognitive load.
Under the surface, the search model improved too. Traditional keyword and contains searches were weak for real consumer behavior because people do not always know the exact product name. Semantic search performed far better. In the deck example, searching for Elmo Nightlight returned the correct recall first, while a comparable public search experience buried the answer several pages deep and loaded more slowly.
Visual recognition
Images, mini carousels, and stronger card layouts helped users identify relevant products faster than text-only results.
Semantic matching
Intent-aware search handled naming differences and misspellings better than exact keyword logic.
Consistent actions
Unified action bars for sharing, bookmarking, and quick access reduced decision friction while scanning results.
Recall detail needed to be readable, trustworthy, and accessible
The detail page was another place where the product had to do more than mirror existing public systems. Users needed the right information surfaced upfront, with stronger grouping, better imagery, clearer contact information, and better accessibility support. The design aimed to answer the practical questions first: what product is affected, why does it matter, and what should I do now?
Accessibility was treated as part of the feature, not an afterthought. The detail experience included keyboard navigation support, accessible image handling, and stronger control around components like lightboxes so users stayed oriented during interaction.
Human in the loop design helped reinforce trust
As the product evolved, trust in agent-driven recall processing became a visible concern. Users were interested in proactive messaging, but they also wanted reassurance that important steps could be verified, corrected, or unblocked when needed. That led to stronger thinking around SMS and email notifications with actionable calls to action, along with clearer verification steps around product registration, address confirmation, and resolution status.
Explain the status
Users wanted recall status and blockers surfaced closer to the product card, not buried in a separate management flow.
Confirm gated steps
Verification moments like confirming address, product details, or remediation status improved confidence in the automation.
Escalate when needed
If a workflow required human review, the system needed a clear path for admins or agents to verify and unblock the case.
This is where the product becomes more interesting than a search interface. It starts to behave like a service layer that helps consumers and operators work together to resolve a safety issue cleanly.
Measured product evolution
The product direction became more visual, more accessible, and more action-oriented. The work translated complex regulatory data into something consumers could actually use. Search and navigation performance improved substantially, product identification got faster, and the experience became more inclusive and easier to trust.
Performance
Average page navigation performance improved by more than 90% compared with a public benchmark experience cited in the deck.
Recognition
Visual product cards improved recall identification speed by 60 to 80% in a small A/B test.
Accessibility
The product was designed against WCAG AA targets while improving clarity, hierarchy, and richer metadata handling.
What this demonstrates
The project demonstrates how behavior, testing, and product structure can turn messy safety data into a clear path from recognition to action.
Research-backed design
I used surveys, personas, process maps, and testing to keep the product grounded in real behavior instead of assumptions.
Practical product judgment
I helped the experience move from informative to actionable by prioritizing recognition, clarity, and next-step confidence.
Systems awareness
I treated consumer UX and the supporting workflow as connected problems, especially once human-in-the-loop verification entered the picture.
At its best, RecallSeeker is not just a nicer way to read a recall. It is a better way to help people notice a problem, trust what they are seeing, and act before the risk gets ignored.
Responsible AI • Agent orchestration • Product safety
Designing Bounded Agentic Recall Operations
Designed a bounded multi-agent operating model that adds safe automation, auditability, and explicit human approval to a compliant recall workflow.
A safer way to bring agents into a high-stakes workflow
Recall management is one of those problems that sounds administrative until you map the reality. Teams must detect a possible hazard, verify facts, coordinate regulatory requirements, notify customers, track remediation, and document everything cleanly enough to withstand audit. Most organizations still do that across fragmented tools, manual handoffs, and inconsistent documentation.
This concept for RecallSeeker reframed the problem as an orchestration challenge. Instead of treating AI as a black box that takes over the process, I designed a bounded multi-agent system that sits inside a clear workflow, uses tools to do focused work, and keeps human oversight where it matters most.
5 foundational rolesdetect, validate, comms, resolve, and audit
2 tool layerstask-specific tools plus shared system tools
Level 1 autonomyAI recommends, people approve
Audit-first designtraceability built into every handoff
My role
This case study captures a systems and design exercise. I defined the operating model for how agents should participate in recall management, including the workflow boundaries, tool surfaces, event streams, autonomy levels, and the safety mechanisms needed to make the concept believable in a regulated environment.
Workflow strategy
Mapped the recall lifecycle from incident detection through closure and identified where bounded automation could remove manual coordination without taking control away from operators.
Agent definition
Created role boundaries, inputs, outputs, handoffs, and failure modes so each agent had a narrow job and a clear reason to exist.
Safety model
Defined the testbed, autonomy levels, input limits, and approval posture needed to make the system explainable, measurable, and auditable.
In a system like this, the UX isn't just the interface, it's also the operating logic behind what the system is allowed to do, what it must explain, and when a human should stay in the loop.
The problem was coordination under scrutiny.
Current recall processes are slow because they combine multiple types of work that all carry different consequences. Detection, compliance, communication, product recovery, and closure each have their own rules, stakeholders, partners, and evidence requirements. When those steps live in disconnected systems, the recall becomes harder to move, monitor, and trust.
Automation without boundaries, explainability, and logs would add operational risk rather than reduce it. The design therefore treated decision rights, evidence, and auditability as core product requirements.
Fragmented operations
Teams coordinate intake, compliance, customer outreach, and remediation across separate workflows that do not naturally stay in sync.
High cost of error
Mistakes in messaging, regulatory reporting, or product recovery can create legal, operational, and safety consequences.
Weak visibility
Without a shared system of record, it is difficult to know what happened, what is blocked, and whether closure requirements are truly complete.
The strategy was to anchor intelligence to a stable baseline workflow
One of the most important decisions in the concept was to start with a baseline system that already solved the core recall pipeline. Incident intake, regulatory workflow, customer notification, product recovery tracking, and audit logging all had to stand on their own first. Agents were then layered on top to guide, recommend, draft, validate, and coordinate, rather than replace the foundation.
Baseline first
The workflow remains functional even without agents, which lowers implementation risk and prevents the architecture from becoming AI-dependent.
Bounded roles
Each agent owns a narrow phase of the process, which reduces overlap, makes handoffs easier to understand, and limits where a failure can spread.
Shared tools
Agents act through tools with defined actions and states. That makes the platform easier to extend later without redesigning the whole system.
The resulting model shows how a real business process can adopt intelligence without giving up accountability.
How the architecture works
The orchestration model follows the actual progression of a recall. A detection layer monitors inbound signals and structures a potential incident. Verification checks risk and output quality. Communication handles outreach and acknowledgements. Recovery coordinates returns, replacements, or destruction. Audit keeps the entire chain visible and reportable.
That sequence is supported by both task-specific tools and shared services like telemetry, orchestration, analytics, and a decision repository. The result is a system where agents can participate deeply in the work while still being legible to the people responsible for the outcome.
Explicit handoffs make the system understandable without exposing its internal complexity. Operators can see the current stage, the system recommendation, its supporting evidence, and the action required next.
Agent roles made responsibility legible
Distinct identities and behavioral rules made specialization, handoff logic, and explainability easier to understand. Each role states what it owns, what it will never do, and how it responds when evidence is incomplete.
Clear division of labor
Different voices and scopes reduce overlap between roles and make the operating model easier for users and internal teams to reason about.
Better explainability
Users can understand why a role acted because the persona is anchored to a recognizable specialty instead of a vague AI capability.
Stronger handoffs
When every role has a narrow purpose, it becomes clearer what should be passed forward, what should be rejected, and what should be escalated.
Autonomy boundaries were part of the product model
Because recalls are high-stakes, I designed the system around bounded autonomy. The recommended operating mode was Level 1 autonomy, where AI can recommend actions, draft outputs, and flag risk, but a human still approves key steps. That creates room for automation without forcing the organization to trust an opaque system all at once.
Autonomy levels
Different parts of the workflow can tolerate different levels of automation, but hazardous or regulatory actions stay closer to human approval.
Input limits
The system should only act on approved data sources and structured evidence, not vague or unsupported claims that invite hallucination.
Decision space
Each role needs a clear line between what it may decide, what it may suggest, and what it must never do on its own.
That safety posture is what turns the architecture from a speculative diagram into something a real organization could evaluate seriously. The design asks them to trust a system with visible boundaries.
The testbed was how the concept became operationally credible
A multi-agent system like this can't be introduced responsibly without a place to test it. The testbed strategy created that place. Updates could be compared in a controlled environment, logs and metrics could be collected, and teams could decide whether a change should be promoted, iterated, or discarded before it touched production.
Why it matters
A safe experimentation layer reduces risk, speeds iteration, and creates evidence for what actually improves the workflow.
Why it fits the system
Because agent behavior is measured against outcomes, the organization gets a repeatable way to validate capability instead of arguing about confidence in the abstract.
What this demonstrates
The work demonstrates a workflow-first approach to AI systems: define where intelligence fits, constrain what it may do, keep people in control, and make behavior understandable when the stakes are real.
Systems thinking
I framed the work as an operating model with stages, evidence, and tool surfaces, not as a stack of disconnected screens.
Practical AI judgment
I used boundaries, approvals, and testability to make the concept safer and more believable than a generic agent narrative.
Workflow-first design
I anchored the architecture to the actual shape of recall work so the technology supports the process instead of competing with it.
The product is defined by the behavior of the whole system—people, rules, tools, evidence, and consequences—not by model capability in isolation.
Redesigned time and attendance around an actionable hub, exception-first workflows, batch processing, and worker participation so managers could return to frontline work.
100% early-adopter renewal after release
Enterprise UX•Workflow design•Automation•Cross-product systems
Enterprise SaaS + systems thinking
Workday Frontline Manager
Designing a faster, more actionable time anomalies workflow for frontline managers
Product designWorkflow redesignCross-platformTime and AttendanceReleased
Time Anomalies was part of the broader Frontline Manager Experience program at Workday. The goal was simple to say, but difficult to solve well: help frontline managers spend less time chasing time sheet errors, approvals, and attendance exceptions so they could spend more time on the floor leading their teams.
I led design for this feature area end to end, while also helping shape the surrounding workflow, integration points, and mobile support. The work grew beyond a single dashboard. It became a connected time management experience that surfaced what needed attention, automated the easy path, and reduced the manual overhead of correcting exceptions one worker at a time.
Feature leadend to end across web, with mobile partnership
100% EA adoptionall EA partners renewed after release
Zero-touch approvalmanual review removed for rule-qualified time sheets
Scaled beyond retailexpanded into hospitality and food service
My role
I was the design lead for the feature, working across product areas and across platforms. Beyond designing screens, I helped define how the overall experience should hang together, where the integration points lived, and where automation could remove work from already overloaded managers.
Experience strategy
Developed the day-in-the-life framing for frontline managers and used it to identify where time management belonged in their actual day.
Workflow design
Defined the anomaly detection, review, approval, and exception-handling flows across web, while supporting direction for the mobile designer.
Cross-product integration
Mapped integration points across Time and Attendance, Scheduling, Payroll, HR, Reporting, and planning-related products so the feature did not become another silo.
The design scope extended beyond individual screens to the operating context, connected systems, and moments where the product could remove work or create friction.
The constraint was manual effort around available data
Frontline managers were spending too much time finding and correcting time sheet errors, handling approvals, and chasing down missing or mismatched entries. Many were working weekends and overtime just to stay on top of vacation requests, attestation approvals, and time corrections.
That was a serious workflow problem because frontline managers are supposed to be on the floor. When they are trapped in the back office doing repetitive time administration, the product is taking them away from the part of the job that matters most.
Too much navigation
Managers often had to move employee by employee just to review, correct, and submit time.
Too little visibility
Critical attendance and approval signals were hard to surface quickly, especially at the start of a shift.
Too much back-office work
Managers were doing administrative cleanup instead of spending time with workers and operations.
The day-in-the-life exercise became an important framing tool. It made it obvious that time management could not be designed as an isolated utility. It had to fit inside the first 60 minutes of a shift, support what happens on the floor, and still cover periodic responsibilities across operations, finance, and HR.
Research and framing
The program involved frontline managers, HR, time administrators, top customers and early adopters across retail, hospitality, food service, and manufacturing. What mattered most was not just what tasks existed, but how fragmented the manager's workday already was.
Research showed that managers wanted more actionable information earlier, especially during the first part of the day. They didn't need another passive dashboard. They needed a place that surfaced what was off, urgent, and what could be completed quickly without digging.
Users at the center
The feature was grounded in the lived reality of frontline managers who juggle operations, staffing, finance, and people tasks at once.
Integration mattered
No single team had a complete picture of how all of the connected product areas worked together, so part of the work was simply organizing those connections.
Design target
The experience had to reduce friction for the common case while still supporting more complex labor and compliance scenarios.
The strategy was to meet managers where their day actually starts
A few design principles kept the work focused. First, we needed to integrate into the Time Management Hub instead of creating yet another disconnected workflow. Second, we needed to bubble up actionable items and counts so managers could move immediately into work that mattered. Third, we needed to automate the easy path and reserve manual effort for true exceptions.
Start with urgency
Bring forward what needs attention in the first 60 minutes of the day, not after the manager has already gone hunting for it.
Design for scale
Managers with large teams need filtering, grouping, and batch actions. A one-worker-at-a-time flow does not scale.
Give autonomy back
Where appropriate, workers should be able to contribute to corrections themselves so the manager is not the bottleneck for every issue.
A connected system for review, exceptions, and action
The final experience combined several features that worked together. The hub gave managers a clear entry point. The anomalies flow helped them identify and prioritize exceptions. Batch processing removed repetitive review work. Analytics pages gave them visibility into broader workforce patterns. Each piece had a specific job, but they all supported the same outcome: less time hunting, more time acting.
Hub
Show what needs review, what is urgent, and where the manager should go next.
Anomalies
Use visible counts and simple filters to move from awareness to action without repeated query setup.
Analytics
Support broader labor, attendance, productivity, and operations decisions from the same ecosystem.
One of the most important workflow decisions was batch processing. In the old model, managers could lose enormous amounts of time simply navigating through workers whose time sheets did not actually have problems. By separating low-friction approvals from true exceptions, we reduced wasted motion and let managers focus on what really needed attention.
Worker autonomy was part of the solution
Managers were carrying too much of the correction burden themselves. A better system needed to pull worker input closer to the source, whether that meant attestation, time-event capture, reminders, or a direct path for workers to correct issues without waiting for a manager to clean everything up later.
Fewer bottlenecks
Workers can provide information earlier, which reduces the manager's need to reconstruct what happened after the fact.
Better communication
Resolution becomes an interaction, not a one-sided administrative correction.
More accurate data
Capturing events closer to when they happen improves data quality and reduces cleanup work later.
Challenges and constraints
This was not a simple dashboard project. ML was still a new concept in the Time and Attendance space. Scheduling integration was being developed in parallel. Labor regulations varied by state and country, which made anomaly detection more complex. And because the work crossed so many product areas, identifying the right teams and validating the integration points took real effort.
Conceptual complexity
Anomaly detection sounds straightforward until labor rules, grace periods, exceptions, and regional differences enter the picture.
Organizational complexity
No one person had a complete map of all the connected systems, so part of the design work was building alignment across teams.
Adoption and expansion
The feature delivered meaningful efficiency gains, especially for zero-error bulk processing when paired with automation rules. Every early adopter partner renewed once the feature was released. After GA, adoption and subscription growth continued steadily. Although it was originally built with retail in mind, the model expanded cleanly into hospitality and food service, with manufacturing customers showing interest as well.
Efficiency
Rules removed manual review for qualified zero-error time sheets, creating a zero-touch path for the common case.
Adoption
100% of EA partners renewed once released.
Scalability
The solution extended beyond its original retail focus into adjacent frontline-heavy industries.
What this demonstrates
The project demonstrates how day-in-the-life research, exception-first workflows, and cross-product integration can remove hidden overhead from enterprise work.
Systems thinking
I treated the experience as a connected workflow that spans dashboards, operational detail, exception handling, and worker input.
Practical product judgment
I focused on saving time where it mattered most, especially for managers dealing with large teams and repetitive approval work.
Enterprise collaboration
I helped define the integration points and the product shape across several related domains instead of designing in a silo.
The shipped workflow gave frontline managers a faster, clearer, and more scalable way to manage time—and more time for the work only they could do.
Design leadership • Operating model • Outcome learning
Extending the Double Diamond Through Outcomes
Extended the Double Diamond with a formal outcome-learning space that connects delivery, telemetry, experimentation, and strategic feedback.
A framework for connecting delivery to measurable learning
The Triple Diamond Framework extends the familiar double diamond by adding a third space dedicated to outcome learning. The first diamond defines the right problem. The second validates the right solution. The third closes the loop by measuring what actually happened after launch and feeding those insights back into discovery.
The model gives teams and leaders a shared view of what happens before and after delivery. Telemetry, experiments, customer feedback, and decision logs connect shipped work to evidence that can change product strategy.
3 design spacesproblem, solution, and outcome
1 AI layercross-cutting support across all three diamonds
Shared ownershipaligns design, product, engineering, data, and leadership
Closed learning looppost-launch evidence informs the next cycle
Why the outcome space needs its own diamond
The traditional double diamond provides a strong structure for discovery and solution development, but it usually ends at handoff or launch. That leaves no formal space for comparing the intended experience with observed behavior. The third diamond makes post-launch measurement and learning part of the design process.
From delivery to learning
The framework treats delivery as the beginning of a new evidence stream, not the end of design.
Evidence for strategy
Design decisions can be evaluated against observed behavior, customer feedback, and defined success criteria.
Visible contribution
Leaders can see how design decisions connect to product outcomes and future priorities.
Delivery creates a new source of evidence. The third diamond gives teams a defined process for turning that evidence into product decisions.
Diamond 1: define the right problem
The first diamond is about disciplined problem framing. It starts with user signals, research, and data, then converges through synthesis into a problem definition, opportunity map, and success criteria. This is the point where teams should slow down enough to separate symptoms from causes and document assumptions as risks rather than facts.
Traceability
Every problem statement should trace back to a validated user signal, behavioral metric, or research insight.
Inclusivity
Edge cases and diverse user needs should appear during framing, not as a cleanup step after the direction is already set.
Explicit risks
Assumptions are documented as hypotheses to test instead of being treated as facts in the roadmap.
Anti-patterns to avoid
Teams often move into solutions too quickly. They jump to features before understanding the root cause, respond to the most visible symptom, or treat untested assumptions as evidence. The first diamond creates space to investigate, synthesize, and define the problem before the team commits to a design direction.
Diamond 2: iteratively validate the right solution
The second diamond develops and evaluates possible solutions. Testing provides evidence about usability, engineering review confirms feasibility within scope, and accessibility checks verify the component and interaction model before handoff. These activities narrow the options toward a solution that users can understand and the team can build.
Evidence-backed
Design decisions gain credibility when they are supported by evaluative testing instead of preference debates.
Feasible by design
Cross-functional review identifies platform, scope, and implementation constraints before a direction is finalized.
Accessibility by default
Accessibility requirements are incorporated into the interaction and component system before QA.
Validation also includes error states, empty states, edge conditions, and content. A solution is not ready for delivery when only its primary path has been evaluated.
Diamond 3: outcome space turns delivery into continuous learning
After a solution ships, teams instrument the experience, track behavioral signals, analyze funnels and cohorts, run experiments, and review customer feedback. The resulting evidence informs fixes, backlog priorities, and roadmap changes.
Decision logs
Iterations should link back to observed metrics or insights so teams can see what changed and why.
Learning agendas
Teams define hypotheses and success criteria before launch so they know what evidence to collect and evaluate.
Closed-loop discovery
Insights from the outcome space should feed directly back into the next problem-framing cycle.
Post-launch measurement is useful only when it changes a decision. The third diamond connects observed behavior to what the team learns, prioritizes, and changes next.
Bounded agents shorten the path from signal to decision
The outcome space can include specialist agents that continuously monitor defined areas of product health. Each agent gathers evidence for a specific concern, while a shared analysis step connects related findings and prepares one priority brief for human review. Agents collect and organize the evidence; product teams retain authority over interpretation, prioritization, and action.
1. Monitor defined signals
Each specialist watches a bounded area—customer feedback, onboarding, retention, usage, or reliability—using agreed sources and thresholds.
2. Connect related evidence
Signal analysis removes duplicates, links changes that may share a cause, and preserves the source behind every finding.
3. Prepare a priority brief
The system summarizes reach, severity, confidence, risk, and effort in one consistent format. It does not make the product decision.
4. Review and choose an action
A product team decides whether to run an experiment, create a fix, update the roadmap, or return the finding to discovery.
Customer feedback
Clusters themes across support conversations, surveys, reviews, and research follow-ups, then connects recurring concerns to product behavior.
Onboarding
Monitors completion, abandonment, repeated errors, and time to first value across releases and user cohorts.
Retention
Surfaces changes in cohort retention, engagement frequency, incomplete value loops, and related customer feedback.
Usage patterns
Identifies feature adoption, unexpected paths, repeated workarounds, and capabilities that users do not discover.
Reliability
Tracks error rates, failed actions, crashes, latency, and behavioral changes associated with a release or affected segment.
Reachusers and segments affected
Severitydegree of disruption or harm
Confidencestrength of supporting evidence
Riskcost of acting or waiting
Effortscope, dependencies, and reversibility
From evidence to a reviewable fix
A work-management connection such as Jira can turn a validated finding into a structured issue with evidence links, affected users, severity, reproduction steps, and ownership. Straightforward issues that meet a low-risk policy can be assigned to a coding agent. The agent works in an isolated branch, runs required checks, and opens a pull request. It does not merge its own change.
Complex, ambiguous, sensitive, or high-impact work leaves the automated path at the risk gate. Low-risk work still requires human code review and approval before merge. Branch protection, required status checks, scoped permissions, audit logs, and reversible changes form the safety boundary.
Eligible work
Narrow, reproducible, well-understood, reversible issues with explicit acceptance criteria and limited dependencies.
Required checks
Unit and integration tests, linting, accessibility checks, security analysis, and any repository-specific validation.
Human boundary
A person reviews the evidence, implementation, test results, and product impact before approving the pull request.
AI operates as a capability layer across the process
AI supports different tasks in each design space. In the problem space, it can cluster themes and identify patterns in large sets of qualitative or behavioral data. In the solution space, it can support design variants, content development, and accessibility checks. In the outcome space, it can flag anomalies and surface behavioral patterns for further analysis.
Specific value
AI is assigned to defined tasks where it can reduce manual effort, expand coverage, or help teams find patterns.
Required controls
Human review, provenance, traceability, and governance remain required when AI output influences product decisions.
What this looks like in a real product team
The framework translates into an operating cadence. Weekly reviews triage telemetry, support signals, and defects. Biweekly reviews connect evaluative testing and design decisions to defined metrics. Monthly reviews examine experiment results, retrospective findings, and roadmap changes.
Design, product, engineering, research, and data share the evidence and decisions produced through instrumentation, dashboards, experiments, decision logs, shipped changes, and repeated measurement.
How the framework supports organizational alignment
The Triple Diamond gives leaders and delivery teams a shared view of design before and after launch. It clarifies how outcome learning contributes to product decisions, where AI supports existing work, and how the model can use instrumentation, experimentation, and review practices already in place.
Outcomes complete the process
Telemetry and analytics become inputs to design decisions rather than standalone reports.
AI supports defined tasks
AI is incorporated into existing workflows with specific uses, review points, and controls.
Uses existing infrastructure
The framework works with instrumentation, dashboards, experiments, and review practices already used by product teams.
Design leadership through process design
I designed the framework and its operating model to connect discovery, delivery, and post-launch learning. The work translates strategy into a structure teams can discuss, test, and apply through their existing product-development practices.
Strategic clarity
The model shows how design decisions contribute to product learning and future priorities.
Operational usefulness
Each space maps to defined cadences, artifacts, evidence, and cross-functional responsibilities.
Visual communication
The diagrams make the relationships between process, evidence, and decisions easier to understand quickly.
The framework combines qualitative discovery with measurable outcomes. It preserves the judgment required to understand people and evaluate solutions while making post-launch evidence part of the design process.
Contact
Open to senior product design and design leadership opportunities.
What I'm Looking For
I'm interested in senior IC and design leadership roles where complex workflows, systems thinking, and high craft matter. My strongest fit is enterprise SaaS, responsible AI, design systems, and technically ambitious 0-to-1 products.
Enterprise SaaSDesign systems0-to-1 products
Start a Conversation
If you're building a complex product and need a designer who can connect user needs, system behavior, and implementation, I'd be glad to talk.
