Retail: Fashion Marc O'Polo's journey to create content-driven experiences

Summary

• Dissatisfied with their legacy architecture, Marc O'Polo undertook the journey of a complete relaunch - moving to a modern eCommerce setup within 12 months.

• Operating in a highly competitive market with a greater emphasis on seamless omnichannel experiences, finding a new content solution was on top of the list.

• After building a prototype in only 2 days, Storyblok was set up as the new CMS.

• Today, Storyblok is not only used to manage content, but also to maintain promotions, merchandising, redirects, shop configurations, and more.

The initial challenge: Legacy content management

As a brand with a global reach, Marc O’Polo produces a great amount of content for its online shop. The content is not only high in volume but also diverse both in its format and also its target audience. Providing a seamless user experience across 40 different countries requires a top-notch content management strategy.

This means, of course, that content-related issues are even more critical than usual: localization, content governance, omnichannel publishing, and the need for effortless collaboration between developers and content editors to run innovative and creative campaigns. After all, in such a hyper-competitive market, creating customized and personalized user experiences is only achievable when developers and business users can easily work together.

A quick look at the current state of the fashion/clothing market clearly shows why these issues are becoming so central. As more and more people prefer to buy their clothing products online, the competition becomes exponentially more intense. This competitiveness serves the consumers well, as their online experience continuously improves. However, for companies, this means catering to a consumer base that expects fast, personalized, "1-click" shopping experiences.

Initially, Marc O'Polo relied on a legacy system to manage their content and run the online shop operations. The system put heavy restrictions on the tools and frameworks that developers and content editors were allowed to use. More specifically, the legacy architecture resulted in every new change requiring a disproportional amount of effort.

Developers often felt anxious trying anything new, as it could have resulted in a serious problem somewhere else in the system. The legacy system forced compromises to both developers and business users. Perhaps even more concerning was the fact that compromises on one side (either content editors or developers) did not even result in a better experience on the other side. This left both developers and content editors with a sub-par experience, without any meaningful payoff.

For Johannes and other developers at Marc O’Polo, the lack of flexibility and powerful features were major pain-points:

The "monolithic" architecture of the legacy system refers to the fact that the frontend and the backend were tightly linked together. In practice, this means:

• Dealing with multiple content silos for each channel, instead of a central hub

• Restrictions on how quickly new technologies can be integrated into the system

• Extensive time needed for simple tasks such as content reuse

• Limited customization

• and much more

In addition to acting as a barrier to developer creativity, the monolithic system also required a considerable amount of time spent on repetitive tasks. Something as simple as building a list with products and overriding it with a title would turn into an unnecessary challenge. For developers, the restrictions of the system also meant that developing locally was not an option. So each and every time the code had to be pushed into a remote system - further slowing down the whole team.

On the other side of the company, the content team was not having a much better time doing their tasks. Content editors had to constantly struggle with a counterintuitive system that had an intimidating learning curve. The complexity of implementing changes and coming up with new modules was a bottleneck for the whole team.

For a Business Development Manager like Sidonie Steiner, this was an obvious issue that had to be resolved as soon as possible. The legacy system not only slowed them down considerably but also failed to offer business users a consistent editing experience - especially when it came to omnichannel content management.

Relaunch of the webshop and the CMS implementation

By 2020, Marc O’Polo went through a complete relaunch of the online shop, including both the frontend and the eCommerce backend. A major part of the relaunch was fixing the content problem by finding a new CMS solution. Decisions such as this one require a cross-departmental effort, and finding solutions across teams is a big part of Maria Künzner’s job as the Technical Project Manager.

One major goal of the relaunch was to move away from the monolithic suite, to a modern API-based software solution. In the case of a new CMS, this meant a headless system that would give developers like Johannes the flexibility they needed while empowering content managers and business users like Sidonie to easily create customized content.

