Pearson Design System
UI, UX | 2017 - 2018
How do we help teams adopt the design system effectively?
Overview
In 2016, Pearson adopted a new brand identity, which led to the birth of a unified design system - The Pearson UX Framework.
Our goal was to help the company achieve design consistency and efficiency at scale. While I worked on a variety of projects in the team, I focused on the redesign and growth of our design system website that hosted the UI library, design guidelines, resources, and community support with the goal of helping the company adopt the design system effortlessly and smoothly.
My Role in the Team
1. Designed & Maintained a Sketch UI Kit
I created, maintained, and managed a Sketch UI kit for designers to easily adopt the design system in their workflow.
2. Designed and Documented Components
I designed a few components and documented the design and usage guidelines for designers and developers.
We used Github for documentation:
3. Helped Establish a Standard Process
I collaborated with designers, developers, and accessibility specialists to standardize our governance review process for quality assurance. Below is a checklist created for component creation.
4. Built and Managed Email Newsletter
I initiated an email newsletter to promote the design system by informing people of the latest releases both in design and development. I designed and built the email with MailChimp, and composed the content in collaboration with designers, developers, and a writer.
5. Redesigned & Continuously Enhanced the Design System Website
Pearson Design System Website
A design system isn’t successful if it’s too hard to understand or adopt, or if it’s used in the wrong way. Therefore, it’s important to have a single source of truth to host the repository. This site is the one-stop shop for everything designers and developers need to adopt the design system.
Our Goal
Since 2016, we’ve rolled out two major redesigns to increase adoption and participation. Participation was critical because we knew that our consumers (teams that use the design system) were the ones who would be able to speed up the growth and evolution of the system.
I focused on improving the following areas:
Usability - Is it easy to use?
Utility - Do I want to use this?
My Role in the Website Redesign
I partnered with another designer who was also the developer on the redesign project. Like a startup, we each wore multiple hats and collaborated closely on the project from discovery to implementation.
What I did:
Conducted research, analyzed findings, and proposed solutions
Proposed vision to stakeholders through presentation and prototypes
Provided pixel-perfect UI design and worked with engineering on the implementation
Strategized and planned for the product roadmap together with the team and stakeholders
My Process
Conduct user research to understand user needs, goals, and pain points
Conduct an audit of the current website and identify areas for improvement and opportunities
Present findings and recommendations to stakeholders and team
Build prototypes to convey vision and collaborate with designers and engineers to arrive at the final solution
Plan out the roadmap by prioritizing work based on impact and effort with stakeholder and engineering
Execute the plan
Learn and repeat
User Research
Understanding who we were designing for helped us see the world from the users’ perspective, and ensured we were solving the right problems. I started the project by asking two critical questions:
Question 1: Who's our target user?
The website served two groups of users - the Design Systems Team, and the rest of the product teams in the company.
I wanted to understand:
What are their goals?
What are their processes?
What tools do they use?
What are their challenges and how can we help them overcome these challenges?
To answer these questions, I invited users of different roles to talk about what they do, and how they do their jobs.
Question 2: How can we improve the UX Framework?
What do people think of the UX Framework from the design system itself to the website?
Do they find it useful or do they find it adding to confusion, complexity, or more workload?
How can we better help them accomplish their goals?
To find out, I approached our users with a brief survey followed by a one-on-one interview to learn more about their thoughts and the different use cases. Then, I transformed these insights into tangible design solutions to improve the user experience.
Findings & Recommendations
I conducted an audit on the current website and compiled my analysis and suggested solutions into a 37-page report for stakeholders and the design system team:
Prototyping
Case Study
Dealing with multiple versions amid software development chaos
Step 1: Identifying the Problem
“I don’t know which version to use.”
Through user interviews, I discovered that users were overwhelmed by the different versions of the same component provided on the homepage.
For example, the button component had three different versions: Design, Code, and Beta. Users simply didn't know which one to use. It also caused confusion during team collaboration as each person was referring to a different version of the same component.
This was the UI before the redesign:
Essentially, Beta was the in-progress design that hadn't been approved yet. We learned that showing the Beta version of a component on the website was particularly confusing.
If Beta was causing all the trouble, why couldn't we remove it entirely? While it sounded like an intuitive solution, I soon learned that it would just create new problems. Without hosting the Beta version, we wouldn’t be able to test the proposed designs or collect the feedback needed from our users to move forward. While users complained about the confusion around the Beta version, they still wanted to see what was coming to avoid any redundant work. Therefore, we decided that the bottom line was to keep the Beta version but solve for confusion.
I also learned that since each product team worked at a different pace, we must keep a reference to any previous versions of a component for product teams to access.
Step 2: Brainstorming Ideas
You don’t get to a good idea without coming up with a few bad ones.
How do we empower users to make good judgments on which versions to use while providing access to multiple versions of a component?
The key was to communicate the differences between the versions and let the users weigh in on the opportunities and risks based on their unique situation.
Here are a few concepts I have explored:
Click the arrow icon on the sides to view all 4 concepts:
Step 3: Arriving at a Solution
Meeting user expectation and clarifying the versioning
Confusion is often the result of a disconnect from expectation. So, we decided to go with what users expected - just show me what I should be using! That led us to the decision to go with Concept 4.
Instead of asking users to pick the proper version up front, we took out the guesswork by directing them to the latest approved version by default. Then, if they were interested in seeing what’s coming, they could access the Beta version with an extra click. All previous versions were accessible at the bottom of the page as well. We also added friendly messages to clarify the difference between the versions to help users make their own decisions on which version to adopt.
Here’s the final solution:
The Impact
The redesign had greatly improved the site’s usability and utility.
Users could now:
Be more confident in determining which version of a component to adopt based on their unique situation
Navigate through the UI library more efficiently using the side menu and the component search functionality
Contact the Design Systems Team for support through multiple channels such as emails, chat, and group discussions. This also allowed us to collect user feedback that would contribute to the evolution of the design system.