This is How I Built a Design System During My Summer Internship

Ricky Yu
Ricky Yu
Jan 2 · 7 min read

Last summer, I had a UX design internship in an educational technology company located in Washington DC area. It was a wonderful experience for me to learn in a professional working environment.

One of my major projects there was to help the UX team build a design system. In my own definition, design system is a library of UI elements, UX patterns and principles that can be reused across the products of this company. The components in a design system can work in various combination as a UI solution. Google’s Material Design is an example of a design system. For more information about the design system, please click here.

Google’s Material Design

A design system can largely increase the efficiency of the whole UX team. It can reduce the cost and loss from the communication. Meanwhile, if it’s well documented, the design system can also help the designers to brainstorm a brand new idea.

I was very lucky to be assigned to this project. However, it sounded like a big challenge to me as well since I was just an intern who was new to their products. I had no ideas what their UX patterns were. In this article, I would talk about how I overcame the challenge and successfully built the design system at last.

Problems and Users

No matter what I design, I’ll start from identifying the problem space and users. After talking with my co-workers, I found out there were three main problems I should solve:

  1. We have so many different platforms and products. The visual styles of them are completely different.
  2. Not every designer is familiar with every platform or product. Usually, one designer only had experience working with one or two platforms. If they are asked to design for another platform, they probably don’t know about the visual and UX patterns of that platform. They need to ask other designers for help but this would cost time.
  3. Moreover, we have many contractors in this company. They come and go. It always takes a lot of time to teach them the design style. Training for a new full-time employee is the same.

So, our potential user could be a UX designer who has no experience designing for our company’s product. How can I use a design system to help them?

Here comes my design goals:

  1. Efficient. It should make the knowledge of the design styles more sharable across the team. The designers can access them easily.
  2. Consistent in Variety. It should demonstrate the consistency of the design patterns even if the visual styles of each platform are different.
  3. Inspiring. It should give designs inspirations about how to design and help them generate a solution to their problems.
  4. Easy for communication. It should be used as a more efficient tool to inform the developers of the CSS specs.

Now it’s time to design. I first set up several meetings with my team members to talk about their needs and ideas. Then I tried to prototype the structure of the design system in Confluence (we decided to put our design system in Confluence). After I’ve done my first prototype, I presented it to the team and gathered feedback. Then, it went to the second iteration. After multiple iterations, here is the thing I designed.

Atomic Design

What is the best hierarchy to put all of our UI elements into the design system? What kind of hierarchy is the clearest one?

I referred to a well-know design system concept, Atomic Design. Atomic Design divided UI elements into several distinct levels.

Different levels in Atomic Design

I borrowed this idea but we only kept three levels in our system based on our specific needs. Here they are:

  • Basics/Atoms: Individual UI element (Buttons, images, texts…)
  • Components/Molecules: Several atoms that work together and their interaction models (Filters, Search, Tables…)
  • Complex Components/Organism: Layout and structure of several molecules that work together (Reports, Forms, Onboarding Screens)

In Confluence, I made three major folders for Atoms, Molecules and Organism. Then I put the UI element pages as subpages into each major folder.

The page hierarchy based on Atomic Design

A New Level for Visual Style of Different Platforms

Still, the hierarchy above can’t represent multiple platform styles that we have. In order to solve this problem, I added a new level into the design system. Each UI element page has several subpages containing visual styles of different platforms.

So, in each UI element page, we only show the gray-scale wireframes of each UI element. We don’t show visual styles on those pages. If they need detailed visual references, they can go to the subpages of that UI element to find the visual styles of the platform they’re designing.

An example of the hierarchy: Atomic Design Category > UI element > Platform visual style

The benefits of this hierarchy is that we can use a UI element page to promote consistency and a visual style subpage to contain differences.

The visual style page should also contain CSS specs. Designers can link these pages for the communication with the devs.

Not Just A Style Guide

We all believe our design system is NOT just a style guide that only documents visual style, like colors, shadows or typography. It’s much more than that. I tried to include some usability principles and interaction models into our design system.

Though the visual style of different platforms is not the same, we tried to use the same UX patterns to promote consistency. For example, on the button page, we documented different states of the buttons (hover, disabled, primary, secondary…). On the filter page, we even made a prototype to demonstrate the interaction flow.

So, on the UI element page, I mainly documented the following information:

  1. When to use this UI element;
  2. When not to use this UI element;
  3. Anatomy of the UI element (basic layout, different states, interaction models);
  4. Accessibility information.

In order to write contents about when to or not to use this UI element, I even researched online and read multiple articles to fill in the best usability principles for our design system.

I think these information can help designers to make the best decisions. For example, when they are not sure whether they should use a modal or a tooltip in their design, they can go to the pages of these two elements to read the information I put there. Then it serves as an encyclopedia that they can refer to and helps them pick the one that best suits their needs.

For the basic layout and visual structure, this is very necessary for the organism level. I remember when I was making the page for the “teacher report”, I drew a wireframe to show the layout. The teacher report contains a search bar, a filter and a table. I actually didn’t add details into each element but I showed the basic order of each UI element (a search bar at the top, then a filter, with a table at the bottom).

The main idea of doing this is to let designers know what they need in a report. Then we provide links to the elements that they need for each part. They can click those links to visit other pages to know about the details.

The layout wireframe of the report page

Use Case Example

Next, let me give you an example of how to use this design system. Alex is a UX designer who’s going to design a teacher report for K5 online school platform. But he has no experience in designing a report. He needs the help of design system. Here are the steps he’ll encounter:

  1. Find “Report” in “Organism” folder;
  2. Read the anatomy of a report;
  3. Know that he needs a search bar, a filter and a table. Alex’s already been familiar with how to design a search bar and a table but he needs to know filters;
  4. Click the link to the “Filter” page;
  5. Get to the “Filter” UI element page. Then Alex understands the interaction model of filters;
  6. Go to the “K5 Online School” subpage of the “Filter”;
  7. Read the visual styles and CSS specs.

In this way, the interconnected system easily helps Alex find the information he wants.

Maintenance Strategy

A design system can only work with constant maintenance from the team. Due to the time limitation, I couldn’t finish every page in the design system. Some of the pages just had a skeleton without contents. But I used a banner at the top of each page to indicate the current status of this page (under review, under construction, deprecated, in use…). This can help designers identify the correct information.

Meanwhile, our team also agreed that each designer should commit the change in the design system if they use a new UI element, create a new interaction model or a new visual style.

That’s my summer experience of building the design system. I was so overwhelmed at first and didn’t know how to do it. But eventually, I made it with the help of my wonderful co-workers! Shout out loudly to every designer who has helped me during my internship! Thanks so much for this great summer you gave me! Hopefully, this design system can actually help them solve their problems!

Ricky Yu

Written by

Ricky Yu

I write about media, pop culture, and technology

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade