Shipt CMS is the internal tool used by marketing and digital merchandising teams to design and publish pages across Shipt's global surfaces: landing pages, seasonal campaigns, and promotional pushes, all built from UI components like product shelves, promo cards, hero carousels, and banners.

I'm the sole designer embedded in the product team, helping shape the roadmap. That can mean shipping a new feature from scratch or improving something that's been causing friction for months.

When I inherited the tool, one of the first things I did was start talking to users to understand their day to day and their process before getting into the CMS and after, to get the full end to end picture. I interviewed team leads across marketing and digital merchandising and mapped the workflow from start to finish.

What came out of that was a journey map that reframed the entire conversation with stakeholders. For the first time, the team could see where users were losing time, and it wasn't from lack of effort. It was a tool that had never been designed around them.

The CMS had been built by engineers solving engineering problems. Terminology reflected the system architecture, not how content teams think. Workflows were non-linear. Information that users needed was buried behind interactions that only made sense if you understood how the backend was structured.

While going through the tool, it became clear that some UI elements existed purely to support engineering testing. They had never been removed. Users were seeing information in their interface that had nothing to do with their work, and naturally had no idea what to do with it.

The response to this, for a long time, was more training. If users were struggling, the assumption was that they hadn't learned the tool well enough. But no amount of training could fix a foundation that wasn't built for the people using it. The tool needed to change, not the users.

One of the most immediate pain points was scheduling. Take Valentine's Day. A merchandiser needs to know what product shelves are already scheduled for that homepage slot before they can plan. It's prime real estate and there's limited placement. The CMS had that information, but it was buried behind interactions that made no sense unless you already knew the system.

So instead of finding it themselves, users asked on Slack. An engineer explained where to look. The next person asked the same question. The engineer explained again. This was a constant loop and it showed up every single time there was a high-traffic moment on the calendar.

The fix wasn't a new feature. It was surfacing the schedule directly in the view, showing what was live and what had expired without a single extra click. No calendar to open, no button to find. The information was already there. It just wasn't visible.

While working on the scheduling fix and spending more time with users, it became clear the problem went beyond any single interaction. People weren't just struggling to find information. They had no real home base in the tool. I brought that to my PM and we started scoping a personal dashboard as a dedicated starting point for every user.

Before it existed, users landed on a default table that showed marketing content first. Every merchandising user started every session with an extra click just to reach their own work. If two people were creating content at the same time, finding yours in the list was luck.

What research kept surfacing was a pattern. People were spending more time navigating the tool than actually creating. There was no natural starting point either. Some users started by building a page and adding content to it. Others built the content first and figured out placement later. Everyone had a different entry point, and the tool accounted for none of them.

Here is an example of what my handoff looked like for the preview card. I wanted to call out every piece of information surfaced within it because that detail was the whole point. The card had to work hard enough that users never needed to click through just to figure out if they were looking at the right thing.

The dashboard was one of five. The roadmap I shaped with my PM is building toward a CMS that works the way content teams actually work, with governance, accountability, and collaboration built into the tool rather than managed in Slack.

Role-based permissions will give admins, developers, marketers, and merchandisers the right access without the right friction.

Approval workflows will move the verbal sign-off process into the tool, creating an audit trail and reducing errors going to production.

Commenting will bring the feedback loop into context. Right now it happens entirely outside the tool.

These three features together represent a shift. From CMS as a publishing tool to CMS as a collaborative platform.

In the NPS survey after launch, satisfaction went from 6 to 7.5 out of 10. Users specifically called out the dashboard as the most helpful change. The Slack support channel got quieter. Engineering was pulled in less.

My PM and I had calculated that the engineering support required to build a single page was costing an estimated $700. Per page. Not because the work was complex, but because the tool wasn't self-serve. That number hasn't been remeasured since the changes shipped. That's the next milestone.

The work doesn't stop here. The roadmap ahead includes new features that continue pushing the CMS toward something content teams can fully own, alongside enhancements to what's already there as we learn more from users along the way.