Identifying top direction and self-awareness.

In 2021 after picking up an agency for the execution of the identity change, we (a team of a CMO, Head of Design, Creative Lead, Editorial Lead, and me - DS lead) worked closely with the agency and our teams at Ecosia in order to establish new look for Ecosia.

Shortly after the collaboration with the agency I have sat down and evaluated their end work from DS angle. I run a mini audit to define what is missing and what is needed.

In Jan 2022 top leadership laid out a roll-out plan and alignment prospect for rebrand. They made a statement that:

• the part of the product with the biggest audience reach will be updated within the first release in June 2022 (teams Search, Engagement, Marketing, Mobile Apps)
• the parts of the product planned for the second release will be running the work as usual (features development within the old identity language)
• each product team will create their roadmap and coordinate changes

This obviously added extra complexity to the operational work I needed to handle for DS:

• lead the DS redesign & contributions (for new visual direction)
• maintain previous version of the system and keep an eye on the contributions (old visual language)
• smart rollouts for the new code (operated by my partner in crime - an engineering lead)
• enough flexibility for DS roadmap to quickly respond into any changes inside product teams roadmaps (our dependency)

CHALLENGE

Agency visual direction proposal was insufficient to inform the system with full certainty and to adapt it directly into the sytem.

LEARNING

Agency is not enough, if the company didn't clarify the situation in regards to brand ownership and missing Visual Director role, prepare for struggle as a design systems advocate during the redesign phases.

Mapping the project & uncertainties within.

Too many questions can leave the project team paralyse. What mattered at the start was to vocalise the uncertainties and create a sense of clarity within. I gathered user needs, aspirations, and doubts. Our questions would land in two groups: operational and delivery. 

For instance, how might we: 

Creating a commonly shared purpose for this initiative has been crucial to get team on board. My objective has not only been to readapt the system into the new direction but also to create a fun, learning experience for all.

This has been a long awaited moment to look for the opportunities:

• reduction of existing pain points (styles organisation, font issues, bugs)
• theming infrastructure in place
• boost on accessibility
• reduction of redundant - code clean ups
• increase on adoption & collaboration
• Figma across departments
• more language alignments
• redefining purpose of documentation 

During the agency phase I investigated in collaboration with our teams, how much of the shared language we can create, and what will remain platform specific and native (e.g. technical audit for apps).

This information helped to reflect on the infrastructure we had and map the structure we will be transitioning to. Mapping supported me and the lead engineer on better planning on interactions to keep an eye on.

Obviously one of the end successes was having a fresh look delivered to our users. But aside the company goals, I decided to look at system specific, that truly would matter day-to-day to the team I worked with:

• deprecation and reduction of styles and code
• increased alignment and use of design tokens across the different platforms
• increase on accessibility of the components and styles
• overall work satisfaction among designers and engineers
• boost on guidelines coverage (creative team adoption rate)
• base for themes
  

Apart from project criteria, I’ve also kept an eye on determining if system has been a success on its own already, by monitoring how easy it is to run global changes.

You won’t have the answers for everything at once, accept that they may come along the way. What you can’t see with your sight, you might see with your curiosity. Approaching the uncertainty with curiosity mindset can help you to succeed.

Mapping interactions & recognising the strengths.

At such a scale of a project there is always a bigger group of co-workers involved. That also increases a complexity. What helps is to see the whole network from the start. It is important to understand the relations. Mapping helps creating a shared understanding of the collaborative interactions to form.

The quality of duos is collaboration

I learnt that duos has been very effective in order to move forward and collaborate. A combo build from different strengths is empowered to inform each other and the rest of the team, just like my duos with a Creative Lead, Engineering Lead or Product Designers. We operated as duos, but together we formed a great team.

Expectations clarity

I learnt that to establish a relation is important to be transparent from the very start about expectations we have for each other and if they are realistic. With each duo I created a mutual understanding of the roles we are playing in this project and what we can find each other accountable for. Each week I also expressed my time availability in regards to individual contribution support .

Working on dynamic in duo for some may mean working on encouragement and providing more supervision than expected.

How duos operate is their own way. Relationships are unique and forming them happens through unique ways too. Staying in open and frequent communication forms the trust. Empathy not only builds stronger relationships, it also leads to productivity.

Connect the dots.

Forming a process for every voice.

The experience I gained overtime and the work from past two years has been a game changer for process creation this time. Cultivated rituals, qualitative research, management and  work processes, mentoring and empowering the teams overtime, all came in hand.

