← Back to WorkElias Maliniemi

Case Study · 2017 · UI Designer

Elisa Design System Team

Worked as a designer to co-create a component library and token system for Finland's largest telecom, serving 2.8M+ customers across Finland, Estonia, and international markets.

Elisa Design System Team

Getting a large corporation to meaningfully adopt and utilize a design system requires overcoming organizational inertia and demonstrating tangible value before benefits materialize. Each product team had built their own UI patterns in isolation, resulting in inconsistent interfaces and duplicated work.

120+
Components shipped
8
Product teams onboarded
40%
Faster design handoff

Design at Elisa was siloed — and it was slowing everyone down.

Elisa is a Finnish telecommunications and digital services company with nearly 140-year history. They serve over 2.8 million customers in Finland, Estonia and internationally. Elisa Design System team is responsible for developing and maintaining the Elisa Design System. The design system consists of UI components and visual styles. It helps to create beautiful, consistent experiences across Elisa websites and services. I was the designer in the team, and worked together with lead designer and two developers.

The team is independent but works closely with all different business units in Elisa. It stays in close contact with every designer across different teams. Main goal of Elisa Design System is to save developer time and resources. The brand has many different products that share UI components and it is unnecessary to create those every time from scratch. Another goal is to keep the brand image in line between different products. The Design System works as a centralised collection of all design assets and knowledge. It can be shared to new people joining the company, and to third parties creating assets and content under Elisa brand.

The design system is living and breathing only if the teams actually have interest and say in its development. Instead of creating assets for the teams ourselves, we helped them, guiding the developers and designers in contribution and asset creation. Our main focus was to remove any obstacles they would have using the system. We did so by having scheduled meetings, where we would share knowledge and plan roadmaps for the future.

The process of adding components to our design system was simple: all designers meet in a weekly meeting, showcasing their upcoming products. This was the place where we could challenge them to use our ready components, as well as make them discuss with each other if certain components could be merged for multiple teams to use. If two or more teams could use a component, it would then be considered to be usable in design system. Either one of the teams would then provide the solution that we would add into the system. The usage of components were measured, so that if a component wasn't used, we would decide if it could be removed from the system.

We defined the components in detailed level.

When I joined the team, the groundwork of creating the Sketch library had already been done, but it was missing components. My first job was to add those missing components. I then helped creating storybook components from those sketch assets together with developers. We also had many different workshops with the teams, sharing our personal roadmap and keeping them up to date of what we were planning. We published a monthly blog post telling people what we were up to in amore general level. The blog targeted less technical people in Elisa, and was more of a general . We focused heavily on automatisation and building the pipelines of automated reporting of our actions. The goal was that instead of reporting, we could focus on the actual work of improving the Design System

"The system needed to be opinionated enough to create consistency, and flexible enough that teams wouldn't work around it."
Elisa Design System Team
01
Audit
Catalogued patterns across multiple product teams. Identified components that were in use in multiple products that could be unified.
02
Token System
Designed primitive + semantic token architecture. Aligned with engineering on CSS custom property naming and build pipeline.
03
Components
Built components and icons in design tool. Peer-reviewed by each team before release.
04
Adoption
Ran onboarding sessions with each team. Contributed Storybook documentation and maintained a changelog with migration guides.

Token-first, component-second.

Throughout the year, we were working steadily towards easier and more usable asset libraries. The usage of Design System in different teams increased and our visibility inside them grew. Our measurements showed that we actually saved new projects a considerably large amount of time in asset creation that could then be used in other parts of design and development work. The success we had enabled our team to recruit an additional team member, as the budget was increased for the year. For me, the main learnings were of Design System work, and the realisation that it takes considerable time and effort to get a corporate as big as Elisa to the level of utilisation that you can actually reap the benefits of such a system. The rewards are all worth it, though. For me, the joy of co-creation and sharing and the increased brand unity, good UX practices and accessibility are key successes from this year.

DS
Unified Token System
Consolidating fractured assets to semantic tokens to achieve unified look and feel through all services.
Cx
120+ Components
Full component library with auto-layout, variants, and token bindings.
Faster Handoff
Design-to-dev handoff improved significantly. Fewer revision cycles. Shared vocabulary between design and engineering.
8 Teams Onboarded
Most critical Elisa product teams adopted within 12 months. Teams contribute back rather than building in isolation.