This affected millions of Lowe's customers navigating high stakes, high anxiety purchases. A wrong part means a second trip, a cancelled installation, or a flooded kitchen.

The goal was dual: deflect support load AND improve customer confidence. That two sided brief made this one of the most constrained projects I've worked on.

Customers weren't failing at finding products. They were failing at trusting their choice. The solution became: an assistant that interrogates gently, surfaces evidence, and never bluffs.

Priya is the modal Lowe's customer. Not confident enough to commit. Traditional search doesn't close that gap. Two questions and one part with a 98% fit badge does.

Research across customers mid project, store associates (the human version of MyLow), and support agents. Every insight mapped to a design decision:

Problem. Decision. Why it matters. If a screen couldn't answer all three, it didn't ship.

MyLow shifted how the team thought about the assistant. From "bolted on chatbot" to a decision making layer across the whole shopping journey

What surprised me: the hardest problem wasn't the AI, it was teaching people to trust it. The graceful handoff did more for adoption than any clever flow.

What I'd do differently: instrument conversation quality metrics from day one. Hallucination rate, recovery from misunderstanding, time to confidence. Those are the real UX metrics in an AI product.

The uncomfortable question: when does a personalised assistant become a filter bubble? I don't have a clean answer. Worth someone asking.

The numbers made the shape of the problem obvious once you lined them up. In FY24, self service cancellations of truck delivery orders for item replacement reasons alone came to $44.5M. BOPUIS abandonment cancellations were $47.8M in FY24 and already $30.3M through week 32 of FY25. BOPUIS out of stock cancellations were $59.2M in FY24 and $19.5M in FY25 YTD. And going back to FY23, "items would not arrive on time" alone accounted for $41.03M in cancellation driven losses.

None of those are the same problem, but they share the same shape: a customer's fulfillment promise broke: late truck, missing pickup stock, a store they couldn't reach, and the only tool they had to respond with was a cancel button. There was no way to say "I still want this, just get it to me differently."

That reframe. From "stop the cancel" to "offer the switch" set the shape of everything that followed.

The work split cleanly into two tickets, each solving a different half of the same problem:

Customers don't go looking for a "change my fulfillment method" setting. They go looking for a way out of a bad situation, and by the time they're looking, they're usually already mid cancellation. So instead of one central page, the flow had to live at three separate points of real intent:

Same underlying flow at every entry point, address, delivery type, payment, confirmation, but different framing depending on where the customer was standing emotionally when they found it.

The flow splits into two halves: the entry points that catch the customer at a moment of intent, and the switch itself: address, store, method, money, confirmation. Amber highlights mark the parts that carry the story.

The entry points

Entry 01. Order details, every fulfillment type

Problem

A customer opening their order to check on a delay is already at peak intent, but had no switch option there.

Decision

A "Switch to…" option inside the Manage dropdown on every order type. Delivery, pickup, and same day all get their own.

Why

Proactive recovery: catch them before frustration turns into a cancellation.

Entry 02. Inside the cancellation flow

Problem

By the time someone picks a cancel reason, they've told you exactly what's wrong, but the flow only offered "cancel."

Decision

Selecting "Item would not arrive on time" surfaces recovery options, Get It Fast, Pick It Up, Find a replacement, before the cancel button.

Why

The cancel reason is a research signal. Answer it with a fix, not a form.

Entry 02b. Pickup orders get the mirror

Problem

"Unable to pick up the item" is the pickup side version of the same broken promise.

Decision

Surfaces Switch to Delivery, Change Store, Assign Alternate Pickup Person, or Pickup Later, the pickup mirror of the delivery flow.

Why

Every fulfillment method needed a way out that isn't cancellation.

Entry 03. Out of stock recovery

Problem

When a pickup item goes out of stock, the industry default is substitute or refund. Neither keeps the sale.

Decision

"Explore Other Options" opens the full menu. Delivery, pick up nearby, pick up when back in stock, replacement, or cancel. With a clear 3 day auto cancel fallback stated up front.

Why

The OOS wasn't the customer's fault. Give them every path to still get the item.

The switch itself

Switch 01. Address selection

Problem

Switching to delivery needs an address. Asking for one mid recovery can't feel like starting over.

Decision

Saved addresses first (primary flagged), add new one tap away, no detour into account settings.

Why

Every extra step here is a customer who gives up and cancels anyway.

Switch 02. Store selection, multi store aware

Problem

Sourcing may split items across stores, and "optimal" for the system isn't obvious to the customer.

Decision

Default store shown with per item availability; the highlighted callout tells the customer up front when items span multiple stores.

Why

