In 2016 I had the change to work on Kosmos, a proprietary platform, developed and customized for big enterprises in the US, Canada and EU with up to 60.000 subsidiaries (e.g. McDonald’s, 7Eleven, Pizza Hut, Arby’s, KFC, or Subway.)
Kosmos let C-level executives supervise their entire company and act based on custom indicators. It also allowed individual business owners to create and manage their websites, job applications and other business needs such as printing branded material or managing promo deliverables.
Francise owners had to deal with very high turnover rates, which had a big impact on their overall business. They were dependent on the parent organization for any kind of communication towards attracting employees and customers to their restaurants, but that was far from effective locally. Still, franchisors did not allow them to develop individual websites, as this would create branding inconsistencies across the company.
The solution was to create a white label website builder, supervised by the parent company and used by individual franchisees to personalize their online presence within the branding guidelines.
Because of its size and complexity, the project was split into multiple modules based on the main features, each having a separate team. We were not isolated, though, we shared the same workspace and constantly communicated and made decisions together so that all components fit together.
I was responsible for designing the website builder module, probably the biggest of the platform, working alongside another designer, 2 frond-end developers, 2 back-end developers, 2 QAs and a product manager.
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 discover more insights, 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 very 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.
I knew that the website builder was going to be a core feature of the platform so I had to find the easiest path for users to access it. I 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, the website builder was integrated inside the website pages, as this proved to be the place where users were expecting it when customizing their website. We also connected the builder 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 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, 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 actual content elements.
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.
Because of its capability to build detailed components, I used Axure for building the interactive prototypes.
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.
Throught the process, I worked closely with the other members of the team (designer, front-end and back-end developers, QAs, product manager) to ensure a consistent experience that would integrate the website builder 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.