As UX Designers, we put care and critical thought in our projects. Every interaction is planted with a specific purpose for the user. This is why it makes it that much more painful for us when the final developed interface does not align with our original vision.

It’s easy to blame the developer, but I’d argue that the onus is on us to improve documentation in the designer/developer handoff. It’s not that the developer is incompetent or that she lacks common sense. When the design comps lack a clear explanation of what happens when X occurs, the developer has to … well, try to make it up as they go. It would kill momentum to stop development, send an email to the designer to ask about a certain interaction, wait, respond to clarify her question, wait, then finally get an answer.

Illustration by Havana Nguyen

We, as interaction designers, have to explain the behavior of the interface … but how? I searched for various ways to bridge this communication gap. I tried creating user flows, annotated wireframes, and logic trees … but they all fell short of conveying the ideas in my head.

I then started developing Interaction (IX) Flows.

Where the idea for IX Flows came from

Dan Saffer’s “Microinteractions”

Dan Saffer’s “Microinteractions” book has to be one of the best books I’ve read on interaction design yet. Though short, it is dense with great information. He breaks down microinteractions into 4 elements: the trigger, feedback, rules, and loops/modes. To [over]simplify:

Triggers: the user-initiated or system-initiated action that starts the microinteraction (Example: a submit button, a light switch)

Rules: the capabilities and constraints in the microinteraction; what can and cannot be done in a microinteraction (Example: a date picker for an airline allows you to select departure and returns dates but neither date can be in the past)

Feedback: the visual cues that tell the user what is happening (Example: a red warning icon appears when the user’s password is incorrect, the flash on the screen when a user takes a screenshot, the dwindling character count as you type out your tweet)

Loops: the repeatability and lifecycle of a microinteraction (Example: a software update modal will pop up whenever your device detects that a new update is available)

Modes: the different versions or states of an element (Example: a read-only mode versus an edit-mode)

Nielsen and Norman Group: Wireflows

I also just happened to run across this article on Nielsen and Norman on Wireflows, which argued for the fusion of user/task flows and wireframes. While they show processes and relationships in a simple way, user flows don’t show how the visual elements provide entry points into each page or how they facilitate the user’s goals. Wireframes are great for laying out those visual elements, but by themselves, they are not very descriptive of the relationship or flow between pages.