Company
Attractions.io
Role
Product Designer
Scope
Research · UX · UI · Testing
Managing Categories & Points of Interest at Attractions.io
Attractions.io's content management tool gave venue operators control over their guest app, but managing hundreds of POIs and categories had become slow, fragmented, and frustrating. Customers were raising support tickets for things they should have been able to do themselves.
The problem
Connect, Attractions.io's CMS tool, let customers manage the content of their guest-facing app, but the POI and category management experience had accumulated friction over time. Editing a single POI required navigating to its own page. Reordering categories meant contacting support. Bulk changes weren't possible at all.
Customers were doing workarounds, support were fielding requests that should never have reached them, and subcategories, a powerful feature, were being ignored because nobody could find them.
Goals
Self-service
Let customers manage categories and POIs without needing engineering or support involvement.
Reduce friction
Cut the time spent on routine tasks, editing, reordering, bulk toggling, to a fraction of what it was.
Drive engagement
Surface underused features and make the management experience good enough that customers actually used it.
Research
Interviews with customers and the customer success team surfaced a consistent pattern. People couldn't reorder things without help. Editing individual POIs one at a time was exhausting at scale. Nobody had discovered subcategories.
"I want to move a category to the top of the list, but I don't see any way to do that myself."
"I spend too much time clicking around just to edit POIs. Is there a quicker way?"
"Can I disable an entire category at once instead of going through every POI?"
"Managing POIs on the app is too time-consuming. We need efficient bulk changes."
Feature analysis
A structured audit of the existing system mapped every task against the number of steps it required. The pattern was clear: the interface had been built one feature at a time, and navigation had grown around it rather than being designed for it.
Hundreds of POIs with no way to filter or batch-edit. Category ordering locked behind support. No inline editing anywhere.
"The interface had been built one feature at a time. Navigation had grown around it rather than being designed for it."
Process
Story mapping helped frame the scope, not just what to fix but what a good end state looked like for each user type. The key structural decision was to bring POI and category management into a single unified interface rather than keeping them siloed.
Wireframes & testing
Prototypes were tested using Maze across multiple iterations. The key finding: users preferred table and list views for scanning large datasets over tile layouts. That aligned with existing platform patterns and gave a scalable foundation for filtering and bulk actions.
The solution
Unified interface
POI and category management brought into a single view, with no more context-switching between separate sections of the tool.
Batch operations
Enable, disable, or reassign multiple POIs at once. The task that previously required clicking through individual pages became a two-step action.
Search, filter & drag-to-reorder
Customers could now find, sort, and reorder content themselves, no support ticket required.
Final designs
Impact
Post-release Hotjar observation captured one customer enabling and disabling 20 POIs in under 2 minutes, a task that had previously taken 5–7 minutes of individual page navigation. Search and filtering were used heavily from day one.
The support team saw an immediate drop in category management requests. Customers were doing it themselves.
What I took from it
The most valuable research came from the support team, not the users. The tickets they were fielding were a perfect map of where the product had failed to explain itself. It's a data source that's easy to overlook.
The phased release also taught me something: testing close to launch isn't enough. We caught some usability gaps in post-release observation that earlier testing would have surfaced in time to fix. Committed after this project to building that into the process, not treating it as optional.