Motion is Meaning
Interface designs are too often based on static presentations before going into development. A model which is ill-suited for the reality of how interfaces work. When we rely on static elements to depict change, and we don’t take into account the transitions between them. Users often get mentally staggered and have to detach themselves from the task at hand to re-orient themselves with what’s happening in the interface itself. Things like spatial relations, gestural user actions and the rhythm of time get lost in these static environments impacting usability.
So in a design world fascinated with human-centered design why are we so often validating design decisions in an environment where humans struggle to perceive change?
Human Perception is Heavily Contingent on Motion
Humans have a very visual processing system. Sure, sound and touch are an important part of multi-modal design. But visual intake processes a bulk of the information provided by our digital devices. Motion provides the user visual cues to handle content change and spatial association. When focused on a task or workflow, users are extra sensitive to very small details associated within objects around the tasks at hand. Change to objects distant from those focal tasks often go unnoticed when happening in the peripheral background.
In Figure 1.1 below, we’re tasking a user to create a custom group of people from an extensive contact list. After selecting a user it’s not immediately obvious where the change happened.
When a user is focused on the task of adding users it’s not immediately evident that they were added to the header in a static presentation.
Our peripheral vision is sensitive to movement. The edges of the human retina is primed to detect background movement sending a signal jerk to our eyes in that direction. So a visual change to the interface which is seemingly disconnected from the task at hand is always going to be easier to visually track for the user if it’s done in natural motion rather than a comic book strip style display of static presentations [Figure 1.2].
Animation lowers the cognitive load between screens and mitigates the user relying on their interpretations of cause and effect. When showing a static representation of one screen, and the following screen with similar elements moved, users are left to infer assumptions on what the cause and effect were between the two screens. This relies on a lot of cognitive processes for the user to constantly be tracking, and draw speculative inferences around the components between the two screens.
Let’s turn to everyone’s favorite pub game Photohunt, which feeds off of this exact difficulty in human perception. When examining two similar screens side-by-side, users are naturally dissecting the screen down and quickly comparing the two micro-segments asking themselves, “Is this different? No? Okay, is this different? No? Okay…” and so on.
Offloading the ambiguity of relation from one screen element to another reduces cognitive load and increases the perceived speed of relation. If we can visually articulate the explicit relationship between two items on a screen, thats more time users can spend on deciding what they want to do next with the task at hand and less on, Wait, what just happened?
Designing with motion allows users to track where they are to where they want to be. It adds critical context to seemingly disconnected items. It’s ironic that a game where it’s intentionally difficult for users to perceive relation is the very format we so often use to communicate design flows.
Motion Defines Change
We use motion to communicate location dependent objects that exist behind, in front of, or adjacent to other objects. Motion is directional and leaves a mental “breadcrumb” of clues as to how the user arrived at a particular view.
Again, Figure 2.1 below is an example of two static presentations as the result of a gestural tap.
These screens alone can’t articulate expectation — in the sense of what these objects are or how they behave. Motion allows the designer to narrate relation between the two screens and sets the expectation of future actions.
The use of animation in Figure 2.2 allows the user to see specific movements within UI components upon a particular action. Not only will the user be able to more easily depict relation between these screens, but they can infer what will happen next based on equal and opposite reactions (ie: where the close icon will lead to). Motion supports wayfinding for the user and articulates the navigational structure in a way that static prototypes can’t.
Motion in Your Design System
Motion is more than making things move. It’s a tool for tying together an ecosystem of components which users manipulate through a variety of input types.
The use of animation should enrich information on the page and bring context to the transition of a users action. Once we’ve started noticing patterns it’s important to document these patterns, build guidelines around them, and implement them within our design system amongst all of the other design patterns we use in our design repository.
But just because an animation brings some value to the screen, it ultimately doesn’t mean its always worth implementing. Consider whether its meaningful motion or an entertaining one. A simple prioritization matrix can help your team justify if it’s worth the level of effort to implement these animations into your product or design system.
Ease of Effort — Timing, Costs, Risk
Impact — Value, Necessity, Pattern Support
- Quick Wins: High impact across a lot of patterns or components within your product or design system with a low level of effort. Typically this could include a simple navigational motion feature which is used heavily all across the product but its a relatively simple animation to create.
- Major Projects: Animations that will touch many areas of the product but require a lot of developers to plan and execute, typically due to complexity or technology constraints.
- Fill Ins: These are pet projects that are great to keep in the backlog or parking lot for pockets of downtime but don’t warrant a lot of value within the system overall.
- Hard Logs: Both difficult to implement and a bit of a hopeless cause. While they may have been fun to prototype, its ultimately, as Ed Catmull has accurately portrayed, a beautifully shaded penny.