From “user education” to “product education”

There’s a term used in the product development world that has started to make me cringe, even though I know I’ve used it before. It’s unavoidable if you work on any experience that even remotely touches user onboarding. But it can have a negative impact on human-centered product design. The offending term? “User education.” 

Used too often, the term “user education” can grow into the user education mindset, where a team views it as entirely the user’s responsibility to adapt to a product, and a design strategy is built around that. “Let’s just solve this with user education” can be as problematic as writing off things we didn’t expect or plan to happen as “user error,” rather than viewing these as opportunities for improvement. This mindset doesn’t inspire teams to build better products, it just inspires them to shift responsibility and dump instructional content onto users to figure out. 

What can inspire us to provide better products? The “product education” mindset. More on that in a moment.

The issue with the “user education” mindset

In clinical terms, osmosis is “the movement of molecules from a region of higher concentration to lower concentration until the concentrations become equal on either side of the membrane” — molecules automatically moving across a barrier until both sides have reached equilibrium. 

Some teams assume that information about a product is also something that can be osmosed: if we simply provide information to our users, it will automatically flow over and take up residence in their brains. So when a team talks about providing “user education,” they’re usually talking about pushing pure information. Maybe it’s a hint, tooltip, or overlay with instructions explaining what a button does, a list of new features, or describing how to use a feature. Maybe it’s an FAQ or a terms of service document. The assumption is, by showing it, people will read it, and then everything is copacetic.

But this user education mindset sets the wrong expectations about how to introduce people to new things, and distracts us from real opportunities to improve our product. Here are a few reasons why this mindset is unhelpful:

  1. Serving information does not equate to helping people learn and gain knowledge. You only have to look at the scholastic field to know that. Any study done on how students learn in the classroom will show that rote memorization of information doesn’t ensure long-term retention or application of it. Knowledge is what you’re after because that’s the understanding of how to apply concepts to real-world use. Information is data that can be used to help build or refine someone’s knowledge, but knowledge often comes about from practical application and reinforced practical application over time. 
  1. “User education” is too often an attempt to patch opportunities to improve our core product design. Are our users not using things the way or in the timeframe we expected? Instead of coming to terms with the fact that our expectations may have been wrong, we try to cover it up with some form of information display instead of addressing the underlying issue. A classic example is icons without labels. A team may use tooltips explaining what navigation icons do because they see people aren’t using them, when in reality it would be better if they simply added labels to those navigation icons in the first place.
  2. The user education mindset presumes that we are omniscient, yet we can’t predict how our products will behave in all circumstances. Even if some people would sit down and study product information (read about the active user paradox, however, to understand why this isn’t likely), our products and services are getting more complex, precisely because we’re always trying to scale for more users, making it hard to predict all outcomes. You can even see this issue in the context of a user education pattern itself, overlays. There are many cases where informational overlays end up overlapping each other because their creators didn’t predict that each of them could be triggered at the same time.  
  1. The user education mindset can encourage us to push our own goals on the user instead of focusing on theirs. A 2012 patent application includes a great illustration of this concept. It shows how an interactive television commercial could teach the viewer to speak the name of the commercial’s brand to return to the TV show it had interrupted. It’s using “user education” to teach someone how to get out of a commercial they likely didn’t want to be in in the first place by saying the name of the brand.
Diagram from patent application
This patent illustration shows a person is shown having to say “McDonald’s” in order to exit a commercial

Over reliance on the user education mindset pulls us away from the roots of UX in human-computer interaction best practices, where the goal has been to make systems that meet users where they are, rather than forcing users to meet the technology where it is. Shifting back to the “product education” mindset could help us.

The “product education” mindset

“Since computers are so smart, wouldn’t it make sense to teach computers about people, instead of teaching people about computers?” So was written in Apple’s 1984 magazine ad.

30-odd years later, how well are we doing on that front? 

So often in onboarding design, we fall into a trap of assuming our product is this fixed thing that we must make users adapt to. But people come to our products with different motivations, with different goals, and with different ways in which they will integrate a product into their lives. We need to be flexible; our products must adapt to the user at least as much as, if not more than, we’re asking the user to adapt to them.

