Would you say that in 2022 e-commerce creative teams can be truly creative with their website? Can they create new visuals and add them to the website with relatively high level of freedom? Without struggling with engineering and hearing “it’s not possible”? Without constantly fighting for development resources and waiting weeks for new ideas to happen?

Unfortunately, in most cases the answer is no.

It hurts e-commerce businesses badly. Website is a brand temple. If storytelling capabilities are limited how are you supposed to optimise customer experience? In a perfect world content teams would have a lot of creative freedom, they could make and break things fast, quickly spin off new ideas, experiment. In reality most new ideas get stuck with developers.

It might sound like a problem for a modern CMS like Contentful, Contentstack, Amplience, Sanity, Shopify Online Store 2.0, etc. The problem is I'm talking about companies that already have one. Modern CMS allow you to modify some content without developers but they are all form-based, non-visual and every block must be custom coded. The amount of visual options you get is severely limited. It’s very far from what content teams actually need and any new idea that doesn’t comply with existing system must go through developers anyway.

Can it be solved? Can creatives get more freedom while keeping developers happy? I believe you can. But before we get into solution, let’s first analyse what's so problematic about current way of managing content.

Let’s take a look at a typical campaign page and how it’s managed in a modern CMS. In this article I’ll use Contentful as an example. If you’re not familiar with Contentful, don’t worry. All the concepts are similar in other CMS and all my arguments apply to them too.

Our example campaign page is short and simple. It’s composed of 3 content blocks: intro banner, featured products and banner about 100-day trial:

Let’s see how our campaign page looks in Contentful:

No matter which CMS you use, the page entry will always have some meta fields: page URL, page title, fields related to SEO, social media, searchability, etc.

But the crème de la crème of each page entry is “real content” - the content blocks used on our campaign page.

In literally every headless CMS you compose pages (or parts of pages) out of reusable content blocks. Each reusable content block is represented by its content type with unique name and fields.

In our demo we use 3 content blocks:

1. Block > Banner
2. Block > Products Grid
3. Block > Two Columns

Let’s take a closer look at them.

By changing the fields in the form you change how banner looks in your website. There are 5 fields available: Title, Description, Image, Button Label and Button Link. If you have a new idea that isn't covered by those 5 fields you must probably go to developers.

Where do our content blocks come from? Why are they even there? Why the fields are what they are? To better understand this, let’s take a closer look at how Banner is actually built.

Designer built it in Figma, Sketch or similar. Obviously these tools don’t generate production-ready code, you just draw on a canvas. At that particular point in time, this Banner was exactly what was required, it satisfied business needs.

In order to make it available for the content team, it had to go through following process:

1. Developer coded the banner in HTML/JS/CSS in your front-end.
2. Developer added a new Content type to your CMS (Blocks > Banner). She defined  fields, order, validations, etc.
3. Developer connected everything together (fetching data from CMS and applying it to banner code).

It takes some time. But once it’s done, you can easily create as many Banners as you want and add them anywhere you want without developers. It took a minute or so to build our new banner:

The promise of this approach is that once you put in some initial developer work, you can compose content easily and quickly without needing developers.

In theory it sounds good. Unfortunately, only in theory.

Let’s see alternative banner variants that our content team might need:

None of them is achievable with the existing Banner. If you want any of those changes you must go to developers. And it means waiting. They’re probably busy. And some of those variants require a lot of development time.

The same problem applies to our Product Grid:

I made up around 20 examples (took me 3 minutes) but could easily make up 100s of them. It’s extremely rare to see such a comprehensive set of content blocks that creative teams are satisfied. Personally, I’ve never seen one.

Another problem is that even if you get to the point where you have huge amount of content blocks with huge amount of options, you still edit them with forms. And the bigger your design system, the harder it is to edit things with forms. There are just too many options and too many nested entries (I recently heard a term “blockception” from a client, LOL). To handle such complexity you need visual editor, not forms.

The bottom line is that despite having reusable content blocks, most new ideas have to go through developers because they were not predicted before. In the worst case scenario (very common unfortunately) new ideas will be killed by engineering team because there is no capacity. In a more optimistic scenario they’ll be scheduled for development and released after some time. Most frequently it won’t happen fast and the process is painful with all the feedback loops etc. Forget about building something in 1 day or usually even 1 week. The struggle is inevitable. It’s never easy.

However, there are multiple problems with this approach:

1. It’s very hard and there’s big chance such project will fail. You must have very experienced team of designers and developers to that correctly. The success of such project depends on how well the team can predict future use cases. You can’t do it right without experience.
2. Even if your team is super experienced, the cost will be high. Months, not weeks, of work.
3. The bigger the system the worse the UX for content team. They will still edit content with forms. When you have many nesting levels and many visual options, it quickly gets very confusing.
4. The cost of CMS will grow significantly as you will use much more content types.

As you can see, both cost and risk are high. I don’t think it’s a right thing to do.

