Unifying pet commerce, services and rewards

Morshel sold pet products through one flow and booked grooming through another, two apps that happened to share a logo. I merged them into one architecture and pulled the rewards programme out of its own tab into the moments where people earn and spend.

What I can and can't claim here

I designed and delivered this. I did not get to measure it.

The engagement ended in January 2026, before the redesign had a full post-launch measurement window, and the team had no analytics instrumentation beyond basic funnel counts when I arrived. So the 62% abandonment baseline is real and pre-existing; the after-numbers are not mine to claim.

What I did instead was define what should be measured, and instrument the success criteria so the team could read the result without me. Those metrics are below. Where I have a number, it's sourced. Where I don't, I say so.

One note on wording: I was the only designer here, so every design decision below is mine and I write it as "I." The few places I write "we" mean the working group that had to agree on it: me, the two engineers and the founders.

The Problem

Most pet apps treat buying a bag of food and booking a groom as unrelated tasks. Morshel had built both, and users had to learn two different products to use one company.

Where it broke, specifically:

• Discovery: products and services used two separate navigation architectures. Users searching for grooming often ended up in the store.
• Booking: real-time slot availability sat behind a 4-step wizard, so users often abandoned before seeing open slots or upfront pricing.
• Rewards: points, tiers, coupons and referrals were all tucked away in an isolated wallet screen, instead of appearing at the moments people earn and spend them.

What the audit turned up

Three things came out of going through the existing app with the founders and the support log, and they all pointed the same way.

The booking flow lost people before it showed them anything worth staying for. Real-time availability and upfront price are the two facts that decide whether someone books a groom, and both sat behind a four-step wizard. The user was being asked to commit to a path before finding out whether the path was even open.

The rewards programme had the same problem in a different shape. Points, tier status and coupons all lived in their own tab, and as far as actual behaviour went, that meant they didn't exist: nobody navigates away from a booking or a payment screen to go and check whether they have something waiting. A balance you only see when you go looking for it isn't a loyalty programme, it's a line in a changelog.

The third one only became obvious once I started sketching live states. When your dog is at the groomer right now and you want to know whether it's finished, you want the system to be predictable, not interesting. Every bit of novelty I put into those screens was a cost, and that turned out to be the rule that killed my favourite idea on this project.

Success Metrics

• Increase combined cart checkout completion rate.
• Drive higher utilisation of the rewards programme (points redemption rate).
• Reduce customer support tickets related to order and appointment status confusion.

What I decided, and what it cost

I spent a week building a gamified 'pet avatar room': your pet's profile grew as you bought food and booked grooms. I liked it a great deal. In the review, the founder asked how many taps it now took to reorder dog food. Three. I killed the concept the next morning and went back to standard e-commerce patterns, which is a dull sentence to write and was the right call: this is a utility people open with a task already in mind, not somewhere they come to spend time.

The scope fight went the other way. Engineering wanted to ship grooming booking without live slot synchronisation to make the launch date, a version where you pick a time and find out afterwards whether it existed. Given what the audit had just told me about why people abandoned bookings, shipping that would have been shipping the original problem with new colours. I proposed a two-stage rollout instead, which kept real-time availability in scope rather than letting it become the thing quietly cut to save a date.

The one rule I refused to bend was that earning and spending points gets no detour. If applying a balance meant a trip to the wallet tab, most people were never going to bother, and the whole point of the engagement was to get that programme used. So the earn moment had to sit on the confirmation screen and the balance had to be applicable inside the payment step, or it may as well not have been built.

Ideation & Module Architecture

I focused on modular, system-first thinking before touching visual design. The product was broken into 9 core modules to manage complexity and keep commerce and service flows consistent.

Feature Deep Dive

Final UI Gallery

Thirteen screens across the four flows I owned: entry, service booking, rewards, and the commerce and post-order stack.

Two things I reference above aren't in these thirteen: the cart and payment step, and the live slot picker. Both were designed and handed over; they're just not in the export I kept, and I'd rather say that than let the gallery imply it covers everything.

Sign-in: One button, no form. The old entry asked for phone, OTP and a profile before showing anything, so I cut it to a single Google tap and moved every other field to the point where it's actually needed: breed and size get asked during the first booking, address during the first order.

Welcome: One confirmation beat between auth and the app. It exists to say the account is done and nothing else is being asked for. The previous flow dropped you into a half-filled profile form here, which is where a chunk of the drop-off sat.

