How to name things in your application

Posted on May 31, 2012 by Kevin Matz

Humans use language to think and communicate, and when we think and speak about things and concepts in the world, we use names or labels to refer to those things. In other words, names are linguistic handles that refer to things in our speech and writing.

It’s usually pretty difficult to talk about something if it doesn’t have a name. In casual in-person conversations, you might be able to point to somebody and say “that guy” to refer to him, but of course this doesn’t work well in a written context (or when “that guy” leaves the room). Things in your application need to be named and labelled so that users can know where they are, what data they’re looking at, and what actions they can perform. Good names and labels help the user form a correct mental model. Clear and consistent naming is also important so that unambiguous instructions can be formulated, like “In the Search dialog, under the ‘Advanced’ tab, uncheck the ‘Case sensitive’ checkbox.”

What kinds of things are typically given names in software applications?

  • “Places” such as pages, screens, dialogs, and tabs
  • Menus
  • Tasks (the names of tasks may not necessarily be exposed to the user in many applications, however)
  • Controls such as buttons, icons, checkboxes
  • Data elements such as fields and column headings
  • Objects, classes, tables, records, files, and other forms of persistent data collections almost always need to be uniquely identified (though not all of these may be exposed to the user), and unique identifiers such as customer IDs or social security numbers could be considered to be names
  • Domain-related or interface-specific concepts, constructs, and abstractions, such as “contribution limit” in a pension administration system, or “layer” in Photoshop

Names are used for differentiation between things. If two things are given the same name, then that name is ambiguous because it could refer to either of the two things. Imagine you work in an office where there are two people named John: John Smith and John Thompson. If your boss asks you to “please pass this letter on to John”, then without additional information, you can’t be sure which John your boss is referring to.

In other words, “John” is not a unique name within the context of your office. The name “John” is ambiguous because it could refer to either John Smith or John Thompson. To eliminate the ambiguity, you have to add enough “qualifying” information to uniquely identify the target. So “John Smith” would be ideal, but “John S.” or, say, “John in Accounting” would also suffice in this case.

Ideally, names are unique within the context in which they are used. You may know a Suzanne in your office and a Suzanne at your yoga studio. If someone from the office mentions Suzanne’s name, you’ll probably assume they’re talking about the Suzanne in the office, whereas if someone you know from the yoga studio mentions Suzanne, you’ll probably assume they’re talking about Suzanne from the yoga studio. Because of the two different contexts, you’re usually able to make a reasonable assumption about who is being referred to.

In software development, naming contexts are often called “namespaces”. If you were to make a list of all the names within a namespace, it is best if all the names are unique, because they can then all be differentiated from each other.

Here are additional guidelines and things to keep in mind when you are naming things in your application:

  • Does the name accurately describe the target? For instance, a tab named “Address” is accurately named if the tab contains a customer’s address information. But if the tab is then redesigned so that the customer’s phone number and e-mail address are displayed, then “Address” no longer accurately describes the contents of the tab. Perhaps “Contact Details” might now be a more accurate title.
  • Does the name unambiguously describe the target? If not, consider a different name or add adjectives to make the name more specific. For example, if you label a field “Profit”, is it clear from the context whether this refers to the gross or net profit?
  • Consider whether the level of abstraction is suitable for your audience and context. The name “Universal Serial Bus” is an technically accurate name for hardware designers, but from average consumers don’t know and don’t care about what “serial” and “bus” mean; the context of computer architecture is irrelevant to consumers. “FireWire” is a better name for marketing purposes, because the name does not expose unnecessary technical details (and the rhyming and repetition in the name makes it more memorable).
  • Names should be of a reasonable length, as excessively long names are hard to remember and time-consuming to read and write. On the other hand, don’t try to shorten a name to the point where it no longer clearly and uniquely identifies the target. Yes, abbreviating John Smith to JS makes the name shorter, and may be suitable in some particular context, but now JS referring to John Smith is no longer differentiable from, say, Jane Smith or James Schmidt or Jerry Springer (or perhaps even Javascript). Abbreviations and acronyms increase the chances of misinterpretation and so should be used with restraint, except for well-known or domain-specific cases that you’re certain your user audience will understand. For example, VAT for Value-Added Tax is a well-known acronym in the UK, but is unfamiliar (and probably irrelevant) to users in the US.
  • Whenever possible, use existing standard terminology. If there are multiple synonymous terms for the same thing, like “Income Statement” and “Profit & Loss Statement” in accounting, choose one as the standard and use it consistently in your application.
  • The first letter and first syllable, or the first word in a compound word, are the most strongly memorable and differentiable. Suffixes are the least differentiating and memorable.

