When designing a new site or app, you may begin to pen down all the great, revolutionary new features you are going to add in. As you begin user research you might notice them looking for information that is just not there on your current site or app. This is a great opportunity to build in that content into your designs.
However, adding these new elements into your site can have a significant impact for the CMS team who manages the data.
Take for example you’re working on an eCommerce site that sells t-shirts and you learn that users really want to know what the cotton/polyester blend is on said t-shirts. So you build in an awesome new widget that allows the user to filter out t-shirts within a given ratio. You also determine that t-shirt color is important and create a little swatch grid for users to select their desired color without navigating to the product page. These are both great ideas and should be implemented, but at what expense?
Too frequently we design and develop with little thought towards who’s going to be managing this content going forward. And who is going to add these new data points to thousands of SKUs within the CMS or commerce platform?
The previous t-shirt example happened to me. I was managing the CMS team at the time of this new feature roll out. The designer built a beautiful new page design, got these new features to the developer and the developer started work immediately. I got called into the discussion 3 weeks before launch to approve the new feature roll out plan.
I asked the designer and developer, “How we were going about getting the swatch image for each SKU. Was it going to be automatically calculated based on the SKU image?” Nope.
“You’ll need enter in the hex code for each SKU”, they told me. “Oh, and we will launch in 3 weeks and we didn’t build in a fallback plan if a SKU doesn’t have a swatch.”
Great.
My team spent the next few weeks scrambling, reaching out to t-shirt vendors, seeing if they had the hex code handy. We also added plugins to our browsers to capture the hex code with a color picker. Fortunately, for everyone involved in this project we filled in every last hex code just days before the launch (we did have to spend some time post launch cleaning up some colors that were “off”). During this time of adding this new data point into our CMS, I had to pull valuable resources previously allocated to other projects, putting those projects behind schedule.
Now that we’ve got that out of the way we won’t have to worry about hex codes any more, right? Wrong. It’s now a new data point that we have to capture on each of the almost 100 new clothing SKU we add every week. Let’s say that this one new data point only takes us 1 extra minute to gather and input into our CMS. That is 100 minutes (2.75 hours) every week dedicated to this singular data point. By the way, we rolled out 15 new features and 6 new data points with that build. We later had to hire a new editor just to support the reduction in bandwidth on the team. All of which we had not planned on.
All this pain could have been significantly reduced, if not prevented altogether had the conversation started much earlier in the process. Often the CMS team can be the missing puzzle piece to help unify the final project and ensure a smooth launch and ongoing management.
So when you start your next design project, ask yourself the following questions:
- Who’s going to manage this new feature?
- Is the ROI for the new feature worth the management impact?
- Should we loop the managing team into the design discussion?
After all, you want that new feature to be rolled out and managed correctly, right?
Eric Davis 