© Sarrah Vesselov and Taurie Davis 2019
Sarrah Vesselov and Taurie DavisBuilding Design Systemshttps://doi.org/10.1007/978-1-4842-4514-9_6

6. Measure and Maintain

Sarrah Vesselov1  and Taurie Davis2
(1)
Dade City, FL, USA
(2)
Portland, OR, USA
 

Design systems require continuous effort. Even as you are writing design guidelines and working with engineering to implement your components, there will be revisions and improvements to be made along the way. Focus on the following key areas as you continue to grow your design system: measuring the effectiveness, understanding how to scale with your organization and product, and learning how to iterate over time.

Measuring Effectiveness

Your design system is only as effective as it is useful. To make sure it is achieving results, you’ll have to make plans to measure your design system’s effectiveness objectively.

Building out a design system is hard work. It can be easy to feel discouraged and wonder if your efforts are paying off. Seeing data that shows its effectiveness will help keep the team’s momentum going. If the data you collect indicates that the system is not making the difference you anticipated, you can take steps to make the necessary course corrections.

Stakeholders will also want reassurance that your system is working. Design systems can increase speed and agility for your team, reduce technical debt, and improve the user experience. Focus your measurement efforts on the items listed in the business case you created in Chapter 3. Gather baseline data before introducing your system and check in at critical points along the way.

When communicating with the executive team and members of management, it can be helpful to frame results in terms of the cost savings and profit. How has your system saved the company time and money? How has it positively affected the user experience in a way that increased customer retention and sales?

Note

To learn more about making the business case for your design system, review Chapter 3.

Gathering Data Through Goal-Setting

Establishing Objective and Key Results (OKRs) for your design system can be a helpful way to track results. Google introduced OKRs as a tool to track alignment and progress toward shared, measurable goals. They consist of an objective, what you want to achieve, and key results, the set of outcomes that signal you have met your goal.1 Here are a few OKR examples to illustrate how this can work in tracking your system’s effectiveness:
  • Objective: Reduce UX cycle time to increase speed to market.
    • Key Result: Define the road map for getting all “priority one” user experience components into the system (these could be core elements, such as typography, color, etc., or high-priority product features).

    • Key Result: Publish eight finalized guidelines to the system each month.

    • Key Result: Reduce UX review time spent on code changes by 50%.

  • Objective: Accessibility is built into everything we do.
    • Key Result: 100% of new components ship with accessibility standards checklist met.

    • Key Result: By the end of three months, all existing components will be updated to meet accessibility standards.

  • Objective: The design system is an organization-wide resource.
    • Key Result: Increase membership of non-design team members in the design system team chat2 channel by ten members each month.

    • Key Result: Increase design system contributions by five non-design team members each month.

Whether your organization uses OKRs or some other way to measure goals, use them to your advantage. There are many ways to measure and demonstrate how useful your design system is for your organization and your user base. Focus on creating measurable goals that allow you to track results related to your business case. This can include:
  • Maximized adoption within a certain time period.

  • Commitment to adopt.

  • Reduced development times and increased time to market.

  • Reduced technical debt and bugs.

  • Improved user experience.

  • Increased collaboration among teams.

Gathering Data Through Surveys

Surveys are another way to measure how useful your design system is for your organization, especially if you don’t have access to analytics or usage data. Create a survey to send to your fellow colleagues that helps you understand the state of your system, what you may need to change, and what can be added to make your system more effective and efficient.

When creating your survey, be sure to include questions that will capture how much time is being spent on team members inquiring about styling or usage guidelines. Over time, these guidelines will be captured within your system, allowing everyone to be more autonomous. You can also ask UX designers how much time they are spending answering style or usage questions vs. brainstorming solutions to problems.

Send the survey when you first start the process of creating your design system, as well as after you have made significant progress. By sending out the survey in regular intervals, you can measure how effective your system is compared to the previously sent survey. Overall, you will see that there is less time spent on discussions that revolve around styling and usage as your design system becomes easier to navigate, with robust and up-to-date guidelines. With this information, you can keep the momentum going and continue to gain buy-in from key stakeholders.

