With the company’s fast growth and an influx of new features, the platform quickly outgrew its original design. We were accumulating technical debt and losing a grip on user experience. Yet, we could not afford to stop and consolidate. I devised a strategy for implementing a design system on the fly, designed its foundation, and led the team through challenges of a gradual platform overhaul.
Design: A. Venta, A. R. Urankar, G. Furcolo
Engineering: U. Pirnat, M. Tribušon
Some projects were executed by recycling the legacy UI for pragmatic reasons; others were inventing new visual languages. Despite the team’s efforts to contain the problem, the product design was organically transforming into several different directions, and the existing style guide became anything but.
On the other end, the three core parts of the platform were built using different front-end technologies which prevented us from using the same UI components across the (dash)board. We struggled with unacceptable loading times, usability issues, handicapping restrictions, and increasingly longer development times.
We campaigned for consolidation, but we were unable to allocate resources to develop a design system. The business circumstances dictated executive decisions to prioritise new features over internal tooling.
The opportunity arose with the green light to rewrite the platform’s core with Vue.js. I approached the key engineering stakeholders with a strategy to exploit the code overhaul for finally institutionalising a design system. With them on board, I designed the initial concepts to get CPO’s blessing, assembled a small core team, and kickstarted the mission.
Part 1: Planning
Stack research and testing
We researched available tools, took them for a test drive, and made evaluations based on capability, compatibility, and reliability.
Our objective was to achieve a lean workflow and lower the cost of licences by reducing the number of tools. Choosing one of the leading vendors meant a safer bet our stack would be interoperable and still around in two years.
Framer X vision of all-in-one design and prototyping tool using interactive components (as opposed to their graphical representation) was precisely what we wanted. Sadly, Framer X was built on React with no plan for Vue.js compatibility within sight. Invision’s suite was also in the shortlist; however, Studio was fresh in beta, somewhat buggy, and its import of Sketch files was unreliable. Also, the DSM offered only style-guide documentation, whereas we needed reliable versioning control. Figma was an exciting new kid on the block, however at the time without a desktop client and with limited features for managing the component library.
Good old reliable Sketch in conjunction with Abstract and Principle was the way to go. It was a safe interim bet that would enable us to easily port to Framer, InVision, or Figma in the future when/if they matured to fully satisfy our needs.
Studying the leading design systems such as Google’s Material Design, IBM’s Carbon, Airbnb’s DLS, Shopify’s Polaris, Atlassian Design System, etc. and their implementations allowed us to quickly learn from the best and avoid rookie mistakes.
The ambition was to eventually achieve a system that relied on code as the single source of truth by using Airbnb’s React Sketch.app for generating Sketch components and VUEDS for generating documentation.
Part 2: Exploration & Specs
The biggest initial challenge was finding consensus on diverging views between aesthetic richness versus technical simplicity. It took several months of incremental progress and stress-testing (with more than 10 shades of blue) to arrive at a visual language that pleased the eyes of stakeholders while simultaneously ticking off all the technical requirements:
The platform spans from the data-heavy dashboard with analytics which requires dark text on a light background, to ad authoring and (pre)viewing tools where a dark UI works best to accentuate the artwork.
The question of accessibility versus aesthetics is not straight forward when your main user base is designers. We stroke balance by tweaking the text and functional colours to an enhanced ratio (AAA rating), while decorative colours and containers could pass with the minimum ratio (AA rating).
To support our customers globally, we required UTF-8 charset. A custom web-font in at least three font weights would translate to a significant payload. Using OS’s native type family was an obvious choice to get premium typography and full accessibility while staying within the performance budget.
To achieve clear visual hierarchy and optimise the user experience for the entire spectrum of devices (from 27” external displays to smartphones) we would need every UI element in three sizes: condensed, normal, and fat.
By analysing platform data such as the quantity of list items, length of titles, time ranges, frequencies, etc. we probed UI constraints and optimised for realistic maximums and minimums.
Part 3: Implementation
See it in action
The operational constraint of developing a design system while simultaneously using it in production was incredibly challenging but also proved extremely effective. It expedited our learning about intricacies of the platform’s nooks and crannies, enabled us to stress-test elements before rolling out the entire system, and prevented us from creating design fiction.
Within the next year and a half, we meticulously directed all roadmap projects to prevent ongoing development from derailing into a mess that would again be too costly to clean in the future.
Once the component library foundation was laid, we shared it with our peers, begun collecting feedback, and invested time to enable their work through hands-on support until the style guide was put in place.
Unfortunately, I left the company before having the pleasure to see v.01 fully released, but took comfort in knowing it was set up for success and its future was in good hands.