Well, have you ever tried to build responsive rich content layouts with WYSIWYG?

Yeah, you know what I mean. It’s like trying to run with swimming fins. It just doesn’t work, they were not designed for this. They were designed for text and not much else.

But it never stops surprising me is to how much energy people can spend to get some layout working in WYSIWYG. It is insane how much you can endure only because your alternative is waiting for developers 🤷

The reason is that e-commerce need custom code to survive. And custom code + visual builders are not a perfect match:

1. Advanced and complex visual builders are a big “no” from engineering team. The risk of screwing up the website is too big.
2. Simple visual builders are almost always too simple and visual flexibility is affected too much. Designers won’t like them because they can’t customise designs properly. (Still, too simple is way better than too hard).
3. Embedding custom-coded components is not possible. This one is huge. My favourite example is a Product Card component. Product Card can be very complex (data fetching optimisations, connected to cart, variants pickers, lazy loading, etc). Not being able to embed custom-coded Product Card in visual builder is an instant “no” for e-commerce.
4. No design constraints. Design-driven brands take huge amount of energy in keeping the right look of their website. Visual builders must be able to respect design system and design constraints. And it must be easy to do.
5. Poor workflows. Form-based CMS might not be visual but the workflows they offer are extremely advanced. Publishing, reviewing, scheduling, permissions, custom apps, etc. No serious business at scale will ditch them for visual builder.
6. Bloat. If visual builder generates ton of bloat that deteriorates performance then it’s a no-go, period.

I have personally never met a visual builder that meet all those criteria.

So we built one.

I built everything visually, without developers. In less than 2 minutes. It’s a very simple example but it’s just a tip of an iceberg what you can do with Shopstory at full scale.

I believe this is another level or productivity. Shopstory integrates with your headless CMS and your storefront so that you can build things without developers. Visually, no forms. And the best thing you can keep reaping all the benefits of both your headless CMS and decoupled front-end. You’re not losing anything. You just get new options. It’s just a powerful extension.

I didn’t mention last important advantage of traditional form-based content management in headless CMS. Editors get low level of flexibility but at the same time there’s a certainty that it’s developers who build layouts. And developers are professionals. They know how to do it, how to handle responsiveness, edge cases, how to test stuff. The site will work correctly.

That’s true.

But at what cost? There’s definitely a trade-off here. The more control you pass from editors to developers the more expensive and long the process of building new stuff is. And you want to be agile and fast.

At Shopstory we know how important that risk is. That’s why we spend insane amount of hours on thinking how to give editors power and yet confidence. Some decisions we made in order to make it work:

1. Predefined content blocks. We’re not giving editors “canvas with layers”, where you can endlessly nest things inside of things, build complex hierarchies, absolute positioning, flexboxes, grids etc. It would be really hard to manage for non-technical people. Instead of that we give editors simple yet powerful pre-built blocks with relatively small amount of options. Options that always work. It’s hard to break them.
2. Automatic responsiveness. Responsiveness is hardest part of building layouts. Our AI-driven algorithms take care of responsive layouts automatically. You can always override defaults if you want, but by default for whatever you build on desktop, the mobile looks good.
3. Custom components. Editors shouldn’t be able to build everything in visual builder. Some things are too complex and must be done by developers. Product cards in e-commerce are connected to e-commerce platform, cart, they often have built-in variant pickers with lazy loading capabilities, etc. And they’re usually heavily optimised, because they’re so common. Should editors build product cards in visual builder? Definitely not. What we do is we allow developers to publish custom coded components for being used in Shopstory. It’s a no-code and code mix and I truly believe this is the future of web.
4. Design tokens. Shopstory is heavily tokenised, by default editors are allowed to use only fonts, colours and other design tokens that are accepted by designers. Thanks to this no matter what you build it’s consistent with your branding.
5. Performance obsession. We put huge amount to have state-of-the-art performance. No bloat. Content built with visual builder can’t screw up performance. Otherwise it’s a crap.

We believe that with proper care you can really keep the best of both worlds: confidence and flexibility. Obviously there’s a limit to that and visual builder will never be as flexible as custom code. Nor it should be. That’s why for really custom needs you’ll still need to go to developers. Let’s just make it happen less often. Both creatives and developers will be happier.

I love Webflow claim: “Your website should be a marketing asset, not an engineering challenge”. In reality most of headless ecommerce today are engineering challenge. It’s okay for some use cases like for performance, integrations, stability. But for content management? Not really. Developers shouldn’t be the bottleneck and shouldn’t own the process. Creatives should.

There’s magic in the concept where developers build all the complex things (a “skeleton” or a “frame”) while knowing that within that system editors will be able to modify website with a visual builder. It’s kind of like “no-code-driven code”.  I truly believe it’s the future not only for e-commerce but for web in general.

Thank you for reading. If you want to follow along or have some comments, you can always find me on Twitter. I'm more than happy to discuss this topic.