Design System for Supplier Discovery Suite
In this project I wore the hat of the product manager and led a multi-disciplinary team to deliver a design system that powered multiple products in a market-leading supplier discovery suite. I managed stakeholder communication, cross-product dependencies, and ensured delivery ahead of schedule.
In this case study: vision, strategy, roadmap, prioritization, stakeholder management, cross-team dependencies, design language, documentation, communication strategy, design system adoption
My role
Product Manager
Year
November 2021 - July 2022
The Problem
Over the years, the suite grew and new solutions developed quickly in silos. This led to many problems, mainly:
-
different user experience and design language across the many products,
-
divergence in the way teams design and develop products,
-
lack of a recognisable design language.
The Goal
The goal was to build the Design System, complete with foundations, design assets, reusable code, UX principles, accessibility guidelines, interaction specifications, and a unique and recognisable design language.
This would help the company and the product teams to:
-
build consistent, accessible, bug-free products faster,
-
free up time to focus on running more research, designing new experiences, developing new algorithms, and defining new business logic,
-
create new features, services, products, POCs efficiently and cost-effectively.
-
shape a recognisable design language for the brand and products by collaborating with marketing and branding teams.
My Responsibilities
-
Initiated research, stakeholder and expert interviews to define scope
-
Created a detailed plan, elicited requirements from product teams
-
Defined scope, goals and milestones
-
Helped the team define and track key success metrics
-
Created and updated roadmap based on product requirements
-
Planned and prioritzed sprints
-
Set up transparent collaborative communication inside team and between other product teams,
-
Defined communication strategy with stakeholders and the wider company
-
Aligned on dependencies with product teams, managed stakeholder expectations
-
Collaborated with marketing teams on product branding and positioning
-
Motivated team to successfully meet deadlines and milestones
-
Enabled product team to launch MVP using the design system ahead of schedule.
Approach
A Design System is a product like any other and requires a dedicated team of its own and a regular development process.
Scope Definition
The first step was to understand what exactly we’re building, who will use it and when. We ran a series of stakeholder interviews with designers, developers, product owners and leadership to understand what the expectations for the design system were from the wider company and product teams.
We would build a UI Kit (components in Figma) and a Component Library (its code version), complete with usage guidelines, design principles, and a reference website.
Research & Exploration
Next, we created a knowledge base of best-practices and made decisions on how we would build the components, how we would put together the documentation, how we would organize the assets, which taxonomy, tools and plug-ins we’d use.
Defining the Design Language
First, we talked to designers on product teams and defined our design principles. These were loose guidelines informing our design language such as: show data sources, provide user guidance, make B2B feel like B2C.
Then, we put together five moodboards that showed very distinctive design directions, out of which we selected two unique styles. At the same time, the marketing team were working on a brand repositioning, so we joined forces to harmonize our one approach.
Next, we designed key "hero" screens: the dashboard, profile page, and search. This activity helped us finally crystalize the one style that would be truly ours.
Preparing the Design System
We started with foundations: color, typography, grids. Next, we would built essential components such as buttons and inputs. To define which components we would build next, we did an inventory of existing products and of future product wireframes, compared them, synced with product teams and prioritized components for new products with higher priority.
Component documentation included:
-
Types and variants: active, disabled, pressed, hover
-
Behavior (a link to Storybook) with any animation
-
Anatomy: size, padding
-
Usage guidelines: do’s and don’ts, placement, order, text info such as semantics and syntax
General documentation included:
-
Accessibility guidelines – which we baked into the components while designing & developing them
-
Design Principles – 10 general rules which informed our design language.
Core Team Setup
We worked in sprints, had daily standups, plannings and retrospectives, internal design reviews twice a week. Internal design reviews had a set structure: check-in on roadmap, track OKRs progress every fortnight, prioritize components and fixes, design updates, review and open questions.
Instead of Meeting Minutes (which are sometimes difficult to navigate, with decisions actions get lost on various pages) we had an Open Questions List with a date, question & discussion, resolution and status.
We also created a Creating Components Checklist – a definition of ready for designers to use when designing and documenting components. It included:
-
checking spacing, margins, auto-layout,
-
designing necessary states,
-
checking accessibility,
-
adding and cross-checking metadata,
-
checking naming and taxonomy,
-
writing the component description,
-
describing component use cases, layout, placement, outlining the component anatomy and structure, providing grid info,
-
adding a link to Storybook for interaction reference,
-
describing responsive and screen size implications,
-
showing edge cases, empty states.
Communication Strategy
One of the most important parts of any design system initiative is the communication that goes into it. We identified key stakeholders, the information they are most interested in, the updates they need, the channels they’re most comfortable using, and how often they’d want updates.
This informed the following communication channels:
-
Slack channels for support and announcements
-
Dedicated Design System team wiki page (who we are, wow to reach out to us, links to Figma & Storybook, glossary, feedback and announcements channel)
-
Regular weekly syncs with product teams (where we discussed how to bring together our roadmaps, discuss new components ready for handover, component feedback, fixes etc.)
-
Regular syncs with marketing (to stay on track with the rebranding initiative)
-
Monthly company-wide presentations (for bigger announcements)
-
Surveys to track team satisfaction
Cross-Team Dependencies & Collaboration
Collaboration with Product Teams
When we started out building the Design System there was a mismatch in timelines. We tackled the issue by working closely and consolidating our roadmaps and ensured that the platform could launch an MVP using the Design System in a month and a half.
We were in constant sync with the product team. First, we looked at their wireframes and identified all the possible components. Then we prioritized them, staying flexible to changing priorities.
Initially, we'd planned component handoff in mini-waterfalls, but in reality we were able to handover components very flexibly as soon as they became ready and get early testing feedback.
Collaboration with Marketing & External Design
One of the benefits of having a design system is the flexibility to easily implement changes. So while we were building the design system, an external design agency was working on a redesign. We collaborated early on and made sure we were on the same page, adjusting both the branding design and the design system foundations.
User validation
The primary users of design systems are product teams. That's why we ran internal usability testing sessions with them. We prepared an example mockup of the registration screen using the design system. In the session, the participants had to recreate the mockup, as we observed how they use the design system in order to complete the task.
The feedback was great and there were many insights mainly around:
-
what wording is used to search for components
-
grid usage and sizes naming (e.g. what's the pixel width equivalent of "S,M,L,XL"?)
-
whether to use icon button or icon
-
whether to use text styles or components that contain text styles
We also asked open-ended questions about how they interact with the design system. For instance, we learned designers don't read the documentation new components that are added to the design system, because unless they're actively using it in their Figma files, they will not get any notification when it's published.
We gathered these insights, ideated recommendations and implemented the fixes: clearly stated the screen width in the grid name, improved the component documentation usage guidelines, improved the wording, agreed to post an update in the general Slack channel when new components became available and where to read more about them.
Achievements
The Design System is an overreaching effort that helps bring cross-functional teams closer together by creating a shared, unified language that they can use to talk about the product.
What we achieved:
-
Created a unique design language that captured the essence of the brand, which customers claim is the unique selling proposition
-
Created a scalable foundation on which to grow new products
-
Decreased time spent on UI design and increased time spent on user research and usability testing
-
Enabled the product team to launch their MVP using the design system ahead of schedule.
Next Steps
Design systems require maintenance so that entropy doesn’t take over, so work on a design system is never really done. The next steps for us are to continue enriching it with new components and documentation, to bring in contributors from product teams, and to continue empowering teams to build POCs and new products.
