Designing the Obvious: A Common Sense Approach to Web Application Design

Later on, we ran into a problem with how users navigated our courses.

Typically, the Next button in an eLearning application advances a user to the next screen in the course, a screen the user has not yet seen. But we had added history to our application. Instead of forcing a user to start a section over again each time he wanted to go back to a particular screen, we tracked the pages he went to so that the Back button enabled him to traverse through the pages he had already seen, one by one, just like a browser.

A typical Next and Back button setup for an eLearning course.

The problem was that when a user began using the Back button to return to pages she'd already visited, the Next button did exactly what you'd think it would doit advanced her through the same set of screens.

She eventually reached a point where the Next button advanced her past the last screen she'd already visited and began showing screens she had not visited. This is, after all, the purpose of the Next button.

So, we suddenly had a Next button with two purposes. This broke the single most basic rule about how users navigate courseware. And it was confusing users to no end.

Users needed to know when they stopped seeing visited screens and started seeing new ones, but the application did not indicate this in any way.

At the time this issue was being discovered, I was head down, fingers flying, writing code. Other people in the company, however, were meeting about the problem. Over the course of about a week, several people met several times to discuss ways to remedy the situation.

How could we make it clear to users that they had stopped going forward through the course history and had started seeing new screens? Should we show them some sort of message? That would affect the design for every course. Should we remove the ability to go backwards? That meant users would have to start over every time, or at least start a particular section over again. Should we simply explain it really well in our elaborate Help documentation? Sorry. No one reads Help documentation.

On and on the discussions went. We were innovators, after all. All we needed was some time to think it through and we'd come up with something amazing. But it just wasn't coming together.