Can you build a plane starting with a car chassis?
Can you easily turn a desktop app to work on a mobile phone later?
Can your regular bike be converted to electric?
The answer to all of those questions is "yes", and even when the amount of work needed to achieve the transformation is the same, the end result will suffer having started from an inappropriate place. It’s similar to adding Stackbit's visual editing interface to website or digital experience as you’re building them, or after the fact. The amount of work is the exactly the same, but adding Stackbit early on will help you avoid irrevocable damage and waste a lot of efforts into solutions you’ll end up not needing.
Back to our analogies, if you know the end goal is an electric bike, it's easier to build the frame with the battery, cables and controls in mind before. If you're building a plane, you'll probably use lighter materials, place the wings differently and not have 4 huge wheels, and if you know your app will be used on a mobile phone, you'll create touch friendly controls that match a tiny screen from the very beginning.
What are the pitfalls of adding a visual interface too late?
Making limiting architectural compromises without cause
Using inferior information hierarchy and content models
Losing a huge amount of engineering and marketing hours on unnecessary training and support
Let's shed some more light on these issues below.
1. Making limiting architectural compromises without cause
If your content source (often a headless CMS) is also your primary editing experience, you're much more likely to store all your content in that one content source. This means you might have to migrate content from other places into it, you'll store content in it, even though that content is better stored in other formats/mediums and you'll spend a lot of money on that content source.
This is pretty natural, since you don't want to send your editors to edit in multiple locations (and even before that, figure out which application they should log into to edit that particular piece of content).
Migration takes time, reducing your ability to move fast, capture the market, experiment and iterate.
It also means that you might have to force content that might not be suitable for a headless CMS to now be stored in it (for example, design and presentation information).
Finally, most content storage systems will charge you the more content you store in it, often crossing thresholds that make things exponentially more expensive for content that should be there to begin with.
If on the other hand you have a visual interface that enables any marketer to just click on a title and edit it, while the system syncs it back to the proper content source, you're free to migrate things gradually (if at all), store only content that makes sense in the headless CMS (such that is transferrable across multiple interfaces, needs internationalization, etc.) and other content elsewhere, while your team always has a single place to log into and edit.
2. Using inferior information hierarchy and content models
When your business team members, such as marketers, need to edit in a headless CMS, they are exposed to the implementation details of your components.
This means that if you've chosen an Atomic design system, when your marketers need to build a Hero Section, they'll have to understand a build something like "Row, with two columns, the left column having 4 more rows to include a title, subtitle, text and buttons, etc."
If that's too complex and you'd rather allow them to have a single click Hero Section model, that's great, but every time they need to tweak something (for example use 3 columns), they'll have to go back to the developer to either create a "3-col Hero Section" component, or add another property to the existing Hero Section.
So the architect or developer has to make a decision between flexibility and ease of use, for example. With Stackbit's visual interface, you can benefit from both worlds because Stackbit enables even non-technical people to save templates of their complex component setups and use them with one click, even if in the underlying CMS tens of objects are instantiated and linked to enable that.
Furthermore, ask any headless CMS employee and they'll tell you that getting the content model right is the number one indication of success of a company using it. What does "right" mean? Well, it means your marketers have the right controls in place to create the experiences they envision to drive business impact. Without a visual interface to easily manipulate the components in the building phase, it might be way too late by the time they have to make that change that goes into production tomorrow morning.
3. Losing a huge amount of engineering and marketing hours on unnecessary training and support
Editing a webpage or an application screen without seeing how it looks like is borderline impossible.
It's equated to building a Lego creation with blindfolds... you can feel the pieces more or less, minus their color, and even build, but then once you open your eyes and see your creation (hopefully in a preview environment and not in production) and need to adjust it, you have to close your eyes again...
Take a look at our Telus case study... training marketers used to take many hours spread over days and still engineering had to field multiple support tickets about operating the headless CMS, yet now with Stackbit this whole process takes a 5 minutes Stackbit training videos.
Another pitfall is that working without being able to directly edit the element you're working on means you have to look for it in the headless CMS. Looking means searching by name, but when you have tens of thousands of objects and about a hundred different Hero sections, you need so start naming each one of them with the full "breadcrumbs" of their location... reversing this setup after you finally add in a visual interface would be frustrating (and even more so knowing that you had to do it to begin with because you just wanted to add Stackbit's visual interface later).