Survey Template

Below is a sample survey to utilize within your team. Customize the questions and answers to better suit your individual organization.

Team Member Survey

Which team are you a member of?
  • Front-end

  • Back-end

  • Product

  • Marketing

  • Support

  • Sales

  • Other

How often do you ask a UX designer or front-end engineer for help regarding the styling of a component?
  • 0–1 time a cycle

  • 2–4 times a cycle

  • 5–7 times a cycle

  • 8+ times a cycle

How often do you ask a UX designer or front-end engineer for help regarding the usage of a component?
  • 0–1 time a cycle

  • 2–4 times a cycle

  • 5–7 times a cycle

  • 8+ times a cycle

On average, how long does it take to get the assistance you need regarding the usage or styling of a component?
  • I don’t have to ask for help with usage or style guidelines.

  • Under an hour

  • 1–3 hours

  • 4–8 hours

  • 1 day

  • 2+ days

How often are you able to work on a UI bug or improvement without UX assistance or review?
  • Frequently (most problems)

  • Sometimes (some problems)

  • Rarely (once in a while)

  • Never

  • Other [text field]

How often do you visit the design system to answer a question regarding a component?
  • Frequently (most questions)

  • Sometimes (some questions)

  • Rarely (very few questions)

  • Never

  • Other [text field]

If you do not utilize the design system as a resource, tell us why.
  • It doesn’t have what I’m looking for.

  • Guidelines are out of date.

  • It’s difficult to navigate.

  • I didn’t know there was a design system.

  • Other [text field]

On average, are you able to find the information you are looking for within the design system?
  • Yes

  • No

What can we add to the design system that would help improve your process?
  • [Open-ended question]

It can also be useful to create a similar survey that is directed toward members of your design team. This will give you specific feedback regarding their time spent, as well as their perception of the usefulness of the design system. Remember to take one of the surveys yourself as well!

UX Member Survey

How often are you asked to help clarify the styling of a component?
  • 0–3 times a cycle

  • 4–6 times a cycle

  • 7–9 times a cycle

  • 10+ times a cycle

How often are you asked to help clarify the usage of a component?
  • 0–3 times a cycle

  • 4–6 times a cycle

  • 7–9 times a cycle

  • 10+ times a cycle

How much time do you spend responding to questions regarding the styling or usage of a component?
  • Less than 25% per week

  • 26–50% per week

  • 51–75% per week

  • 76%+ per week

How much time do you spend responding to questions or doing reviews for new features?
  • Less than 25% per week

  • 26–50% per week

  • 51–75% per week

  • 76%+ per week

How much time do you spend writing documentation?
  • Less than 25% per week

  • 26–50% per week

  • 51–75% per week

  • 76%+ per week

How much time do you spend brainstorming and creating solutions to new problems?
  • Less than 25% per week

  • 26–50% per week

  • 51–75% per week

  • 76%+ per week

How often do you reference the design system when working on design related tasks?
  • Frequently (most problems)

  • Sometimes (some problems)

  • Rarely (very few problems)

  • Never

  • Other [text field]

How often do you reference the design system when answering a user-experience related question?
  • Frequently (most questions)

  • Sometimes (some questions)

  • Rarely (very few questions)

  • Never

  • Other [text field]

Overall, how useful is the current design system to you in your work?
  • Very useful

  • Somewhat useful

  • Not very useful

  • Not useful at all

What makes the design system useful or not useful to you?
  • [Open ended question]

Measuring the effectiveness of your design system will be crucial to its success. Frame the context of your data in terms of who you are communicating with. Design and development managers will care about how the design system helps their teams function internally while an executive will care about time and money. Tell an effective story and be able to defend your business case, enabling you to continue on the path of building an effective design system.

Maintaining Your System in the Face of Growth

