Business owners needed a customized digital presence in order to attract local customers and employees to their restaurants. However, the franchisor did not allow them to develop individual websites, as this would create branding inconsistencies across the company.
The solution was to create a global website builder where all individual franchisees could personalize their presence within the branding guidelines. The builder allowed the franchisor to supervise the websites, while also letting the franchisees engage more closely with the local community.
Kosmos is a proprietary platform, developed for big enterprises in the US, Canada and the EU with multiple subsidiaries or franchisees.
Kosmos lets C-level executives supervise their entire company and act based on custom indicators. It also allows individual business owners to create and manage their websites, job applications and other business needs such as printing branded material or managing promo deliverables.
The platform combines core and optional features, which are then customized for companies with up to 60.000 subsidiaries (e.g. McDonald’s, 7Eleven, Pizza Hut, Arby’s, KFC, or Subway.)
The first step was identifying existing website builders and learn more about their strong and weak points. After filtering some of them, we were left with 4 products relevant to our task: Squarespace, Wix, Webbly and Blocs.
I analyzed each one of them in detail, looking for how they structure the information architecture, how they build the pages, what type of elements they let users manage, what interaction patterns they use and so on.
To confirm some of my assumptions, I invited some potential users and tested the website builders using identical tasks. This highlighted the differences and allowed me see which features they found difficult or easy to use.
Some of the tasks given included:
Add a new page and name it “About”
Add a text widget to the About page
Edit the text widget in the Contact page
Reorder About and Contact pages between them
Delete the About page
Change the Contact page description
Change the website name
Knowing the right type of persona was essential for putting together the website builder. We already had access to the personas created at the start of the project, so we filtered some of them, keeping and adapting those that we knew will have access to the builder.
We were dealing with entrepreneurs, managers, assistants and marketing professionals that could be involved in the customizing or the approval process for the new websites.
We knew that the website builder was going to be a core feature of the platform so we had to find the easiest path for users to access it. We also had to take into account the fact that people would use the product in different environments that shouldn’t influence the overall experience.
In the end, this feature was integrated as the main action in the websites page, as this proved to be the place where users were expecting it when customizing their website. We also connected some of the other website builder’s features with other modules like the job management or the analytics dashboards and minimized dead ends.
There were a lot of features to take into account when designing the website builder which generated a very complex feature map. To make it easier to follow, I split them by roles so that there would be no redundant or duplicated elements. I listed the content for each feature and organized them by type.
It proved to be an efficient approach, which helped me during prototyping and acted as a useful support sheet for the front-end and back-end developers and QA engineers.
Our main goal was to transform a complex list of features into a simple structure that was easy to use. We decided on a hierarchy where websites were composed of pages, pages were composed of slots and slots were composed of widgets that were made up of the actual content.
This way, we had control over the design output but we still allowed business owners the freedom to choose the content of their choosing for each page.Every website had a custom theme, which included a specific visual style, multiple page layouts and a website structure.
The first iteration included a hidden sidebar that was easy to use and saved screen real estate but as we went on, we realized that, once the complexity of the websites grew, it will not be a sustainable solution.
All the interactive prototypes were build in Axure.
Serving a franchiser with tens of thousands of franchisees, letting each franchisee manage multiple restaurants and having to support pages generated from outside the website builder, meant that the best decision was to treat the pages separately.
It simplified the builder screen even more and allowed us to impose a more straightforward user journey, that minimized user mistakes.
We also took the decision to use an inline system for adding widgets instead of drag-and-drop. Not all slots were compatible with all widgets so we didn’t want to raise false expectations when users were trying to add new widgets. As a request from the franchisor, some slots had also predefined content that did not allow users to make changes other than simple text editing.
In developing the website builder, I worked closely with the visual designer and front-end developers to ensure a consistent user as experience that would integrate it seamlessly into the overall product. Jointly, we found solutions whenever problems came up.
In the end, the output was a modern and elegant design, complying with the product’s image.