I spend most of my time before the problem is defined. Consumer discovery at Amazon, enterprise systems at Upland. Different enough that what transfers between them had to be earned.
AI handles scaffolding. I don’t use it to frame problems or decide what a user meant. Those are the two places where being wrong is expensive and being fast is worthless.
Selected case studies
Customers knew the job: "secure my front door." Not the product. A four-question flow translates that intent into the vocabulary the catalogue understands, turning a wall of results into a short, confident shortlist.
Read case study ↗
The trust signals were already on the page, just scattered across it. Synthesized quality proof, review sentiment, and seller trust into one module a skeptical buyer could actually read before committing.
Read case study ↗
The brief was a UI refresh. The audit found six modules that had never shared a design model. Restructured Solution Manager end to end: navigation, forms, content lifecycle, solo, from audit to delivery.
Read case study ↗
Six products, six different date and time pickers, none built the same way. Defined one interaction contract, accessible by default, and shipped it as a component every team could adopt instead of rebuild.
Read case study ↗Five steps, and the places I keep AI out of.
AI · none
AI · clustering, verified by hand
AI · scaffoldingAI · none
AI · analysis supportA guided discovery experience for Amazon India's OHL vertical, built to close the gap between what a customer wants to do and the product that actually does it.
OHL covers more than 1,000 product types, most bought once every few years: a lock when you move, a geyser when the old one dies. Customers show up knowing the job ("secure my front door") and almost nothing about the product that does it. Search "door lock" and the catalogue answers with rim locks, mortise locks, aldrop bolts, handle sets and digital locks, ranked against the keyword, not the person.
The vocabulary that unlocks the catalogue (lock type, material, finish, access method) is exactly what an infrequent buyer has no reason to own. The gap isn't missing results. It's the missing translation between intent and specification.
I didn't take the gap on faith. Before proposing anything, I audited three sources of evidence: two from customer behaviour and one from the catalogue itself. They met from opposite sides. Customers could describe the job, not the product. The catalogue was indexed on the product alone. That gave me a problem statement I could defend to skeptical stakeholders, and it pointed the whole solution at translation instead of ranking.
A large share of sessions scrolled, re-queried and left without opening a product. People were looking without finding. Results weren’t missing. The way in was.
Returns, questions and reviews traced back to one root cause: the wrong type bought for the job. A mismatch of understanding, surfacing downstream as cost.
I went through the locks catalogue by hand. Every filter was expressed in seller language: type, material, finish, access method. Nothing described what a lock is for. The catalogue was organised around what a product is. Customers arrive knowing what they need it to do.
Amazon India had tried to solve this twice. I used both tools the way an honest customer would, and wrote down exactly where each broke. That gave the search and ads teams a shared reference to argue against when the harder decisions came.
Guided Navigation was single-turn filter refinement with no education. To use it you already had to know the lock type, material and finish you wanted, the exact knowledge the customer lacked. It also couldn't grow. Its widgets shared placements with GCCP ad units and conflicted with dynamic ranking, so "add guidance to filters" was ruled out before it started.
The Buying Guide was long-form education before selection. The content was sound. The timing wasn't. Chiclet choices were unintuitive, nothing branched, and nothing it taught became a live refinement. It asked customers to study before they could shop.
Product Finder had to be as quick as Guided Navigation and as informed as the Buying Guide. It had to deliver both inside the decision, under placement rules neither tool had to respect.
Both earlier tools treated this as discovery: better results, faster. But speed does nothing for a customer who can't name what they're looking for. The real job was translation: converting plain-language intent into the specification the catalogue understands, and teaching just enough, at the right moment, to make the choice feel obvious.
Naming the gap this precisely was the highest-leverage move I made. It compressed a sprawling "improve discovery" mandate into one sentence India and Global stakeholders could agree on before any UI existed. Vague problems produce vague debates. A specific gap produces specific decisions.
Locks was the pilot, never the deliverable. A flow that only worked for locks would never earn a rollout across 1,000+ types, so the first decision was an architecture rather than a screen: a configurable Q&A template where question type, option format, education and branching are all config, not code. Get the template right and a new category becomes a content exercise.
I mapped the complete flow before opening a single screen: search → ingress banner → mandatory Q1 (location) → mandatory Q2 (lock type, with education) → contextual questions → filtered results with applied tags. Fixing the structure first meant UI exploration happened inside a stable frame, instead of quietly baking assumptions into early comps. I built this alongside engineering from the start, because a template is only real if it's buildable. Pairing early meant the config schema I designed matched what the platform could actually render, not an ideal it couldn't.
Fixed the flow and the ingress-placement debate with a business case, before any screen encoded an assumption.
Prototyped three UI patterns to expose failure modes, then locked each decision with a documented trade-off.
Each direction was built far enough to fail in a specific, instructive way. Two reproduced the exact problems of the tools we were replacing. The third became Product Finder.
Education-first. Chiclets read as unintuitive, and it was slow to the decision. The Buying Guide's problem in new packaging.
Stacked form. Tidier, but still front-loaded education. And it couldn't express multi-node branching, because a choice at one level never reshaped the next.
Inline + branching. Education below each option, live result counts, real branching. As fast as navigation, as informed as a guide. The one direction that solved both.
Five decisions carried the most weight. The first was less a design choice than a negotiation with the team that owned the real estate.
The entry point was a revenue decision, not a design one. The high-visibility option (a dynamic inline widget) sat on top of GCCP ad inventory and dynamic ranking. Rather than design around a constraint I couldn't move, I took it to the ads team early and we settled on a written trade-off: a static "Find the right Locks" banner in a predictable slot that never competes for ad space or reorders results.
Q1, "Where would you use the lock?", is photo-based: pick Main Door, Bedroom, Window, Drawer/Wardrobe or Bathroom/Balcony. That sets the frame for Q2, "Main Door Lock Type," where each option is an image tile carrying its real price range, Rim lock ₹450-₹8120, Handle set ₹740-₹1900, Digital Door Lock ₹4000-₹50000, down to Padlock and Towerbolt. A live match count updates on every tap.
Free text and long dropdowns tested worse, for exactly the reason the project existed. They asked customers to produce vocabulary they didn't have. Image tiles carry the meaning instead, so recognition does the work rather than recall. The education ("Rim Lock: fixes on the edge of the door frame, no cavity needed") sits folded under the selected type. It's there when you want it, and out of the way when you don't.
Optional questions branch on the Q2 answer. Rim Lock asks about Material and Finish. Digital Door Lock asks about Access Method and Special Features. A generic set would have been simpler to build, but it would show irrelevant options the moment a customer committed. One wrong question costs more trust than five right ones earn back.
Every selection updates a live count of matching products. Watching it fall from 769 → 198 → 34 reframes the whole interaction. Each answer visibly does something, so the flow reads as exploration instead of a form to endure. A step counter ("2 of 4") would have shown progress, but not that the answers were narrowing anything. The count does both, and every tap feels consequential.
The strategy had to survive a deadline. The fast way to launch the pilot was a hand-built flow. The durable way was to ship the configurable template underneath from day one. I made the case for the slower path. A bespoke locks flow would prove the idea, and then need rebuilding to prove it anywhere else.
I designed the experiment with the applied-science team: 28 days, 50% of India's OHL traffic, control on the standard results page and treatment on Product Finder. The primary metric was incremental GMS. The guardrail was ad revenue, the same GCCP concern that shaped the ingress decision, now measured directly. That let us prove the banner earned its slot without quietly taxing ads. It didn't. The treatment lifted GMS while holding ad revenue flat.
I led the readout and carried the numbers into the rollout conversation. The lift was clean enough that Global greenlit worldwide expansion off the India data alone. Because the template already existed, other teams could extend the pattern without a rebuild.
Where control saw an undifferentiated wall of listings, treatment landed on a curated results page. The customer's answers carried through as removable applied tags (Rim Lock, Zinc Alloy, Antique Brass), and the count collapsed to a relevant set. That is the endpoint the +$10.9MM was measured against: not more results, but the right ones, arrived at with confidence.
Framing this as an intent-to-specification gap compressed a broad "improve discovery" mandate into one defensible sentence. It's the highest-leverage move in a project. I now spend real time on it before touching a screen.
The ingress banner began as a limit from the ads business and became the sharpest decision in the project. Taking the constraint to the team that owned it, early, turned a blocker into a defined space to design inside.
A live result count did more for perceived progress than any copy could. "769 → 198 → 34" told customers they were getting closer without a word of guidance. It's a pattern I've reached for well beyond this flow.
The static banner was right under the constraints. It trades visibility for safety, and I shipped it without fully knowing who the quieter entry point never reached. With the engagement data the experiment produced, the next iteration is a query-aware trigger that still lives inside the ad-placement rules, earning back visibility from evidence rather than assumption.
The change that moved the most money was never visible in a single screen. It was the template that made every screen unnecessary to design one at a time. The intent-to-specification gap shows up anywhere customers know the job and not the product. Designing the pattern to travel from day one is what turned an India experiment into a platform decision.
Know Your Purchase, a product-page module that turns Amazon's scattered trust signals into one confident answer to the question a furniture buyer is actually asking: should I commit?
The furniture PDP was not missing trust signals. It had a "Quality Verified" badge, a warranty strip, customer ratings by feature, and thousands of reviews. The problem was arrangement. The signals sat scattered down the page as separate claims: a badge in one place, feature ratings far below, reviews below that. A buyer asking "is this actually any good, and can I trust who's selling it?" had to assemble that answer across screens. Most didn't. They stalled at commit, or defaulted to the cheapest option. Furniture makes the stakes plain. A bed or a sofa is a five-figure purchase. You choose it from photos and text, and you live with it for years. On a decision that size, evidence spread across the page is close to no evidence.
The current PDP is the evidence. Trust cues are real, but disconnected. A replacement/warranty strip in one place, "customer ratings by feature" much further down, reviews below that. None of it framed to answer the buyer's underlying doubt.
Instead of "surface more trust content," I reframed the problem around the buyer's actual questions. Sitting with reviews, returns, and support logs, the hesitation nearly always reduced to four. A confident purchase is just a page that answers all four before the customer has to go looking. That reframe became the module's information architecture. Every element earns its place by answering one of the four.
Annotating the proposed module against those questions made the intent legible to partners early, engineering, the reviews-science team, and the ads business could all see why each block existed, not just what it showed.
"Quality Verified" already existed as a badge. A badge is a claim, and a claim doesn't move a skeptical five-figure buyer. Evidence does. So the first module rebuilt Quality Verified as proof you can inspect: a lab-test video, a plain statement that the product cleared 20+ checks by a Govt-accredited lab, and a carousel that translates those checks into outcomes a person cares about: sturdy material, defect-free finish, flaw-free fabric and stitching, verified dimensions.
The accreditation story is dense: independent testing lab, ISO/IEC 17025, NABL, sample inspection, the badge awarded only after all checks clear. Early versions put all of that on the page, and design rightly flagged them as too textual. The fix wasn't to cut the credibility. Skeptics need it. The fix was to tuck it behind a "Know more" modal. Confident buyers move on. Doubters get the full proof one tap away.
The reviews carried real trust, and they were hard to use. Thousands of them, unstructured, hard to skim for the one thing you care about. Partnering with the reviews-science team, we distilled them into aspect-level sentiment, the dimensions people actually weigh a bed or sofa on: Looks & Design, Material & Build Quality, Comfort, Delivery & Assembly, Brand, Seller, Customer Service. Each shows as a % positive drawn from real review analysis, not a star average.
A percentage builds confidence. A specific review sentence adds to it. So each aspect opens into representative snippets, and any aspect becomes a filter on the full review list: a Positive / Negative toggle, keywords highlighted in context. A buyer can go from "85% positive on build" all the way to reading the exact reviews behind it, without leaving the flow.
Here is what made this a hard design problem rather than a nice one. Two rich modules, verification and reviews, want a lot of vertical room. Page height on a PDP is not free. Everything the module added pushed ad placements further down the page, and past a certain point that costs measurable ad revenue. A feasibility review with engineering and the ads business was blunt: the tall, text-heavy versions would not pass for launch. The design had to fit the height the ads business could afford to give up.
The real brief wasn't "design a trust module." It was "design the most convincing trust module that fits inside the height the ads business can afford to give up."
We didn't arrive at the compressed module by taste. I built three directions, and each failed against a version of the same constraint before one survived it: too textual, too tall, or too heavy for tech to ship without dropping ads. What survived kept the proof and the sentiment and shed everything that was explanation for its own sake.
Accreditation and test detail as long copy. Credible, but a wall. Design flagged it, and the height was unworkable.
Everything expanded: imagery, per-aspect cards. The most complete version, and the most over the height the ads business could give.
Video proof plus collapsible aspects, with depth on demand behind taps. Same conviction, a fraction of the height. This one passed.
Compression became the design. Collapsible aspects, a modal for the accreditation, snippets and filters behind taps. Every rich thing still exists, but its default state is small. The page reads in seconds, and the depth is there for anyone who wants it.
Because the module was funded, in effect, out of the ads business's page height, the bar was specific. The confidence it added had to outweigh the ad revenue its height cost. So the experiment measured that directly: a clean 28-day A/B, control versus treatment, 50% of India traffic, read on conversion and revenue. It cleared the bar, and cleared it well enough that the India result set up a worldwide dial-up of the weblab.
The number I care about most isn't the revenue. It's what the revenue proves. A module built under a hard space constraint, with its richest content deliberately collapsed, still moved a five-figure-purchase decision. Confidence, structured well, was worth more than the page height it cost.
None of this ships without the ads and engineering partners agreeing to give up the height. The four-question framing and the compressed, depth-on-demand design were as much a negotiation artifact as a design one. They let me argue, concretely, that every pixel was doing trust work, and that the conversion upside was worth the ad trade. The weblab result settled the argument for the WW rollout.
The signals were all on the page already. The value wasn't new information. It was structuring what existed into a single answer at the moment of doubt. I now look for the synthesis before assuming I need more content.
A "Quality Verified" badge is a claim. A lab-test video and 20+ inspectable checks are proof. Turning the same fact from assertion into evidence is often the whole design job on a trust surface.
The ad-height limit forced depth-on-demand: collapse, modal, filter. The compressed module wasn't a lesser version. The constraint is what made it disciplined enough to ship and to work.
The module leads with positive sentiment, % positive up front, negatives one tap away behind the toggle. It converted, but I'm not sure it's the most trustworthy default. My instinct now is that surfacing balanced sentiment more prominently could build deeper, stickier confidence, especially for the most skeptical buyers. I'd want to test a more visible negative view against the current one rather than assume positivity-first wins. The second open thread is the lab-test video. It's the strongest single proof point, but I never measured whether people actually watched it or scrolled past. That number would tell me how much height the video truly earns.
Product Finder was about the moment before you know what you want. Know Your Purchase is about the moment after, when you've found it and still hesitate. Designing for that pause is a different craft. Less about paths and filters, more about assembling scattered proof into the confidence to commit, and doing it in whatever small space the business can spare.
Support agents using RightAnswers were spending more time navigating the platform than using it. The product worked technically, but the experience had accumulated years of structural inconsistency. The brief was a UI refresh. It became something bigger.
Enterprise knowledge management is a hard design problem. Support teams manage thousands of articles across product lines, juggling approval workflows, governance and taxonomies while agents pull answers under SLA pressure. A wrong or stale article costs time on every ticket that touches it.
RightAnswers had the integrations and the infrastructure. Solution Manager, the core authoring interface, was where it fell apart. The damage was structural, not visual. Modules had been built independently, with no shared model holding them together.
Align Solution Manager with the Upland design system and clean up the visual inconsistencies. A well-defined brief, deliverable in weeks.
Structural failures beneath the visual ones, in the workflows, the information architecture, and the interaction model. A cleaner surface would have masked them, not fixed them.
A full UX restructure, now live across enterprise support teams globally, with Airbnb as a named deployment, and patterns contributed back to the Upland design system.
The audit found one root cause behind six modules of symptoms. The product had been built feature by feature, for longer than its architecture could sustain. It showed in four places (the interaction model, the information architecture, the forms, and the content lifecycle) and each got worse at the scale RightAnswers was sold into.
Dropdowns that expanded in one module collapsed in another. Confirmation dialogs appeared inconsistently. Tab navigation broke without warning. Each module had been built as a standalone product, so users could never build confidence in a system that didn't work the same way twice.
Finding an article in review took a different path than finding one in draft, and bulk actions sat three levels deep. The product had menus for features. It needed menus for tasks.
Article creation opened with 14 fields, metadata, categorisation, audience targeting, expiry, before a word of content. Experienced users built workarounds to defer them; new users made errors. Every interaction assumed all decisions had to happen at once.
Articles moved between statuses with no audit trail, and expiry surfaced only after content had gone stale in front of customers. At thousands of articles per team, that absence was a real governance risk. Outdated answers reaching customers through agents with no way to know.
Two weeks into the audit, the brief was wrong. Aligning Solution Manager with the design system and cleaning up visuals was deliverable in weeks, but it would have painted over structural failures instead of fixing them. So I made the case to expand scope, backed by the audit rather than by opinion.
A UI refresh delivered as scoped would have put visual consistency on top of a structurally broken experience. Agents would have seen a tidier interface and hit the same fragmented navigation, the same overloaded forms, the same missing states. The friction would have survived the redesign.
The expanded scope addressed four compounding problems, in a deliberate order:
Accepted: running a full audit before opening Figma slowed the visible output in the early weeks. Gained: every decision that followed had a rationale grounded in evidence, not aesthetic preference. And a scope the stakeholders had already agreed to.
With scope agreed, the sequencing was the strategy. Design the final UI last, not first. Without the structural work underneath it, visual consistency would only be cosmetic.
These aren't visual improvements. They're decisions about how the product should behave, each with a cost accepted deliberately. The Upland design system alignment came after all three were resolved.
Article creation opened with 14 mandatory fields before any content: metadata, categorisation, audience targeting, expiry, all on load. I cut it to 4, staged the rest, and surfaced governance fields contextually. Core content first, classification on save.
Accepted: the step count increased slightly. Gained: the cognitive weight at each step dropped significantly, and completion errors fell with it.
Every screen had been designed for completeness: every option present, regardless of how often it was used. Action-frequency analysis of common user sessions showed that the top 20% of actions accounted for the overwhelming majority of daily interactions. The redesign surfaced those actions at the primary level and moved the long tail behind explicit affordances. Users stopped scanning full menus to find one item.
Accepted: the long tail now costs an extra click, and power users notice. Gained: the tasks people run hundreds of times a day stopped paying a scanning tax on every visit.
The most consequential work was the least visible. Auditing every pattern across six modules exposed the full scope of the fragmentation. I unified it into one model, so learning one module means learning them all.
Accepted: months of work with nothing visibly new to demo. Gained: users who learn one module have learned them all, permanently.
Solution Manager ships inside Salesforce, ServiceNow, direct portals and more, environments RightAnswers doesn't control. Every pattern had to hold up everywhere it rendered, not just in a clean Figma frame.
Support agents on SLA timers, knowledge managers accountable for governance, administrators managing integrations, each needed the same interface to behave predictably under very different pressure.
One designer carrying audit, IA, flows, component design and UI delivery. The artifacts had to do the persuading. The pattern audit argued for scope. The flow maps argued for the structure.
The metrics here are structural, not instrumented. This was an enterprise redesign, not a consumer product with A/B infrastructure. The evidence is in what the redesign retired: 14 fields to 4, six modules to one model, 11 navigation landmarks to 4. Now live across enterprise support teams globally, Airbnb among them.
Aligning with the Upland design system was the final phase, and it ran both ways. The structural complexity of Solution Manager surfaced gaps in the system's own patterns. I fed them back, so the work strengthened the system it drew from.
Visual consistency is meaningless on a fragmented navigation model. The component library would have looked correct in Figma and shipped compromises into every embedded context, because the structure underneath it hadn't changed.
This user base isn't looking for delight. They're agents on SLA timers and managers governing large content estates. The redesign optimised for the thing they actually needed: an interface that behaves the same way every time.
A product's visual layer can be healthy while its structure fails. The only way to tell is to audit the flows, IA and interaction model first. That audit is what turned a cosmetic brief into a structural one.
The scope expansion was the senior move, not a discovery miss. It was the right call, at the right moment, with the right evidence. Redefining the problem before solving the one you were handed is often the whole job.
Every Upland product asked people for a date and a time. No two products asked the same way.
Date and time entry had grown the way it usually does: product by product, deadline by deadline. One product opened a custom dropdown under the field. Another used a pair of native selects. A third relied on a masked text field. A fourth had inherited a third-party widget nobody wanted to touch. Each behaved differently, validated differently, and failed differently.
The audit surfaced two consistent gaps. A consistency gap: the same task resolved through four different entry metaphors and two time formats, so nothing users learned in one product transferred to the next. And an accessibility gap: keyboard support and ARIA behaviour ranged from solid to absent, with no shared standard to audit against.
We weren't designing a picker. We were designing the one interaction every product borrows. It had to behave like infrastructure, not like a feature.
Date and time pickers existed in six uncoordinated versions across Upland products. Interaction models, validation rules, and accessibility all diverged. Every product team paid the maintenance bill separately.
Audit every implementation across products. Define one interaction model. Design a modular Date & Time Picker family for the Upland Design System, with accessibility as a hard constraint and engineering in the room from the first spec.
One unified model adopted across products, with every state and variant documented. A reusable field-and-picker foundation that removes duplicated design and development work from every future form.
I led the component work end-to-end: the cross-product audit, the interaction model, component architecture, accessibility decisions, and delivery specs. I worked with product managers to anchor the design in real product requirements rather than a hypothetical ideal, and with engineering to pressure-test feasibility and edge-case behaviour before anything was marked ready.
The design decisions I drove centered on:
I catalogued every date and time entry point across the suite and scored each implementation on the things that actually determine user experience: the entry model, time-format handling, keyboard operation, and ARIA behaviour. Visual drift was the least of it. The deeper problem was that the interaction contract changed from product to product.
The matrix did more than describe the problem. It made the consolidation decision defensible. Stakeholders didn't have to be persuaded that fragmentation existed, they could see which implementation carried each strength, and what the unified model needed to keep from each.
Before drawing components, I defined the contract they all had to honour. Components change. The contract is what makes six products feel like one platform.
Field, picker, confirmation, in that order, with the same actions in the same places. A user who learns the picker in one Upland product already knows it in every other.
On desktop the picker opens under the field. On mobile it opens as a modal dial. Different rendering, identical states and outcomes. The form factor is an implementation detail, not a different design.
Every picker carries an input toggle. People who know what they want to type shouldn't be forced through a widget to say it.
Constrained inputs prevent the mistakes they can. Clear error states and unambiguous recovery handle the rest.
Where established platform patterns matched user expectations, we followed them. Invention was reserved for genuine Upland product needs, not for novelty.
Date and Time Pickers shipped as one family assembled from shared primitives: the trigger-field anatomy, the header with the selected value, a selection surface, calendar grid or clock dial, and the action bar. Products configure the family to their requirements. They don't fork its behaviour.
The audit's accessibility gap set the bar for the redesign. Every component in the family is fully keyboard-operable, every interactive state has an explicit ARIA decision, and behaviour is screen-reader tested before it's marked ready. Designing to that constraint from the first spec forced every interaction state to be explicit, which made the components better, not just compliant.
Product managers kept the component honest about real requirements: which formats their users actually work in, which constraints their forms actually need. Engineering reviews shaped the component API and settled behaviour questions early, while they were still cheap to change.
Locale formats and 12/24-hour handling, min/max constraints, disabled dates and ranges, prefilled versus empty fields, how invalid entry recovers. Those working sessions with engineering are where the picker stopped being a mockup and became a contract both disciplines could build against.
Six pickers side by side ended debates that no deck could. When stakeholders can see the fragmentation, and see exactly what each implementation does well, the consolidation conversation moves from whether to how.
The component was designed in the happy path and defined in the edge cases. The sessions with engineering on locales, constraints, and error recovery contributed more to the final quality than any polish pass on the visuals.
Teams didn't switch because a system existed. They switched because every state was already designed, every variant already documented, and the cost of adopting was lower than the cost of maintaining their own. That's a design outcome, and it was deliberate.
What I'd explore next: extending the model to range selection and duration entry, and deepening locale coverage. The same contract, stretched over the adjacent problems products will hit next.