Anxiety flow: Anxiety flow is the result of mistrust and lack of context. Navigating to the front end of the site to double check a post after publishing is an example of anxiety flow. As is checking your destination before and after publishing when you run multiple sites in a multisite environment. Publishing to the wrong site can be embarrassing and leak private information, especially when automatically publicizing your posts to social networks. Context, progress indication, and good notifications can prevent anxiety flow. #

Boxed input scrolling: Boxed input scrolling is when you can’t move the cursor through text lying beyond the confines of an input box. This sometimes happens on iOS devices, particularly in the post title and caption inputs. #

Broken flow: Broken flows are “places where the transition between touchpoints, or through a specific interaction on a site (like a form), isn’t working correctly.” — Design for Real Life #

Content gap: Content gaps are “places where a user needs a specific piece of content, but you don’t have it—or it’s not in the right place at the right time.” — Design for Real Life #

Continuous empathy: Using and reporting on interfaces that aren’t being maintained and are scheduled for later replacement because our users are still stuck with them. #

Desktop bias: Patterns and interfaces that work in desktop interfaces don’t always work on mobile. UI elements triggered by mouse hover, opening in new windows, dragging into bookmarks bars, drag-and-drop, and auto-focusing search input fields are examples of desktop bias. #

Flow: Flow is the path of screens and interactions taken to accomplish a task. It’s an experience vector. Flow is also a feeling. It’s being unselfconscious and in the zone. Flow is what happens when difficulties are removed and you are freed to pursue an activity without forming intentions. You just do it.

Flow is the actual user experience, in many ways. If you like, you can think of flow as a really comprehensive set of user stories. When you think about user flow, you’re thinking about exactly how a user will perform the tasks allowed by your product.

Flow and Context


Flow comparison: When an existing feature changes or is replaced, a flow comparison visual record is made to compare flow through the old interface with flow through the new interface. Seeing two flows side-by-side helps determine whether the new interface actually flows better. #

Flow Empathy: Empathizing with a flow even though you don’t use it. Put yourself in another’s flow and try to appreciate it. Offering user anecdotes (and documenting them with visual records) can help others empathize with your flow. #

Flow patrol: Flow patrol is the regular exercise and monitoring of important flows. Issues found while on flow patrol are kibbled and ticketed. Continuous flow patrol encourages use of our own software and increases awareness of what our users are experiencing day to day. Flow patrol duties are outlined in the flow handbook. #

Flow scrub: Flow scrubs are much like bug scrubs. We gather in a chat channel and give full attention to a particular flow for half an hour to an hour. Bugs are documented and fixed. UX improvements are discussed and implemented. Every screen in the flow is studied. Flow scrubs should aim to improve a flow in some way by the end of the scrub. #

Forked flow: Opening in new windows/tabs forks flow, particularly on phones. Phones don’t display tabs the way desktop browsers do. Phones hide tabs beneath a tab switcher button. Tapping the tab switcher brings up a stack of tabs. Opening in new windows in mobile can result in a lot of discarded tabs, making it hard to find the parent window of your current session. Each of these windows is a fork, a side quest split from the main quest. The original window goes on to the stack of discarded windows, and the new window becomes the questing venue until the next fork. Open in new window is particularly bad with post preview. Tapping preview in the post editor opens a preview of the post in a new window. That window takes over the screen and the parent session that launched the preview is now out of sight. Going back to the parent session requires tapping the tab switcher and finding the parent session in the stack of windows, not always easy when you have a bunch of forks lying around. Back in the parent editing session, if you tap preview again the button seems to do nothing. The preview window that was opened last time you clicked preview is being refreshed, but you can’t see it because that window is out of sight.

Forking flow by opening in new windows is often the result of unresolved desktop bias. Opening in new windows is a common desktop pattern that doesn’t work well on mobile.

Forked flow is also the result of laziness. Hooking up flow is hard, and forking flow with a new window is a convenient workaround on desktops. #

Keyboard flyup: Keyboard flyup is the unexpected display of the keyboard on touch devices. Keyboard flyup is often triggered by auto-focused search fields. Auto-focusing search fields in modals is recommended practice on desktop, but on mobile it is an example of desktop bias. When search fields are auto-focused on touch devices, the keyboard flies up when the modal opens. This obscures the modal and usually results in the user making an extra tap to dismiss the keyboard. Keyboard flyup is also caused by rogue cursors. #

Kibbling: Kibbling is the process of dogfooding a flow and publishing visual records and narratives of that dogfooding. The make/flow blog is an example of a kibbling blog. Since we are publishing these “kibbles” with the software we are dogfooding, the act of kibbling further dogfoods the software. Kibbling encourages more dogfooding which encourages more kibbling and so on. #

