How we used feedback to improve our CMS
Skylark: a better interface and experience for editorial teams
Every digital product must be backed by a content strategy. When it comes to how that content is managed or delivered, people usually approach this less strategically. The CMS that powers a product is too often neglected despite being crucial to achieving a successful product.
The digital industry has come to accept user-centred design as being essential for creating the right products for end users or audiences but rarely considers the experience of another type of user: the editorial team. These are the people responsible for implementing a content strategy.
An important focus for Skylark has always been to consider how editors work. This has been driven by a need to enable both technical and non-technical teams to manage digital content. Skylark delivers to the parameters of a content strategy, in whatever way this may evolve.
We’ve been redesigning Skylark’s navigation and tweaking some of the terminology and wanted to share some of the thinking behind this. Much of this has been achieved through testing and validating ideas with clients’ editorial teams. Before setting out the changes in the navigation, I’ll mention briefly why Skylark has been designed as it is.
Skylark at its core
From our experience, most rich media products do not conform to a single architecture, nor are they structured according to the same language or terminology.
Each product has its own way of structuring content whether it delivers video, images, games, e-books, music, or a combination of these. Skylark has been designed for flexibility in structure, media type, and industry. It has been developed to meet a range of required capabilities, and can be adapted specifically for each of our clients. It does this as a headless CMS that works beyond traditional CMS structures.
Closely tied to flexibility in Skylark is reusability for each product. Being able to reuse aspects of any architecture, for example, demands finding a balance between an architecture that is generalised and one that is unique to a client’s workflow. Flexibility and reusability allow our team to customise Skylark for each client, and evolve it from day one to meet their needs.
Customisation has become really important for the digital industry. Every company must be able to design a product experience that is specific to both their audiences and editorial teams. Our work involves developing a bespoke experience that delivers the features, architecture, and terminology that a team needs. This stands against white-label products, which are very generic as well as limited in how they can be customised.
Working with editorial teams is also essential to the research and development process. Our clients can inform our roadmap based on their needs and requirements.
Part of this is about becoming more efficient in customising each client’s infrastructure. The other aspect is allowing greater control and scalability to clients. It is essential for us that editors and product managers have a good user experience.
Drawing our roadmap with research
We believe that research is critical to business planning and to a constructive production cycle: for business planning, this usually works through a formal steering group approach in which the roadmap is defined and larger workflow problems are addressed; in a production cycle, this is incorporated into sprints. Sometimes, the research will point us to entirely new features.
Adding value in the product development cycle
For us as a product development team, this is about choosing to:
- Empathise with the people for whom we have created the CMS;
- Find inspiration to enhance the product from current behaviours;
- Draw as much as possible on analysis so that we can be confident that the solutions we are delivering are appropriate;
- Build a trusting relationship with each client to gather relevant feedback.
As part of revisiting the navigation and some of the terminology in Skylark, we tried to learn more about how editors and product managers worked day-to-day.
We drew participants from a range of clients including broadcasters, sports organisations, and children’s products. During this phase, we collected feedback from more than 20 editors through interviews, testing, and written responses.
First, re-evaluating the notion of the term ‘sets’ in Skylark. A ‘set’ is an arbitrary collection of things. Sets typically contain content but can also contain other sets. They have a range of properties, with behaviours linked to these. All of this makes an extremely powerful tool for organising data. The challenge here was in explaining what a set was. The versatility of Skylark is found precisely in the use of sets. Testing, though, showed that the term was far too abstract for many users.
We heard this quite often:
“Sets are like building blocks for a page. Start from the bottom, then build up.”
— Editor from a broadcast service
A decision to describe them as the building blocks for pages meant that they were much more easily understood. The latest version of Skylark will split the notion of sets, referring instead to ‘pages’ and ‘components’, while still accommodating all types of media.
Second, the navigation. We learned that a number of users were struggling to find content quickly in the CMS. However, a majority understood the concept of using building blocks to create and manage the front end of their digital services.
From concept to implementation
The feedback we received on building a page from the bottom up motivated us to observe how editorial teams found the content they needed for their daily, weekly, and monthly tasks. Through usability testing sessions and evaluating their user journeys, we learned that editors expect the way that the CMS is structured to reflect the front-end UI of the product they manage. This may seem obvious but it is a challenge that hardly any headless CMSs are able to meet.
By splitting ‘sets’ into ‘pages’ and ‘components’, we were able to create an architecture that more closely resembled what the product editors were working with. The resulting architecture allowed an even greater degree of freedom and customisation.
The revised navigation leads to new behaviours and interactions. We modelled these quickly with InVision, as part of iterating on the architecture. Afterwards, we built a code-based prototype using HTML/CSS/jQuery, introducing the appropriate transitions and micro-interactions.
While carrying out usability testing, we had the opportunity to develop small innovations for the product.
This was the case for a new feature, ‘bookmarks’. It came from our research which revealed that editors would consistently use the same paths in their workflows.
The new feature allows editors to pin specific pages, components or media content that they return to, easily accessing the areas and features of Skylark they use regularly. It reduces the number of clicks they have to perform — over the course of the day this can make a huge difference in their efficiency. It also helps to improve loading performance.
‘Bookmarks’, as an idea, has been extremely well received by our users, encouraging us to include it in the development of the new navigation. Its development validates the importance of user research in arriving at new opportunities within a product.
In the example above, you’ll notice that each client has their own way of structuring how their CMS appears — either to manage a single product or multiple products using a single interface.
‘Quiet innovation’
New navigation, tweaking the terminology, and bookmarks: these have all been born from working closely with our clients who use Skylark every day. This development reflects our philosophy of ‘quiet innovation’, which translates to finding outcomes that may appear to be small but make a big difference for our clients.
Research and iterative development are helping us to improve Skylark to match the specific needs of clients. What might appear to be a minor detail in fact enables us to draw out significant themes of interest.
By implementing these changes, we aim to improve efficiency, bring more consistency to the user experience, and onboard new users more easily.
Our goal is not merely to remove editors’ pain points from managing a service, but to enable them to deliver the best possible experience to their audiences.
We’d like to thank the editorial teams that provided the insights mentioned in this piece, as well as the entire Skylark team for their huge effort. To learn more about Skylark visit our website or contact us with any questions you have at hello@skylarkcms.com
Thank you for reading!
If you like this article, give us 50 claps. If you really like it, let us know why. Leave us a comment with any question or opinion you might have on the subject.
You can reach us on Twitter @Ostmodern to continue this and other discussions.
Follow our publication for more stories on tech, design, video and other interesting topics.