Ako is a Maori word that describes a reciprocal learning relationship between teacher and student, and is a principle applied to some areas of the New Zealand educational system. This reciprocal learning relationship is one in which the teacher is not an expert who transfers knowledge to a student, but instead the learning of the student is shaped by their interactions with the teacher, and the teacher shapes their activities in response.

Reciprocal learning is also an apt way to think about product design. The “product education” mindset is, in contrast to the user education mindset, about believing that it’s our products (and, by extension, our teams) that need to learn from the user in order to provide an experience that is easily understandable and adapted to. This mindset embraces 2 broad strategies: (1) using research and design practices to build a clearer core product; and (2) employing personalization and/or customization to give each individual the chance to shape it.

Product education through research and design

Designer Morten Just wrote about how the most basic form of “telepathy” in products starts from good interaction design, saying:  “Even today, an app designer can improve their app with telepathy in two ways. First, outbound telepathy is figuring out what the user wants. Then, inbound telepathy is about shipping that information to the user’s head. Any decision a designer makes will either take the product closer to telepathy, or move away from telepathy.” 

The product education mindset starts with good human-centered design and research practices to create more understandable products at the outset. Through research, we can reveal the expectations and mental models our potential new users hold, then through design we can find the right metaphors to use. The book User Friendly by Cliff Kuang and Robert Fabricant has a great quote about metaphors: “In digesting new technologies, we climb a ladder of metaphors, and each rung helps us step up to the next” (page 147). An example from the book is from self-driving cars, where the old metaphor of the steering wheel was adapted to help people understand when and how to take manual control, and when the car was in autopilot. The old analog steering wheel metaphor helped build trust in and understanding of the system. 

With the product education mindset, we also embrace the fact that we may not find all the perfect metaphors, and that people will go through some process of trial and error to build their mental model of our products. This kind of friction is the good kind of friction. We just have to design products that reinforce this, which means giving good feedback and support as users plod along. This can be anything from clear empty state designs, informative error messages, confirmations of success, or clear transitions between states. Information is not so much pushed in these instances, as much as given in service of responding to what people are doing. 

The ultimate research and design method in the toolkit of “product education” may be co-design, or collaborative design. It’s when teams build products side-by-side across the life cycle of development with the people who represent a range of users. It is especially helpful in the design of complex services and systems. Correct use of co-design has the potential to generate solutions that work for a wider range of people and make the product anticipate people’s needs.

Product education through personalization and customization

The other strategy used by teams with a product education mindset is considering how the product can learn about the needs of each individual user as they arrive and adapt to them 1:1. Personalization and customization are two ways to look at this. 

Personalization is when a product learns about the user implicitly, based on their behavior or information using either pre-programmed inferences or machine learning models. For example, a new user arriving on Tripadvisor finds an inviting, simple home screen with a generalized list of categories and a search field inviting someone to look for locations they want to travel to. Over time, the home page interface adjusts to show more specific links to content from that user’s searches, and starts to prompt them to start building a trip. 

The home page of Tripadvisor’s website gradually adjusts its content to reflect the user’s activities. Left shows the default view, and right shows the view after someone searches for content. 

Meanwhile, customization is when the user explicitly teaches the product by making choices. Users can customize the interface of their mobile phones, for example, by selecting color themes or arranging the apps on their home screen. People can calibrate an audio assistant to recognize their voice. Or users can make more predictive choices, such as telling a product what music genres they like listening to so that a product can then serve up suggested tracks that match those selections. 

These are very simplistic takes on personalization and customization, but these are strategies that can be used in addition to starting out with a user-centered approach, to build smarter experiences that learn about and reflect the needs of our users.  

Users may still need to learn

The product education mindset isn’t saying that a user doesn’t have to learn anything. They’re learning the entire time they’re using your product! That’s why it’s important to make sure your product offers good feedback and outlets for giving them information in the context of use and on demand. And sometimes, user-facing education may be warranted to inform one user about their potential impact on the larger ecosystem of people that may be influenced by a product. 

