Hey recruiters, dive in and learn more about Lorraine.

Ask about Lorraine's product strategy, research, systems thinking, enterprise UX, AI work, or experience.

I find the system problem underneath the visible product problem.

My work sits at the intersection of product strategy, user experience, systems design, operations, and AI. These case studies show how I diagnose complex systems, make consequential product decisions, and create structures teams can continue using after the immediate project ends.

Physical Product / Market Strategy

Wrist Caddy

A manufacturing request became a product-definition strategy informed by six years of market evidence.

AI Governance / Operating Systems

Pickahroo AI Brand Operating System

A traditional brand guide became governed infrastructure for humans and AI.

Enterprise CRM / Service Architecture

From KnowMe Cards to Homey

A CRM usability problem became an information architecture roadmap for context-aware service.

AI Product Strategy / Information Architecture

Rainer

A traditional portfolio became a candidate knowledge system designed for both human and machine understanding.

Design Technology / React + TypeScript / In Development

Design System Workbench

A shared environment for validating design intent, component rules, tokens, accessibility, and implementation before engineering handoff.

Visual Design / Consumer Product / Interaction Design

Tripthy

A travel-gifting experience designed to make an experience feel giftable before the recipient has chosen where they want to go.

Product Strategy / UX Research / 2026

Wrist Caddy

A product conceived in 2020 entered a very different market in 2026. I used six years of competitor performance and user evidence to redefine what should be manufactured before my client invested in production.

My role Product Strategy

Client Early-stage Founder

Stage Pre-manufacturing

Methods Digital Ethnography, Workflow Analysis

The Staff-level intervention

The client asked for manufacturing help. I identified a product-definition problem first.

01 Client request

Find a manufacturer for the existing concept.

02 What I noticed

The design was six years old and the market had matured.

03 My decision

Evaluate market evidence before committing to production.

04 What changed

Manufacturing became the final step rather than the first.

Research approach

Why I used digital ethnography and system analysis

The client was preparing to enter an established product category, but the engagement did not have the budget or access required for recruited clinical interviews or in-field observation. Rather than treat that limitation as a reason to skip discovery, I selected methods that matched the evidence already available in the market.

Method 01

Digital ethnography

I reviewed naturally occurring conversations, product reviews, and forum discussions from people using comparable phlebotomy products. This allowed me to study unsolicited feedback generated through real use rather than answers prompted by my interview questions.

I looked for repeated problems across products, users, and time, then grouped those signals into themes such as cleanability, retrieval force, tube compatibility, durability, and stability.

Method 02

System analysis

I mapped the product against the broader blood-draw workflow rather than evaluating the wrist caddy as an isolated object. This helped identify when the product becomes active, what else the clinician is managing at that moment, and where a seemingly minor interaction can increase physical or cognitive load.

The analysis made tube exchange the critical interaction point because the clinician is managing the patient, needle stability, tube sequence, and retrieval simultaneously.

Why these methods were appropriate

Digital ethnography gave me longitudinal evidence from an already mature market. System analysis gave that evidence context by showing where reported problems intersected with the clinical workflow. Together, the methods helped me move from individual complaints to product requirements and manufacturing questions.

Limitation: forum and review data cannot replace direct observation or prototype testing with clinicians. I treated the findings as discovery evidence and hypotheses to validate before production, not as final clinical proof.

Discover

What I needed to know before recommending manufacturing

Cleanability

Recurring concerns about porous materials and clinical maintenance.

Retrieval

Secure retention could create excessive extraction force.

Compatibility

Different tube sizes produced inconsistent interactions.

Durability

Elastic and fasteners changed after repeated use and cleaning.

Stability

Loaded wearable products could shift or rotate during use.

Attention

The product competes for attention during a demanding procedure.

My synthesis

These were not isolated complaints. They pointed to weaknesses in the interaction model shared by many products in the category.

System analysis

Where the product creates risk in the clinical workflow

