Do you remember the first time you used an ATM? How easy was it? Were you prepared to slide in your debit card? Did you assume the keypad was for your PIN?

Before you knew how to use an ATM, you went into the bank to withdraw cash. You interacted with the teller, slid your card, entered your PIN, answered a few questions about amount and account, and then received the cash. This real-world experience prepared you to interact with an ATM. Whether you realized it or not, you walked up to the ATM with ideas of how it would work. Our experiences with items, people, and technology form expectations for how new things will work. These expectations are called a “mental model.” Every new experience you encounter—a new website, item, or place—is governed by your mental model.

Mental models are often unconscious. For example, if you read a digital magazine on an iPad for the first time, you may use your finger to slide the bottom right corner and turn the page. Most likely, you won’t think to yourself, I slide and grab the corner of a real magazine page to turn it, so I’ll try that on a digital one to see if it works. You just did it because you expected the digital page to respond.

Mental models are unique to each person, which makes identifying them a little tricky. The reason we do our Stage 1 UX research is to uncover the users’ mental models. We want to understand the users because software is more useable when it closely matches the user’s mental model. Once we’ve done the research, it needs to be communicated with the project team. One of the best ways to communicate mental models is wireframing. Very simply, wireframes are line drawings of a software’s interface. Sketching out an interface is a great way to take our understanding of the user and put it down on paper. Wireframes also function like blueprints, and the developers refer to them extensively as they program. Wireframing serves several purposes, including:

• making the users’ expectations tangible,
• communicating the expectations of the customer,
• and exposing any assumptions made by the designers and developers.

At Rocket Jones, wireframing is a corner stone of our process; it makes up the majority of Stage 2. We’ve found over the years that investing time and effort into wireframing saves our customers time and money in the end.

Before beginning Stage 2, we’ve already identified goals, user personas, and a clear vision. We take all that information, analyze it, and then create wireframes. Once we have the screens drawn up, we send them to the customer. They give feedback, and point out any incongruities or miscommunications, and changes are made. Without something tangible in front of us, it would be hard to verbalize details and mental models. But with a clear representation of the software, it’s much easier to identify strengths and weaknesses of the design. More importantly, the wireframes act as a catalyst for key conversations. They provide a way to balance

• the customer’s desires and goals,
• the developers’ technical constraints,
• and the users’ mental model.

The nature of important conversations means that wireframing is a recursive process. It’s not uncommon for wireframes to go through 10 revisions before development begins.  That may seem like a lot, but it saves us hours of development in Stage 3. Using wireframes to make revisions instead of actual code allows us to correct issues quickly and with little effort. Wireframing also helps us avoid putting development on hold to ask the customer detailed questions every week. Of course, we still communicate and ask questions when needed, but doing revisions before developing reduces the emailing back and forth. We’ve already hashed out the details in wireframing, so our developers can get right to work.

On complex web application projects, we will often add another step to Stage 2 before beginning development. An interactive prototype is a simulation of the software that responds to clicks like the real thing. As far as personas and research can take us, they aren’t perfect. There may be gaps between our interpretation and the user’s actual mental model. Using an interactive prototype to do some brief usability testing can identify those gaps while they are easy to fix. While interactive prototypes are created quickly and without great detail, they are a great way to test for major differences in our design and the user’s mental model.

So the next time you interact with software, stop and consider what shaped your mental model. And if you enjoyed this post, stay tuned for part 3 coming next week or read the previous article.