A silent store split is exactly what triggers a second wave of cancellations.

Switch 03. Delivery → Same day (eligibility aware)

Problem

Not every item can go same day, and OOS items shouldn't appear as switchable at all.

Decision

Only same day eligible items are listed; OOS items are filtered out entirely, the highlighted note makes the rule explicit.

Why

Offering a switch that then fails validation is worse than not offering it.

Switch 04. Delivery → Pickup (partial aware)

Problem

A customer might want only some items switched, and switching can forfeit paid installation or haul away.

Decision

Item level selection with two highlighted truths: unselected items stay delivery (charges remain), and installation/haul away is refunded if switched.

Why

Partial switches are the realistic case. Hiding the trade offs erodes trust.

Switch 05. Payment: charge or refund

Problem

A switch can net to a charge or a refund depending on the new method. Including OOS triggered ones.

Decision

New vs. original order summary side by side; the highlighted line shows exactly what will be charged, or the total shows the refund. Always before confirm.

Why

A surprise charge at the end of a recovery flow undoes the recovery.

Switch 06. Success & failure

Problem

A silent success is confusing; a dead end failure just becomes a cancellation with extra steps.

Decision

Stacked confirmations that handle multi status switches at once, and a failure state that routes back rather than dead ending.

Why

The fallback still has to be at least as good as doing nothing.

Before designing the flow, I checked what the rest of retail actually does when a fulfillment promise breaks. The answer, almost everywhere, is the same: there is no switch. You either accept a substitute, or you cancel and start over. The self service path I was designing didn't have an obvious competitor to benchmark against, because it barely exists in the market.

✓ full support  ·  ~ partial / one narrow case only  ·  ✕ not offered. Cancel & re order

The detail behind the marks is where it gets interesting:

So the reframe from the brief wasn't just internally novel, it was a genuine gap in the category. The industry treats a broken fulfillment promise as a binary: substitute the item, or cancel the order. This work adds a third path, switch how it's fulfilled, keep the sale, triggered at the exact moments customers hit the wall, across both web and chat. That's not a polish on an existing pattern. It's a capability the largest players in the category simply don't have.

Broken down: $6.2M of BOPUIS abandonment cancellation saved (13% of that opportunity), $7.6M of OOS cancellation saved (13%), $8.7M of truck delivery delay cancellation saved (20%), plus a further $6.1M in additional cancellation value recovered across both workstreams.

What surprised me: how much of what gets logged as "customer cancelled" was actually "customer gave up because we didn't offer them a real alternative." The cancellation reason dropdown had been sitting there as a research instrument the whole time, we just hadn't read it that way before.

What I'd do differently: the three entry points catch the customer in the moments they react to a broken promise. But the system often knows a delivery will slip, or a pickup item is short, before the customer does. The natural next move is a fourth, proactive entry point, a push or email that surfaces the switch before they ever open the order in worry. Turning recovery from something the customer reaches for into something the system offers first.

The uncomfortable question: is switching fulfillment always genuinely better for the customer, or does it sometimes just delay a cancellation that was going to happen anyway? We could measure "saved a sale" cleanly. We never found a clean way to separate that from "postponed a refund", and I think that's still worth someone's attention.

"Order status" was the #1 intent for customers calling Lowe's contact centre. Over 600,000 calls a year. A tracking page exists to answer that question before someone picks up the phone. Ours wasn't doing it.

The old experience was live for Truck Delivery only, and it answered "where is my order?" with "8 stops away." That's a dispatcher's unit. It doesn't convert to time in any way a customer can predict. Eight stops could be forty minutes or three hours. The rest of the page was carrier telemetry surfaced raw: FedEx scan events, warehouse city names, a tracking number shown twice. And at the top, "Estimated Arrival Today" sat directly above a scheduled window of "7am to 9am" on a different date.

If your tracking page shows a stop count, a scan log, and two conflicting dates, it isn't deflecting the call. It's generating it.

The core move was small and total: stop reporting position, start answering the question. "8 stops away" became "Arriving in 45 Min · Estimated Arrival 5:30 PM." The map went full bleed with a live route and a vehicle that actually moves, refreshing on a timer with an honest "Updated 2 mins ago" stamp. The carrier scan log became four plain states a person can read at a glance.

It worked. Independent valuation put it at $1,110,887 in FY26 and $215,166 in FY27. $1.33M annualised, modelled from unique visitors interacting with tracking, adjusted for the share who historically would have called, at an $8.33 cost per call. These are soft savings: the model assumes call volume reduction frees capacity rather than cutting headcount, and it gets re forecast over 52 weeks post launch.

