Evolving Pearson’s Design System

Instead we decided to prioritize and focus our efforts on resources for designers.

We would still provide redlines and documentation for developers to implement our components, but we would no longer create an official library of code.

2. Partnering with product

As part of our new focus on the design side we partnered directly with key product designers to bring the components and patterns they used into our library of guidance.

For the first version of the design system we had just created our own interpretation of common UI elements based on audits and reviews of the various Pearson products.

Now we had the opportunity to partner directly with the key designers involved in Pearson’s latest and greatest design efforts. We analyzed the new designs to identify their constituent patterns and create new components specifically for them.

3. Offer higher level guidance

One bit of feedback we received about the original design system was that designers didn’t always understand how they should combine our components into complete pages and flows. We had documented the trees pretty thoroughly, but had little guidance around how to plant them into a forest.

We took our partnership with the key product designers as an opportunity to add higher level resources that explained the thinking behind the components and would help designers understand how each piece could fit together.

Together we created guides that covered the underlying decisions and approaches for topics such as our design principles, visual style, page layout, writing, accessibility, and globalization.

Over time we worked with other domain experts to add even more guides, including topics such as onboarding, data visualization, and animation.

These guides helped orient designers and created a shared context for understanding and using our various components.

4. Invest in easier and more powerful authoring tools

Although we were seeding the updated design system ourselves, we wanted any designer to feel empowered to contribute to and evolve the system.

I had set up a Jekyll static website system to power the first version of our guidance.

Contributors needed some command line kung fu to install Jekyll and start working with git, but these weren’t common skills amongst the design team. In addition, our templates had grown pretty complex at this point and required a bit of domain knowledge to fully leverage.

If we wanted other designers to quickly and easily contribute we would need to invest in a better authoring tool.

I drove improvements in this area, researching different options and ultimately choosing a Craft CMS installation. I set up and configured a server, customized our templates, wrote migration scripts to import our old content, and trained the rest of our team to begin using this new authoring tool.

5. Simplify contribution process

In the first incarnation of our design system we had a 16 point checklist that each component had to meet before we included it in the library.

Although designed to ensure the quality of our guidance we found that this significantly slowed the creation of new elements and discouraged contributors from other design teams.

We wanted to make it easier to add new ideas to the design system while retaining our quality standards for finished guidance.

We explored processes that would allow contributions to start as rough ideas and then gradually mature into polished guidance. Instead of requiring contributions to go through a full checklist review before sharing with the team we created options for posting basic ideas earlier on in the process.

This allowed the whole team to share feedback and help shape the new guidance from an early stage.

6. SWARM meetings

Another issue that prevented contributions to the design system was simply time, or the lack of it. Product teams tended to have very full schedules, tight deadlines, and often bounced between different projects. This made it difficult for them to find dedicated time to share the patterns and approaches they used.

We could make our tools simple and easy to use, but we couldn’t invent more hours in the day.

Instead we tried to meet the designers where they were at, and shift some of the contribution work onto our team itself. We created a series of S.W.A.R.M. (Surprisingly Wonderful and Refreshing Meeting) events where we could catch some precious time directly with designers to collect information about their latest patterns and approaches.

This was a workshop approach designed to make the most of just a few dedicated hours with various product designers. We would pre-plan an agenda based on our reviews of various product screens so that we could jump straight in to gathering information about new components and patterns.

We then spent several cycles internally cleaning up and finalizing the seeds planted in these meetings. Ultimately this proved to be an effective method for growing the design system, and we created several components based on input gathered in this way.

7. Adopting Shape Up

As our design system team grew over the years we realized we needed to create some internal project management processes to help us decide what to work on, manage our time, and ensure we completed projects.

We were fortunate to work with a couple skilled contract project managers at various points, but unfortunately lost the budget for this role. I stepped up to take over these responsibilities.

It was around this time that Basecamp published their Shape Up book describing their process for creating and shipping product work. I thought several of the principles would help our team make more feasible plans and get better at completing projects.

I advocated for this to the rest of the team, helped teach them the new ideas, and got the green light to try out incorporating it into our workflow.

We focused on adopting the idea of shaping work to fit in a predetermined timebox before we committed to doing that work. The shaping process involves taking a raw idea, investing time to understand the underlying problem, choosing a general solution, and creating a boundary around the work so that it can fit within a predetermined timebox. It leaves room for the specifics of the solution to be guided by this boundary, but details are ultimately finalized during the execution of the work.

Before adopting this workflow we had a whole group of stories in our backlog tagged as “Needs more planning”, but we never seemed to put in the time to plan them. Mostly they just sat in the backlog. On the few occasions we did pull them in to active work they would invariably end up taking much longer than we had initially estimated.

Following some of the Shape Up practices helped us devote time to shaping these unwieldy stories into specific problems and a bounded solution. Switching away from estimates to timeboxes helped us finish work more regularly and ship new content and features, instead of carrying work over from sprint to sprint.

8. Comment System

One specific project that benefited from the shaping process was our addition of commenting tools to the website.

We’d had the idea for a while, but going through the steps of shaping the idea into specific chunks of work helped us refine the problem we were trying to solve and tailor the solution to the amount of time we wanted to spend on it.

The ultimate problem we were trying to solve was the high-touch nature of our contribution and feedback process. We used the swarm meetings as a way to kick off new contributions, but when our team worked to mature the rough outlines created in the swarm meetings we often needed some follow up input from the original designers.

Frequently this meant scheduling meetings or trying to replicate the context for our ask with long emails. Instead we wanted to have a method to notify designers directly on the page where we had questions.

We started with the basic idea of adding a standard comments section to each page. After going through the shaping process we realized that we also wanted the ability to create separate threads for organizing different discussions, the ability to close out threads once we came to a conclusion, and a notification system so that we could ping people to keep them engaged in the conversation.

I built out the comment system in our Craft CMS instance, which involved creating a few custom backend endpoints, integrating with an internal Pearson email service, and building out the frontend interactions.