The sprawling city of Calgary, Alberta, Canada requires all streets within each demarcated suburban community to have names that begin with the same three letters. The Taradale suburb, for instance, is a maze of streets with names like Taradale Drive, Taradale Close, Tarrington Close, Tararidge Close, Tararidge Crescent, Taracove Road, Taracove Landing, Taracove Crescent, Taralea Park, Taralea Green, Taralea Way, Tarawood Grove, and Tarawood Lane. This can make finding a particular address while driving rather difficult. “Tararidge Crescent” would be a very unique name in a community with street names like “Bay Street”, “MacDonald Avenue”, and so on, but since all the names in the community sound nearly identical, the cognitive load of trying to remember an address and simultaneously compare it against virtually identical alternatives is challenging.

Map of Calgary's Taradale suburb

Calgary's Taradale suburb (courtesy of Google Maps; map data copyright 2012 Google)

  • Within each naming context, names should be consistent in terms of phrasing and capitalization. If you are choosing names for your tasks, for instance, having both “Add new customer” and “Customer editor” in the same list is awkward. The former with a verb and describes an action, while the other is a noun phrase that describes the “place” (screen, dialog, or page) where actions take place. Using the pair “Add new customer” and “Edit customer” would fix the problem. Likewise, “Add new customer” and “Edit Customer” are inconsistently capitalized. Yes, some people will not notice this sort of thing, but your more literate and attentive users will notice, and this kind of sloppiness does not inspire confidence.
  • Human languages tend not to consider numbers to be names, but numbering systems like social security numbers, passport numbers, phone numbers, etc. are essentially a form of naming, as they are intended to uniquely identify something and differentiate specific things from other things within a context.
  • For product names, distinctiveness and descriptiveness are important, and of course you’ll want to make sure that the name is available for domain name and trademark registrations. When selling internationally, try to ensure that the name is free of negative connotations in all of your markets. For example, “Siri”, the iPhone feature, sounds like the Japanese word for “buttocks”. And a “Mist” air freshener wouldn’t sell very well in Germany because “Mist” is German for “manure”.

Product names should also be pronounceable: given the name in written form, people should not have to ask, “How do you say that?” And when someone hears the name being spoken, it should be recognizable and the listener should ideally be able to spell it. If you had never heard of YouTube, but somebody said that name to you, would you interpret it as “YouTube” or “UTube”? Intentional spelling and punctuation variations like “Flickr” and “del.icio.us” can be distinctive but have the trade-off that people will be forever misspelling them. Also, be consistent with your branding; is the correct spelling Walmart, Wal-Mart, or WAL*MART? That retailer has itself used all three variations in different contexts.

Posted in Information Architecture, Psychology for UX Design, Usability, User Experience Design, Visual Design | Leave a comment

Choosing an interaction style for your application

Posted on May 30, 2012 by Kevin Matz

One of the first things to be decided in creating your application’s interaction concept is to decide on the general interaction style, by which we mean the fundamental way that the application presents itself to the user and allows functionality to be used.

To give you ideas for structuring your application, the following list gives some examples of major interaction styles. There is much overlap between some of these classifications, and most applications use a combination of these styles. A video editing application, for example, combines aspects of the direct manipulation and control panel styles.

  • Command-line: The user controls the system by entering commands or queries in a console.
  • Menu-driven: The user controls the system by picking options from menus.
  • Conversational: The interaction focuses around a give-and-take between system and user, often with one side asking the other questions. Depending on the sysetm, the user may engage in the conversation using natural language (textual or vocal), a specialized query language (essentially the command-line style), or by picking options from a menu (the menu-driven style). For example, medical expert systems ask a series of questions about a patient’s symptoms, and then suggest a diagnosis. iPhone users can speak questions or commands to Siri and receive responses.
  • Form-filling: The interaction revolves around the user entering data into standard forms.
  • Direct manipulation: The user manipulates objects on the screen. In Visio or Photoshop, the user draws or edits diagrams or photos by directly drawing and working on a canvas. A word processor lets the user write and manipulate text as if it were on a page. An automobile racing game lets the user steer the car.
  • Control panel: The display simulates gauges, buttons, and other controls normally found on a traditionally hardware-based device or control panel, like a industrial process control board, a stereo, or aircraft flight controls.
  • Content consumption: The application serves to present content to the user, but the user may have little means of interacting with it, other than navigation. Video players and book readers are examples.