Clinical moment

Setup

Prep

Needle insertion

Tube exchange

Cleanup

Primary attention

Supplies

Patient

Needle + patient

Needle + patient + sequence

Specimen + disposal

Product interaction

Load

Passive

Active retrieval

Clean

Design implication

Organization

Stability

Do not interfere

Lowest possible interaction cost

Cleanability

My finding

The most important usability moment is not wearing the product. It is retrieving a tube while the clinician's attention and motor control are already constrained.

Define

Turning evidence into product decisions

Evidence	What I concluded	Product decision	Business consequence
Cleaning concerns across porous designs	Material affects clinical usability	Make cleanability a requirement	Do not choose a manufacturer based only on sewing capability
Larger tubes can require excessive pull	Retention and retrieval compete	Prototype retention mechanisms	Avoid premature commitment to elastic-loop construction
Performance changes over time	First-use testing is insufficient	Add lifecycle testing	Reduce risk of early product failure
Tube sizes vary	Universal fit is an assumption	Define supported tube ranges	Create measurable manufacturing specifications

How I influenced the work

Changed the investment sequence

The founder moved from searching for production capacity to validating product requirements first.

Changed the manufacturing conversation

Manufacturer selection could now be based on functional requirements rather than the original construction alone.

Reduced irreversible risk

Prototype validation became a prerequisite to production commitment.

Outcome

A manufacturing request became a product strategy.

The original idea remains the founder's. My contribution was ensuring that the product entering the 2026 market did not remain frozen in 2020.

Decision outcome Validation moved ahead of manufacturing

6 themes Recurring market issues synthesized

Lower commitment risk Production no longer begins from an untested 2020 assumption

AI Product Design / AI Operations / Governance

Pickahroo AI Brand Operating System

I redesigned the role of a traditional brand guide for an AI-enabled organization, turning static documentation into an operating source of truth that both people and AI systems could understand and govern.

My role AI Product Strategy

Focus AI Governance

System Brand Operating Model

Methods Systems Analysis, Governance Mapping

The Staff-level intervention

The problem was not getting AI to generate content. It was giving AI enough structure to make trustworthy work.

01 Existing model

Brand rules lived primarily as documentation for humans.

02 What I recognized

AI was being asked to generate first and comply later.

03 My decision

Move governance upstream into the assistant's operating context.

04 What changed

The brand guide became operational infrastructure for people and AI.

Research approach

Why I used systems analysis and governance mapping

Pickahroo was not primarily a usability study. The design problem involved how brand knowledge, authority, permissions, and approval rules should move through an AI-assisted workflow. I therefore used methods that exposed dependencies and decision rights rather than relying on interface evaluation alone.

Method 01

Systems analysis

I decomposed the existing brand ecosystem into the information an AI system would need to operate responsibly: identity rules, language, accessibility standards, product terminology, campaign constraints, source authority, permissions, and approval states.

This revealed that the central problem was not generation quality in isolation. The system lacked a structured operating context that could govern generation before work reached human review.

Method 02

Governance and decision-rights mapping

I mapped where authority should live across the workflow: which sources are authoritative, what the assistant may do, where automated preparation must stop, and where accountable human approval must resume.

This converted abstract brand guidance into explicit operating rules that could support both human review and AI behavior.

Why these methods were appropriate

The risk was not that users could not understand a screen. The risk was that AI could act from incomplete or conflicting context. Systems analysis exposed the information dependencies, while governance mapping established how responsibility and authority should work across the human-AI system.

Limitation: this work defines an operating model and governance architecture. Ongoing production use should still be evaluated for failure patterns, policy drift, and areas where human reviewers repeatedly override the system.

Discover

What had to become explicit before AI could operate reliably

Brand identity

Visual rules, typography, color roles, photography, and component behavior.

Language

Voice, terminology, messaging boundaries, and prohibited phrasing.

Accessibility

Requirements that should remain true regardless of who creates the work.

