Case study — Calendar Redesign
Reshaping the most-used, most-complained-about feature in the product
"A reference example of mature work" — my manager's review
Emerging Travel Group · mobile app
The redesign was already planned — the job was to validate it before shipping
This is one of the most heavily used features in the entire product — a large share of daily active users interact with it every week, specifically on the mobile app — and it consistently generated more negative feedback than any comparable feature.
A severity-tagged readout that doubled as a prioritization document
I designed a testing guide focused on the most contested design decisions rather than testing everything indiscriminately, then ran moderated sessions with a mix of experienced and newer users across property types. I used a severity-tagged framework (critical / moderate / minor) for every finding, paired with a proposed fix and a team verdict — so the readout doubled as a working prioritization document, not just a list of observations.
I also used the project to mentor a designer through running her own session, building the team's internal capability rather than keeping usability testing as a single-person bottleneck.
Severity, topic, and verdict — for every finding
Users consistently misread color-coded booking status
Users consistently misread the color-coding used to indicate booking status (own bookings vs. external-channel bookings vs. manually blocked dates) — critical, since it affected every single use of the calendar.
Date-range selection was awkward across the board — a fix was proposed and shipped: tapping the first and last date of a range instead of dragging.
A portion of respondents used one particular restriction regularly and valued it; almost none understood the difference between two closely related minimum-stay rules, while the majority wanted a simpler way to just set a minimum length of stay.
A design collaborator flagged that some findings weren't design problems at all but pointed to a separate discovery topic (special/discounted rate logic) — a useful example of scoping findings to the right owner rather than force-fitting everything into one fix.
Split by property type — and measured after launch
The most significant outcome was a decision to split the layout by property type: multi-room properties (hotels) kept separate rate and availability screens, while single-unit properties (apartments) got a combined, simplified view — directly supporting a broader strategic push to make the product more useful for smaller, single-unit hosts.
Following the app launch, mobile engagement with the feature increased relative to the prior period (with no comparable increase the year before, ruling out seasonality), while the frequency of opening the detailed editing panel decreased slightly — my collaborating analyst and I independently arrived at the same read: users could now see the key information directly on the main screen without needing to drill in. A good sign, not a drop in engagement.
I'd push earlier for a dedicated round specifically on the restrictions/settings area — it surfaced some of the clearest, most actionable findings (which restrictions to keep, simplify, or cut), but it was originally scoped as a secondary topic within a broader test.