As you work on your design system, it is inevitable that your organization and product will experience change. This change comes in many forms: growth, reorganization, new product focus—the list goes on and on. Continuous, and sometimes rapid, growth presents both opportunity and risk for your design system.

Opportunities

  • The ability to work on initiatives for which you previously lacked resources.

  • The capacity to create a team dedicated to the design system.

  • Enriched user experiences (depth).

  • The opportunity to add additional features the product is lacking (breadth).

Risks

  • Loss of culture and morale as too many people are added too fast.

  • Increased UX debt as new team members fail to understand or use the design system. UX debt could also increase if UX hiring lags behind engineering or product.

  • The inability to sufficiently support the design system due to time spent onboarding new team members.

There are many outside influences and factors that can affect the growth and progress of your design system. Don’t allow yourself to get bogged down by what could happen. Learn to recognize the opportunities and risks and use them to your advantage.

Organizational Growth

Organizations are not static; they grow and change over time. When an organization enters a high-growth phase, it is both exciting and stressful. Organizations hire more employees when there is the opportunity to grow the product and its footprint within the market. This is a good sign that the organization is healthy and headed in the right direction. It also means onboarding new employees, adding additional managers, and making sure processes support the growth and change. To maintain and continue to grow your design system, you will have to make sure every new member becomes familiar with it.

Onboard new designers properly. Ensure that every new designer on the team gets proper instruction on how to use and contribute to your system.

Utilize organizational announcements to educate other departments. It isn’t enough to have a design system. You will have to share, socialize, and evangelize it continually. Reach out to new product managers and developers. Conduct AMAs (Ask Me Anythings) or webinars for internal employees.

Product Growth

Products are not static, either. As the product matures, features are added and taken away. The visual design and user experience of the product undergo constant iteration as user feedback comes in and new designers add new insights. A side effect of these changes is UX debt. UX debt refers to the inconsistencies that accumulate and have a negative impact on user experience. These can include differences between styles you have documented and those found in the product, as well as misuse of components across features.

Tackling UX Debt

UX debt creeps in when the solutions and standards in your design system have not yet been implemented into the product. These lingering discrepancies can feel particularly painful to your team. Just like developing your design system, addressing UX debt will be a continuous process.

Accounting for UX debt is important to maintaining and growing your system. Discrepancies can lead to confusion and require more communication between engineering and design to ensure that things are being implemented correctly. Without a reliable single source of truth, the speed and efficiency of the engineers and designers working on the product will be greatly affected.

Incremental implementation. It is tempting to try and fix existing problems all at once. This can lead to long, drawn-out debates and little to no progress. You may need to implement newly defined styles one feature at a time. Create a road map for these changes and communicate it across the organization.

Consistency. Give your designers ownership of the system and hold them accountable. Try and schedule a certain number of improvements for each sprint. These could be UX debt issues already in the product or corrections and additions to the design system itself.

Collaboration. Work alongside product management and engineering to tackle existing UX issues. This isn’t just a problem for the design team, this is an organizational problem. Understand what is most important to product management and use that knowledge when prioritizing. Talk to engineers to understand which fixes are more difficult or complicated than others.

Tackling UX debt will ensure that your product can continue to scale alongside your design system .

Design System Growth

Growing pains can cause daunting challenges, but there are strategies you can use to mitigate risks and take advantage of opportunities. You should think of your system as another team member. It can take on duties and responsibilities, freeing you up to tackle more complicated tasks. The competencies and skills of your design system should grow alongside those of the organization.

Ensure a centralized location for your design system. Make sure that everyone has access. It should pull its weight for the team, answering known questions and allowing other teams the autonomy to work independently.

Stay focused on developing your system. Don’t allow delivery pressures and tight timelines to distract you from keeping up with your design system. Your system is an organizational priority. Advocate for it when scheduling and prioritizing work. Make the space for your team to add to and improve its contents continually.

