Attendees: Henry France – Marketing Manager, Sean Lamacraft – Head of Technical Services, Chris Rickles – Senior Front-End Developer

Can you tell me about the site redesign?

HF: We’ve been in existence for 17 years now, but in the last two or three, we’ve evolved quite a bit. Many agencies are able to ‘talk the talk’, but not necessarily ‘walk the walk’. So we revisited our proposition strategy, and the website was just one part of executing that.

How did you learn about headless CMS? When did it first appear on your radar?

SL: We’ve been Kentico partners for 12 years, and one of the highest ranking gold partners in the UK. We got a heads up about Kentico Cloud a couple of years ago, and signed up for the early partner program – I think we were one of the first to utilize it for a production site. 

We wanted to try something a little larger after our first couple of sites, and our website seemed like a good candidate.

Talk me through the key reasons why you decided a headless CMS would be good for your redesign.

HF: From a marketing perspective, we just wanted something a bit more flexible and that made content authoring quick and easy. 

We looked at many different options to add to our tech stack, and wanted to get in on some more modern technologies. On top of that, we wanted the design to be cleaner and have full control of the mark up.

CR: I had the freedom to write the mark up I wanted to write and use its flexibility to build, without fearing it would change further down the road. I could write the exact HTML, pass it to Sean—then he’d plug it in and that’s that. It gives us the opportunity to expand as well. We’ve opened it up to adapt easily in the future.

Were there any considerations you needed to address beforehand, and what would you say they were?

HF: We cast our net quite wide. We looked at Umbraco, HubSpot, and Contentful, to name a few. But we settled on Kentico Cloud for a few of the aforementioned reasons, and because we were encouraged by the philosophy of product releases. 

It’s come a long way in a short time.

SL: Given the velocity of the way it’s changed, it seemed like a safe option. We’ve spoken a lot to the support guys, come up with suggestions on how to change things, and when these appeared on the roadmap, it was quite positive. That helped with our decision to use it. 

CR: Some of what we had done previously also helped inform that decision. We also had a consideration towards maintenance, because utilizing Cloud makes that much easier. The only upgrades we need to do are changes to the front end—that’s going to save a lot of time.

If we wanted to do a complete rebuild, it’d be a lot quicker, and that’s what held us back from initially redesigning for a long time.

Talk me through the development process and timeframe, especially lessons learned

SL: In terms of timeframe, we had just over a month from starting the project to build. As with every project, we started with a bit of a discovery and fact-finding mission. This was looking at the tech we’d be using, the approach, what we wanted it to look like. 

That leads on to the wireframing exercise. After wireframing, we can start, in parallel, a whole bunch of things: building content types, designing the site itself, and starting the build, which is one of the benefits of the headless option.

It’s not a waterfall approach anymore, it’s more agile and this allows us to adapt and change, and test as we go.

In terms of lessons learned, the one takeaway for me was about publishing content. We took the approach of adding it all, leaving it unpublished because we were using the preview API on our staging site which is all well and good—but when it came to saying ‘right, we’re ready to go live’, nothing was published.

In hindsight, it would have been better to publish the content straightaway, then just create a new version, unpublish, and change it. 

How do you feel the non-technical people were able to contribute to this project?

HF: I think obviously editing content without being able to see what it looks like on the front end was a new experience for us. 

Working in parallel was also interesting. I’m not sure I’d necessarily say it was ‘collaborative’ because you could say the opposite is true in that the roles are so clearly defined. We were all able to work independently without affecting each other. But while traditional approaches often cause bottlenecks, the team was autonomous on this project.

So it was more streamlined, and people could just get on with it? They knew what was expected of them and they weren't so dependent on another role to finish what they have to do before they can move further?

SL: Exactly. There’s an element of collaboration, the way the content fits around the front end. Because of the way they run in parallel, we have page structures built and we add the content at the same time as the front and back end are being built.

It gives us the opportunity to adapt and be a little more agile in making fixes, rather than waiting until the very end when you put the content in and realize it doesn’t quite work, then going back and changing the site. 

It allowed us to produce the final product a lot faster, which I think will mean less stress. People aren’t saying ‘you need to do this before I can do my thing’.

CR: The separation of the front and the back end was a little clearer too. We can get on with what we’re good at without trying to fight against the process.

And for the copywriters, did you do things like content guidelines for content types?

HF: Absolutely. We knew from the designs how much content we were going after, and within Kentico Cloud, we could set clear parameters on headers, body, supporting images, and any structured data – anything a content editor needs.

The validation means that if they go over the limit, they can’t publish a page. You could argue there’s less rework because you’re giving them strict boundaries—you have to get it accurate first time.

You could also argue the quality of the content goes up, particularly with character counts. Every word counts and the quality of the work is streamlined and more useful. 

Which features of Kentico Cloud did you use in particular, and which ones did you find the most useful?

SL: Essentially, we used all of them. We used the preview API for our staging environment so we didn’t have to worry about publishing stuff. We used the web hooks for the cache and validation; workflow for the content admins, which we slightly customized; when building the page types, one of the handiest things are the content type snippets—the reusable blocks of content which we use for all the metadata and generic page data that will carry across all the pages for our first project. Previously, it was a case of doing it again and again.

One of the other features that’s available through GitHub is Cloud Model Builder, so you can produce all your strongly typed classes from the content types you produce. We just hit enter, and we use that as part of our build process to regrab all the models and build the classes off the back of them. It was a piece of cake, and that was a lifesaver in terms of time.

What are the main benefits you would advocate to anyone considering a headless approach?

CR: From a technical standpoint, the speed of development was very beneficial because you can work side by side and in parallel. You can produce something a lot faster at the same quality.

It was a delight to work on because it was just pure front end—in Kentico Cloud, I knew I could build it in flat HTML and it wouldn’t really change much. 

SL: What also helps is the speed of the site. You’ve got more of a say into what goes on in the site, so we’ve made our site exceptionally lightweight, and load time is ridiculously fast. From an end user point of view, it means having your project delivered faster, changes are a lot quicker for us to do, and it, therefore, ends up costing them less. 

CR: The speed at which we produced it meant we were able to concentrate on the nice bits. We’ve been able to do nice animation on the home page, and features on all of the pages. Little tweaks that make it just a little bit more distinctive. Often on projects, they’re a nice to have. But we had the time to do it.

HR: That’s not to say we don’t already have a Phase Two and Phase Three in the works with other nice-to-haves. 

Our MVP was quite a stripped-back version of what we ended up with. That’s just a testament to how quickly we were able to adapt and move on things. I just felt that the creativity behind this site wasn’t restricted as far as it can be with a traditional CMS.

I was so pleased with the end product that it blew my expectations out of the water.

As a digital agency having Kentico Cloud in your portfolio of tools, how do you imagine using it in your ongoing and upcoming projects?

SL: We have some other projects coming up, including a smaller site for Pan Macmillan. For them, we’ve built our own custom API that controls all their data that feeds off Kentico Cloud and into another site of theirs that’s EMS based.

As an agency, we tend to go down a vendor-agnostic route. We’re not believers in ‘one solution fits all’, but if we can use Kentico Cloud for our site, then it’s safe for a client to use on theirs. 

We’re our own best case study. If we’re putting our faith and trust in the platform, that makes it a lot easier to sell to people when advocating for it.