Authority

Which source wins when instructions conflict.

Tool boundaries

What an assistant may access, prepare, recommend, or execute.

Approval

Where automation stops and accountable human judgment resumes.

My synthesis

Brand consistency was not primarily a prompting problem. It was a source-of-truth and operating-model problem.

Define

Turning brand guidance into operating rules

System problem	What I concluded	Design decision	Operational consequence
Rules exist across separate documents and examples	AI needs a defined source of authority	Create a source hierarchy	Conflicting instructions can be resolved predictably
Brand guides depend on human interpretation	Important expectations must become explicit	Convert guidelines into AI-readable operating rules	Less prompt-by-prompt reconstruction
AI can drift beyond intended responsibility	Assistant scope must be defined	Establish permission and tool boundaries	Reduced risk of unsupported actions or claims
Generated work can be mistaken for approved work	Drafting and authorization are different states	Create explicit human approval gates	Accountability remains with the responsible human

How I influenced the work

Changed where governance happens

Brand compliance moved upstream, before generation, instead of depending on correction after the fact.

Created shared operating logic

Human reviewers and AI systems could reference the same source hierarchy and behavioral rules.

Established accountable boundaries

Tool use, assistant scope, revision behavior, and human approval became explicit parts of the system.

Outcome

A brand guide became an AI operating system.

The work demonstrates how design systems can evolve into structured business infrastructure that governs how AI participates in product and campaign work.

1 source of truth Shared by human reviewers and AI systems

Governance first Rules applied before generation begins

Human authority Automation supports work without owning final approval

Enterprise Product Design / Service Architecture / AI Readiness

From KnowMe Cards to Homey

I redesigned how customer context moved through a CRM service experience, creating an immediate solution for associates while establishing the information architecture and reusable patterns required for a future assistant-supported workflow.

My role Staff Product Designer

Organization The Home Depot

Environment Enterprise CRM

Focus Journey Analysis, Information-Flow Mapping

The Staff-level intervention

The request looked like a CRM usability problem. I identified an information architecture problem underneath it.

01 Observed problem

Associates paused live conversations to search disconnected systems.

02 What I recognized

The needed context often existed, but did not follow the customer.

03 My decision

Bring useful context directly into the service moment.

04 What changed

KnowMe Cards became a first phase toward a context-aware assistant.

Research approach

Why I used service journey analysis and information-flow mapping

The visible problem appeared inside the CRM, but associate friction depended on events that happened before the CRM interaction began. Research therefore had to extend beyond individual screens and examine how customer context moved across the service journey.

Method 01

Service journey analysis

I mapped the experience across customer intent, IVR intake, call handoff, associate support, and resolution. This exposed where the customer expected continuity and where the internal experience effectively restarted.

The method helped distinguish a channel handoff problem from a simple screen-level usability issue.

Method 02

Information-flow and system analysis

I traced what customer information already existed, where it was stored, when associates needed it, and where the workflow forced them to retrieve it manually from other systems.

This revealed that the company often possessed the information associates needed. The problem was that context was not traveling with the customer into the service moment.

Why these methods were appropriate

A screen audit would have optimized the CRM locally while leaving the cross-channel failure intact. Journey analysis revealed the service break. Information-flow analysis showed the architectural cause and created the basis for KnowMe Cards and the later Homey roadmap.

Limitation: the case study should distinguish observed workflow evidence from future-state concepts. Homey represents a strategic roadmap direction built on the information architecture, not proof that every assistant behavior had already been validated in production.

System analysis

Where context was being lost in the service journey

Journey stage

Customer need

IVR

Call handoff

Associate support

Resolution

Customer action

Seeks help

Provides context

Expects continuity

Explains issue

Receives support

Associate experience

No involvement yet

Receives incomplete context

Searches / repeats discovery

Resolves if information is found

System behavior

Distributed data

Collects information

Context does not travel

Requires manual retrieval