For many applications, the choice of interaction style or styles is self-evident, but thinking through alternative or unconventional styles of presenting functionality can sometimes lead to ideas that differentiate your product from others in the market. Income tax preparation software involves a lot of form-filling, but some packages, like UFile.ca, offer an “interview” mode that collects information by asking a series of questions about your personal situation. While you end up entering the same information as you would with a long form, the conversational approach of the interview is more personal and less overwhelming than being faced with pages of data-entry forms.

Posted in Information Architecture, Product Management, Psychology for UX Design, Usability, User Experience Design, Visual Design | Leave a comment

Don’t make assumptions about your users’ existing skills!

Posted on May 27, 2012 by Kevin Matz

As a software designers, it’s easy for us to fall into the trap of assuming that users think and act the same ways we do. As a white-collar software professional, you likely have a college education and perhaps an advanced degree, you probably approach problems in a logical and analytical way, and you know how to operate and troubleshoot computers and software. And, evidently, you read books. But if you’re creating consumer products or websites for the general public, you can’t assume that the majority of your customers are like you in these regards!

If you work with a computer all day, it’s easy to assume that, since virtually everybody owns a computer and a smartphone nowadays, everybody has a basic level of computer literacy. But this can be dangerous. The rudimentary skills and knowledge that you may hold as self-evident aren’t necessarily widespread in all user communities. Here are some anecdotes from my personal experience to illustrate this:

Just recently I spoke with a fellow who I assumed had reasonable computing skills because he was able to use e-mail and Facebook, but when I used the term “cut-and-paste” in conversation, he didn’t understand what I meant, and it quickly became clear that he was not familiar with the mechanisms of selecting text and copying it to another location.

Casual home computer users can often manage to “get by” without knowing all the tricks and techniques. When you think about it, how would a brand new computer user discover the concept of cutting-and-pasting and the steps to do it? Computers today rarely come with operating manuals, and there are certainly books for beginners that explain this sort of material, but how many beginning users buy and read such books? Most users pick up skills like these by observing someone else doing it. In an office environment, people have many opportunities to watch other users; someone living alone and not using a computer at their job will probably have fewer chances of observing other users, and they may struggle with their home computer.

But it’s not only casual home computer users that struggle. I once worked in a project during the early 2000’s to replace a legacy enterprise system. The operators used “green screen” dumb terminals connected to a mainframe. Many of the operators had been using this system for nearly thirty years and were highly proficient, and so we assumed that, because of their computing experience, while there would be a learning curve with the new system, there wouldn’t be any great challenges. But the instructors who were training the staff to use the new system quickly discovered that a few of the operators didn’t know to operate a mouse and were unfamiliar with graphical user interfaces. Evidently their computer use did not extend past their job descriptions.

It’s all too easy to make assumptions like these, and talking to users and observing them is the only way to really understand how they think and work. If you find that your users’ limited skills will prevent them from being able to use your product for its intended purpose, you’ll need to give some thought to either modifying the interface so that they can get their tasks done, or you’ll need to come up with a way to give the users the information or skills they’ll need. If you don’t, users will struggle, and they’ll resent and blame your product.

In a corporate environment, you may be able to schedule training sessions to teach your users how to use the application. For mass-market products, since training sessions aren’t really an option, you’ll have to consider things like cues and clues in the interface, user manuals, help systems, and sample projects. A good tutorial can make all the difference to users starting out with your product, and a video walkthrough may hold your users’ attention longer than a text-based tutorial document.

Posted in Product Management, Psychology for UX Design, Requirements Engineering, Usability, User-Centered Design | 1 Comment

What is involved in designing user interfaces for an application?

Posted on May 26, 2012 by Kevin Matz

Designing a user interface is, you’d might think, just a matter deciding what buttons and controls are on the screen and what happens when you press them.

