Lokalise

Lead Designer

Lokalise was facing a situation similar to Hotjar when I joined them. They lacked an internal Design System and were in the midst of a migration to React, seeking solutions to align design and engineering efforts. My main objective was to address this gap by developing a roadmap for Design Systems, establishing team rituals and operations, and creating scalable documentation to streamline the transition.

Work

At Lokalise, my central focus is instilling structure into the design process, encompassing both the Design System and our overall design approach. I'm actively engaged in aligning the language used by design, product, and engineering teams, working to identify and address common miscommunications. The goal is to standardize the decision-making process, ensuring a more cohesive and streamlined collaboration across disciplines.

Impact

Improved our Figma enviornment

By introducing a central Foundations file, enhancing component flexibility, incorporating tokens as variables, and promoting the adoption of the new dev mode among engineers, we successfully enhanced our team's daily workflow.

Design System planning

I collaborated closely with engineers to identify the elements that posed the most challenges for them. Leveraging this insight, I crafted a roadmap to guide the development of our initial set of components, addressing their specific pain points.

Focus on accessibility

We updated our color pallete and typography to adhere to A11Y guidelines and made sure to build our components with accessibility in mind.

Team rituals and culture

I'm implementing team rituals, including Feedback sessions, Office Hours, and peer design sessions. Lokalise initially had an engineering-centric culture, and we're transitioning towards a more inclusive approach, incorporating design into early planning and strategy sessions.

By implementing design tokens along with token aliases, we were able to standardize color usage within the app. I created this reference map to be able to keep track of changes.

Metrics

When it came to measuring the impact of our Design System, we wanted to be selective and settled on things that aligned with our targets for cleaning up our codebase by the end of the year.

Tech / Design debt tickets

While we knew these would be common during our work, the variety of tickets would shrink if they were tied to DS components. This would make them easier to identify and correct.

Number of snowflakes

Because we are early in our system's lifecycle, we wanted to decrease the amount of isolated elements and “adjusted components”. Replacing them with standardized versions.

Accessibility score

By updating simple things like our color palette and updating our components, we could raise our accessibility score.

We set up an icon dictionary to make sure each action in our app had its own clear and consistent icon. It helped avoid any confusion and kept things straightforward for users.