Stores outcome

Opportunity

Understand intent

Capture useful signals

Preserve context

Surface what matters

Inform future interactions

My finding

The handoff between automated intake and human service was the critical failure point. The experience treated each channel as a separate interaction instead of one continuous customer journey.

Define

Turning service friction into product architecture

Evidence	What I concluded	Product decision	System consequence
Customers provided context before reaching an associate	Discovery was being unnecessarily repeated	Carry IVR context into the CRM	Customer and associate can continue the same conversation
Associates searched disconnected systems during calls	Navigation was interrupting service	Surface high-value customer context inside the workflow	Less dependence on manual system hunting
Not every piece of customer data was equally useful	More data would create more cognitive load	Prioritize information by service relevance	Interface becomes context-aware rather than data-heavy
Future intelligent support would require structured context	An assistant could not be useful without an information foundation	Extend the roadmap beyond cards toward assistant support	Immediate UX improvement also creates AI readiness

How I influenced the work

Changed the problem definition

The work moved from improving CRM navigation to repairing the flow of customer context across channels.

Created a reusable pattern

KnowMe Cards established a scalable information pattern rather than a one-screen fix.

Created a roadmap beyond my ownership

The information architecture supported future assistant concepts that could continue after I moved on.

Outcome

An immediate service fix became a roadmap for intelligent workflows.

KnowMe Cards addressed the immediate information problem, while the broader architecture created a structured path toward assistant-supported service.

Operational outcome Customer context moved into the service workflow

Reusable system KnowMe Cards established context-aware patterns

Organizational outcome Roadmap direction continued beyond direct ownership

AI Product Strategy / Information Architecture / Portfolio Systems

Rainer

I redesigned my portfolio as a candidate information system for an AI-mediated hiring environment, combining human-readable case studies, a structured knowledge layer, and grounded conversational retrieval.

My role Product Strategy / Information Architecture

Product Candidate Knowledge System

Audience Recruiters, Hiring Teams, Machines

Methods Task Analysis, Information-Flow Analysis

The Staff-level intervention

The visible problem was portfolio comprehension. I identified an information-retrieval problem underneath it.

01 Visible problem

Recruiters cannot always build a complete understanding of a candidate from long-form portfolio content.

02 What I recognized

Traditional portfolios assume a human will manually browse, interpret, and synthesize candidate evidence.

03 My decision

Separate candidate knowledge from presentation and make that knowledge explicitly retrievable.

04 What changed

The portfolio became a candidate information system for both human and machine audiences.

Context

Portfolios were designed for browsing.

Traditional portfolio architecture assumes that a reviewer will open a website, browse project pages, read case studies, and synthesize a candidate model from the evidence.

That model becomes less efficient when a recruiter arrives with a specific question such as whether a candidate has Staff-level scope, enterprise experience, strong research judgment, AI experience, or systems thinking.

The information may already exist, but the recruiter still has to find it and interpret it.

RECRUITER QUESTION

↓

PORTFOLIO NAVIGATION

↓

READ MULTIPLE PAGES

↓

INTERPRET EVIDENCE

↓

SYNTHESIZE CANDIDATE MODEL

The candidate may already have the evidence. The recruiter still bears the retrieval and synthesis cost.

AI-era opportunity

The portfolio audience is no longer exclusively human.

Recruiting workflows increasingly include search, applicant tracking systems, AI-assisted sourcing, summaries, and other machine-mediated research. Candidate information may therefore be encountered outside the visual page structure in which it was published.

That creates a second product requirement: important experience, methods, decisions, and outcomes should exist as explicit, machine-readable knowledge rather than only as visual presentation.

My reframing

I stopped treating the portfolio as a collection of pages and started treating it as a candidate information system.

Research approach

Why I used task analysis and information-flow analysis

This project was not primarily a visual redesign. The problem was how candidate information was retrieved, interpreted, and moved through the hiring experience.

Method 01

