UI/UX and Digital Product Design Case Studies
Creative5 Case StudiesUpdated Sep 2026
Product design work rarely stays inside the design file. A checkout flow that looks clean in a prototype can fail under real traffic, a dashboard can mislead when its numbers disagree with the warehouse, and an automated assistant can quietly give users the wrong answer. The five cases below follow designers, researchers, and product partners through situations of that kind. Each one starts with a live problem, asks what evidence was actually available, names the limits that shaped the response, and traces who was affected. The goal is judgment under pressure, not a tidy method.
Case Study 1
Checkout failure during a major ticket on-sale
Brindle Ticketing, a regional ticket seller with about 140 staff and a nine-person design team that owns the purchase path.
The situation
Brindle Ticketing sells seats for concerts, theater, and sports venues through a web app and two mobile apps. Its design team of nine owns the purchase path, from seat map to payment confirmation. A redesigned seat selection flow shipped on a Thursday, two days before a major on-sale for a touring act expected heavy demand. By Friday, the queue page was timing out for some visitors, and the checkout completion rate had dropped by roughly a third compared with the previous week. Support tickets described seats disappearing after they were chosen. The on-call engineer rolled back the front end, but the errors continued, which pointed to something in the shared hold service rather than the interface alone.
The challenge
The on-sale was worth a large share of the quarter's fee revenue, and the promoter had been promised a smooth purchase path. The team had little time and uneven evidence: error logs, a small sample of session replays, and the support queue. Replays were sampled at a low rate for privacy reasons, so they showed what some visitors saw, not what everyone did. A full rollback would also remove the accessibility fixes that were the main reason for the redesign, so it could not be the default answer.
Analysis
Teams grounded in UI/UX and Digital Product Design tend to start an incident by asking what the business cannot afford to lose in the next few hours, because that answer sets the order of work. Here the on-sale carried the revenue and the promoter relationship, so checkout completion became the number to protect, not the visual polish of the new seat map. Evidence came in unevenly. Error logs showed that holds were failing but not why a seat looked open to one visitor and taken to another. Replays described the symptom and support tickets supplied the words customers used. Each source was labeled by what it could and could not prove.
Time pressed on every choice. Engineering could ship a server fix only after the hold service's deploy pipeline cleared review, so the earliest realistic repair was several hours out and the interface had to carry some of the load. Designers could adjust copy, add a clear waiting state, and disable the seat map for the most affected browser versions without touching shared services. Stakeholder impact was uneven. Customers who had already paid for a seat bore the most harm, the promoter carried reputational risk, and the box office was fielding calls it could not resolve. Every change was weighed against what each group would see within the hour.
Actions taken
- Flagged the seat map for browsers showing the hold error and left checkout live for everyone else. The flag was scoped by user agent and rolled out to a small percentage first.
- Paired an engineer with a designer for a live session replay review, with each finding tagged to a specific log line before anyone proposed a fix.
- Rewrote the waiting state and the error copy so visitors knew whether a seat was held for them, and the support team received a short script matching the same words.
- Wrote a short prevention checklist: hold service changes require a design review of the seat states, and every release gets a canary with checkout completion as its gating metric.
Results
Within the same day, checkout completion on flagged browsers returned to near its prior level, and the queue timeouts fell sharply. The on-sale closed without a rollback of the full release, and the accessibility work stayed in production. The hold service patch shipped after a second review. The post-incident note recorded three things: the seat map had been sharing a hold timeout with the payment step, the canary gate had not included checkout completion, and the support script had been written after the first wave of tickets. Shared services now get a design review.
Questions for discussion
- Which evidence would have changed the team's first hypothesis, and how early could it have been collected?
- How should a design team weigh a partial rollback against the accessibility commitments made in the same release?
- What belongs in a release gate for a checkout flow, and who should own the decision to pause it?
Case Study 2
Resolving conflicting onboarding metrics before a redesign
Pellmark Rostering, a workforce scheduling company serving residential care providers, with an eleven-person product design group.
The situation
Pellmark Rostering builds shift scheduling software for residential care providers, with about 2,300 active facilities and a product design group of eleven. The design team relies on usage reports to decide which screens to rework, and in the second quarter two reports disagreed sharply. The onboarding completion figure from the business intelligence warehouse showed a little over forty percent of new facilities finishing setup, while the product analytics tool reported closer to sixty. Both numbers were cited in the same planning meeting. The redesign of the staff availability screen was put on hold while analysts tried to determine which was right, and the design lead was asked to choose a baseline before the next sprint.
The challenge
The design lead had to hand over a recommendation without a reliable answer. Neither source was obviously broken. The warehouse counted a facility as onboarded only after its first full roster was published, and a sync job that ran nightly sometimes dropped records during a schema change. The analytics tool counted a facility when a first shift was created, which could happen before setup finished. Management wanted a single number for the planning deck, and the team had less than a week before the sprint began.
Analysis
Work of this kind is easier when the decision is named first. The sprint existed to reduce time spent on a screen that new facilities abandoned, so the question was not which number was prettier but which one could show abandonment accurately. Evidence was split into three layers: the raw event counts, the transformation rules applied in the warehouse, and the documented definitions held by the product team. Designers do not usually read lineage diagrams, so the team made a one-page map of where each metric came from, the job that produced it, and the last run that completed cleanly.
Limits were mostly about time and access. The warehouse team could rerun a job only during its maintenance window, and the analytics vendor's export had a row limit that made a full reconciliation impossible without sampling. Designers could not change either system, so the useful work happened in the definitions. Stakeholder impact was significant. Facility managers who had been asked to pilot the new staff availability screen were waiting on a decision, sales used the onboarding figure in renewal conversations, and engineers would bear the cost of rework if the wrong baseline was chosen.
- Trace lineage Map each figure back through transformations to the raw event source.
- Validate transformations Compare row counts and definitions at each join, not only the final total.
- Monitor drift Alert when row counts or completion rates move outside a set band.
- Review with designers Publish definitions beside each chart so decisions cite the same meaning.
Actions taken
- Split the rendering bill by request type and found that about a third of cost came from combinations ordered fewer than five times in a month.
- Built a prototype of the tiered cache with two combinations pinned, and tested it on three older phone models before any pricing logic was moved.
- Wrote a short decision memo listing what each option would cost to run, who would carry the on-call duty, and what would reverse the choice.
- Set a rule that any cached combination must pass the same access review as the pricing service, and scheduled a monthly check on cache hit rates.
Results
The reconciliation found that the warehouse dropped records during schema changes, which accounted for most of the gap. A smaller part came from the definition: the analytics tool counted a facility as onboarded at its first shift, while the business definition required a published roster. Once both were aligned on the product definition, the completion rate landed near fifty-two percent, which the team reported as a range. The staff availability redesign went ahead in the next sprint with the baseline attached to the design brief. Two alerts were added to the nightly job, and the definitions page became a required link in every design review.
Questions for discussion
- Which of the four steps in the loop is most often skipped in product teams, and what usually causes the skip?
- How should a designer report a metric whose source is still under review without appearing to take a side?
- What level of disagreement between two sources should stop a redesign decision rather than inform it?
Case Study 3
Suspicious downloads from a contractor design account
Greywater Benefits, an enrollment software company for employers, with a fourteen-person design team that includes two researchers.
The situation
Greywater Benefits runs enrollment software that employers use to manage health and retirement choices for their staff. Its design team of fourteen works in a shared design workspace where unreleased prototypes, research recordings, and a copy of anonymized enrollment journeys are stored. In the third week of the quarter, the security team flagged a sequence of file downloads from a contractor account, roughly two hundred items in under an hour, outside the usual working pattern. The sign-in came from a location the contractor had not used before and from a session that began about four hours after the account's normal hours had ended. The contractor's manager could not confirm the activity.
The challenge
The response had to be fast enough to limit exposure and careful enough not to lock out a contractor who might be legitimately traveling or working unusual hours. The design team did not own the security tooling, and its only direct controls were sharing permissions and the prototype hosting settings. Research recordings contained participant names and health details in some sessions, which raised the stakes for anything that had already left the workspace. Leadership wanted an answer on scope before the afternoon briefing.
Analysis
The business objective was containment with minimal disruption. Employers trusted the platform with sensitive staff information, and a public disclosure would cost more than any single design delay. Evidence was partial. The access log showed the sequence of downloads and the sign-in source, but it did not show what each file contained, and the file names were generic. The research team could list which recordings were stored in the folder, which narrowed the question of what was at risk. The team therefore treated the log as a lead to verify, not a finding, and avoided making claims about content until it had been checked against the folder index.
Operational constraints shaped the order of steps. Revoking the account immediately would stop further exfiltration but would also cut off a contractor who was in the middle of a sprint handoff, and the security team needed to preserve the session evidence before any change. Design leads could restrict sharing on the workspace and pause external links, but could not inspect session tokens. Stakeholders were uneven. Employer clients had contractual notice obligations, the research participants had consented to a narrow use of their sessions, and the contractor deserved a fair hearing before being named in any record.
Actions taken
- Restricted external sharing on the workspace within the hour and suspended the contractor's download permission while the security team preserved the session logs.
- Pulled the folder index with the research team and listed every file that could contain participant data, so the review focused on a short, known set.
- Wrote a notice to the security lead describing what the design team could and could not confirm, with each claim marked as verified or pending.
- Asked the vendor manager to confirm the contractor's current project scope, and documented the answer before any access was restored.
Results
The investigation found that the sign-in came from a network the contractor had not used before, and the contractor later said a personal device had been connected to a shared password manager the prior week. The downloaded files were prototype assets and anonymized journeys, with no identifiable recordings. Access was suspended for less than a day, then restored under a narrower scope after the vendor manager confirmed the work was needed. Because no participant data left the workspace, employer notice was not triggered. Workspace sharing is now restricted by default, and session alerts go to both security and design operations.
Questions for discussion
- Which parts of the access log would a designer need to read with care, and which should be left to the security team?
- How should a team decide whether suspending a contractor's access is proportionate when the evidence is still incomplete?
- What default sharing settings would have limited the exposure in this case without slowing legitimate research handoffs?
Case Study 4
Choosing a rendering architecture for a furniture configurator
Ashcombe Home Interiors, a made-to-order furniture retailer with about 320 staff and a seven-person design team.
The situation
Ashcombe Home Interiors sells made-to-order sofas and dining tables through a web configurator. Shoppers choose frame, fabric, legs, and dimensions, then see a three-dimensional preview with updated pricing. The product has grown from a few models to over 1,400 fabric and finish combinations, and the preview loads for many shoppers on the same mobile devices they use to compare prices. In the busiest month of the year, median time to first preview rose from under two seconds to nearly nine, and abandonment on the configurator page climbed sharply. The company's cloud bill for rendering had also grown faster than order volume, which made the cost question visible to finance.
The challenge
The architecture group had to choose between three approaches before the next quarter's catalog launch, which added several hundred new combinations. Each option moved cost, latency, and risk in a different direction. Security requirements applied too: customer dimension data and unreleased fabric pricing could not be cached in shared locations without access controls. The operations team had a small on-call rota and no appetite for a new rendering service they would have to run at night.
Analysis
The business objective was to bring preview time back under three seconds at peak without letting margins slip. Product leaders cared about conversion from configurator to cart more than about rendering fidelity, so a slightly simpler preview was acceptable if it kept the price and fabric accurate. Evidence came from three places: performance traces from real sessions, the rendering bill broken down by request type, and a set of sixty moderated sessions in which shoppers described what they needed to see before committing. Those sessions showed that most shoppers needed a faithful silhouette and a correct fabric swatch before adding to cart, while the full view mattered mainly before payment.
The three options were a live client-side renderer that streamed shared geometry, a server-side render farm that produced images on demand, and a tiered approach that cached common combinations at the edge while rendering rare ones on request. The client-side option pushed cost onto shoppers' phones and created unpredictable behavior on older devices, which the support team already saw. The farm was simpler to secure but needed capacity planning and a rota the team did not have. Merchandising and finance cared about cost per configured order. Each option was scored against workload shape, security constraints, and the ability to run it safely.
Actions taken
- Split the rendering bill by request type and found that about a third of cost came from combinations ordered fewer than five times in a month.
- Built a prototype of the tiered cache with two combinations pinned, and tested it on three older phone models before any pricing logic was moved.
- Wrote a short decision memo listing what each option would cost to run, who would carry the on-call duty, and what would reverse the choice.
- Set a rule that any cached combination must pass the same access review as the pricing service, and scheduled a monthly check on cache hit rates.
Results
The team chose the tiered approach, with the most common frame, fabric, and dimension combinations cached in private edge storage keyed to access controls. Rare combinations render on request in a small, scaled service with a fixed daily budget. Median time to first preview came down to just under three seconds at peak in the first month after launch. Rendering cost per configured order fell, and the operations team kept its rota because no new always-on farm was needed. Pricing and fabric data stayed out of shared caches, which the security review confirmed.
Questions for discussion
- Which measurements would you want before trusting a score like these, and which ones would be misleading on their own?
- How should a design team represent the trade-off between shopper speed and rendering fidelity to a merchandising group?
- When is a simpler preview a product decision rather than an engineering compromise?
Case Study 5
Automated listing drafts with human review and bias checks
Tamsin Goods, a marketplace for handmade and secondhand items with about 180 staff and a six-person design team.
The situation
Tamsin Goods runs a marketplace where independent sellers list handmade and secondhand items. Roughly 48,000 listings go live each month, and many arrive with thin descriptions, missing alt text, and unclear photos. A vendor pitched an automated listing assistant that drafts titles, descriptions, and alt text from uploaded images, and rewrites the error messages in the seller flow. The pitch promised that sellers would finish listings in about half the time, and that the catalog would reach accessibility standards without manual review. The design team was asked to run a pilot in one category before the wider rollout planned for the following quarter.
The challenge
Early demonstrations looked convincing, but the team had seen automated text fail quietly before. Alt text that sounded fluent could describe the wrong object, and descriptions could assign gender, age, or origin to a product or maker without any basis in the photo. Error message rewrites risked changing the meaning of a validation rule. The team had six weeks of work available for the pilot, one part-time analyst, and no labeled set of past listings with known-good alt text.
Analysis
The business wanted faster listings and a more accessible catalog, and both goals were legitimate. The risk was that a tool optimized for speed would move errors into the public catalog where sellers and buyers could not see them. The evidence available was thin. The vendor's accuracy figures came from its own test set, which was too vague to judge, so the team set its own measures: a sample of listings reviewed blind by two designers and one accessibility specialist, scored for factual accuracy, omitted or invented attributes, and whether the alt text served the purpose of the image. Those measures decided whether the pilot earned a wider rollout.
Room to maneuver was small. Listing photos were processed in batches overnight, so any error discovered in the pilot would take a full cycle to correct, and the seller support team could not absorb a surge of complaints about odd descriptions. Designers could turn the assistant's output into a draft only, and the seller had to approve every field before publication. Stakeholders had different stakes. Sellers, many of them small makers, bore the reputational cost of any wrong claim about their work, buyers relied on descriptions to decide, and people using screen readers depended on alt text that matched the image.
- 1Draft from photosAssistant proposes title, description, and alt text for each uploaded image.
- 2Seller approves fieldsEach field is accepted, edited, or discarded before anything is published.
- 3Blind audit sampleTwo designers and an accessibility specialist score a weekly random sample.
- 4Threshold gateRollout continues only if error rate and alt text accuracy meet agreed limits.
- 5Rollback pathAny category over the limit reverts to manual drafting within one batch.
Actions taken
- Defined four measures before the pilot began: factual accuracy, invented attributes, alt text purpose match, and seller edit distance, each with a written threshold.
- Required seller approval on every generated field, with the original input kept visible beside the suggestion so the seller could compare them.
- Set up a weekly blind audit in which designers scored listings without knowing whether the text came from the assistant or the seller.
- Agreed a rollback rule with the seller support lead: any category that crossed an error limit would revert to manual drafting within one batch.
Results
The pilot ran for six weeks in one category of about 4,100 listings. Sellers accepted roughly two thirds of proposed descriptions with little or no editing, and listing time fell by about a third for the heaviest users. The blind audit, though, found invented attributes in about one listing in twelve, most often material, origin, or age claims on handmade goods. Alt text described the wrong object in a smaller number of cases. The team held the rollout. The vendor was asked to tighten the prompt constraints, and the category was re-scored against the gate after the next audit.
Questions for discussion
- Which of the four measures would you trust least on its own, and what second measure would you pair it with?
- How should a platform weigh seller time savings against the risk of small, repeated errors that buyers rarely report?
- What would a fair rollback threshold look like for a tool that affects many sellers unevenly?
Learning Resources
Creative CASE STUDIES
China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.