Release one left exactly the problem I'd flagged: a customer with a Gig order and a Truck order saw two different tracking experiences from the same retailer. When leadership revisited it, I made the case again, but this time I wasn't asking them to take my word for it.

The second release is where the work got interesting, because I finally had room to design the states that don't appear in a happy path kickoff deck.

One tracker, four plain language states, Received → Preparing → On the way → Delivered, applied identically to Gig and Truck, across web, mWeb and native apps. The interesting design isn't the happy path. It's what the same component does when the plan changes.

State 01. Received

Problem

Before a driver is assigned there's no vehicle to show, but the customer still wants reassurance.

Decision

Dashed route between store and home, a committed "Arriving by 8 PM," and an explicit promise to update at each step.

Why

An empty map reads as broken. A dashed one reads as "not yet."

State 02. On the way

Problem

This is the moment the customer would otherwise call.

Decision

Live vehicle on a real route, a time window ("Arrives 7:35 to 7:50 PM"), a "45 Mins Away" chip, and an "Updated just now" stamp.

Why

A window plus a countdown answers "when" two ways. The timestamp tells them the data is alive.

State 03. ETA updated (running late)

Problem

A silently sliding ETA is how trust dies, and how a call gets made.

Decision

Amber treatment, an honest headline ("Taking a little longer, but it's on its way"), and the reassurance that matters most: still arriving today

Why

Customers forgive a late delivery. They don't forgive finding out late.

State 04. Truck: delivery window missed

Problem

A missed window is the worst moment in the whole journey, and the old design had no answer for it at all.

Decision

Red state, the next available window offered immediately, and two recovery actions: Reschedule, or Select Different Date.

Why

The failure state is where a tracking page either saves the order or loses it. Give them the fix, not an apology.

State 05. Add items, while the window is open

Problem

Same day orders have a short window where more items can still join the run, and customers didn't know it existed.

Decision

A live countdown, "You have 9:58 min to add items to this delivery", turning tracking from a passive status page into a revenue surface.

Why

Urgency is real here, not manufactured. The window genuinely closes.

Worth being precise about the first figure: it's a soft saving. The valuation models call deflection against an $8.33 cost per call and assumes freed capacity gets reallocated, not cut, and it's re forecast over 52 weeks post launch. I'd rather quote it accurately than round it up.

Plenty of the original vision didn't survive the timeline or the third party data dependencies. Naming it honestly is more useful than pretending the shipped version was the whole idea:

Also cut: an upsell rail on the tracking screen, and a multi order view for customers with several deliveries in flight. Both are still the right next moves.

What surprised me: that losing the first argument was what won the second one. If I'd held out for the unified system at the start, we'd likely have shipped nothing that quarter and had no evidence to argue with. Shipping the scoped version bought the proof.

What I'd do differently: I'd have built the Truck states as designed but unbuilt from day one. Specced and componentised even while only Gig shipped. When leadership reversed, we'd have been weeks ahead instead of starting the second round from scratch.

The uncomfortable question: the $1.33M is a modelled soft saving, not money in a bank account. Call deflection is real, but "freed capacity" only becomes value if the organisation actually redeploys it. I can prove people stopped calling. I can't prove what that capacity went on to do.

I've spent enough evenings on stage and enough afternoons in dance studios to know what these problems feel like from the inside, the message that never gets a reply, the gig you hear about two days too late, the sense that nobody's actually looking out for you. So when I read the founder's brief, I wasn't reading a market research summary. I recognised every line in it.

The founder's own research had already named the problem in three parts: performing artists and creative professionals lack support and direction and constantly patch together third party tools; discovering quality talent quickly for collaborations is a crowded, noisy search with no centralized platform; and creators who do get visibility are still at the mercy of algorithmic bias, trends, and platforms that own their data

None of that was unique to Talentverse's pitch deck, it was the documented state of the creator economy at the time. Industry estimates sized it at roughly $104B in 2022, the year this project started, already growing fast toward the quarter trillion mark analysts were forecasting for 2023. Independent artists were, and still are, one of the least served slices of that market: almost none of the tooling in it was built with performing artists specifically in mind.

That constraint, no budget, no existing community, no reliable channel to reach the audience shaped everything that came after it more than any feature idea did.

Instead of a survey form nobody would fill in, we designed one short, consistent interview: the same handful of questions, asked to every artist. What are you struggling with right now, what have you already tried, what would actually help. Then we posted each artist's answers as a short interview style piece on Talentverse's own social channels.