Recruiter task analysis

I reframed the recruiter's task from "read the portfolio" to "determine whether this candidate should advance."

I mapped common hiring questions against the effort required to answer them through traditional portfolio navigation, including questions about seniority, research methods, enterprise experience, AI work, systems thinking, and role relevance.

Method 02

Information-flow analysis

I mapped how candidate knowledge moved from my experience into case-study pages and then into recruiter understanding.

The bottleneck appeared between published evidence and candidate understanding. The information existed, but the portfolio lacked a retrieval layer that could respond directly to recruiter intent.

Why these methods were appropriate

Task analysis exposed what recruiters are actually trying to learn. Information-flow analysis showed why a visually complete portfolio could still be inefficient to interrogate. Together, the methods shifted the solution from better presentation toward better retrieval.

Limitation: recruiter behavior varies across organizations, roles, and hiring stages. This work treats constrained reviewer attention and growing machine mediation as design conditions rather than universal claims about every recruiting workflow.

Task analysis

Recruiter questions should not require a scavenger hunt.

Hiring question	Traditional portfolio behavior	Rainer behavior	Design implication
What makes Lorraine Staff level?	Read several case studies and infer scope	Ask directly	Make seniority evidence explicit
What research methods does she use?	Search project narratives	Retrieve research summary	Separate methods from page location
Does she have enterprise AI experience?	Browse multiple projects and About content	Ask directly	Make capabilities queryable
Which case study best shows systems thinking?	Review all selected work	Retrieve matched projects	Allow intent-driven exploration
How do I contact her?	Locate contact information manually	Retrieve approved contact path	Make escalation explicit

System analysis

Designing for human and machine audiences

Presentation layer

Human-readable case studies, journey maps, research artifacts, decision matrices, and visual evidence.

Knowledge layer

The Lorraine Wiki stores explicit candidate information such as Staff-level positioning, research methods, experience, project summaries, product philosophy, and contact information.

Retrieval layer

Rainer lets recruiters query the candidate according to their own hiring questions without knowing where the answer lives.

Machine discovery layer

Semantic HTML, structured metadata, and explicit relationships can make portfolio evidence easier for external systems to understand.

CANDIDATE EVIDENCE

↓

LORRAINE WIKI

↙︎             ↘︎

HUMAN-READABLE PORTFOLIO      MACHINE-READABLE KNOWLEDGE

↓             ↓

CASE STUDIES           SEARCH / AGENTS / SYSTEMS

↘︎             ↙︎

CANDIDATE UNDERSTANDING

Rainer is the human-facing retrieval interface. The Lorraine Wiki is the structured source underneath it.

Define

The product was not a general-purpose chatbot.

One of the most important product decisions was defining what Rainer should not do. I did not want a generative assistant inventing or embellishing information about the candidate.

Candidate claims require provenance, so Rainer was designed as a retrieval system grounded in candidate-controlled portfolio data.

Product risk	What I concluded	Design decision	Consequence
Generative AI can invent candidate details	Candidate claims require provenance	Retrieve only from Lorraine Wiki	Answers remain grounded
Recruiter questions vary	Fixed navigation cannot anticipate every path	Add conversational search	Recruiter controls exploration
Portfolio evidence is distributed	Important facts need a shared source	Create Lorraine Wiki	Candidate knowledge becomes explicit
Unsupported questions will occur	Hallucination would reduce trust	Create a canned fallback	System limitations remain transparent
Some questions require a person	The assistant should know when to stop	Add human escalation through Megan	Recruiter can continue with a real contact
Chat can become a dead end	Assistant should support the portfolio	Add navigation intents	Recruiter can return directly to case studies

Product principles

What had to be true of the experience

Grounded

Answers come only from candidate-controlled portfolio evidence.

Machine-readable

Important experience exists as explicit structured knowledge.

Queryable

Recruiters explore according to their own hiring questions.

Transparent

