The journey

We've been on a long run to DS maturity and it wasn't the one where you go from point A to B without surprises. Along the way we've been facing challenges, and we had to quickly adapt or experiment. Company focus has been shifting often, team members have been changing. How we learnt to deal with this living organism over time, was meeting people where they are, starting from there and doing our best.

Identifying the needs and success for a system.

The idea was born

As a newly coming designer shifting from a company with established way of working to a company that is just about to scale and find their ways, I quickly identified the key pain points you face as a designer, and observed the ones faced by the engineers. 

User & business needs:

• Cohesion level throughout the product has been in an extremely poor shape when I joined the company → build users trust and elevate product quality.
  
• I spent great amount of time on onboarding myself and on tiny design decisions → minimise the appearance of arbitrary decisions & fatigue, decrease onboarding time.
• Navigating through the files was time consuming, the hand-off with engineers didn't feel as a handshake, the working experience felt like going back in time → improve & speed the designing and prototyping processes.
• The entire product was based on outdated code, the available variables haven't been used → minimise the technical debt.

Needs that emerged overtime:

• The company's strategy was to scale within the next two years, hire more designers and engineers, establish new product teams → scale product cohesively and get on board new mates quicker.
• The company had an appetite to improve the look and feel, but needed to grow a budget for that → get prepared for global design changes & define clearer design direction.

Hypotheses for the journey

Taking into consideration primary needs, I established a set of criteria, which we carry with us along the way as a guide for planning, prioritisation, measuring, and evaluation.

We believe that the design system:

• will allow to bring to our brand cohesive experience and improve the user experience overall
• will enable our teams to work together better, efficiently, and aligned, leveling up design and code quality 
• will enable our teams to test the performance of the components in isolation
• will provide a base to roll any change in visual direction
• will support our efforts on accessibility
• will provide easy to use tools to empower us on faster and better quality iterations
  
• will grow the skillset of individuals and overall design maturity, attracting talent due to modern ways of working
  

Working on the buy in, highlighting opportunities.

Through past 3 years I've been consecutively working on the buy in among leadership, product, and marketing teams. It is not something you can do once and then sit calmly, not in the company I worked at. We obviously have been experiencing frequent push backs.

