Laying the Foundation for the NPR Design System
If your team is considering creating a design system — a shared language of patterns, components and styles — it might help to know how we began to build one at NPR.
Ed. Note: Janet interned with NPR Digital Media Design in Summer 2017. Learn more about internships at NPR.
While NPR has long prioritized consistency of design, the product design team didn’t have formal documentation of design as a system — and finding time to jumpstart the process had always been a challenge.
That’s why they asked me to start creating the NPR design system, a design management tool to create a shared understanding among the team. This post will cover my process and takeaways from my three-month internship.
Define the Problem
The first thing that came to mind was the scope of the project. Building a design system from scratch can take a whole design team months, if not years, of hard work. For example, the well-known Google Material Design system was created by experienced designers with considerable time and effort.
However, being the only person devoted to the project at that moment, how would I prioritize what to document and how to set milestones?
To start the process, I interviewed each team member to understand what has been tried in the past, what kept them from making progress, and what their needs were.
I interviewed nine people in the digital media department, including five designers, two developers, one product owner and one scrum master. While designers are the future primary users of the design system, other users might include developers and other professionals. I included them to have a more comprehensive understanding. I interviewed colleagues who would use the design system and also have influence over its wider adoption.
From nine interviews, I learned that they expected the design system to:
- Create a shared understanding.
- Reuse existing patterns.
- Explain and defend design decisions.
- Correspond to QA test plans/cases.
- Shape expectations before kicking off new projects.
- Preempt contentious conversations.
And they expected the design system to:
- Be clearly defined and serve its intended purpose.
- Be flexible by showing examples and suggestions.
- Demonstrate principles and concrete examples, e.g., what is recommended.
- Be a format that’s easily accessible from anywhere.
- Be easy to update.
- Make commenting and feedback easy.
- Include version history or an update log.
- Not present too much text.
At the same time, some concerns and suggestions were unique to this project. I heard them say:
“My biggest concern is that it will be out of date. Will it be live and accurate?”
“Try to think about a way to show the volume of decisions and updated pieces as time goes by.”
“Everyone here works differently: Sketch, Illustrator, CSS or something else. So, it’s hard to share sometimes.”
“I would say a past mistake was focusing too much on technical issues.”
At this stage, I did several things: checked my options for tools and resources, collected information about constraints and possible challenges, and understood the user needs of the design system.
Ideation
Then, I started to think about how to document the design system and what tool to use. I talked with my mentor Liz about what’s more important: the tool or the documentation? These connected considerations would affect where the project would go.
One of the past roadblocks was too much focus on technical issues such as website tools, and whether documentation should be specification-based or code-based. So I focused on documentation first. The team was keen to work from a central collection of patterns and components.
Information Architecture and Prototyping
I began to build the information architecture of the design system to review the existing design work — from components and patterns, to color and typography. At this stage, I used Google Docs and Sketch to document the designs and collect feedback.
The project gave me lots of reasons to talk with the designers and ask about every design detail. Why was it designed this way instead of that way? What’s the design rationale? What didn’t turn out as expected?
After completing the low fidelity prototype based from my documentation and supportive materials, it was time to think about the best tool for accessing the design system. Based on the interviews and ongoing conversations across teams, I chose Google Sites. It was:
- Easy to start and edit.
- Easy to update by multiple contributors.
- Simple to navigate.
- Accessible internally and externally.
However, it’s not perfect. I knew that there were:
- No search features.
- No in-page anchoring.
- No detailed version history.
- No grandchildren pages.
- No easy way to comment.
Evaluation
With the first version of the design system shaping up, a quick evaluation was need to see what worked for our users and what didn’t.
I conducted nine user tests with participants including five designers, one developer, one product owner and one design manager. I created three tasks, adapting them for each role.
Task 1 : Browse and explore
Can you spend five minutes exploring the website?
Task 2 : Check out existing patterns
Imagine you are kicking off a new project to design an app/website that involves presenting audio content. Can you find existing design styles, components or patterns?
Task 3 : Update the system with a new design
Imagine you just designed a new button variation for your project. Can you update it in the design system?
User test results
It was difficult to find and use specs when they were flattened as part of the image to annotate styles. Multiple participants used Ctrl+F to search the web page for keywords. The images containing specifications weren’t accessible by these actions. Users also couldn’t copy and paste specs.
More instructions were needed on how to make the best use of this tool. The design system was intended as a reference and a tool to be maintained and updated by everyone. The team needed further instructions on how to do so.
Iterations
As a result of the testing and other stakeholder feedback, I made the following changes:
I added “Related pages” on each page to show similar items and overlap.
I separated text from images to make it accessible.
I added “Getting Started” and “How to Contribute” pages.
After addressing the findings implementing changes, the second version of the design system was good to go.
One thing to emphasize is that the design system was intended to be a living tool to facilitate conversations. It has been a work-in-progress, and iterations could take place any time. Users’ needs may change, workflows may change, so the tool may change. I wouldn’t be surprised to see if it’s totally different after three months.
Takeaways
- Ambiguity and accomplishment go hand-in-hand.
Starting a project from scratch gave me a huge sense of accomplishment as I saw how it evolved “from zero to one.” The process was an ongoing conversation. It was a bit intimidating at the start, but as I moved forward every day and every week, the problem-solving process was a lot of fun.
2. Flexibility comes with critical decision-making.
My mentor gave me profound flexibility to approach the project in my own way. That also meant that I could end up with nothing if I didn’t have a sense of what I was doing, why I was doing it, and who I should talk to. I embraced and enjoyed the flexibility.
3. Good communication is everything.
To stay on track, my mentor and I had semi weekly check-ins. Time was limited, and that forced me to get to the point. Before our 30-minute meeting, I always made a specific list about the things I’d done in the past two weeks, or the questions I needed to clarify to move on with the project.
4. Show options to collect feedback.
When starting the conversation, it was more helpful to show sketches and proposals, rather than asking for people to come up with something from scratch. Throughout the project, I asked for feedback as often as I could to align expectations and make sure I was on the right track.
5. Mutual support makes everyone’s work easier.
The design system would not have taken shape without the help of many people — all those who helped me conduct user testing, who gave me selfless feedback, and who pointed me to some awesome resources. The team was very supportive.
The challenge going forward
At the conclusion of my internship, I felt the design system was a good foundation for the future. It was not yet close to perfect, and would need to evolve to be useful. This brought up the biggest challenge for this project:
If the design system isn’t up-to-date, it loses its purpose and designers wouldn’t use it. How could the design system stay up-to-date with work that designers create every day?
To address this, I hosted a brainstorming session with the design team, posing the question “How might we take the design system forward?” I asked the team to write up stickies, answering:
- What’s the ideal state of what you want for the design system? The opposite?
- How might the system serve you now? In three months? In a year?
The conversation naturally moved on to how and when everyone could contribute to it. The design team agreed that each could update the design system at the conclusion of each two-week sprint, between stakeholder review and sprint-planning. When faced with the challenge of when to actually put the system into practice, one team member said, “Start by starting.”
In the long term, I hope that the design system will be used by more people across departments, by third-party partners, or anyone who’s interested in defining digital products.
Janet Li, who interned with NPR’s Digital Media Design team, works in user experience, product design and human computer interaction. Follow Janet on Twitter.