Rainer discloses when the knowledge base does not contain an answer.

Human-escalated

Unsupported questions move to a real contact rather than fabrication.

Designing the fallback

The assistant needed to know when not to answer.

When Rainer cannot retrieve an answer from the Lorraine Wiki, the experience does not improvise.

Fallback behavior

"I'm only version 3 of Lorraine's portfolio assistant, and I don't currently have access to that information. I suggest contacting Lorraine in real life through her assistant, Megan."

The recruiter is then given the approved human contact path through mm@regencreatives.com.

Navigation behavior

Rainer supports the portfolio instead of trapping users inside chat.

Queries such as "show me the case studies," "go back to the portfolio," or "let me read the projects" are treated as navigation intents rather than information questions.

Rainer closes and returns the recruiter to the selected-work section.

My decision

The assistant should reduce retrieval friction, not replace the underlying case studies where the evidence can be inspected in depth.

How I influenced the work

Changed the product definition

The project moved from improving a portfolio to designing a candidate information system.

Changed the information architecture

Candidate knowledge was separated from the pages used to visually present it.

Defined AI boundaries

The assistant was constrained from generating unsupported claims and given explicit fallback and escalation behavior.

Outcome

A portfolio became a candidate knowledge system.

Recruiters can still browse the work visually, but they can also query the candidate according to their own hiring criteria while answers remain grounded in candidate-controlled evidence.

Human + machine Portfolio architecture supports both audiences

Grounded retrieval Rainer answers from the Lorraine Wiki rather than open generation

Human escalation Unsupported questions route to a real contact

Decision path

From portfolio pages to an AI-era candidate information system

TRADITIONAL PORTFOLIO

↓

HUMAN-READABLE CASE STUDIES

↓

IDENTIFY RETRIEVAL PROBLEM

↓

SEPARATE KNOWLEDGE FROM PRESENTATION

↓

BUILD LORRAINE WIKI

↓

ADD GROUNDED RAINER RETRIEVAL

↓

ADD NAVIGATION + HUMAN ESCALATION

↓

AI-ERA CANDIDATE INFORMATION SYSTEM

What comes next

Extend machine readability beyond the assistant.

Semantic HTML

Make roles, projects, methods, and outcomes explicit in markup.

Structured metadata

Represent candidate facts and project relationships in machine-readable form.

Searchable evidence

Expand retrieval across richer project details and supporting evidence.

Unknown-query analytics

Use unanswered recruiter questions to identify gaps in the Lorraine Wiki.

Continuing question

How should a candidate represent their experience when the audience may be a person, a search system, an AI assistant, or some combination of all three?

Design Technology / Design Systems / React + TypeScript / In Development

Design System Workbench

I am building a shared environment where designers and engineers can inspect the same component through visual, system, and code views, validate it against explicit design-system rules, and catch ambiguity before it becomes implementation debt.

My role Lead Design Technologist / Product Designer

Stage Build in Progress

Technical stack React, TypeScript, Design Tokens, Modern CSS

Planned extension Governed AI Review + Tiny MCP Demonstrator

The design-technologist intervention

The visible problem is inconsistent handoff. The deeper problem is that design intent and implementation logic live in different representations.

01 Visible problem

A component can look approved in design while its states, tokens, responsive behavior, and implementation assumptions remain ambiguous.

02 What I recognized

Designers and engineers often inspect different artifacts, so inconsistencies surface late during implementation or QA.

03 My decision

Create a shared workbench that connects the live component, its tokens and rules, and its React/TypeScript representation.

04 What changes

Validation moves earlier, when design and implementation decisions are still cheap to change.

The product problem

Handoff is not a file-transfer problem. It is a shared-understanding problem.

A design file can communicate appearance while leaving important implementation decisions implicit. Engineers still have to interpret component APIs, supported states, token usage, responsive behavior, accessibility requirements, and invalid combinations.

My framing

