Redesigning components for an existing design system

What to do when a component is no longer aligned and causes downstream usability issues

February 4, 2020

8 mins

Read this piece on Medium

As a designer, have you ever come across an outdated component in your design system that was no longer serving the needs of your team? Dusty from the years since its conception, it fails to provide its original value as it has accumulated its fair share of pain points and usability issues?

If this sounds familiar, redesigning the component may be the best thing you can do for yourself and for your design team moving forward. This is a step-by-step guide on how to do just that based on a recent side project I worked on at MongoDB.

Step #1: Audit the component’s current usage across your product’s platform.

In order to best understand the potential value a newly designed component can provide for future projects, identify where it has been in former projects. Explore your current application or platform to best understand what specific contexts it lives in.


Step #2: Identify pain points and poor usability attributes.

Write down all of the different pain points you’ve experienced using this component and all of its areas of improvements. Then, transition into internal interviews with members on your design team who have used this component in their former projects. From this internal research, you’ll be able to learn more about the reasoning behind its usage and confirm existing or discover new pain points across a multitude of different teams within your organization.

For my specific stepper component, below are examples of pain points I collected from speaking with my team.

  1. Limited Step Count
    The component’s width size doesn’t allow for a high number of steps due to its limited parent container size.
  2. Inconsistent Sizing
    Currently, the step indicator component faces challenges that come with its usage, specifically with sizing. As check-marks are added and font weights change as users progress through steps, the bar increases in width, making it difficult to work with a fixed parent container.
  3. Accessibility
    The visual language of steps that have not yet been completed may be hard for users with visual impairments to read.
  4. Inability for Customization
    Currently, the standard is to use a check-mark icon for every stage of the process in the stepper component that has been completed. Allowing flexibility into adding different icons for different steps may aid in visual designs.
  5. Unclear Divide
    The margins and spacing between the different steps seem to be on the narrower end. Increasing this may allow for higher contrast and easier distinction between the stages.

Step #3: Outline key functional aspects of the ideal component.

Analyze the data you’ve collected and write down a list of principles that you’d like the new component to embody. Creating a vision for what improvements can be made will help focus on fixing the weaknesses the current component has.

You can find examples of the ideal principles I wrote for my stepper component below:

  1. Contrast Ratio
    Adopt a minimum contrast standards to align with the W3 (AA), a 4.5:1 contrast ratio. Here’s a helpful tool to check contrast for your elements: https://webaim.org/resources/contrastchecker/. Also, a helpful resource on contrast guidelines: https://www.w3.org/TR/WCAG/#contrast-minimum.
  2. Character/Word Limit
    Each step should contain a specific character or word limit in order to ensure less risk of an inconsistent visual balance in wording.
  3. Account for Long Step Counts
    There should be a way for users to navigate the stepper component, even in scenarios when the step count is large.
  4. Be “Clickable”
    To allow users to easily maneuver between previous steps, it should be clear that steps of the stepper component allows this functionality — making it obvious the step itself can be clicked.
  5. Vertical Version (slated for future work)
    When the user has to complete tasks that may have a large step count and the horizontal real-estate may not be as available, it may be helpful to use a vertical version of the stepper.

Step #4: Audit existing components across current design systems.

Below is a list of existing design systems that I explored during this phase of the project along with their respective links. This can serve as a solid foundation if you’re not familiar with most design systems already.

Step #5: Iterate, prototype, and test.

This is my favorite part — exploring a myriad of options derived from the inspiration of your competitive audit in addition to ideas from your own early sketches. Lay them all out on a collaborative prototype screen so that you’re able to share them with other members of the team to gather comments. From the feedback, nail down 4–5 options that seem to be the strongest directions. You’ll be evaluating the alternatives in external user testing. It may also help to develop early concepts for other states of the component in order to help visualize the designs further.

After selecting the specific designs, focus on your goals for the user research studies by defining the UX principles you’d like to test (i.e. discoverability, comprehension, etc.). To save on time, I performed task analysis on remote, unmoderated users on UserTesting.com. I understand that not all design teams have the budget and resources to use a third-party service; you can also perform internal testing within your company or recruit outside participants to gather this data.

Here are some example questions from my user testing script below to act as a baseline for your own use.

Discoverability
- What are some elements that catch your eye on this page?
- What do you think the user is attempting to accomplish on this screen? How do you know this?
- What do you think you will be doing next? How do you know this?

Comprehension
- What do you think about this element now that you’ve seen it in this page context? What do you think it means?
- Give me a rating on how clear it was on a scale from 1–7 (1 being least clear, 7 being most clear). Why?
- What are some hover interactions you’d expect from this component?
- If you had a magic wand that could change anything about this component, what would you alter (if anything)?

To better organize your test results for analysis, create a table that captures your data in a structured manner. I watched countless UserTesting.com videos and jotted down whether or not a participant passed the task I asked of them (indicated with a checkmark). For questions that were more open-ended, I copied the answers into the matrix.

Step #6: Gather feedback through a “Request for Comments” (RFC).

You’ve done some user testing now, but you should confirm the design decisions you’ve made up to this point with your peers. Your team will be the ones that will be using the component in their projects extensively, and, in turn, users will ultimately be the ones impacted heavily since they’ll be interacting with the component the most. By speaking with colleagues, this gives you additional feedback on the visual and interaction design and also gives others on the design team an opportunity to voice their thoughts on the progress of the project.

*Keep in mind, you do not have to follow all suggestions as long as you can defend your decisions and reasoning.

Step #7: Define guidelines for all possible states.

Make sure your designers are aware of the colors, padding and margin measurements, and interaction behaviors for all the different states of your component. Placing your component in a sample page context also helps envision how it could be used.

Step #8 (Optional): Add animation to amplify the user experience through micro-interactions.

To amplify the design of your component, animation may be a great addition to enhance micro-interaction elements and add polish to the component.

For my specific use case, I’ve linked the prototype I created to show hover animations for my component.

Step #9: Create the Sketch symbol. Ship!

Work with someone from your design systems team to establish the different states that you need to create as a handoff file. Then, hand it off to the team responsible for developing the component that you redesigned. Once the component is fully built, share it with your team and include the guidelines to remind your peers of the appropriate usage behavior. Moving forward, it may help to include the component file in a shared space or add it to your design system library where others can find it quickly.

If your company does not have a dedicated design systems team, this might be a great time for you to brush up on your coding skills to develop the component yourself.

Before and After

It’s always fun to see a side-by-side comparison of old and new designs. Be sure to thank those that’ve helped you with your redesign project and be on the constant lookout for how your design system can be improved!

RETURN  TO THE BLOG