Aero StudioMeridian
A shift scheduling app with twenty-two features, three of which accounted for almost all use.
The situation
Meridian is used by shift workers in hospitality and healthcare to see their rota, swap shifts and request time off. It had been in the market for six years and had grown the way products do — every enterprise customer that signed asked for one addition, and every addition shipped.
By the time we were brought in, the app had twenty-two top-level features, a five-item tab bar with an overflow menu, and a support burden that was growing faster than the customer base.
What the data said
The client had good analytics and had never looked at them from this angle. When we did, the picture was unambiguous: 94% of sessions involved one of three actions — checking the next shift, swapping a shift, or booking time off. The median session lasted under forty seconds. Most sessions happened between 6am and 8am, or immediately after a shift ended.
Then we watched people use it. The pattern was consistent: open the app, ignore everything on screen, navigate two levels down to the rota, screenshot it, close the app. Several people told us they kept the screenshot because loading the rota was slow enough to be annoying when you were standing outside in the cold.
People were not using our app. They were using a photograph of one screen of our app.
What we changed
The redesign opens directly on the rota. Not a dashboard containing the rota, not a home screen linking to it — the thing itself, cached locally, rendered before the network request completes and updated silently when it returns. If the phone is offline the last known rota is still there, with a clear indication of when it was fetched.
Shift swapping and leave requests moved to persistent actions on that same screen. The remaining nineteen features moved behind a single menu, ordered by actual usage rather than by the order they had been requested in. Four were removed entirely after we established that no customer had used them in over a year.
We also reduced the app's cold-start payload substantially. The rota view now needs one request rather than four, and the whole first screen renders from cache in under a second on the mid-range Android devices that make up most of the user base.
The part that was harder than the design
Removing features from a B2B product means telling customers who asked for them. We wrote the communication plan alongside the design work and helped the client run sessions with the six largest accounts before anything shipped. Of the four features removed, one turned out to matter to a single customer, and was reinstated behind a setting. The others went quietly.
Outcome
- Time from launch to seeing your rota: 6.2s → 0.9s median.
- Support tickets tagged "can't find" down 61% in the first quarter.
- Sessions ending in a screenshot down by roughly two-thirds.
- Twenty-two features to eighteen, with the remaining ones easier to find.