In today’s highly connected world of products and services, such “teaching moments” can help people understand how their use of a product influences the lives of others. For example, Twitter recently introduced a notice for the first time people retweet an article before they’ve clicked the link. It suggests that people may want to read the whole article first before sharing, in an attempt to reduce the sharing of fake news. 

Two screenshots side-by-side of how Twitter showed messaging when people attempt to retweet articles before reading them.
Twitter showed an educational suggestion for someone to read an article before retweeting it. Left image shows the initial, detailed view of the message; right image shows a condensed version.

During the COVID pandemic, a number of ridesharing and public transit apps inserted reminders at the point of looking up travel options, to remind people of their responsibility to travel only for essential purposes to reduce the spread of the illness. And in a more well-known example, psychologist Jennifer Eberhardt worked with Nextdoor to address issues with racial profiling by inserting a checkpoint into their neighborhood reporting flow to prevent users from submitting a report if race was the only identifier and making them reflect on that point. 

These may be acceptable forms of user-facing education, because they serve a purpose that goes beyond our team’s own desires to shortcut core product design issues and is instead about helping other users. But these sorts of teaching moments still have to be rigorously evaluated to ensure that they’re truly necessary and helpful.

From user education to product education

When a product team adapts a product education mindset, they view it primarily as their responsibility to learn about and teach their product about users, whether it’s with better in-product feedback, best-practice research, personalization, and/or customization. Having the product education mindset is healthier than the user education mindset for several reasons:

  • It helps us view our users with empathy. Instead of blaming them for not reading the darn manual or putting a lot of work on them to fill in the gaps, we can thank them for teaching us about something we hadn’t anticipated.  
  • It puts less pressure on us to be expected to be omniscient. We can’t predict up front how everyone will use our product, so we can’t expect to “educate” users about that, either. And that prepares us for the less predictable world of automation, where we’re unlikely going to be able to predict every branch of an experience someone may get. 
  • We stop wasting our team’s time on unhelpful solutions, like explanatory overlays, website FAQs, and similar patterns that attempt to explain away the gaps in our products. This gives us more room to focus on building in-product feedback as well as designing any type of user-facing education that’s more in service of helping them understand their impact on their human peers.

So, why don’t teams embrace the product education mindset as much as they embrace the user education mindset? Primarily, because of time. Or, perhaps more accurately, patience.

Relatively speaking, it’s quick and easy to whip up a piece of user education to explain away the nuances of our product or to talk about features we think new users need to learn about. Anyone can create information, especially the kind of information that’s us narrating how we expect something to be used.  

It takes more time to learn our users’ different needs, expectations, and mental models, and then design a product around them. And neither personalization nor customization today are silver-bullet strategies for quick-and-easy implementation either: as Jeffrey MacIntyre states in his extensive article about Progressive Personalization, “what personalization needs […] to be successful is clear, rigorous, thoughtful design.” Meanwhile, customization requires the user to recognize that they need to do work, and then be motivated to do it, and too often people will stick with defaults rather than change them. So we’d still need to do the work to create a product with a good starting point design. 

Thus, yes, adopting the product education mindset means we have to do more work than we would if we just created a user education patch for each of our product’s issues. But this is the hard design work we should be doing anyways. Nothing I’ve shared in this article is a new design strategy. We keep trying to find ways to reduce our responsibility to teach computers about our users, but we can’t escape it. And I worry about what will happen if we don’t give up our user education mindset for the product education mindset as we move into the world of brain-computer interfaces. Ideally, such neural interfaces could enable true adaptive user interfaces (AUIs), where the interface between content, a service, and a system could morph into what’s most natural for each user. But if we bring our user education mindset into that world, we could see neural interfaces used just to push more narrated, homogenous forms of information. We have the opportunity to do so much more (as pointed out in this post), but we need the right mindset first. 

My hope with this article is that it will inspire you to find opportunities to shift out of the user education mindset and into the product education mindset. Any time you or your team discuss pieces of “user-education,” you have an opportunity to do this: take that moment to deconstruct the assumptions that everyone has behind what user education means to them, and why they believe it’s necessary. Evaluating every piece of user education gives you an opportunity to revisit past product decisions and decide where you have more opportunities to teach yourselves and your products about your users.