Let's Talk
Planning for great UX often depends on being able to step back and see the forest for the trees. We map out user flows, establish broad goals with personas and key experiences, and refine our layouts based on our findings. This sort of macro-level thinking is essential, but it's only a part of creating great interfaces. Microinteractions - small, discrete moments of engagement with the software are their counterpart. While these details are easy to overlook, great design at these key moments can elevate software from merely functional to satisfying and trustworthy. They are essential to the overall perception and experience of an interface. Getting these small moments right can reduce cognitive load, clarify ambiguous application states, help establish consistent usage patterns, and even reinforce a brand's personality or values. When done well microinteractions will feel intuitive and natural, obvious even. Unfortunately this doesn't make them easy to design! I'll address a few common misconceptions about when these should be employed, discuss strategies for identifying which interactions deserve this special attention, and explore approaches to prototyping them.
Where Microinteractions Fit In
While it's tempting to treat microinteractions as decorative flourishes that get bolted onto an otherwise finished interface, this approach misunderstands their purpose. Microinteractions are about articulating or communicating otherwise ambiguous aspects of an application's state. This can mean providing timely messaging, clarifying the outcome of a given action, or providing real-time feedback to tactile adjustments. A user tapping a "like" button, pulling down to refresh, or nudging a volume slider up are familiar examples. These are all tasks with a well defined trigger and a clear set of outcomes. A transition state on an animation might reinforce that precious data is actively being preserved, while inline form field validation can reduce the "did I do that right" anxiety that often precedes form submission. Thinking in these user centric terms and approaching microinteractions as opportunities for improving communication will help in identifying where it's worth investing extra time and energy.
Understand your context
In most cases it's a mistake to dive straight into visual design without fully understanding your user's context and needs. This temptation is particularly acute when dealing with aspects of design that can seem like details. Unfortunately skipping the research stage puts you at risk of either solving the wrong problem or solving the right problem but having no clear metrics for validating your solution. Put differently, having clear design goals will tell you when to stop designing and start testing your solution. There are a number of proven UX research methods that can provide this context, and each is likely worthy of its own writeup. Regardless of how you choose to go about answering these questions you should aim to establish what users are thinking, feeling, and trying to accomplish at that particular moment.
An equally important aspect of context is understanding how your users think about at your application itself. Are there any semantic relationships between components, pages, or sections that you want to preserve or emphasize? What do they think is going on behind the scenes when they perform a given action?
Once you've established context you can address the question of content: what specific information do users need at that particular moment? This will change from case to case, but for example’s sake this might be tactile feedback, a clear indication of state, iconography, or concise messaging.
In case this feels too abstract let's look at a practical example. In the "pull down to refresh" interaction the context might be a user who is waiting for an important email to arrive. Since this update generally happens silently in the background it’s often unclear if the mailbox is up-to-date. Without a clear mechanism to trigger an update it can feel like the user is at the mercy of the device. Once an update has been triggered there is the possibility for additional ambiguity: is the update in progress, or has it completed with no new messages? The content needed is a visual indicator of the current position in the flow. In this case this is accomplished with an icon that visually reinforces the current state. The icon ramps up until it is triggered (spring-loaded progress ring), communicates that the task is in progress (spinning), and transitions out once the check has been successfully completed.
Taking this example a level further we can consider context to include the user's' mental model of the layout of their inbox. The spinner icon is effective because there is a clear spatial mapping between the action and the outcome. The user looks above the current results to the spot where new items will be placed for any additional updates. New items can simply appear if they are present, and the existing content can slide back into place if not.
Leverage Existing Patterns
Great, you've got a clear picture of how your users perceive your software, you have a good sense of their cognitive and emotional needs, and know what content you need to present them with. You're almost ready to dive into your favorite prototyping tool, but before you do, pause and consider whether there are any existing, well established solutions to the problem available to you already. This might mean extending an existing interaction pattern found within the application already, or working in a well-established UI pattern from elsewhere. Leaning on these previously established patterns of behavior can feel a bit unglamorous but is often an extremely powerful approach. Doing so leverages existing training, and works with expectations rather than against them.
Experimental UIs, conceptual navigation, and similar novel interactions are great for pushing our collective UI toolkit forward. There is still a great deal of room for new, better UI paradigms to emerge, but in many cases these solutions need a compelling and significant differentiator to be worth asking users to pay the up-front costs. If you do see a compelling reason to explore new solutions, your next step should be prototyping.
Prototype complex solutions
The discrete nature of microinteractions makes them well suited to prototyping. Prototypes are most valuable when testing aspects of a design that aren't easily validated with static tools. Tactile feedback and touch-driven interactions in mobile apps are one common candidate for prototyping. These can be used to test affordances, identify small tap targets or awkward element positioning, or simply validate that a given solution feels right. Prototypes are also powerful collaboration tools, enabling designers to gather stakeholder feedback and run concepts by developers. A prototype will invariably be a cheaper, faster, lower-risk way to validate an idea than attempting to tune production code.
Why not start in the browser?
Designers with strong front-end development skills might be tempted to dive directly into code. While this is promises high fidelity solutions it’s often a mistake. In Bill Buxton's classic UX design text "Sketching User Experiences" Buxton describes a prototype as a sort of sketch, a disposable, low-cost tool for working through a problem visually. These goals are often directly at odds with the needs of production code, and there are usually strong incentives to construct good-enough solutions that won't need to be discarded once they've been built. Instead of focusing solely on finding the best UX or validating a particular idea the designer now has to contend with front-end development concerns: constructing universally accessible markup, weighing SEO implications, planning CSS architecture efficiently, and doing it all at 60fps. These are all essential things to plan for, but this is usually the wrong moment to attempt to solve these problems. Doing so will make your prototype less sketch-like and disposable, and split your attention away from user-centric, UX focused thinking.
Choose the right tool
The prototyping tools market has been moving forward at a dizzying pace recently. New tools promise to address the challenges of rapidly modeling interactions at every level of fidelity. A recent article in Smashing Magazine on selecting prototyping tools underscores how complicated choosing the right tools can be. Good tooling is essential, but again this should be driven by context. What do you want to learn or accomplish with a prototype, and which tools will let you do that most effectively? Digital tools are extraordinarily powerful and getting better every day, but a sketchpad or whiteboard remains hard to beat for speed, efficiency, and availability.
Plan for repeated exposure and perceived performance
Microinteractions often require animation, and because of this it's worth thinking about these in the larger context of perceived performance. It's tempting to treat performance as being purely an engineering concern, but as designers our choices have a direct impact on how fast users think an application actually is. Apart from the actual constraints imposed by hardware and software, transitions and animations can make an otherwise performant application feel slow. Make sure that when you plan a given interaction you're considering not just how it will feel on the first run but on the third or the tenth. A dramatic page transition might help tie together sections on the first few viewings, but will become a grating annoyance once users get the underlying concept it is understood.
Industrial designer Dieter Rams’ famous Ten Principles of Good Design dictates that "Good design is thorough down to the last detail. Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the user." Microinteractions provide us with a tool for doing exactly that. They allow us to make our software feel less arbitrary and more predictable.