Celtra Design System
Context
Company: Celtra
Timeframe: 2017 - 2018
Role: VP of Product
With the company’s fast growth and an influx of new features, the platform quickly outgrew its original design. Some new projects had to be built with legacy UI components for pragmatic reasons; on others, the team was innovating with new visual languages.
Furthermore, the three main parts of the platform were built using different front-end technologies, which prevented us from using the same UI components across the board. We were accumulating technical debt and losing grip on user experience, yet we couldn’t afford to stop and consolidate because business circumstances dictated new features over tooling.
Mission
The opportunity finally arose when engineering got the approval for rewriting the platform’s core with Vue.js. I partnered up with engineering leads responsible for the overhaul and devised a strategy for finally consolidating visual language and user experience with a design system.
Contributions
I initiated the design system and was responsible for it from conception to the production rollout.
Hands-on contributions:
- Researched leading design systems and best practices
- Designed the stack and production workflow architecture
- Designed the foundation of the component library
Throughout the 18-month gradual rollout, I rallied and directed a team of three designers to establish the DesignOps function and worked closely with engineering leads and other product teams to support adoption with active development projects.
Results
Highlights
Stack research and architecture
Our objective was to achieve a lean production workflow, ensure long-term interoperability, and be rational with licensing costs.
The 2017 tooling landscape was mid-upheaval. We were bullish on Framer X’s vision of designing with live codebase components, but unfortunately, it was incompatible with our Vue.js stack. InVision’s Studio was fresh in beta, buggy, and its import of Sketch files was unreliable. Figma seemed promising; however, at the time it had limited features for managing component libraries, no desktop app, and requiring the entire team to learn a new tool would be a hard sell.
| Design | Version control | Prototyping and animation | Handover | Icons | Style guide |
|---|---|---|---|---|---|
| • Sketch • Framer X • Figma • InVision Studio • Adobe XD |
• InVision DSM • Abstract • Plant |
• Framer • Principle • Marvel • Flinto • Origami Studio • LottieFiles • Kite Composer |
• Sketch Cloud • Zeplin • InVision Inspect |
• Nucleo • Streamline • FontAwesome • Noun Project |
• VUEDS • Fractal • Catalog • Patternplate • Bit • zeroheight |
We decided on the combination of Sketch, Abstract, and Principle. It was a safe bet that wouldn’t require convincing the rest of the organization to change the stack, and it left the door open for migrating to Framer, InVision, or Figma in the future if necessary. Within Sketch, the Overrideit plugin alleviated the pain of finding components within dropdown menus, and a clever hack gave us auto-resizable button symbols (before the native auto-layout features).
The longer-term ambition was a system relying on code as the single source of truth, with Airbnb’s React Sketch.app generating Sketch components and VUEDS generating the documentation.
Form vs. function
The biggest initial challenge was finding consensus on diverging views on optimum between aesthetics, functional requirements, and simplicity. It took several months of incremental progress and stress-testing (with more than 10 shades of blue) to arrive at a solution that ticked off all the boxes.
We opted for the underline form elements style to reduce the number of nested rectangles and borders, which make the UI harder to comprehend due to visual noise. As a B2B product with technically savvy users, we could afford the clarity trade-off associated with this style on the component level to make the whole clearer.
Luminosity and contrast
Another area where we had to find optimal balance was color space. Grayscale and semantic colors used for text had to pass the WCAG AAA requirement, while for decorative colors and background shades, the AA rating was sufficient.
Type system
To support our customers globally, we required the UTF-8 charset. A custom webfont in at least three font weights would translate to a significant payload. Using the OS’s native type family was an obvious choice to get premium typography and full accessibility while staying within the performance budget.
Scale
To achieve clear visual hierarchy and optimize 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.
Iconography
Components
Data-driven design
We often run into dilemmas where accommodating a wide range of edge case scenarios would require big trade-offs. By analyzing live data (e.g., quantity of list items, length of titles, time ranges, frequencies, etc.), we were able to optimize UI decisions for realistic value ranges.
Implementation and rollout strategy
The operational constraint of developing a design system while simultaneously using it in production was incredibly challenging but proved extremely effective. It expedited our learning about the platform’s intricacies, 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 ensure all ongoing projects were using the correct components and were aligned with the platform redesign big picture. The rollout continued past my tenure.
Credits
Design: A. Venta, A. R. Urankar, G. Furcolo
Engineering: U. Pirnat, M. Tribušon