ARTICLE: Chris Albert

Design systems can make or break your EdTech product’s UX. Here’s how to do it right.

You already know that design systems are critical when it comes to creating consistent user interfaces. In fact, you may already have invested in a design system for your EdTech product. You’ve seen some benefits, sure. But you’ve also found that it’s opened up a whole new Pandora’s box of sticky design questions. Rather than arming your team with the information necessary to make confident decisions, they are frequently bogged down with uncertainty and indecision. It seems like every new use case results in a debate over which version of a component should be used or whether new variants should be created. 

Sound familiar? Don’t worry, you’re not alone. The thing is, design systems are often heralded as a failsafe solution to all the most common design consistency woes, including design debt. But too often, design systems miss the forest for the trees. They get so bogged down in the details of various UI elements that they totally neglect to address fundamental UX considerations. The result? Confusion on the part of designers and a slowly deteriorating user experience. 

So why is it that so many design systems fail to adequately address UX concerns? And how can you be sure to create a system that actually gives your UX teams the tools and confidence to make your EdTech product better? We have answers. 

How Design Systems Unintentionally Undermine Product UX

Simply compiling all of your EdTech product’s many visual components and design patterns is quite the undertaking. But if you stop there, your design system will almost certainly fail to support your UX efforts down the road. 

The missing link? Documentation. Your design system should provide your UX designers with practical guidance on how to select, use, and combine components confidently and consistently. 

Without proper documentation, designers will find themselves sorting through an assemblage of parts and pieces without a sense of the rules governing their actual use. And usage is where the rubber meets the road when it comes to UX outcomes. It’s what enables designers to create internally consistent experiences within a product. 

Design systems without comprehensive usage guidelines leave designers to fend for themselves when it comes to picking the correct components for a particular job. There is often a gray area in which a design system’s UI-based guidelines are either too rigid (“Whichever solution I choose, I’m breaking a rule”) or too vague (“Can I combine these two components in this way?”). 

For example, let’s say your design system includes four or five versions of drop-down menus that are used in various contexts throughout your product. Some include icons, others don’t. A few feature different states depending on a user’s interaction with them. Your design system gave all the specs for these items, but it doesn’t explain when to use each of the different variations. 

It all comes down to design intent. You probably had a solid UX justification for creating each of the different versions of the drop-down menu. But without the necessary documentation, individual designers can’t be sure which selection would yield the most consistent user experience. In this instance, your product’s UI isn’t in danger of being undermined, but the UX is. 

This lack of documentation gets even hairier when designers attempt to address a new use case for which none of the existing components quite fits. In this case, they must choose to either modify an existing component or build a new one. But without a firm understanding of the design intent behind the components that have already been created, designers can only guess at the right course forward. 

Building a Better Design System to Support Your EdTech Product’s UX Needs

Want to build a design system that facilitates thoughtful UX solutions instead of triggering new UX brainteasers? Start with these tips. 

Develop Guiding Design Principles 

Guiding design principles establish and reflect your EdTech product’s core design values. Together, they communicate the underlying design intent behind each element in your product’s design system. These principles likely won’t be directly actionable, but they will give your team a high-level understanding of how the design system should be used. 

Every brand and associated design system will have a unique set of guiding design principles. For example, Salesforce’s design principles are clarity, efficiency, consistency, and beauty. Google Material Design’s principles, on the other hand, include words like “bold,” “graphic,” and “intentional.” 

Identify your own brand’s guiding design principles and make sure your team understands what they represent and how they impact your approach to design. Then, be sure to include your principles in your design system, too. 

Document Usage Guidelines

Your usage guidelines should provide actionable guidance on how existing components, new components, and larger UX organisms should be used — and how they interact with each other, too. 

What are some good ways to use a particular component, and which use cases are off the table? Which elements can be combined, and under what circumstances? Can elements be modified? If so, how? And if not, why? Your usage guidelines are how your designers will connect your UI components to your UX goals. 

Of course, you won’t be able to anticipate every use case. But if your documentation is thoughtful enough, it should give designers the information they need to extend beyond the current boundaries of your product in a way that remains fundamentally true to your product.

Build Out UX Patterns and Service Design Patterns

UX patterns and service design patterns, both of which are frequently misunderstood, have an important role to play in design systems that is too often overlooked. 

UX patterns (also called UX design patterns) are patterns that document a component’s attributes when stripped of their styling. Because UX patterns abstract components from the UI, they help designers think about the application of the design system from a UX perspective. As such, they enable designers to apply your core UX principles to your design system in a directly actionable way. 

Service design patterns, meanwhile, are patterns that document the building blocks of a service or complex task within your system. For example, a service design pattern might show the steps and components needed to apply for a course, authenticate an account, or pay for an e-book. These patterns are an order of magnitude further removed from UI. Like UX patterns, they play an important role in UX decision-making by allowing designers to create patterns keyed directly to the building blocks of a service. 

Service design patterns are much more challenging to create than UX patterns, so they should be used sparingly as part of a design system. However, for an EdTech company, connecting the design system to a few critical service design patterns can ensure consistency and resilience across products over time. 

Design systems without strategic documentation do little more than serve up ready-made components in a vacuum. In order for your design system to actually serve your product’s best interests, it must arm your team with the core principles and actionable guidelines necessary to make informed and strategic decisions. Do that, and your design system will become an indispensable tool for producing the best possible user experiences every time.

  • Photo of Chris Albert
    Chris Albert

    As a UX Design Lead at Openfield, Chris is a deep thinker with a savant-like ability to untangle and simplify complex systems. Now in his 8th year with Openfield, the wisdom of his 20+ year career in design and his tireless devotion to his work and clients inspires everyone at Openfield. Out of the office, you’ll find him doing the same thing he does at work – ever advancing one of his many crafts and interests. He’s a letterpressing photographing traveling gaming car guy. Chris is our Renaissance man.

Spread the word – help avoid the traps of digital product development!