UX Immersion: Interactions 2016 Conference

UX Immersion: Interactions 2016 Conference

This year I had the pleasure of attending the UX Immersion: Interactions Conference held on April 18–20, 2016 in San Diego. Positioned as “A UX Conference Unlike Any Other” I was thrilled and eager to participate in the different workshops and featured talks. It was an incredible learning experience with some of the most talented UX leaders speaking at the conference.

On Monday and Wednesday, each participant had the option to choose 1 of 3 different workshops. On Tuesday, all 7 of the presenters gave a featured talk to all the conference attendees.

With many great options to choose from, I narrowed down my workshop choices to Designing the Critical Details using Microinteractions with Dan Saffer on Monday and Leading Design Sprints to Jump-Start Team Collaboration with Richard Banfield on Wednesday. On Tuesday, I attended all the featured talks, and my three favorites were Practical Creativity with Dan Saffer, Your Product Idea Is Great. But Who Cares? with Richard Banfield, and the closing talk Beyond the UX Tipping Point with Jared Spool.

Below are the most salient key points from the Day 1 Workshop.


Day 1 Workshop:

Designing the Critical Details using Microinteractions with Dan Saffer

Dan Saffer’s workshop focuses on microinteractions, which he defined as “a contained product moment that revolves around a single use case — a tiny piece of functionality that only does one thing.” Microinteractions do one task well. They are contained product moments. Another way of looking at it — microinteractions are “the feel” in “look and feel.”

Some examples of microinteractions include silencing your phone, logging in, setting a status message, searching, exporting, and making a comment. Unfortunately, microinteractions areall too often overlooked or forgotten. However, when microinteractions are taken into consideration and designed well, they add details that delight the user and make the systems more human.

It’s important to note microinteractions are not features. Features are multi-faceted, have multiple use cases, and can be complex. Microinteractions are simple, rapid, often forgettable, and frequently overlooked. When designing microinteractions, you can stack them together to create a bigger feature. In this way, you are designing from the bottom up.

Why are microinteractions important? It comes down to this: the difference between a product you love and the one you tolerate are often the microinteractions you have with it. If you have great features and a great product, but the microinteractions are poor, people will not want to use your product. If you care about user experience, you need to care about microinteractions.

When done well, microinteractions can be signature moments that increase adoption and customer loyalty. For example, Apple’s “Slide to Unlock” is a signature moment. So was AOL’s “You’ve got mail.” notice….which ironically has outlived the company!

So how does one begin to design a microinteraction?

You start with an understanding of the elements of a microinteraction, which is composed of four parts:

  1. A trigger that initiates it.
  2. Rules that determine how it functions.
  3. Feedback that the rules generate.
  4. Loops and modes that make up its meta rules.

Let’s dive deeper into each of these four elements.


1) Triggers

A trigger is the mechanism by which a user completes their goal. There are two types of triggers — manual and system triggers. Manual triggers are user-initiated, meaning that the user has to do something to begin the microinteraction. Flipping the switch on your iPhone to turn the ringer off is an example of a manual trigger.

System triggers are triggers initiated by the system itself — like when the device or application detects that certain conditions have been met and initiates a microinteraction. When your inbox detects that a new email has arrived, that is an example of a system trigger.

Once a microinteraction has been triggered, it starts the sequence of behavior, which can be turning a piece of functionality or interactivity on, or it can show the current state of the application or device. It might use some data to guess what the user wants to do.

At this point in the microinteraction, we move into part 2, Rules.


2) Rules

Once a microinteraction has been triggered, it turns to rules that have been set to help determine what happens next. The rules determine what can be done and what cannot. There is always at least one rule, if not multiple, and the rules can usually be defined by the designer. The more choices you have, the more rules you need.

The goal for microinteractions is to minimize choice and instead provide a smart default and a limited number of choices. It is important to emphasize (or perform automatically) the next action the user is most likely to take.

Use Rules to prevent human error. For example, when composing in Gmail, if the user writes “I’ve attached” but no file is attached, Gmail will remove extra space here remind you that there are no files attached. Then it will ask if you would like to send the message anyway.

From Rules, we move into Feedback.


3) Feedback

Feedback (or the lack of) is what allows us to learn the Rules. Anything you see, hear, or feel that helps you to understand rules is considered feedback. Feedback conveys a message like:

  • Something has happened.
  • You did something.
  • A process has started.
  • A process has ended.
  • A process is ongoing.
  • You can’t do that.

Feedback should occur:

  • Immediately after a manual trigger.
  • On any system trigger in which the status of the microinteraction has changed.
  • When the user reaches the end of a rule.
  • When the system cannot execute a command.
  • When there is progress on a critical process.
  • At the beginning or end of a process. (optional)
  • At the beginning or end of a mode. (optional)

Feedback can take many forms, including graphics, sounds, vibrations, and animations. It is important is to match feedback to the action and communicate the information in the most appropriate medium possible.

Feedback, along with triggers, are places to express the personality of the product. This is a subtle yet valuable opportunity for your product to connect with the user and differentiate itself.

Feedback can have its own rules too, including when to appear and how to change colors. These rules can become their own microinteractions, as users might want to adjust them manually as a setting.

From Feedback, we move into Loops & Modes.


4) Loops & Modes

The final elements of a microinteraction are the loops and modes that make up its meta rules.

A mode is a “fork in the rules.” Modes are mostly unwanted in microinteractions and should be used very rarely because they can add human errors. The primary reason to create a mode is when there is a rare action that could jumble and confuse the microinteraction’s main purpose. An example of this would be on a weather app — when you add a new city, you have switched from reviewing the weather in your current city to a new mode where you are adding an additional city to see data from. If you do use a mode, it’s helpful to move the mode to its own window/screen whenever possible.

A loop is cycle that repeats, usually for a set duration. The cycle can be short or long — microseconds, minutes, days, or years. Loops determine both the speed and the duration of the microinteraction.

Loops can be open or closed. An open loop does not respond to feedback; it will carry out the task and end. A closed loop has a feedback piece built in and will self-adjust based upon the feedback it receives.

What are some of your favorite microinteractions?

Date posted: May 3, 2016

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Metal Toad is an Advanced AWS Consulting Partner. Learn more about our AWS Managed Services

Have questions?