Instead of asking how to make handoff documentation more complete, I asked how designers and engineers could inspect the same product decision through the representations each discipline actually uses.

Workflow analysis

Find the point where intent becomes interpretation.

Design decision

A designer defines a component, variant, or interaction.

Design artifact

The decision is represented visually in a design tool.

Interpretation

Engineering translates visual intent into props, state, tokens, and behavior.

Implementation

The component becomes working React and TypeScript.

QA discovers gaps

Unsupported states, accessibility issues, or token drift appear late.

System finding

The critical break happens between the design artifact and the engineering interpretation. The workbench is designed to make that translation inspectable before implementation is considered complete.

Product architecture

One component, three synchronized representations.

Visual view

A live component preview shows the actual state, variant, size, theme, and responsive behavior being discussed.

System view

Tokens, component properties, supported combinations, and design rules make the system logic explicit.

Code view

React props and TypeScript definitions expose the implementation contract rather than leaving engineering to infer it from pixels.

Review layer

A constrained reviewer checks the current configuration against explicit system rules instead of freely redesigning the component.

Technical principle

The visual component, design tokens, and implementation contract should describe the same system. When one changes, the others should remain inspectably connected.

MVP scope

Prove one design-to-code workflow before building a platform.

Capability	Initial scope	What it proves
Component explorer	Button, Input, Card, Modal	Reusable component architecture and interaction-state thinking
Property controls	Variant, size, state, radius, spacing, theme	Design intent represented as explicit system properties
Token inspector	Color, typography, spacing, radius	System-level changes propagating through implementation
Code representation	React props and TypeScript contracts	Design-to-engineering translation made visible
Governed review	Token, accessibility, state, and API checks	AI-assisted evaluation constrained by explicit rules
Tiny MCP demonstrator	One narrow tool-connected workflow	How a design system can become usable context for an agent

Technical architecture

The design system becomes executable product context.

Component configuration

Variant, state, size, theme, responsive context

↓

Token + rule layer

Color, spacing, typography, radius, accessibility, supported combinations

↓

React + TypeScript component

Typed props, reusable component logic, implementation state

↓

Governed review

Evaluate the current implementation against the system rather than open-ended generation

↓

Tiny MCP demonstrator

Expose a narrow design-system capability as structured tool context

Governed AI review

The assistant should evaluate against the system, not invent a new one.

The AI layer is intentionally narrow. Its job is to inspect the current component configuration and identify violations of rules already defined by the design system.

Token compliance

Flag values that fall outside the approved spacing, color, type, or radius scales.

Accessibility

Surface issues such as contrast, labeling, focus, or unsupported interaction states.

Component consistency

Identify duplicated or conflicting variants that should use the existing API.

Responsive behavior

Check whether component behavior remains within documented responsive rules.

AI boundary

The reviewer can explain a violation and point to the governing rule. It should not silently alter the design system or invent an unsupported component pattern.

Tiny MCP demonstrator

Use MCP to prove the system can become tool-accessible context.

The first MCP demonstration will stay deliberately small. The goal is not to create a large agent platform. It is to expose one useful, structured design-system capability so an agent can request authoritative component information instead of guessing.

01 Agent request

Ask for the rules or supported configuration of a component.

02 MCP tool call

Request structured component metadata from the workbench.

03 Authoritative response

Return tokens, props, states, constraints, and accessibility requirements.

04 Grounded assistance

The agent works from system truth instead of generating from memory.

Design principles

The workbench is designed around shared technical understanding.

Inspectable

Important design and implementation decisions should be visible, not implied.

Typed

Component behavior should be represented as explicit supported contracts.

System-governed

Components inherit shared rules instead of accumulating one-off decisions.

Accessible by default

Accessibility is part of the component contract, not a final QA step.

AI-grounded

AI assistance should use explicit system context and disclose its boundaries.

Changeable early

The system should surface disagreement while decisions are still inexpensive to revise.

What this project is intended to prove

