How we started building a design system at LumApps
The project started with a small team in October 2018. The main motivation was to ensure the safe growth of LumApps products by creating a consistent design language and pattern library.
Where we came from
Since the beginning LumApps has been built on top of LumX, our home-made UI Kit. LumX was closely following material design guidelines and provided more-or-less the essential components we needed to build LumApps’ UI. At the end of 2018 LumApps got recommended for G Suite as the only solution for corporate & social portal. Things started to accelerate drastically, more complex features were pushed in the product and at a never-slowing pace. Since then, four problems had arisen.
An aging UI kit
Built with Angular JS, a relatively old technical stack, even in 2018, LumX wasn’t really a “living” UI Kit. Critical bugs were fixed but there wasn’t any special workflow to maintain and improve it. That said, when the product needed to evolve its own technical stack, the UI Kit needed to be rebuilt accordingly.
No dedicated documentation
Even if we did rely on Material Design Guidelines to create our interfaces, they slowly drifted out of sync. The reason is that every-time we had to create something we had to juggle LumX components and MDG for usages and best practices, leaving a whole space for personal interpretation.
No design resources
Apart from the living coded components, there were no design files in the Kit. So, product design files varied from strictly respecting material guidelines but out of sync with LumX, to strictly respecting LumX but somewhat ignoring MDG.
Developers and designers own libraries
Naturally, most developers created their own mini component library. They did share some components code but, without written documentation, knowledge was purely oral thus work was re-done most of the time.
On the designers’ side we built, piece by piece, a sketch “master” file that hosted the most used LumX components, text styles, and also specific product UI pieces like :
- Site header
- Main navigation
- Visual identity tokens
- Icons
- Color selector
- Image positioning controls
All this wasn’t horrible to work with, but we weren’t really prepared to accelerate.
Getting a buy-in, a matter of opportunity
One of the first milestones to effectively start a design system project is to get stakeholders’ attention and buy-in. We started to talk to stakeholders back in June 2018 and in fact we did have two great opportunities to initiate the project just after that.
Market widening
LumApps’ Board decided to open our strictly “Google” customer focus to a more diverse market. We were now targeting customers used to other digital working suites than solely G-suite, mostly Microsoft users.
To accompany this change we decided that our graphical user interface might evolve from « pure Google product look » to something more neutral.
We were going to design a complete new UI « skin » from the default color palette to buttons and textfields shapes.
Scaling
More features needed to be delivered, and at a greater rhythm. To ensure a safe product development, we needed to :
- ease product people’s work by improving exchanges between teams
- improve the overall UI quality
- minimize friction and let users be more efficient and happy, even with a more dense product.
Our way of doing it
UI Inventories
At first we needed to have an overall vision of the product’s UI. We conducted two major inventories.
- A visual inventory to capture not every single piece of UI but most of it, and then organize them in categories by similitudes.
- A code inventory, as developers had their own mini component library, to capture potential components, and again organize by names or similarities.
Workshops
There were a lot of possible improvements but we needed to know where to begin. That’s why we did workshops around two goals:
- Identifying UI problems From the user perspective, but also from designers and developers points of view, as the design system should ease the work of people building the app while improving users’ lives.
- Identify key screens By identifying first key user flows we determined the most used screens of the app.
Key screens helped us logically prioritize the UI problems, because the more a problem is present on key screens the more it needs to be solved.
Visual exploration
At the same time, UI designers worked on defining a new visual identity for the app. We needed to change the pure “Google” look to something neutral. We did a classic webdesign workflow, a lot of visual research, three proposals which led to one that served as foundation for building each component. A new color palette, new font choice and base styles were decided at this stage, validated by stakeholders.
Re-designing components
In fact we sort of ignored the prioritizing we did. We urgently needed existing LumX components but developed with the new front-end language: React. So we established a new plan. We needed to replace each LumX component used in the app as soon as possible. We tried our best to tackle UI problems at the same time whenever it was possible.
The work was essentially doing a systemic visual rework of each base component, and when improvement was doable we made changes.
For example we created a button hierarchy based on three “emphases” and we improved the textfields affordance.
Designers were producing mockups that were put on Zeplin for developers to review, then after several iterations and then validation, devs were implementing each component one by one.
Since then, components are being produced according to needs.
Creating component
Some components were not LumX components but rather pieces of more or less reusable code within the product. With our prioritization we knew which ones needed to be created as whole.
For example, we had a particular scarce “accordion box”, it looked different and acted different according to each context and depending on who implemented it.
In order to create the new “accordion box” (now called “expansion panel”) we did workshops to establish a definition, and then designers produced written documentation and visuals specifications of each possibility and states.
Next step
By doing a sort of UI Kit v2, we built solid foundations for our design system. Hopefully we solved some problems on the way, but now we need to focus on wider “patterns”, tackle flawed user flows, establish best usages, clear rules and get closer to standards to improve accessibility to build an even enjoyable experience.
