Two years ago we kicked off the huge undertaking of designing and building our own content management system. It’s now giving life to our consumer products, easily scaling alongside them and making the day to day tasks more enjoyable for the Ops team.
Over the years, little consideration was given to upholding the internal content management tools. The tools that were used to manage the companies global network of discounts and community of members were riddled with bugs, the usability was poor, and the operations teams had resulted to creating little hacks to get things to work properly.
Every second they waste trying to find the right information or perform an action because of poor usability, is money the business loses. An easy to use product means they’re more productive, and companies need to invest less time, money and effort in training and mentoring. As the company continued to grow, with teams split across the globe, the cost of ignoring this problem was also growing.
My role as a Product Designer in this project was to hit two main objectives:
- 1. 🚀 Create a new content management tool to allow our global Operations team to efficiently manage all content
- 2. 🛠 Design for consistency and scale by using reusable components to simplify changes, reducing design and technical debt
We spend our days improving the consumer facing products, carrying out user studies, prototyping, constantly iterating and collecting data all to improve the experience for our users. It was time to use the exact same methods to improve the efficiency of the backend business.
To successfully do this I needed to create an environment for collaboration of a cross functional team. Some of the methods I used though the discovery and design phase to understand the business needs, analyse user behaviour and understanding the technical constraints were;
- 🗣 Open and frequent communication — A dedicated slack channel let team members throw in any issues they had as they worked with the current tool, as well as suggestions they had. This also became a place to share ideas as we moved forward.
- 👀 Observations & Interviews — I could learn from the already existing product. Taking notes of how specific tasks were carried out, did the Operations team carry out tasks differently to each other? what were their pain points? what already worked well for them? where did the tool have to be ‘hacked’ ? what was most time consuming task? What screen sizes do they like to use…etc. I spent a week in London sitting with the Ops team to do this effectively.
- 📑 Documentation — With the help of the Ops team and Product team, we built out documents that started to detail the systems must-haves based on the vision for the future. This helped develop the new IA and allowed engineering to start on the backend infrastructure.
- 👨🎨Sharing early and often — Working closely with the team that would be using the end product meant that I was able to test assumptions and design solutions at very early stages and iron out any issues before costly development.
- 🤖Sitting with Engineering — We encourage a close relationship with design and engineering and make sure that projects are kicked off in tandem. This meant I could discuss designs, ideas and get feedback on technical feasibility before moving any concepts too far forward.
The discovery phase of this project fell nicely on the week the engineering team took a retreat to the south of France. Three offices across the UK got together for a week; I used this time wisely to work closely with the Product Manager and Engineers, accelerating the design and technical feasibility discussions.
There are around 12 top level models that need to be handled by the content tool (discounts, categories, brands, collections to name a few…) that can have unlimited objects created inside of them, all of which are closely interlinked, can be managed independently, and across 15 countries & languages 😳
During the discovery phase, I identified consistent areas that we could evolve the design around — There would always be 4 main areas/stages to managing and creating objects in specific models:
- 1. Model Index — An area that would provide an overview of all objects related to the specific model.
- 2. Object Create — A way to create a new object within the model
- 3. Object Edit — A way to add/edit all dependancies for an object
- 4. Object View — A way of viewing an object and all its dependancies
Identifying and defining consistent elements, approaches and themes meant we could create reusable components rather than one-off solutions.
I built out a breadboard of the agreed IA. This map included all the data points that would need to be available from each page and visualised the high level user flows — Showing us all the possible states, user’s inputs and goals.
This provided an agreement between Design, Operations & Engineering. I was able to reference this as I refined the design direction.
🚀 Improving efficiency by design
Design Goal 1: Create a new content management tool to allow our global Operations team to efficiently manage all content
The main aim of this project was to create a new content management tool to empower our global Operations team to efficiently manage our content.
The CMS allows admin to manage over 12 different objects, for the purpose of this case study I will show how we improved the management of Discounts specifically as this is the most demanding use case.
1. Creating and editing discounts
The creation of a discount created the most headaches for our Operations Team. The major issues lay in the complete lack of attention to the information architecture. To list a few;
- The 11 step-by-step wizard type flow only had two or three options per step that were unrelated to each other. Removing all benefits to a wizard type form.
- Lack of descriptive field labels, descriptions or helpers. Making it incredibly hard to use for anyone that wasn’t a veteran.
- Unable to easily differentiate between online and in-store offers. To edit an In-store offer you had to edit the Online offer first.
- Default copy was not shown to the user. You were expected to just leave the field blank if you didn’t want to override copy, but this wasn’t communicated clearly
Through out the design, my primary goal was to eliminate the usability issues from the current CMS and make sure I wasn’t just moving them elsewhere or creating new issues. As stated previously in the approach, I shared solutions and design directions early and often with the operations team. My aim was always to get flows in to a fairly testable state as soon as possible.
Creating simple click through prototypes allowed us to receive rapid feedback from multiple stakeholders. Using the top twenty tasks identified from the initial research, I conducted holistic tests of the UI. Users of different experience levels completed isomorphic sets of tasks, to measure ease of learning and ease of use once learned.
After each round of testing, annotations were added to printouts to easily collate what had been learned. In this particular example I found that there were different expectations for what would happen when you tapped the next button on the multi-step edit flow.
Identifying any potential flaws in the UI or UX prior to the build are invaluable. I was able to address these issues in the cheapest phase of product development.
The new and improved
The new way to create discounts.
How is it better though, mate?
- A more logical step by step process that groups forms together. The groups having more editable sections favours being able to add content in a sequence the user wants to.
- Form blocks have clearer titles and it’s more obvious why fields are grouped together. Descriptions are used to provide more instructions and there are optional helpers to add further details. Both help onboard new users quicker.
- The fundementals of a discount are now asked up front. The brand, whether it's Online or In-store and the code type. These are the core elements to defining a discount, which allows it to be much easily identified while in its draft status.
- Any default copy is now dispayed. The user can clearly see what it will be and if they want to override it.
- I've created better visual cues to help users identify which brand and country they are working with. Helping reduce human error.
2. Improving discoverability
Another issue theme with the current CMS was being able to find content in the abyss, and being able to easily identify types of content.
To improve the way that the Operations Team find existing content, the following features were added:
- "Glances" were added above the table to provide an overview of the content. Providing insight into the number of discounts that are live. The most useful being the "low codes" notification.
- The country of every page of the cms can be selected at the highest level to allow Ops to move around and only have to filter once.
- A colour code for the status of the discount (live, draft, boost and ended) was added to help provide a quicker way of identifying live discounts. Logos and flags were also added to help improve scannability
- An "Advanced Filter" was designed to allow the user to deep dive and conduct granular filtering. In the old CMS it wasn't always clear if filters were present, so visibility has been improved and a way to easily tweak has also been introduced
- A free form quick search has been introduced for less granular filtering needs
3. Speed of managing existing content
The third issue theme related to the managmenet of existing content. There were a few tedious actions with the current CMS that could be addressed to save the Ops team valuable time
To improve the way that the Operations Team edit existing content, the following features were added:
- We allowed for multiselect and bulk actions - meaning that changes could be made to a number of discounts in one go
- Clearer notifications were introduced to provide better feedback to the user that actions had been completed successfully or unsuccessfully
- Quick actions were added so that you could make changes to frequently edited options without having to go into the complete discount editing process
- A view model for the object allows you to see the complete makeup of a discount in one view
- From a view model, you can navigate straight to a relevent editable section
🛠 Improving technical efficiency
Design goal 2: Design for consistency and scale by using reusable components to simplify changes, reducing design and technical debt
We wanted to be sure to create a platform that other people could use, build upon, and extend internally. Building an entirely new product and a design system at the same time was a challenge.
As the UI began to evolve and define itself, I would pull components out into a separate Figma file. We developed standards across a number of elements from foundational parts to common components. Over time this created an extensive suite of patterns, components, templates, as well as specifications and usage examples for each — Becoming the master design system.
Development first began with a focus on these core elements of the CMS which set the foundation to build specific featured on top of.
The system’s promise is enabling a consistent experience spread across products and sustained with a dependable, predictable practice.
Templates & Components
The Design System (CMS POD) contains all the individual elements and components that make up the whole product. This is the single place to come to to grab the building blocks to adding any new features to any of the products that use this design system. The aim is to be able to use any of these components to build anything new, only if these are unable to satisfy the brief can new components be introduced.
All of the form components are set up as symbols, consisting of nested symbols allows for all states to be accounted for from the single use. Although each state has its own symbol, each is made from a single form input which has a placeholder, hover, focus, value, error and disabled state. All of which can be altered on the fly.
All of these field variants can be made from a single input symbol
The documentation within the design system is to provide a mechanism to help designers and developers know how to properly use the common components and patterns of the design system.
Above image shows a snippet of “Blocks” in my documentation. Explaining how they should be used and their specification.
Like any product we design and develop, a design system must address the needs of adopting product teams within the current landscape of culture, tools, existing systems, and practices. For us at this moment in time, it meant keeping the UI kit, templates and documentation in a master Figma file. Why take it out of the software we use everyday?
Naming conventions were defined in collaboration with engineering which was invaluable in making sure we were always in sync. The engineers developed the components defined in the Figma documentation into their own library using the exact same terminology.
How is the Design System used in practice?
As previously stated, the goal of the design system is to allow us to build new features faster, without sacrificing quality.
Once these core components and templates were in production, new design and development phases became ridiculously quick and simple.
To document what needs to be added to the CMS, the designer can use a range of already existing components to solve a specific problem. 90% of the specification documentation is likely to be just written using the semantics agreed between Design and Engineering. With no need for new visuals!
These are exmaples of Design Specification document that didn’t require any new UI design because of the components and shared semantics.
Obviously sometimes visuals need to accompany the words to give a clear picture, especially if it’s a new user flow. Thanks to the design system in Figma, the designer can create high fidelity visuals in next to no time.
Conculsion & Next Steps
Being a product designer goes beyond the end user, here we solved an internal business problem too and I don’t just mean for our ops team. Design considered the time and effort of the designer and engineer too going forward.
The delivery of the CMS was a bit of a headache, however, throughout the 2 years it made us challange and restructure the way we scope and deliver software for the better of the whole organisation.
Since inception, the CMS now has its own full time dedicated team responsible for improving and stabilising it. It’s the heart, brain and digestive system of Student Beans, it’s health is detrimental to all the other products and it’s great to see it getting the attention it needs.