Appointments: A dated agenda rather than a list of bookings, because the question people open this with is "what's happening today," not "what have I booked." Service type, pet and breed sit on the card, and the note to the specialist, "my pet went through a knee surgery recently", is shown, not buried, since that was a live support-call topic.

Empty state: I designed the empty case alongside the filled one rather than after it. The date strip and the primary action stay exactly where they are (only the middle changes) so an empty day reads as "nothing booked" instead of "something failed to load."

Booking add-ons: The old four-step wizard revealed price at the end. Here the base service is priced up front, every add-on carries its own price and a one-line description of what it is, and the total updates as you tick, so the number at the bottom is never a surprise. Nothing is pre-selected on the user's behalf.

Confirmation: The one fact that matters after booking is the date, so it's the only fact on the screen. This is the screen I'd change first now: it reuses the "your pet is snoozing" illustration from the empty state, and using the same image for "nothing here" and "you're booked" is a mistake I'd catch earlier today.

Points earned: Rewards used to live only in a wallet tab. I moved the earn moment onto the confirmation itself, as a sheet over the appointment you just made, and wrote the terms into it, "points will be credited after completion", so the reward isn't promised in a way the system can't honour if the service is cancelled.

Balance & referral: Balance, tier and the recent delta (+10 MP) in one block, so "what do I have and did it just change" is answerable at a glance. Referral is a sheet on top rather than a separate destination: it's an offer, and burying an offer in its own tab is what caused the original problem.

Coupons: Each card leads with the saving and states its condition on the second line: "Flat ₹200 OFF / on orders above ₹1,499." Discount screens that hide the threshold until checkout generate support tickets, and the founders were already getting them.

Listing: Sort and Filters are pinned to the bottom bar, in thumb reach and visible the whole way down a 4,231-product result; previously they were a drawer you had to know about. The result count is stated in words, and availability (Sold Out, Best Seller) is on the card rather than discovered on the product page.

Product detail: Ordered by what blocks a purchase: price and rating, then weight variant, then bank offers, then the pincode check. Long-form description and specs are collapsed into accordions so the page stays scannable, and Add to Cart is sticky so the decision can be made at any scroll depth.

Orders: Products live here; appointments live in the agenda. Splitting them was the call: "where is my grooming slot" and "where is my order" are different questions and one merged list answered neither well. Status, order ID with a copy affordance, and points earned sit in the group header, so the list answers most queries without opening anything.

Returns: The refund amount and its status lead the screen, because that is the only thing someone on a return is looking for. Tracking number, payment method and invoice sit below it, and "Need help with this order?" is the last line rather than a floating support button; by then the screen has usually already answered the question.

Tradeoffs & Decisions

What Changed Because of This Design

Business Impact

Not measured: the team lacked analytics instrumentation post-launch. The target I agreed with the founders was to bring the 62% cart-abandonment baseline under 45% by making the points balance redeemable inside the payment step. Whether it got there is something I genuinely don't know.

Collaboration & Alignment

As a solo designer on this project, I owned the end-to-end design but I was never designing alone. I held bi-weekly alignment sessions with the founders to ensure the UX met their business goal of driving repeat purchase through the rewards programme. When developers pushed back on the complexity of applying a points balance at checkout, we negotiated a phased rollout: launch with manual redemption first, and save automated point application for v2.

Reflection

• What worked: Treating rewards as something that happens inside other flows rather than as a destination of its own. Earning shows up on the confirmation screen, and each order states what it returned: the programme is visible without anyone going to look for it.
• What I learned: Operational clarity matters more than visual delight. Clear system states reduce user anxiety, and designing for failure is critical in live, time-sensitive workflows like service bookings.
• What I'd fix: The reward currency is called MP on the balance screen and Morshel Coins in order history. I shipped both names because they came from different conversations at different times, and I didn't catch it until I laid the final screens out side by side. Two names for one currency is the kind of thing a shared glossary prevents, and I now write one before the second flow gets designed. The confirmation screen also reuses the empty-state illustration, which is the same failure of cross-flow review.
• Next Iteration: Usability testing with real pet owners. The flows above are argued from a support log and a founder audit, not from watching anyone use them, and that's the gap I'd close first. After that, instrumentation on the redemption funnel, so the next person to work on this has the numbers I didn't.