That’s not incorrect, but there’s usually a little bit more to it than that. To design a product’s user interface effectively, you have to think through and decide on all of the following:

  • What tasks and activities can the user perform with the application?
  • How does the interaction proceed for each task? What steps and actions does the user perform and what steps and actions does the product perform?
  • What is the overall visual style or appearance of the application? (For example, what will the basic page template or screen layouts look like, and what fonts, colors, iconography, and branding will be used?)
  • What “places” are there in the application? “Places” could be pages in a web application, screens and dialogs in a desktop or mobile application, or even levels or locations in a game.
  • How does the user navigate between the places (if applicable)?
  • How will each “place” look? What controls and objects are available, how are they arranged, and how can they be manipulated or activated?
  • What happens when the user activates or manipulates the controls and objects? What behavior is performed?
  • What events does the application have to deal with that aren’t triggered by the user? (For example, do regularly-scheduled events occur? Does the application react to information arriving from another system?)
  • What data or content does the application store, manage, and present? How is it presented or represented on the screen?
  • What names or labels do you use to refer to all the things (data elements, objects, controls) in your application? How are the places, controls, and menus labelled?
  • When errors occur, how is the user informed of the situation, and what opportunities are there for recovery?
  • Are there different roles or classifications of users? What is each role allowed or not allowed to do?
  • How will users get assistance when they’re unsure of how to use the application?
  • How will you help new users figure out how the application works and how to get their tasks done?

Thinking through these issues isn’t enough, though. Since you’re probably working in a team, you’ll have to communicate your designs and intentions to the team members who will build and test the product. This communication can take the form of formal design documents and specifications, or prototypes and mockups, or perhaps even just face-to-face communication in front of a whiteboard.

And you need to be sure that what you design is feasible within the constraints of your project: It has to be implementable using your technical framework, it must be implementable with the skills of the team members available, the performance must be acceptable, and so on. Can the project team build the product at a reasonable cost and within a reasonable timeframe? And if the product is being marketed (as opposed to being a one-off custom project for a client), will the product sell enough copies to be profitable?

How do you figure out all of this? To start, you need to understand who will be using the product, and what they want and need. You’ll need to do this at the beginning of the project, and you’ll need to continually research and improve your understanding of your users as the project progresses, as these user requirements can often change.

We should note two things:

  • Not all of the things in the above list may necessarily be done by one single designer! In most project teams, multiple people in different roles will take responsibility for different tasks. Examples of roles include product managers, business analysts, information architects, user interface or UX designers, usability specialists, developers, and so on. If your product is being developed for a particular niche or industry, such as banking or insurance or air traffic control, specialists with knowledge and experience in that domain will also play a key role in defining the product. Some organizations refer to these domain specialists as Subject Matter Experts, or SMEs.
  • The above list, being focused on designing the user-facing part of a product, is not a complete list of all the things that need to be decided and designed for a software product. It excludes all of the technical design work, for instance. As since products are built by project teams, the project and its processes need to be planned and managed, and while this is usually considered a management task, there is no reason why this planning should not be approach with a design mindset as well.
Posted in Product Management, Project Management, User Experience Design | Leave a comment

What is gamification?

Posted on May 21, 2012 by Kevin Matz

Can software products be designed to motivate users and increase productivity?

If you’re running an organization and your staff gets their work done using an enterprise application, you’ll naturally want to increase their productivity. Or, if you’re running a community-driven website that relies on user-generated content, you’ll want to encourage participation and repeat visits. Especially in a business setting, some of the tasks that have to be done are often tedious or unpleasant — well, it is work after all.

But there’s one class of applications that tends to have little difficulty keeping users intensely focused and always coming back for more: Games.

Games are fun diversions, of course, and yet a lot of the actual tasks that players do in games are actually quite repetitive and often difficult. If these tasks actually led to any result in the real world, they would probably be considered work! In fact, some people really enjoy playing games that are highly accurate simulations of other peoples’ day jobs — flight simulators, for example.

Some people think some of the things that make gameplay addictive can also be applied to other kinds of applications. This is called gamification, and it’s currently a hot trend.

What makes games addictive?

First, there’s the voluntary nature of game-playing: People are more likely to enjoy something when they’re choosing the activity (unlike work, nobody’s forcing you to play a game).

Second, games have goals and rewards: You want to get to the next level, and it’s satisfying when you finally achieve it. Some games have elaborate systems of rankings, and as your skill improves, you get promoted; other games might revolve around “quests” for various “items” that are desirable for any number of reasons. And winning the game is ultimately the most satisfying reward.

