This case study is password protected
When I was brought onto the CMS team, the goal was to help it scale as a self-service product. I turned user pain into a direction the team could build on. The dashboard and enhancements below are what shipped first.
When I was brought onto the CMS team as sole designer, they needed a partner who could shape strategy as the tool scaled forward. The ambition was a self-service product like other industry CMS tools. What we had was tech- and eng-led: 100+ marketing and merchandising users building landing pages, campaigns, and promotional pushes every day, but finding the tool confusing and leaning on training and Slack to get work done.
My role was to understand those pain points and translate them into actionable projects with my PM and engineering partners. I mapped end-to-end workflows with team leads. The journey map showed the CMS reflected system architecture, not how content teams plan, schedule, publish, and collaborate. Five systemic gaps surfaced: discoverability, ownership, scheduling, collaboration, and governance. Not one-off fixes. The reason the product couldn't scale with the org.
I reframed those gaps with my PM: evolve from a publishing tool into a collaborative content platform. The five-part roadmap maps one initiative to each gap, giving engineering and stakeholders a sequenced direction instead of reactive requests. Scheduling also surfaced in research; I shipped it as enhancement work on existing surfaces while the platform bets took shape.
The five-part roadmap
The dashboard was initiative one of five. Everything below is proof that the platform direction was buildable, not just a research deck.
The dashboard validates the platform bet on ownership and discoverability. Before it, users landed on a default table prioritizing marketing content. Merchandisers started every session with an extra click. Finding your work in a shared list was luck. People navigated more than they created, and no entry point matched how anyone actually worked.
Start where the user is. Make status scannable. Support multiple entry points. The preview card was the highest-leverage decision. It had to surface status, schedule, and ownership so users never clicked through just to confirm they had the right item.
Prototype of the full platform direction. The dashboard shipped first; permissions, approvals, commenting, and governance follow on the same roadmap.
Platform direction doesn't pause daily operations. As sole designer, I owned net-new initiatives and the enhancements that kept 100+ users working. Scheduling is the clearest example of the same discoverability principle applied at a smaller scope: proof the strategy held on existing surfaces, not only greenfield work.
Scheduling was the clearest example. Before a high-traffic moment like Valentine's Day, merchandisers needed to know what was booked for a homepage slot. The data existed but was buried, so users asked in Slack, engineers answered, and the loop repeated every cycle. The fix wasn't a new feature on the roadmap. It was surfacing live and expired schedules directly in the view, without extra clicks.
Same principle as the dashboard: the information already existed, the problem was discoverability. The difference was scope. The dashboard was a platform bet on the roadmap. Scheduling was an enhancement that reduced engineering dependency while the larger direction took shape.
User satisfaction (NPS) after launch. Users called out the dashboard as the most helpful change.
Before launch, my PM and I estimated engineering support at roughly $700 per page because the tool wasn't self-serve. Not remeasured post-launch, but the baseline we're working against.
The impact on the space outlasts any single ship. The org now has a shared product direction, a roadmap sequenced against real workflow gaps, and early proof that users can self-serve without engineering in the loop. Metrics confirmed the direction; the remaining roadmap carries it forward.