We sat together with an Engineering Lead, drafted initial roadmap and added extra cherry → milestones.

Milestones have been for us moments of celebrations. Created not only to admit the progress of the work, but foremost be grateful back to everyone who has been involved in that heavy lifting. As a ritual every end of the week we would highlight the DS wins both on design and engineering side and the ppl behind them. Setting a space to bring the best in everyone.

When planning the roadmap in zoomed-out and later zoomed-in format, it has been important to always mind the roadmaps of dedicated product teams. Here consult with PMs & designers in order to form an alignment of expectations. Staying in the feedback loop frequently. We obviously had our DS logic for execution, based on the impact, usage & effort, but we also depended upon the product teams contributions and shifts in their roadmaps.

Due to uncertainties around the proposed visual direction for the product we decided to focus on unlocking the potential of using the system (especially styles) as early as possible by our designers to test and iterate.

We used Jira board both for roadmap mapping and tickets management on DS engineering and design production sides.

We approached the challenge with a mindset to adapt quickly. It was important to have the team on the same page and mentally ready for frequent back and forth exchange, not being discouraged that we may rework something we’ve already touched. It has been a process based on the circular exchange of information working in both directions.

When creating a process and culture around it, rituals always been our favourite.

In this initiative we run

• me & engineering leads collaborative catch up (weekly)
• weekly ds open hours → my check-ins with product designers, collaborative-review sessions
• me & creative lead catch up (more less bi-weekly)
• ds-rebrand slack channel → weekly updates for DS curious and DS involved 
• coffee breaks & learning sessions 
• participation in bi-weekly demos (operated by the company leadership)

We used

• Figma for commenting, design reviews, engineering expertise sharing & hands off 
• Jira ticketing for management and progress overview
• Google docs for track of our agendas and desicions made during the sessions

My calendar became a jigsaw puzzle while performing individual contribution and team assistance at the same time.

There is no one fit all and hiccups in the process will appear. Showing vulnerability along the way can bring far more support to the team than silence or frustration. Cherish the experience you’ve gained and use it, it will cut quickly through the complexity.

Pick up the fruits.

Achievements over time.

I worked on the translation that would swap the values and update the names for design tokens without the harm to the system, unnecessary detachments or extra relinking work. Translation method helped not only to keep the system in Figma out of breaking, but also supported guiding engineers through their implementations. We could see the effects on all our components instantly and find any visual regressions. Obviously we faced deprecations or creation of new styles that has not been in use, since not everything could have been translated 1 to 1. It has been one of the most exciting moments for me when applying changes. Global updates = pure magic!

The minus point I have found was that Figma didn’t allow to merge two styles into one. We had this issue with text styles for instance. Another weak point in Figma that could speed up the process and even closer align us with engineering was that semantic colors didn’t pull from base colors styles, you always had to add the hex code manually to every token. This wasn’t fortunate for frequent testing we had to go through.

Strategy for design tokens

Within this redesign we set a bar higher and used this time to get as much alignment between Web & Mobile Apps in terms of design tokens as possible. In the past the mobile team would rely on native libraries nearly for everything. But with the new visual direction this could partially change. The big one were semantic colors which we structured in the way that could use cohesive naming conventions across all the platforms. Very long awaited moment for me and an example of effective collaboration.

Expansion in guidelines on creative side

I dreamt about this since I started the DS initiative, to see Creative team getting their part in contributions. In the past there has been no bandwidth to invest into expanding the guidelines. The team operated only on minimum system touch points that we set together in Adobe Libraries. However overtime we actively exchanged knowledge with each other. Few guidelines inspirations I’ve sent would now blossom into extended documentation. One of the examples are colors pairings and their usage for the channel specific storytelling (instagram, youtube). Another achievement would be updates to the Adobe Libraries, this time independently. 

Assets library

In the past only Web Library and Creative team would use the custom icon set. Android and iOS apps would rely on external libraries and have them located internally in their UI kits. During the redesign not only we swapped the icons inside the Assets Library without name changes on files, but expanded to be used by all platforms. Icons been delivered in two flavours - outline (default) and solid (Android usage). Android and iOS Libraries would gradually start relinking icons inside the components to connect with Assets Library. Sooner the Assets library would start getting reacher with iconography and illustrations (delivered by a hired illustrator).

Single line of code and accessibility increase

Redesign became also an opportunity to do some clean up in components that been overcomplicated, and increase on their accessibility scores. Each Product Designer and Front-end Developer in charge for the contribution, would be responsible to run accessibility check & suggest improvements. In addition we would also host a couple sessions with accessibility experts who would test and provide us with feedback on new designs. 

