Michaels Content Management System

My first project at Michaels was to lead the adoption of a Content Management System. Previously, Michaels engineered their custom CMS, but it required too much maintenance that leadership chose to migrate to a 3rd party system. Because of my extensive experience with replatforming and design systems, I was chosen to define what the CMS needed in order for the business units to be successful. The goal of the project was to create a single system that could create create pages for both Michaels and Makerplace e-commerce teams with minimal to no development involvement post-launch.

discovery

There were 2 lanes of discovery needed for this:

1. What do we need in the CMS?

2. How were we going to build a single CMS that met both business units?

In order to define what we needed, I led a series of workshops between both Michaels and Makerplace e-commerce teams. These teams function completely separate from one another. We first documented their process from how they take an idea/change through the execution and pushing content live. Then once we had their separate workflows we were able to identify commonalities because we needed to understand the high level what is needed by their team to create content, review/approve content, and launch content. Then I led content workshops. These teams were used to someone custom developing a “component” for what specific instance they needed. In this workshop, we laid out the key pages they wanted to migrate and I started to group similar components together. I led many sessions explaining what a component was, why reusability matters, and trying to connect patterns together because as stated before, the teams were conditioned to create unique components or exceptions to a rule. We eventually came out these workshops with a list of templates and components that the e-commerce teams said would help them launch a subset of content pages.

In the other lane of discovery, we had to ask ourselves how are we going to architect a single system that supports two very different teams and brand identities? This is where my passion for design systems came in. I worked with product management and engineering to create design tokens, which historically Michaels and Makerplace had separate codebases and did not share. So this was a big win for the tech team and its still having ripple affects in other areas of the tech.

Iteration

Next came the actual design of the component and authoring experience. The CMS platform we used did not offer any OOTB components. So with every component, I provided the design and interaction, as well as, the authoring controls. I created a template for the product management team to use to communicate what the author should be able to modify in the CMS (ex. layout, backgrounds, etc.), what options they will see (ex. heading value, font color, button type, etc.), and what content the author can insert (ex. character count, file type, text formatting, etc.). I won’t lie, this is where the project started to spin out of control. The e-commerce teams were used to 100% flexibility because we were trying to create a single set of components that could be used by anyone, anywhere. But the e-commerce teams were to used to having their own set of components that were unique to each page template. The number of variants and controls the content authors wanted seemed unsustainable. After many, many meetings explaining that ultimate flexibility results in high maintenance, we eventually gave in. This was without a doubt the hardest part of the project for me because I knew where we were headed, but it got to the point where the team needed to experience it. So we opened the flood gates and let them have all the control and flexibility (within reason 😉).

A few months later the e-commerce team started to assemble their first batch of pages and the feedback was not great. Sure, there was a learning curve to any new system and we didn’t come prepared with training documents for the authors. But, what the authors quickly learned is that by adding so many options on a single component, it actually made the time they spent assembling it significantly greater. So then the conversation became, how do we simplify the components so that our authors can build quickly and easily? Now that we had authors building real content, we (authors, product, UX, and engineering) started to see where there could be efficiencies and where we just needed to simplify things.

Results

We succeeded in fully migrating all content pages into the new CMS. The content teams are 100% self-sufficient creating and modifying pages, and time spent authoring pages did not change with the new system.