Riding the Magic Escalator of Acquired Knowledge

Thank you to Marco Dini for the Italian translation to this article.

Robin had done this dozens of times before. In the past, it took about 5 minutes to order the money wire transfer, but it always involved calling someone at the bank to make it happen. Thinking it would make her life easier, the bank set her up with her own web form interface.

However, now her life wasn’t easier. Robin was staring at a form with three groups of fields: Receiving Bank, Intermediary Bank, and Beneficiary Bank. She knew she had to plug the bank and account info into one of these groups, but which one? Nothing on the screen told her what to do and she had no idea.

Initially, Robin told me she was feeling a little dumb. After all, she’d made money transfers before. How hard could it be?

After a few minutes of trying to figure it out, Robin started to get angry: How was she supposed to figure this out without any clear instructions? How could anyone do this?

She called a friend at the bank—the person who had executed the transfers for her before. He gave her the secret: she was to put her own bank info into the Receiving Bank group and use the Beneficiary Bank group for the person she was wiring the money to. As for the Intermediary Bank? “Oh, we don’t use that. We’ve tried to get them to take it off the form, but they won’t.”

Introducing the Magic Escalator of Acquired Knowledge

Robin’s experience is familiar to anyone who has experienced complex software they didn’t understand. Interestingly, we can also explain it with an interesting device we call the Magic Escalator of Acquired Knowledge.

The Magic Escalator of Acquired Knowledge represents all the knowledge the user can have about the design. When they are at the bottom, they know very little about the design, and when they are at the top, they know everything there is to know about it.

Current Knowledge

While it sort of breaks the metaphor of an escalator, it’s helpful to think of two points of interest. The first point is what we call current knowledge, and that’s the point where the user actually gets on the escalator. It represents everything the user knows about the design, before they start using the design.

Robin knew quite a bit about wiring money. She knew that to wire the money, she had to provide the recipient’s bank’s identification number, name, and account number.

That was her current knowledge, which is more than someone who has never needed to wire money before. Robin had acquired that knowledge long before she ever used the bank’s online application.

Target Knowledge

Target knowledge is the other point we care about on the Magic Escalator of Acquired Knowledge. That’s where the user needs to get to so they can accomplish their goal.

Robin didn’t understand why there were three groups of fields and what they meant. She had to learn this to wire the money.

Her friend at the bank knew about those field groups. His current knowledge was much closer to the wiring task’s target knowledge than Robin’s.

Bridging the Gap Between Current and Target Knowledge

Bridging the gap between current knowledge and target knowledge is where designers bring out their talents. There are two ways to make this work.

The design can move the user’s current knowledge closer to the target knowledge. This is training the user on what they need to know to complete their task.

Or the designers can reduce the knowledge necessary, moving target knowledge down closer to current knowledge. This is simplifying the design.

The question for the designer becomes a straight forward one: do you train your user or do you reduce the need to learn something?

The bank system folks could add a tutorial or other types of user assistance to help the user learn what the various field groups are for. Robin could use these to learn how to interact with each field group correctly. That would move her current knowledge up.

Alternatively, the designers could simplify the design. They could choose language closer to what Robin was used to. They could break the process into simple steps that match the knowledge Robin already has, such as moving money between accounts or to other financial institutions she’s already familiar with, like Paypal.

Designing for More Than One User

It’s easy to design for a single person. (This is why self design is so tempting, since you only need to design for yourself.) However, most of us desire more than a single user of our designs and that’s where things start to get complicated.

Each user has a different current knowledge point (which, as they use the design and experience other interfaces, moves on its own). Each of the users’ objectives have their own target knowledge points. How do we design for everyone?

This is one of the unsung benefits of personas and scenarios. You can tell when a persona project is well done because the team has embodied their users’ current knowledge in each of the personas. As the team designs for their chosen scenarios, they can identify what the likely target knowledge will be.

The Magic Escalator as a Communication Tool

Mapping what we know about our users and their tasks on to the Magic Escalator of Acquired Knowledge can help us predict where those users are likely to encounter complexity issues. Looking at the top tasks and listing out what we think users know and don’t know can help us develop a strategy for creating simpler interfaces.

We’ve found the escalator is a great way to explain to our colleagues and stakeholders why our users are having trouble with our designs. It’s easy to explain and they get the concept right away. It’s nice to have a visualization tool that makes something as complex as complexity into something simple to explain.