Buttons have always been our headache, the previous “visual direction” wasn’t fortunate on that aspect. Finally with the new simple vision we could clean many lines of code by providing one button in multiple variants, and reorganise the structure in Figma as well. Another win was getting them to be accessible.

Testing branch & Storybook

Web Engineering Lead with his team would set a rebrand branch. We would use it for implementation, QAs, and to monitor impact of changes in entire product. Storybook would be updated on the side. Developers quickly added a toggle that enabled us to switch between light and dark mode (a feature that hasn't been existing before), so we could instantly observe the impact of semantic colors and slowly mentally prepare for another release. 

Theming in Mobile Apps

Dark mode has been planned for a second launch, however Mobile Apps team already needed to provide users with some answers. A Product Designer has put the efforts to start testing the colors for the dark theme (from agency suggestion) and inform DS back. Together we would collaborate on analysing values, as well as elevations possibilities. This has been still far from the end vision for successful dark theme, but it was a good start for everyone. Mobile libraries would have both variants of the same component (light & dark) available in one library. This has served a current need for the PD. Alternative that I wanted to test later at scale was to use a theme plugin to generated entire version of independent dark mode library at once.

Collaborative bridges for shared components

The teams not only depend on alignment in terms of shared styles, but they also shared some of the components (if not directly via code, at least via appearance). Therefore when working with my duos I was making sure that they are also collaborating between each other. Header navigation, search field, buttons, cards would be just examples of components present in both apps and web user journeys. We run ideations on exploring different proposals, and while converging we would pick the one that would be implement inside the system.

Rethinking documentation

Work on documentation began after the brand book delivery but further investment been planned for later in July. Normally when working on contributions we would always provide component and guidelines together, but there was no bandwidth this time to hold this simultaneously. Documentation we had in Figma has been from the time when part of it was tailored to guide engineers on building the components. Focusing in depth on the composition, behaviour and interaction. This time the purpose was to simplify it and make it even more design oriented. Documentation for engineering specifics would sit in the Storybook.

Highlighted designers needs around components guidelines would include:  general purpose of the style/component, show rather than tell, if applicable provide do's and don'ts of how to use it, inform which parts of the user journey can be affected if the change in the component happens, provide a link to a Storybook to see the prototype, leave the info about the owner of the component (team to contact), contributor of the component (designer & engineer), and status (done, in progress etc.).

CHALLENGE & LEARNING

Creating awareness around the system work might be a never ending process. Even when you are far along. Always practice gratitude for your team and make everyone feel valued. Projects are a collective effort. If you need people to deliver project outcomes, the project needs to deliver something to them as well.

Belonging for each of us.

My last goodbye before release.

Look back. The timeline.

Back in the end of 2021 I’ve been already holding a decision that I will be leaving Ecosia by the end of April. Which meant that I have not been around to observe the first release to the public in June. Early April was a transitioning phase and passing my responsibilities to a DS freelancer. It has been a difficult decision especially that we just hired DS engineering lead (after long time advocating for one) and a Content Designer, but it was my time to say goodbye.

Looking back on the timeline, and the circumstances behind this project, I am extremely happy of the progress that has been made in DS within such a short time.

Leaving with peace of mind. Belonging as ROI.

Analysing the initial success we were aspiring for, I was proud to see that consequently we hit almost all of the points from the list within first 2 months.

• The system allowed smooth and quick global updates during the rebrand.
• We were capable to create new feature improvements way quicker while keeping the cohesiveness.
• Rebrand of the system provided higher scoring in accessibility and more simplicity in the code and Figma components.
  
• Shared language and bridge between product design-engineering-creative had been formed.

Above all I was calm since not only 70-80% of existing system has been updated by new direction, but also I could see that we gained more advocates for the system, that will continue sharing the value of maintaining and expanding it.

It has been a project to not only identify the belonging of styles & components, and their changes, but also about re-identifying our interactions with DS. Recognising its power & dependancy. Re-identifying a belonging of each product designer within their work as much as each engineer. Building the awareness of not just producing, but producing smartly and in collaborative mindset. Learning to understand the system role better, open up and be playful with it. Show how it can flex and be fun at the same time. After all systems are for people, and what mattered the most was the cultural belonging that has formed around the DS.

To take with you. Best practices for cultural belonging.

Interested to read more? Find out about my journey to create a design system  → On the road to Flora

Or learnings when leading one  → Nudging a Culture