Mobile abandonment: Bugs that terminally block flow on mobile cause mobile abandonment. Users must do a huge context switch from mobile to desktop to resume flow, which usually means postponing an action until the next time a laptop is available. #

Pain point: Pain points are “places where you know from research or analytics that users are currently getting hung up and have to ask questions, or are likely to abandon the site or app.” — Design for Real Life #

Rogue cursor: Rogue cursors can show up in input fields, buttons, and notificiations, particularly after an action such as saving or publishing. Rogue cursors are often in the company of keyboard flyup. #

Scroll bleed: Sometimes when scrolling a modal such as the media modal on touch devices, the scrolling bleeds through to the page beneath the modal. Instead of scrolling the modal, the page beneath scrolls. Sometimes the scrolling nests and sometimes the page beneath grabs scrolling all for itself. Android doesn’t usually have this problem, but iOS triggers it often. #

Stress case: Stress cases are “moments that put our design and content choices to the test of real life.” Related: Anxiety flow

But making digital products friendly isn’t enough to make them feel human.

Real life is complicated. It’s full of joy and excitement, sure, but also stress, anxiety, fear, shame, and crisis. We might experience harassment or abuse, lose a loved one, become chronically ill, get into an accident, have a financial emergency, or simply be vulnerable for not fitting into society’s expectations.

None of these circumstances is ideal, but all of them are part of life—and, odds are, your site or product has plenty of users in these moments, whether you’ve ever thought about them or not.

Our industry tends to call these edge cases—things that affect an insignificant number of users. But the term itself is telling, as information designer and programmer Evan Hensleigh puts it: “Edge cases define the boundaries of who [and] what you care about” ( They demarcate the border between the people you’re willing to help and the ones you’re comfortable marginalizing.

That’s why we’ve chosen to look at these not as edge cases, but as stress cases: the moments that put our design and content choices to the test of real life.

It’s a test we haven’t passed yet. When faced with users in distress or crisis, too many of the experiences we build fall apart in ways large and small.

Instead of treating stress situations as fringe concerns, it’s time we move them to the center of our conversations—to start with our most vulnerable, distracted, and stressed-out users, and then work our way outward. The reasoning is simple: when we
make things for people at their worst, they’ll work that much better when people are at their best.

Design for Real Life #

Tap bleed: Sometimes when tapping in a modal such as the media modal on touch devices, the tap bleeds through to the page beneath the modal, actuating underlying UI elements. #

Threshold friction: Threshold friction is bad flow across a threshold such as log in. Trouble when crossing a threshold is frustrating. #

User anecdote (flow narrative): To document flow and encourage flow empathy, offer anecdotes of your flows and experiences. Offer your opinions and project your point of view in your anecdotes. Your experience is a valuable data point. For example:

Many people like to print recipes, including myself (@ryan). Printing recipes may seem old school to some, but I started doing it again after years of using tablets and food apps. Paper works in the kitchen. My family pins recipe print outs on a board in the kitchen and revise and annotate as we iterate on a dish or adapt it to a new piece of equipment. Occasionally, I snap photos of the paper, add them to a folder on my universal camera roll service, and call that backup. Empathize with old school, and always empathize with the love of print.

When experiencing a theme that doesn’t provide print-styles.css, remember this anecdote. Core bundled themes should always empathize with print.

Please share anecdotes and narratives in #core-flow and on make/flow. Anecdotes are even more powerful when accompanied by a visual record. #

Visual history: A visual history shows the evolution of an interface over time and across releases. #

Visual oxygen (vizox): If communication is oxygen, then communicating with screenshots and visual records is Visual Oxygen. Communicating with screenshots makes development more accessible. #

Visual record (vizrec): Visual records are storyboards of flow. They can be a screencast or a series of screenshots presented as a captioned gallery. Visual records document a particular experience vector and capture what someone is actually seeing. They capture what a flow looks like on a particular device with a particular browser and a particular set of plugins/extensions. There are usually many flows for accomplishing a given task. Visual records of the real flows of real people enumerate which flows are being used and reveal the difficulties and workarounds that spawned and directed those flows.

Example visual record: #

Visual survey: A visual survey is a collection of screenshots for a like set of screens or interfaces, such as all list table screens or all toolbar incarnations across various devices. These screens are not presented in the context of a particular flow. #

Windmill: Adapted from Don Quixote, a windmill in the context used on make/flow is a long term goal or vision that you never stop pursuing while attempting to gradually, steadily change a system. Actions taken toward a windmill’s goal are called tilts. Tilts over time steer change. The Flow Patrol windmills are listed here.