Technical fluency should strengthen product judgment, not replace it.

React + TS Working component implementation, not static mockups

Tokens Design-system rules connected to visible behavior

AI Constrained review grounded in explicit system rules

MCP A small demonstration of tool-accessible design context

Current status

This case study documents the product and technical hypothesis before implementation. The next step is to build the working MVP, validate the component and review flows, and replace these planned outcomes with implementation evidence, screenshots, code, and observed results.

Next build

From case-study hypothesis to working technical evidence.

Build the component workbench

Implement the initial components and synchronized visual, system, and code views.

Add rule-based review

Make token, accessibility, API, and responsive rules inspectable and testable.

Add the Tiny MCP demonstrator

Expose one authoritative design-system lookup as an agent-accessible tool.

Document implementation evidence

Capture architecture, code decisions, screenshots, constraints, and what changed during the build.

Consumer Product / Visual Design / Interaction Design

Tripthy

Tripthy is a travel-gifting experience designed around a simple idea: the giver can contribute to an experience without having to know the recipient's destination, itinerary, or exact plans in advance.

My role Product Designer / Visual Designer

Product type Consumer gifting experience

Primary design focus Visual hierarchy, interaction, responsive experience

Core challenge Make an undefined future experience feel tangible enough to gift

The product challenge

How do you design a gift when the final experience does not exist yet?

01 The tension

Traditional gifting is concrete. Travel is open-ended, personal, and often undecided at the moment the gift is purchased.

02 What I recognized

The experience needed to sell possibility without forcing the buyer to make decisions that belong to the recipient.

03 My decision

Separate the act of giving from the act of choosing the eventual experience.

04 What changed

The product became a flexible travel gift rather than a preselected excursion, destination, or itinerary.

Interaction model

Keep the giver's decision simple and preserve the recipient's freedom.

Choose the gift

The giver chooses an amount rather than a destination-specific product.

Personalize it

The gift carries the emotional meaning without requiring travel planning.

Recipient receives it

The value is framed as an invitation to get out into the world.

Experience comes later

The recipient can use the gift when and where it fits their plans.

Interaction principle

The buyer should not have to plan the recipient's trip in order to give them a meaningful travel experience.

Visual design direction

The interface has to make possibility feel specific.

Because the final destination may be unknown, the visual system carries more responsibility than it would in a conventional product catalog. Typography, imagery, pacing, hierarchy, and composition work together to make the gift feel aspirational without pretending the buyer is purchasing a specific trip.

Editorial, not transactional

Large typography and travel imagery create emotional context before the interface asks the user to make a purchase decision.

Simple hierarchy

The page keeps the core proposition, gift amount, and next action visually dominant.

Flexible by design

The experience avoids locking the gift into one destination, activity, or travel style too early.

Responsive storytelling

The visual rhythm has to survive from wide editorial layouts to a narrow mobile gifting flow.

Audience architecture

One consumer product, two reasons to give it.

Team leaders

A practical alternative to a generic gift card when managers want to recognize employees within a modest gifting budget.

Friends and family

A flexible experiential gift for birthdays, holidays, milestones, or simply encouraging someone to travel.

Product decision

Keep the core redemption experience shared. Different acquisition paths can speak to different gifting motivations without fragmenting the product itself.

Product principles

Make travel feel easier to give than to plan.

Low commitment for the giver

The giver chooses value, not logistics.

Choice for the recipient

The recipient keeps control over where and how the experience is used.

Emotional clarity

The interface should communicate appreciation and possibility before mechanics.

Visual confidence

The product must feel polished enough to be given as a gift, not merely used as a utility.

What this case study demonstrates

Visual craft is part of the product strategy.

Visual Editorial hierarchy, typography, imagery, and brand expression

UX A simple gifting flow around an intentionally undefined future experience

Responsive Interaction and hierarchy designed to work across desktop and mobile

Product One shared experience serving both team gifting and personal gifting