Back
At Xello, we began working on a new exciting project that will be helping young students - grade 3-5 - to be self-aware. They can find their interests and learn about many different topics that are essential for any well functioning human being. In a more general sense, it is a redesign of our grade 6-12 product for a younger audience. A few months through the project, we must come up with standards and establish patterns before it is too late. This was a lesson learned from previous products.
The project started with one dedicated designer (me), then later another talented designer joined the team. The product had to be consistent with other Xello products, but at the same time be different. We wanted to have a more playful and simpler experience considering the nature of our users. So after a lot of explorations, we developed a uniquely different design language that feels related and is coherent with its product siblings.
This difference was enough to require a standalone and sovereign design system and library. Several sprints passed, and a few pages were built before we realized the undeniable need for a cohesive guideline that could unify our designs. A guideline that sets up rules and standards to create new components. A set of foundational truths that would function as basic elements to build our designs on top of. This guideline would also be a source for our developers to check. A new team, a new product needs a common ground.
Since we were a few months into the project, the first step was to conduct an audit to see what has been built and where consistencies and inconsistencies are. We gathered all the elements and components from the developed website and in-progress design documents. We created a shared Sketch file where we populate it collaboratively with our findings.
The Sketch file wasn't a good idea. It limited collaboration, communication, and made us think granularly instead of globally and holistically. So we decided to print out the pieces we found and put them all on the wall. That shifted the perceived undertaking of this project. It made our work visible and transparent to everyone else in the team. It sparked conversations from anyone who passed by the wall and was curious enough to stop and ask questions about it. Utilizing our physical space enhanced our learning and led us to see the big picture.
We categorized every element and grouped them by nature of their function and type of behaviour. We discussed their context of use and purposes. With that, we could now identify errors and misalignments, then we come up with rules and standards to unify them. It was a great exercise for us to discuss and articulate the decisions we have made, and the reasoning behind them. It provided a rich base ground to share knowledge and to learn about each other’s way of design rationalization.
We realized there are a lot more things to be discussed and to agree on than our time and limited resources allowed. So we came up with an MVP for our design system and prioritized things we wanted to tackle. We identified the most essential ingredients that were the most fundamental for us to stay coherent and consistent. The MVP was to come up with style guides that could get us up and running, at least for now. When we defined rules and standards for them, then we would document them, and share with the team. We made specifications and contexts where the rules apply.
Because of the lack of resources, we decided to spend 20% of our time every sprint to add and complete this document. We created a Sketch document which would be the only place we record our decisions. The file is open to everyone and anyone could create a new rule when they design a component.
This was just the start of this project. We are planning to continue adding, and finally build a live website including code snippets and tokens for devs to use, and designers to refer.