Earlier I posted on the importance of designing the small details (aka, microinteractions) with as much care as we design features. Dan Saffer
, the author of Microinteractions – designing with details, refers to them quite simply as “small pieces of functionality.” He goes on to say they tend to be simple and brief, and either delightful or frustrating.
Designing rules, start with the goal
In this post I wanted to focus on the “rules” that guide creating a satisfying microinteraction. As Dan would say, we need smart rules to guide smart interactions. Rules govern how the microinteraction can be used or “played.” So before I can make a rule for a microinteraction I have to decide on its goal − intended purpose – which is simply the end state of the microinteraction. A cautionary note from Dan’s book is to “make sure the goal isn’t a step in the process.” So for example, I want users to login to their Pandora account; that’s the goal, the end state. Prompting uses to enter their login information is a step in the process. The main thing to remember here is that when designing microinteractions, keep your goal in mind so that the interaction will be successful.
From my experience the point of crafting good rules for interactions, in this case microinteractions, is that it affects the user experience by “determining what happens and in what order.” Rules are by nature limiting to users so instead of creating an experience that might feel confining, it’s better to design to create a natural flow so users are “gently guided” through an interaction.
A rule that worked!
A recent project comes to mind where we created an important rule so that the employees of an intranet portal would be satisfied with a key microinteraction – finding some specific things. Through user research we learned that employees had too much trouble finding their paystub, 401k, timesheet, job listings and health benefits (to name a few) in their current intranet (i.e., too many clicks and too much hunting around). So, our goal was to reduce unnecessary complicatedness. To achieve this the information architect created a rule to replace multiple tabs, which users had become accustomed to, with only two mega drop-down menus. Those menus stored the main categories of information along with specific keywords such as “job openings.” In usability studies, we learned we had made the right choice; for example, we found that the categories within these menus were easy to discover, and better still, just one click away. If we had asked users ahead of time if that was a good idea, it’s likely all would have wanted to keep tabs. We confirmed in testing that our rule was solid and participants “got” the paradigm shift and liked it.
Rules of thumb for microinteractions
As you design a microinteraction, there are some rules of thumb to be continuously thinking about so that your designs are usable, even satisfying.
Know as much as you can about users, their context of work and their environment. This is by far the best way to know how to set the goal, create the rules and design the interaction. And, know as much as you can about the previous and current behavior of users. Like the previous point, when we have this data we can use it to predict or enhance the microinteraction and to make smart choices and good defaults.
Decide how much complexity and decision-making the user must “absorb” and how much will be absorbed by the product (i.e., system). Taking my earlier project as an example, we had enough research under our belts to know that employees would be more than happy to relinquish control of the task of finding new job listings, or their pay stubs for instance, to gain the benefit of an easy to use experience. As Dan put it, “computers are simply much better at handling some kinds of complexity than humans.”
Here are some tasks Dan advises the product / system handle for users:
- Rapidly performing computation and calculations
- Doing multiple tasks simultaneously
- Unfailingly remembering things
- Detecting complicated patterns
- Searching through large data sets for particular item(s)
Limiting the number of options you give users is typically the best way to go; and, it’s better to create smart defaults than to make users work harder than is necessary to complete a task. Dan advises being “ruthless” about eliminating options. This, in turn, reduces the number of rules you have to create. Another bonus.
Design for perceived simplicity and avoid operational simplicity whenever possible. With perceived simplicity, a single control does multiple actions and that is better for microinteractions performed repeatedly.
Design microinteractions to prevent users from making an unintended choice, a mistake. Good design should do everything in its power to prevent user error.
A final rule of thumb, don’t forget about microcopy (labels and instructional text) as part of understanding how to craft good microinteractions. Don’t use instructional text when a good label will do the job and when you do need to include text, keep it as short as possible.
A last thought
Keep in mind that the most important rule of microinteraction design is knowing what the user is intending to do, what is he/she finds meaningful and valuable.