The key when working on the buy in was to highlight the opportunities from various angles. Showing that the end effect will impact our end-users & brand. Expressing how it ties to Brand and CLTV (company's objectives), having on the radar stability, stickiness and consistency.

Defining what it means to the business: the amount of working hours saved over time = amount of money saved over time. And last but not least what it meant to the team - direct users, knowing about the decision fatigue, burnouts, and hope to attract talents.

We maybe didn't get all what we wished for, the ideal focus or circumstances for building design system, but what we won overtime was a team advocating for this movement and a vision that we don't want our efforts to go in vain because we already benefit from it.

Metrics.

We didn't have resources in place for establishing better monitoring system of the progress. Tracking employee's delivery time directly wasn't a part of the company's culture. We heavily needed to rely on manual calculations and mostly qualitative feedback  from the users of our system. Which obviously not always provides data to be very reliable.

We measured: 

• coverage overtime 
• direct-users satisfaction
• adoption

We observed: 

•  shared ownership
• development speed
• time spend on hand-offs
• effort investment into simple change across the platforms (e.g. color update).
  

Meeting you where you are.

Collaboration & Team.

Our set up has been changing overtime. We remained flexible to the company circumstances, and receptive to feedback from the product teams and the individuals.

We went from a side project to a 2 person centralised team (DS duo). Quickly aspiring for evolving into a hybrid model (in its better-worse shape). Sadly we faced challenges which led us to cut engineering management costs, and reform collaborative ways. Throughout the year I focused on working intensively on shaping the hybrid model inside the design team, forming a DS culture together, and elevating the level of shared ownership.

We kept the collaborative spirit through:

shared roadmaps and planning, stand-ups, forming communication channels and engaging others to participate in them, workshopping and collecting feedback on contributor's guidelines, user testing the libraries and guidelines, engaging direct-users into feedback rounds through surveys, monthly & quarterly retros, open hours consultations and 1-1 sessions, engineering rotation, onboarding meetings, studio day & creative workshop with designers, audits & prioritisation workshops with the migrating team, annual evaluations & TGIFs.

The highlights of the bumpy road.

Flora in action.

Before March 2020 I conducted audits on entire product to define the links and to understand what our system will consist of, before diving into work on Sketch Libraries. I've been looking at the product offering in 3 sectors: web, mobile apps, marketing (brand). The audits compared live version vs. Sketch version vs. Ecosia Styleskit of styles and components. I analysed availbility, use, its behaviour, number of variants, and product visibility to the user. Additionally added hints for improvements. During the year of 2020 me and Frontend Engineer made few mini-audits when working together on the guidelines & code, as well as when establishing specific components together with the Search team. Audits have been a helpful practice.

Collaboration & Contribution  - Governance

In the first months in the centralised set up I collaborated on establishing a solid theoretical basis (governance) in terms of vision, principles, roadmap, communication channels, feedback loops, versioning, contributor's guide, and ticketing. This has been very important when setting the expectations, keeping others informed, as well as providing directions to the teams who will be contributing. Since we've been fully remote due to pandemic, we (DS duo) used Miro to support each other with mapping the work to be done. We also set up an environment on the Confluence, Jira, dedicated Slack channel to offer a visibility to others, as well as ease in tasks management & execution.

Libraries & Documentation

Parts of our design libraries had been already reflected by me in Sketch before March 2020, however much of the work needed reviews, alignment, and further development between design and engineering.

We defined the structure of the system together and shared it between design and engineering team, as well as kept aligning ourselves where possible on the naming conventions. What really helped us on this journey and when moving forward was competitive analysis. Obviously we were not competing directly with other design systems, but that type of research served us as a learning to find strengths, opportunities and at times solutions to common problems. 

We had an implemented page that was hosting few components from the years before. However the investment costs to evolve it and maintain it were too high for our budget. Following my suggestion, my engineering partner explored and tested the available on the market solution: Storybook. He provided the integration with Vue.js and got the buy in from the rest of the FE guild. Ability to test components in isolation was a big selling point. The excitement on the engineering side started to really pick up.

Next we've been able to put some of the work I've done on the assets into our Storybook and sync them with the code → a set of the interface icons and guidelines. 

On the marketing side I made sure that the shared foundations such as colors and icons, have been available in the Adobe libraries, so at least in that aspect we could start bridging and strengthening the realtion.

The implementations of our components has been coming through the work of centralised team, and individual contributions from the product teams. Prioritised components for the search migration have been a great add to evolution of DS.  

To coordinate contributions on design side in 2020 I've used Abstract. In the mid of 2021 we hit another milestone → together with the design team I migrated our libraries and design workflow into Figma. We actually never looked back to Sketch since then.

Each of our styles and components would be supported with documented guidelines since the beginning. In the past each page would be exported to Zeplin for easy access & design hands-off. After migration Figma & Storybook were two places holding design and engineering parts. Our management and workprocesses documentation would be located in Confluence (same as for the rest of the company). Overtime I also looked into other tools, for instance Zeroheight, to analyse if investing into it could be promising. Due to shortage of time and resources further testing been abandoned.

Expanding to Mobile Apps

Next step on this journey during our migration to Figma has been building UI kits both for iOS and Android Apps. Since we've been heavily relying on the native systems, this has always been a mix between some of the Flora foundations and external guidelines. The current outcome has been a result of collaborative work between me and a Product Designer (PD - an executor, me - a guide). Further development has continued after the rebrand of our product (in 2022). 

Jet lag & delayed flights.

Challenges along the way.

Obviously there is no perfect journey, but what makes it interesting are the challenges along the way. And here is what we've faced:

• business pressure - desire to push new features prioritised over the migration to DS
• the amount of tech & design debt vs the size of the product
• low engineering availability to implement fixes and iterate (e.g. accessibility global fixes)
• knowledge gaps causing slow process of adoption in the very first year
• lack of leadership on the engineering side (no clear ownership behind the code and self-organization)
• resentfulness from cross team planning and collaboration
• staffing issues and frequent hiring involvement
• major shift of visual direction through redesign before the code reflects our design libraries

Souvenirs brought back.

Coverage (data from 2021)

• Design libraries: 90% coverage of foundations and components in Figma for Web & Apps, colors and assets in Adobe Libraries
• Code libraries: 80 components exist, of which 61 have unit tests, and 17 provide component-specific documentation (Web); nothing reflected on the Apps side at this point, only reuse of native systems
• Documentation: 85% of design guidelines established for Web, 10% for Apps and represented in Figma. Our Storybook is missing documentation for some of the existing components. There are no established design guidelines on marketing side, only few presentations.

Adoption (data from 2021)

• Product Design: 5 Product teams (web & mobile) = 4 designers directly contributing
• Engineering: 3 Product teams reusing what has been established, 4th is currently onboarding
• Marketing design: 4 Creative designers relying on colors and assets, no formal contributions at this stage
  

Shared ownership. I've been observing a significant improvement from the time when we started in March 2020. At the beginning the team been fearful and resentful when it comes to contributions and communication. The first shift happened during engineering rotation. The next shift been identified in design team during integration of Abstract, and then another the most significant right after migration to Figma. We are consequently improving our shape.

Return on investment observed:

• Improved delivery speed → designer who uses libraries is proven to be more effective with their time and consistency than the one who is not
• Reduce of cognitive load for the end-user and for the direct-users (consistency)
• Improved performance of the code files rendered, unified & simplified code for FE - better testing opportunities, cleaner code guidelines
• Ability to share existing common guidelines with other engineers, new designers, and external companies minimises the time investment from weeks of work into minutes of work, while expanding the audience reach.
• Documentation prepared upfront has been a life saver when taking on the Search Migration or thinking about mapping a new visual direction
• Small improvements on accessibility and usability of the existing Product (e.g. Colors)
• Small improvements on brand cohesion 
  

Travel lived stories.

Learnings.

#1 / Setting and maintaining design system is a team sport.

#2 / Accessibility or brand cohesion doesn't sit only within responsibility of the design system.

#3 / The more you talk about the needs and show the value, the more positive response you may receive. 

#4 / Meet people where they are, be gentle, responsive, and remain flexible.

#5 / Start small and work on adoption as early as situation allows you.

#6 / Buy in is not enough, a willingness to adjust could be the first step.

#7 / Someone's enthusiasm doesn't mean their direct engagement into the work, someone's enthusiasm doesn't mean lack of fear and doubt. 

So where are you heading to?

Aspirations and next steps.

Today ... we continue the journey with a purpose to provide empowering and intuitive experience to our teams and our brand. Next milestones we would like to hit are: 

• New visual direction adapted into the system together with a significant boost on accessibility
• DS Engineering Lead hiring & further implementations in the web and mobile code base
• Interactive components in place in Figma
• Further development of DS culture through playful and creative activities
• Setting better testing and analytical base when monitoring life of the system
• Setting a page to hold the new company guidelines (e.g. by use of Zeroheight)
• Investment into plugins and translations methods (bring automation to generate components in various languages)

Interested to read more? Discover my journey when redesigning a design system →  Re-identifying belonging 

Or learnings when leading one  →  Nudging a culture