That single decision did two jobs at once. Asking the same questions every time turned scattered conversations into comparable data. Patterns showed up after a dozen interviews that a single conversation would have missed. And every interview was also a piece of content: the artist got visibility, Talentverse got a following before it had a product, and the platform's earliest community was built out of the exact people it was designing for.

Being a dancer myself helped more than I expected going in. Artists tend to open up differently to someone who's actually stood backstage waiting for a set to start, not just someone holding a clipboard, a few interviews turned into genuinely candid conversations because I could ask the right follow up question, not just the scripted one.

Part of making the case for a new platform was being honest about what artists were already using, and where each one fell short for this specific audience:

No single competitor covered all three. That gap, not a clever feature, was the actual opportunity.

The interviews mapped cleanly onto the founder's original three problem areas, which became the brief for information architecture:

That research shaped two connected areas of the site, Social/Discovery and Courses, which became the scope of this design phase. Every artist's path through Talentverse ran along one of two tracks:

Screen 01. Discover / social feed

Problem

Standard follower count feeds reward existing reach, not talent. Exactly what artists said they were tired of.

Decision

Feed built from the interview format itself. Short artist profiles with real answers, not vanity metrics.

Why

The research method and the product surface became the same thing. Discovery that's actually about the work.

Screen 02. Instructor / artist profile

Problem

Recruiters and collaborators said vetting talent across scattered platforms was their single biggest friction.

Decision

Profiles built around portfolio, tagged skills, and reviews. Structured for fast scanning, not a wall of links.

Why

Fast, credible vetting in one place, the "talent hunt" problem from day one of the brief.

Screen 03. Course library

Problem

"I don't have anyone to learn from" came up almost as often as "no one can find me."

Decision

Structured course paths as a first class section, not a bolt on. Directly maps to the brand's "Advancing" pillar.

Why

An artist who can't grow their craft won't stay for a directory listing.

Screen 04. Course detail

Problem

Generic course pages read like SaaS onboarding. Wrong tone for a creative audience.

Decision

Applied the brand's dark, gradient led visual language and Como/Poppins type system directly into the product UI.

Why

The platform needed to feel like it was built by people who understood creative work, not enterprise software.

Screen 05. Course creation, instructor side

Problem

Instructors had no simple way to package a workshop, course, or one on one class themselves.

Decision

A guided two step form, details first, availability and pricing second, instead of one long page.

Why

The biggest blocker to supply side growth is getting an artist's first listing live in minutes, not hours.

Screen 06. Creator insights & analytics

Problem

Artists had no visibility into whether a course was actually working, no data, no feedback loop.

Decision

A dedicated analytics view, revenue, ratings, likes, and enrollment, per course, not just platform wide.

Why

Ties back to "talent struggles": artists said they lacked support and direction. Data is a form of both.

Screen 07. Artist / creative profile

Problem

A teaching profile (instructor) and a creative profile (artist identity) are two different things. One page can't do both jobs.

Decision

A separate profile for the creative side. Skills, achievements, certificates, and "open to collaborate / open to gig" status, distinct from the course teaching profile.

Why

Not every artist on Talentverse teaches. Everyone still needs a credible, browsable identity.

Screen 08. Gig / opportunity matching

Problem

"Finding quality talent quickly for collaborations is a crowded challenge", the deck's own words for the talent hunt problem.

Decision

A dedicated Opportunities listing, pay range, dates, location, applicant count, linked straight to the poster's profile.

Why

Discovery and paid work needed to sit one click apart, not live on two different platforms.

Talentverse never reached real users, so none of these have a metric attached. What I can stand behind is the reasoning:

The Courses and Social/Discovery experiences were designed end to end, full UI, a component system, and a working prototype, and handed off for development. What came after wasn't a design problem: funding tightened and the build stalled before it reached a stable, shippable state. Talentverse is currently paused rather than live, with the design and research fully intact.

I'm including this case study anyway, because the research and the design decisions behind it were real, tested against real artist input, even though the product never was.

What surprised me: how much research design work doubles as marketing when your users are also your earliest community. The interview method blurred that line in a genuinely useful way. I hadn't designed a research method that was also a growth channel before.

What I'd do differently: formalize the interview answers into a proper research repository as we went, not just design inputs I kept in my own notes. That documentation would be worth more today than most of the screens.

The uncomfortable question: is it fair to call this a "case study" when the product never met a real user? I've included it anyway, a portfolio that only shows what shipped hides how most early stage design work actually happens, and I'd rather be honest about that than pretend every project ends in a launch.

I went into this project as a designer who happens to dance. I came out of it thinking about the two a little less separately, the instinct for knowing when a room needs something different, on a floor or on a screen, turned out to be the same instinct.