Third, as players achieve these goals and rewards, there is a sense of progress and and an awareness that the player’s skill is improving.

Fourth, most online games are multiplayer games, and so there is an element of competition. Many people are driven to be the best, and they want to win against other players. There is pride and social recognition in being at the top of the “high scores” leaderboard.

Lastly, multiplayer games are a social experience, whether you’re competing head-to-head with other players, or in some games, forming cooperative teams. For some people, games are a way to spend time and share social experiences with friends and family.

If these ideas make games fun and addictive, then can some of those ideas be brought to other products like enterprise applications and websites, and will this make those products more fun and addictive? It depends on the product and its users, but often the answer is yes — as long as it’s not done in an overly gimmicky way.

StackExchange, a programming question-and-answer community website, is enormously popular. Much of that popularity today is due to the vast amount of content that often shows up at the top of the search results for programming-related queries. But how did they get all that content? It was created by the users, and a clever incentive system had a lot to do with it. On StackExchange, users accumulate points for successfully answering questions and earn “badges” as recognition of achieving certain milestones. Some badges “unlock” special privileges, like the ability to moderate the community. Users with lots of points and badges enjoy respect and status for their contributions to the community.

Rewards systems can be effective for work that is easily measured. But you can breed resentment if the rewards system is not seen to be reliable or fair. Creative work is particularly difficult to reward because totally objective metrics for measuring “quality” and even productivity are often impossible to define. For example, how would you create an algorithm to judge the attractiveness of an artist’s logos? Or if programmer A took two hours and wrote 100 lines of code to solve a problem, and programmer B took one hour but needed 200 lines, who is more productive?

One proxy for quality is popularity; on a community-driven website, you can let users “upvote” or give points to other contributors to reward them for good contributions. When the community is large and active, this system can be quite effective. This sort of peer voting is more problematic in a workplace setting, though. Asking employees in small teams to judge each others’ work and hand out rewards rarely results in objective evaluations and can exacerbate office politics.

Reward systems are always well-intentioned, and yet they often lead to unexpected and unintended consequences. In a business environment, management will inevitably use these systems as a metric for judging and comparing workers’ performance, even if that was not the original intention. And metrics-based incentives encourage workers to game the system, to the detriment of the organization and its customers. I’m aware of one technical support call center that measured the time spent per call and disciplined workers whose average time per call exceeded a certain target. While the scheme was intended to reduce costs, it only had the effect of forcing workers to do anything possible to reduce call durations. So rather than try to actually resolve callers’ issues, workers would unnecessarily forward calls to someone else or even give faulty but short answers so that they could hang up as soon as possible. This only led to an increased volume of calls from angry customers!

Competition can be a powerful motivator for some people; sales teams have used competition (such as salespeoples’ results and rankings being posted in the hallway) as a motivator for years. But competition can be a turn-off for many others. If you structure the system so that there is only one “winner”, then you’ll have one happy winner and the rest of your users will be unhappy losers. And on community websites, competition tends to discourage newcomers: How can a new user possibly compete against the obsessive-compulsives who have been contributing non-stop for years and have 50,000 points?

So if you’re considering applying some of the ideas of gamification to your product, be sure that you understand your users, and be sure to think through all of the consequences.

Gamification can be very appealing to some audiences, and gimmicky to others. Established professionals, for instance, tend to be highly self-disciplined, take a lot of pride in their skills and accomplishments, and gain intrinsic satisfaction out of doing their job well. (They also tend to be rewarded with good salaries.) These people will be personally insulted by the notion that their work can be turned into a “game” with phony competition and incentives.

For professional users, the simple indication of progress on long tasks is probably the best reward. There is satisfaction in finishing a task, and for longer tasks, it’s reassuring to know that you’re making progress towards completion. Reading a 500-page book with 50 small chapters tends to be more satisfying than reading a 500-page book with only 5 big chapters, because there’s a feeling of completion and accomplishment when you reach the end of a chapter.

So in a data-entry-centric application such as income tax software, it can make sense to break down data-entry forms into smaller sections or pages that be checked off when complete. A graphical progress meter showing the percentage of work completed and work remaining can be very useful. LinkedIn has a nice example of just such a progress indicator on its profile editing page:

LinkedIn Profile Completeness Indicator

 