Set up processes and a system of checks and balances. This means a self-documenting design system with designated maintainers tasked with checking the work that is added. Have documentation steps for adding to the system as well as reviewing additions.

Stop trying to make it perfect. Iteration will be vital to keeping your system going. Long, drawn-out conversations about every detail in your system will stop progress and exhaust the team. Get something in and continue to improve it over time.

Iterating on Components and Guidelines

As your organization grows or client needs shift, there will be times when you must iterate on the components and guidelines you have already created. A usage guideline may no longer be useful or a component may have to change entirely to match the needs of your changing product. Don’t paint yourself into a corner; keep an open mind and allow your design system to evolve to fit the ever-changing needs of your users.

Making Room for Revisions

Learning to iterate can be a challenge. It is likely that you won’t be completely happy with the first iteration of your design system. As you continue to iterate, adding more guidelines often means adding more complexity. Be open to allowing your system to shift over time.

As your product grows and user needs change, so might your guidelines. It is okay to throw out components and begin anew. Remember that your design system is supposed to provide guidance for your team. If a certain guideline is not working within your product anymore, it’s time to change or remove it.

Utilizing Research

Research is a powerful tool that will help you to build robust components that function well for your users. Whether you have a team of UX researchers or you’re working on your own, you can create small studies that help you test different variations of the same component. Below are a few research techniques that can help you iterate and revise your components to best match your users’ needs:

A/B Testing

Performing A/B tests allows you to compare two versions of a component and measure how effective each one is. There are many tools out there to help you easily perform A/B tests, but you can also keep it simple by creating your own prototypes and testing with users one-on-one. This is a powerful tool that helps you determine the most effective iteration of a component.

Usability Testing

If you are unsure whether a certain component will solve a user need, utilize usability testing to get the answers. Start by creating a hypothesis and a list of assumptions. Be clear about what you are hoping to accomplish with your study. Then create a script that you can use when talking with users that addresses your hypothesis and helps answer your assumptions. Be willing to make changes based on the findings within your study.

Beta Groups

When creating a new feature or feature set, you are likely to introduce components into a new flow. Create a beta group to test the new flow before introducing it to the majority of your users. This will also give you useful information regarding whether you need to make any adjustments to your guidelines.

Communicating Changes

A key aspect of revising your design system is ensuring you have a process in place for communicating changes. UX designers should be up to date with the state of your system, as should your engineering team. Keeping your organization in the dark about the changes you make will only lead to inconsistencies and incorrectly implemented components.

When you make a change to a usage guideline, announce the change in your next upcoming team meeting. Remember that when a usage guideline is changed, it may mean updating the implementation of that component. Check in with your engineering team to ensure that the change can be implemented in a timely manner. If there is no capacity to make the change, be sure to document the issue in your issue tracker. This will ensure that the change will be made when scheduling allows. For larger changes that may affect the whole of the organization, be sure to have a channel in place that allows you to communicate the changes to all parties. This will vary between organizations but could be a chat channel, a company call, or a team bulletin.

Tying It All Together

Your design system cannot be completed and then simply set aside. It will require continuous effort and constant attention to thrive. Treat your design system as you would a product. Set goals for what you would like your system to achieve within a specific time frame and track the results. Doing so will allow you to make corrections when necessary and bolster morale for the team as the benefits become clear.

Measuring and tracking results is vital for your stakeholders as well. Provide data that shows the effectiveness of your system and how it is benefiting customer growth and retention. Make clear the value your system has for the organization, and you are more likely to continue receiving support in the form of time and resources.

Maintaining your system as your organization and product grow can be daunting. Create processes to address the addition of team members across the organization and have a plan to tackle UX debt that accumulates.

Account for the need to scale your system in parallel with your product and organization. Start by placing your system in a centralized location and make it available to everyone. Encourage all teams to contribute but reinforce checks and balances. Be open to iteration and create a process for communicating changes over time. Socialize and evangelize your system within the organization to maintain excitement and keep the momentum going.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.135.200.211