An extensive list of requirements and features was created to help choose a new CMS. This list included input from both developers and content editors. Among many things, the system was supposed to streamline omnichannel publishing, have exceptional localization capabilities, offer intuitive ways to utilize content governance and collaboration, and take considerably less effort and time to run the operations. 

While looking for a new API-based content solution, a new CMS was put into place to replace the legacy monolithic system. However, after a while, it became clear that the new CMS was not up to the task, and failed to live up to the initial list of required features. This was of course very discouraging, as everyone had to compromise again, right out of the gate:

Being in the middle of a huge relaunch project, almost no one was thinking about yet another new CMS. However, for Johannes, this was an option worth exploring. After all, one of the goals of the relaunch was to give both developers and content editors an intuitive system to work with. The newly implemented CMS was already limiting Johannes and his team during the development phase. The features and the overall flexibility of the system were not on par with the expectations that the team had at the beginning.

With that in mind, Johannes started to look for an alternative and soon ended up on Storyblok's homepage.

Finding Storyblok and building the prototype

For Johannes, the list of features that Storyblok offered was a perfect fit for their original requirements. Storyblok’s headless approach matched perfectly with their stack, and its real-time visual editor would give content editors complete control over their work. Additionally, Storyblok’s localization capabilities, modular approach to content structure, and content governance options made the decision even easier.

However, there was one big problem: with the company still being in the middle of the relaunch, and only 5 months after setting up a new system, convincing everyone to migrate to yet another CMS was not going to be easy.

After Johannes brought up his idea to the greater team, he was predictably met with some skepticism. In particular, Maria, being the Technical Project Manager, was hesitant to start another project while still busy with the ongoing relaunch. So she set a hard goal with a strict deadline for Johannes before making any decisions:

Picking out the most complex content modules that they had, and asking him to build them in Storyblok in only 2 days!

Taking advantage of Storyblok’s free trial, Johannes immediately got to work. The task was pretty daunting; something similar took almost 4 months with the CMS they had in place at the time. 

After only 48 hours, Johannes was finished with the prototype in Storyblok and everything was set up and running smoothly. For Maria, this was exactly what every team needed - an agile system that helps you get things done, and doesn’t get in your way. With the developers and the Technical Project Manager on board, convincing the other teams followed quickly, and after only 14 days a completely new CMS was in place!

Working with Storyblok: More than a CMS

With Storyblok set up, developers and content managers can now exercise a great degree of freedom. Instead of dedicating their efforts to time-consuming workarounds, they now can focus their time on more creative tasks. For Sidonie and the content team, the benefits came in different forms. The real-time visual editor was the true What You See Is What You Get experience that they were looking for from the beginning, and the modular approach to content structure offered them an easy and intuitive way to manage content:

For business users like Sidonie or developers like Johannes, Storyblok goes beyond what a traditional CMS is supposed to do. Different teams at Marc O’Polo use Storyblok not only to manage content, but also maintain promotion logic, merchandising, redirects, and shop configurations.

The current technology stack at Marc O’Polo is a modern API-based solution with best-of-breed principles at heart. The frontend is running with VueJS and NuxtJS for server-side rendering. With Storyblok as the CMS, other microservices are integrated to the stack with ease, be it an external tool or one developed in-house. The API-first approach means any future technology can be easily integrated into the stack at any point.

For a global company like Marc O’Polo, localization and agile content governance are absolutely essential. With Storyblok, scheduling content and releases are taken to another level by their seamless integration into customized workflows and pipelines. Storyblok’s localization capabilities help content teams publish their material in 6 languages simultaneously and offer their services to users from 40 different countries. 

For Project Managers like Maria, having happy developers and content managers is a huge step towards successfully running large-scale and cross-departmental projects. By giving developers the freedom to work with the frameworks they are already familiar with, any new capability can be put into place in record time. Similarly, the real-time visual editor paired with the component-based approach to content, allows content editors to easily set up new landing pages and publish or customize new content with a greater sense of independence.