Posted in Office Politics, Psychology for UX Design, Usability, User Experience Design, User-Centered Design | Leave a comment

How do users learn and use software applications? An introduction to mental models

Posted on July 11, 2011 by Kevin Matz

As your users learn to use your software application, website, or device, they gradually form a mental model of how it works and how to operate it.

A mental model is a conceptual representation, in a user’s mind, of how a system works, and how to operate it. A user’s mental model reflects the user’s current understanding, and is subject to change as the user gains experience with the product.

When faced with a new situation, users rely on their mental models to reason about the situation and the system, and to make decisions and formulate strategies on how to proceed. Users also form expectations based on their mental models.

But mental models are not always correct representations of how a system works, and the mismatch between an incorrect mental model and the system can explain many usability problems. It’s important, therefore, for a system to be designed in such a way as to help users form a correct mental model of the system’s operation.

Mental models are cognitive structures in peoples’ minds. It’s hard to say that mental models have any particular form or structure. A mental model is not inherently visual, although visual images do form an important part of a mental model.

Let’s look at a number of things that I believe make up a mental model for operating a software-based system.

What does a mental model consist of?

1.  General appearance

Users will mentally form visual images of the system, or at least the parts of the system that the user has encountered and is familiar with. But these mental images are typically very vague and imperfect.

For a simple physical device, the mental visual image may be quite vivid: I can quite easily picture a screwdriver or a can opener, for example.

For a typical complex software application, users will become familiar with the general layout of the screens, pages, tabs, or windows that they encounter. The level of detail of mental images will vary depending on each user and the frequency of use.

For example, as a frequent user of Microsoft Word, I have a vague image of the layout of the main window in my mind, though I wouldn’t be able to recall the exact sequence of icons in the toolbar or even what pull-down menus exist after “File” and “Edit”. I know some of the dialogs like Font, Find/Replace, etc. well enough that, even if the text of the labels and buttons were blurred, I could still recognize the dialogs by the “shapes” of their layouts. But my recall is not good enough to be able to sketch them out accurately.

2.  Concepts, vocabulary, and rules

In general, every software-based system or product solves some sort of problem or issue. The concepts, vocabulary, and rules involved in the context of that problem are referred to as the problem domain, the business domain, or the application domain . A bank uses specialized software to run its operations, and so the application domain of that software system is banking.

For some systems, the application domain is relatively small. The operator of an e-mail client only needs to understand a handful of concepts, like e-mail addresses and attachments. Other systems will demand in-depth knowledge and understanding of a domain. Imagine what a master operator in the control room of a nuclear power plant needs to know!

Some applications, like the nuclear power control system, can safely assume that the user already has the prerequisite knowledge of the domain, whether through education, training, or experience, or some combination of these.

Other applications have the responsibility of communicating their unique concepts to the user. Games, being “imaginary worlds” rather than real-world problem-solving tools, are an extreme example of this. The first time you play, say, Angry Birds, you need to learn what objects are in the game and how they interact; in other words, what the basic rules of the game are.

Or, take Twitter as another example. To use Twitter, you need to understand what a “tweet” is, and you need to learn that you can follow other users and that other users can follow you. If you’ve never used Twitter before, you might learn these concepts by reading the introductory instructions on the Twitter website, or you might figure them out yourself by trying it out (self-discovery). Or, in the somewhat unique case of something as popular as Twitter, you might learn the concepts “accidentally” by watching a friend use it or by hearing about it in the media.

In many cases, users can grasp concepts without knowing the associated vocabulary. For example, web browser users can enter website addresses without knowing that the addresses are technically called URLs.

Additionally, users often don’t need a full understanding of many concepts if the software handles the details for them. Users of a shipping postage calculator may only need of know of a customs duty fee; they do not need to know the rules and technical details, as they will trust the software to calculate the fee for them.

In many cases, users who aren’t aware of all of the application’s concepts, or don’t understand them completely, are still often able to use the application effectively, if not optimally. Virtually all beginning users of Microsoft Word are unaware of the concept of styles, for instance, but they are still quite capable of producing documents. We’ll see later how we can design applications to help users discover and learn key concepts.

3.  Navigation map

Most software systems consist of different “rooms” or “places”, in the form of pages, screens, tabs, or windows, which the user can “visit”. When it is necessary for the user to differentiate between these places and to be able to get to them quickly, the user will gradually form a mental navigation map indicating how to get to the different destinations.

