Flows are just as important to good interfaces as individual screens are. Customers don’t land on screens from out of nowhere. Specific sequences of actions lead customers through your app as they try to accomplish their tasks.
But as important as they are, flows are hard to communicate during the design process. Drawing out every state of a flow is too time-consuming. And drawings become instantly outdated as screens change. On the other extreme, flows written down into stories or paragraphs are hard to reference and they don’t easily decompose into checklists for design and review.
Working on 37signals Accounts has recently raised this issue of communicating flows for me. We have whole sets of flows that need to be properly designed, implemented, tested and retested. So I’ve scratched the itch with a simple shorthand.
Flows are made out of individual interactions. A screen offers some possibilities and the user chooses one. Then something happens, and the screen changes. It’s an ongoing conversation. Each moment in a flow is like a coin with two sides. The screen is showing something on one side, and the user is reacting on the other side. My flow diagrams illustrate this two-sided nature with a bar. Above the bar is what the user sees. Below the bar is what they do. An arrow connects the user’s action to a new screen with yet another action.
Here’s a simple and concrete example. To add a to-do item in Basecamp, first you go to a list. Then you click to “Add an item.” The form appears. You fill in the item content and submit the form, and if your submission is valid, the item appears and flashes yellow. Here’s a shorthand version of this flow:
The format is really fast to sketch, and it communicates the essentials of what needs to happen as I’m imagining it. For such simple examples, you don’t really need a shorthand. But for more complicated flows, especially of entirely undesigned sections of an app, the shorthand can illustrate a lot of behavior. Here’s a more complicated example for a log-in flow:
This log-in flow includes a few more notations. The dotted line separates alternate actions. There’s only one login screen, but there are multiple possible actions on that screen. The dotted appears above each additional action. Think of it as “or”. When there are multiple actions, the arrows point from an action to a new screen. Screens where the possible actions are uninteresting or out of scope simply have no bar below them. Like “Dashboard” in the diagram above.
You’ll also notice there are two arrows pointing out from “Submit email matching a user account” under the “Forgot password screen.” That’s because two different screens result from that action! You can think of the multiple arrows from an action as “and.” The updated login screen with “your email was sent” message is a result of that action, and the “forgot password email” is another result. Emails are screens because they participate in interface flows.
Here’s another complex flow. This one’s for sending and claiming invitations to create a user account:
Now don’t forget: all diagrams are destined for the garbage. The meaningful work is work that directly affects our customers in the form of screens they can see or code that functions. But we still need to communicate and manage our work along the way. This shorthand has met a bare minimum for me to get a flow out of my brain in order to move on to other things. I hope it’s useful for you too.
Good read on webdesignersdepot
Learn this equation. No leader + no documentation + no follow up = waste of time. Every meeting has to have a leader, a stated purpose, a start and end time, and a valid reason for each and every person to be there. The leader documents conclusions, plans, action items, whatever, then follows up.
Do you even know what you’re doing? Every leader should know how to run effective meetings, like how to set ground rules for constructive engagement, how to use tools like Parking Lots to take issues offline, and how to bring people to consensus.
Have them in the afternoon. I once read in a Scott Adams Dilbert book (no, I’m not kidding) that people do their best work in the morning, so you should have meetings in the afternoon. I asked my staff and they agreed unanimously. Turned out to be a great move. Also most people are more relaxed after lunch. Don’t ask me why.
Beware the hive mentality. I’ve worked with companies where executives were double and triple booked in meetings most days and managers were required to have weekly one-on-ones with their boss and staff (and monthly with peers). How in the world do CEOs expects their management teams to get anything done that way?
Lose the hallway meetings. Founders and other start-up executives are often fond of ad-hoc hallway meetings. The problem is that decisions are made without input from key stakeholders. Sometimes that’s a smokescreen for passive-aggressive behavior. Other times it results in strategy du jour. Either way, it destroys organizational effectiveness.
Challenge the status quo. If you run a periodic staff meeting, occasionally ask your team what you can do to improve it and help make them more effective. You’ll usually get at least one good suggestion. Not only that, but your folks will appreciate it.
Cool article on the Verge:
Gradual engagement encourages visitors to become users immediately. Rather than presenting users with information about the product, it enables them to use the product right away, without signing in and without creating an account …at least not until they have had a chance to use the product and add some of their own data!
This process may not be right for all applications, but it is worth considering for yours.
I was able to sit-in on my first usability test about a week ago. It was for the redesign of Discover Cards home page.
The testing took place in Chicago, so I had to call in and watch on my screen here in NYC. We shared screens with the user in order to view their actions and behaviors. There were about 4 testers on the first day, but I was only able to catch 2. Each were given different styles of the Discover Card home page, and each were asked questions by the moderator:
– “If you had to refute a charge, where would you look?”
– “Is the information provided to you helpful?”
– “What would you rather see in this section?”
These were the types of questions asked.
It’s interesting how different people think, and how experiences affect their behavior. It definitely is a good way to burst the bubble that builds around you when working on a project for so long. I also noticed that everyone loves to play “designer”. Each tester had their own feedback of what they would change and as they grew more and more comfortable in the session, would become more specific with changes they would like to see.
As each tester left, we ended with an internal conversation on making specific changes based on the user feedback, and it was back to the drawing board in order to get wireframes updated for Day 2 of testing.