Marcus

Hammarstedt

THE BUSINESS

Redbubble is the leading global marketplace for independent artists to sell their creations on commercial goods like t-shirts, stickers and phone cases. It was founded in 2006 and has grown to support close to 1 million artists that sold to 4 million customers in 2018 alone.

It is available in multiple languages and has offices in Australia, North America and Europe, with North America being the largest market.

MY ROLE

In my role as Lead Design Technologist I acted as the bridge between design and engineering. I interviewed and surveyed our designers, engineers and product managers to inform our teams roadmap and I collaborated closely with designers.

I also continously evolved our documentation, built new React components and brought our marketing and product departments closer together.

THE PROBLEM

Back in 2017 Redbubble had around 250 employees spread out over three continents: Australia, North America and Europe. About a hundred of those were engineers and close to twenty were designers across product and creative.

We didn't have a Design System at the time. However, we had a brand styleguide and processes like design critiques and #workingon channels in Slack to help us stay aligned on visual treatment as a design team. Even still, the overall product was starting to feel fragmented and inconsistent. Colours, spacing, motion, patterns and overall visual style had started to diverge in different directions.

This was the result of a few key factors:

• Teams running multiple experiments with minimal investment
• Not enough front-end expertise
• An old code base with a mix of styles and technologies

THE BEGINNING

Since we had just delivered a new platform that was starting to get adopted by teams. We found ourselves in a position where if we also delivered a Design System, we could help those same teams get their experiences on the new platform faster and with consistent styles and behaviours.

A technical lead and product manager was also excited about this opportunity. Together we collaborated and explored what we would do, and what it would look like, if we had a dedicated Design System team.

EVANGELISING THE SYSTEM

We had some momentum from working on the new platform where we started to lay the foundations for a Design System. However, it wasn't enough to make it useful for product teams and would require dedicated resources to properly take off.

With this in mind, we took every chance we could to present and talk about the value and opportunities that a Design System could bring. I developed a roadmap outlining the focus areas and how this tied back in with business and team objectives. I performed UI audits and highlighted opportunities for consolidation and optimisation. And eventually, we got buy-in from the business to invest two resources, myself and a technical lead, to start delivering on the promise we had made around the value of a Design System.

INITIAL STRATEGY

At first we wanted to establish a distributed model where we encourage contributions from other teams. We introduced new processes and ran workshops to facilitate a shared understanding of the direction and the value of the system. We felt this would be the quickest way to share the benefits of using the system with people, grow the component library and generate excitement.

WHAT WE LEARNT

• Processes caused friction and teams did not feel they got a return on the time they invested
• Conveying the value of a Design System without having one is difficult
• Getting the vision for the system in place first is important
• Deciding on consistent component API's is difficult when starting out

NEW STRATEGY

We realised that we had to rethink our approach and that our best chance for success would be to work closely with specific product teams and use the system to assist them in their delivery.

To achieve this we identified a few teams within the business where a Design System could have the biggest impact. I worked closely with the designers on these teams, collaborated on solutions and identified what we could break down into smaller parts and add to the system. We then checked in regularly to make sure that the direction we were taking with the system and our components would meet the team' needs and expectations.

• Pair with design & engineering
• Plan based on team roadmaps
• Perform regular surveys and interviews

WHAT WE LEARNED

With this new approach our product teams were able to deliver their experiences much faster, since the components they needed were already available for them in the system. It ensured consistency across all new experiences being delivered and it helped us as a Design System team with planning and building components that would deliver immediate value.

OUTCOMES

• Faster component library growth, 12 components in 12 weeks
• More immediate value to customers
• Recognition and customer satisfaction increase
• Adoption increase in supporting apps went from 0% to ~50% across the whole code base in one quarter

THE SYSTEM

Within a year our Design System was the natural way to build experiences for our teams. We achieved full adoption across our main product experiencs which resulted in reduced delivery times and higher consistency.

Beyond components and styles we built out the support for multiple themes, improved the overall accessibility of the site and introduced prototyping tools like Playroom to make exploration fun and easy.

I also brought our creative and product departments closer together by establishing new rituals and collaborating on guidelines. Thus empowering the creative team to also contribute to the system and think about how their work impacts the overall product.

What started with a single colour guide and one component. In the end it hosted over 40 components, 3 themes and 20 guides for use by our product designers, marketing designers, engineers and external contractors.

Learn more: redbubble.design

Initial status of our Design System

Where it was at when I left Redbubble in 2020