Consolidating Deals Instead of Multiplying Card Types
Safeway had four separate types of savings, J4U deals, buy-one-get-one offers, promo codes, and club card deals, spread across a confusing set of screens, and a single product could carry more than one at once. The easy fix is a card variant for each deal type. I didn't build that, because a product with two or three deal types stacked would still need its own bespoke card, and that number of variants grows every time the business adds a new promotion type. Instead I designed one standard product card with a deal section underneath it that scales independently, from zero deals to several, and pulled every deal type into a single tab so users stopped guessing where a given discount lived. The card system had to hold up under combinations the business hadn't invented yet, not just the ones that existed at launch.
Cutting Category Browse From Four Screens to One
Finding a product meant drilling from a top category into a subcategory into a sub-subcategory before a single buyable product card appeared: Baby Care to Baby Accessories to Bottles and Nursing, three taps before anything a user could add to a cart. I collapsed that into a single accordion screen: open the top category, and the subcategory expands in place alongside featured products, the full product set, and any further breakdowns still available underneath it. Users reached real products in one screen instead of three, and Safeway got a slot to feature a curated product carousel it didn't have before. I paired this with predictive search and a recently-searched list on the home tab's search entry point, so browse and search were solving the same problem from two directions.
Choosing the Checkout Model Least Likely to Fail Quietly
Eight of the app's top ten pain points traced back to checkout, and the single biggest exit point in the flow was the date and time selection step. I built three checkout concepts against the same three objectives: reduce friction and keep users oriented, surface the right information at the right moment with real-time validation, and keep things transparent and controllable once checkout was done. We moved forward with the table-view option. It reduced friction the most and was the easiest of the three to scale as new order types and edge cases got added later, but it gave up some of the moment-to-moment visibility the other concepts had built in. I mitigated that by investing more heavily in the post-checkout Your Orders experience, using iconography and notifications to keep users oriented after checkout instead of during it. The alternative concepts protected against that risk earlier in the flow at the cost of more friction throughout. I bet a strong post-checkout safety net was worth trading for a faster path through it.