Navigation is often one of the steps needed to carry out a task in an application. For example, to purchase goods on an e-commerce site, you may need to navigate to the “shopping cart” page and then click on a “checkout” button, which may lead to a sequence of pages for finalizing the purchase.

Sometimes there may be more than one way to get to a location. For example, to get to the Print dialog box in most Windows applications, you can navigate to the File menu and choose “Print…”, or you can use the shortcut Ctrl-P, or you can click on the printer icon in the toolbar. The user may not be aware of all ways to navigate to a destination, and users aware of multiple options will tend to use only one of them frequently.

4.  Action plans or strategies for accomplishing tasks or for reacting to situations or problems

Users may memorize plans of actions needed for carrying out certain tasks.

An action plan might take the form of a simple sequence of steps to follow. Or, with sufficient experience with the product, users may internalize a conceptual structure similar to a flowchart diagram that has various decision points and branches with steps to follow under different circumstances. (But note that most users will not actually have a visual depiction of a flowchart in their mind, and keep in mind that the structure may not necessarily be complete or correct.)

Sometimes a user may not necessarily understand why a certain sequence of actions performs a particular task, but they’ve still memorized the sequence and are able to reproduce it. This can happen when the user has been taught how to perform a task in a training session, but some of the fundamental concepts (the “why” behind the actions) haven’t been explained. It can also happen when the user has discovered by accident how to perform a task.

5.  General heuristics and conventions

The user’s mental model may include general heuristics and conventions from a broader context that happen to apply to the system at hand. For example, based on the user’s experience with the operating system, one such heuristic might be, “to dismiss a dialog box, click on the ‘OK’ button or click on the ‘X’ in the title bar”.

6.  Implementation model

A user may or may not form an idea of how the product works internally.

For simple mechanical devices and machines, you might be able to see all the moving parts, and you can mentally envision how the parts interact when the device is in operation. If you examine a manual can opener, for instance, you can see how the edge of the can is pinched between the wheel and the blade, and you can imagine how turning the handle slices open the can.

For simple mechanical devices, seeing and understanding how the parts work can be helpful and may even be necessary for operating the device correctly.

But for more complex mechanical devices, like the engine of an automobile, the inner workings are often too complicated for non-engineers to understand – and so such machinery is tucked out of sight. Automobile operators are offered simplified and abstracted controls – like the gas pedal and the automatic gearshift – which eliminate the need to know how the engine works. In other words, the user’s mental model of the underlying implementation can be extraordinarily simple (basically: “the engine burns gas to run, so I need to make sure there’s still enough gas in the tank”). The user’s mental model can instead focus on the actions needed to make the car move: put the gearshift into “Drive” and push on the gas pedal.

For software products, designers need to hide the internal workings to the maximum extent possible. While technically-sophisticated “power users” might try to envision how the underlying algorithms and data storage and communications protocols work, users should never have to know about the technical implementation details.

But even if users are “perfectly” shielded from unnecessary technical implementation details, they will still often be able to observe patterns in how the system operates and responds to inputs. From these observations and patterns, users will form simple implementation models, and implementation models on this level of abstraction are a good thing.

Let’s say your application has an on-screen table containing a list of contacts, and there is an “Add” button to let the user add a contact to the list. The user observes that every time a new contact is added, it appears at the bottom of the list, below the other entries. Based on this observation, the user will tend to presume that the contacts are maintained in a sequential list, and new contacts are always simply added to the end of the list (rather than being added at the top of the list or being inserted at appropriate places in order to maintain alphabetical ordering or some other sort order).

This is a very simple and abstract form of implementation model, but it helps the user predict what will happen when the action of adding a new contact is performed, and when the user encounters another on-screen table, they will assume that similar behavior will apply there as well.

What’s next?

In upcoming posts, we’ll discover more about mental models by exploring questions such as:

  • How do users explore and try out products, and how does this impact how mental models are formed?
  • How do mental models change and evolve as users continue to use a product?
  • How do mistakes and forgetting impact mental models and the user’s experience?
  • How do the mental models of beginners, intermediates, and experts differ?
  • How can we design systems and interfaces so that users can form a mental model that matches the designer’s intended mental model?


Posted in Information Architecture, Psychology for UX Design, Usability, User Experience Design | Leave a comment