Company
Attractions.io
Role
Product Designer
Scope
Research · UX · UI · Testing
Transforming the Butlin's Activity Booking Experience
Butlin's were scaling their activity offering from ~50 daily slots to over 1,000. The existing interface wasn't going to survive it.
The problem
Guests using the existing app couldn't tell which day they were looking at, couldn't filter the activity list in any meaningful way, and regularly gave up. With 50 slots that was frustrating. With 1,000 it would be unusable.
The brief was clear: redesign the booking experience to handle serious scale without losing the legibility guests needed to plan a family holiday.
Requirements
Scalability
Handle thousands of activity slots without overwhelming guests.
Usability
Fix the navigation and filtering problems the existing UI had made permanent.
Speed
Design and ship fast. The activity centres were already launching.
Research
User testing confirmed what we suspected: the existing system was already struggling. But the more interesting finding came from watching how guests actually navigated the resort. They were relying on physical printed timetables, not the app. Those sheets were battered and annotated and clearly trusted.
Operators had observed guests relying on physical printed timetables around the resort, citing them as more usable than the app. Guests already had familiarity and trust with that format. The challenge was to replicate that usefulness in the app, not design over it.
"Guests trusted the paper timetable more than the app. The goal wasn't to replace it. It was to understand why it worked, and build something that did the same job better."
Process
I worked with Butlin's delivery managers and our internal team to map the full scope: what the API could support, what the event timetables would look like when the new activity centres opened, and what would need to wait. Task flows and card sorting helped shape the structure. Sketches came first, always.
Sketching first
Pen and paper before anything else. It lets you take multiple directions without over-committing early, get rough ideas out quickly, and iterate fast before anything looks finished enough to get precious about.
Wireframes
The solution
Scalable filter menu
The API had filtering data that wasn't being surfaced. A flexible filter panel let guests narrow by date, activity type, and group suitability, with Firebase event tracking built in from day one to inform future iterations.
Sticky date navigation
A persistent date header stays visible while scrolling, paired with a horizontal day selector. Simple fix for the single biggest pain point: guests never losing their place in the calendar.
Testing
40 users: 20 Butlin's regulars, 20 who'd never used it. They completed booking scenarios covering families with young children and group bookings. Both cohorts, both use cases.
Final designs
What I took from it
The physical timetable observation changed the whole direction of this project. It's a reminder that the most useful design research isn't always what you planned. Sometimes it's just watching what people actually do when the app isn't enough.
The tight delivery timeline also forced useful constraints. There was no room for over-engineering. The solution had to be simple enough to build fast and robust enough to scale, and those two things turned out not to be in conflict.