Information Architecture

Is this not the most pathetic page on information architecture you've ever seen from a self-identifying Information Architect?

Process Mapping

A process map tells me how a user moves through the system. I've also seen them called by the name flow chart and task flow. They're boxes and arrows.

How to Build a Task Flow by Laura Klein covers the basics of building a process map. She hits the basics but essentially allows you to draw any arrow out of any location and do anything with it and AAAUGH OH MY GOD NO.

Especially as an Information Architected. Physical. Pain.

So okay, read Laura's post and then also read (or listen to) the User States episode of What is Wrong with UX and the come back here and we'll talk disciplined structure.

You back? Ok.

As Laura showed in her examples, a good process map shows the system at a specific level of complexity. She tells you that her initial diagram (which shows a start state, a single task of "add to list" and an end state) isn't done...and she's right, if the diagram's point is to illustrate the complexity of adding a song to a playlist. On the other hand, it is valid if for some reason you were talking at that level of the system. In other words, don't get caught up too much on whether you've captured every step in the diagram. Just like every diagram that you'll do, the point is to make [something] clear about the system, whether that's its behavior, its complexity, the way it bounces around, or just to draw a picture of what it does.

In other words, know your audience.

Next, the shapes. If you open Visio or Omnigraffle or any number of other diagramming tools they're all going to show you roughly the same shapes because flow charting and process mapping has been roughly standardized over the years. Some colleges still teach this stuff, though Lord knows they didn't cover it in any of my classes.

A rectangle is a step. This is a Thing That Happens. Depending on your document it might be a high-level step like Add to List, or a lower-level step like Select Songs to Add. In general I write my process maps from the user's standpoint so mine say things like Log On, Navigate to Balances and Holdings, Select Account... they don't say Repaint Screen, Display Navigation Menu, Display Balances and Holdings, etc. because those are system actions.

If in a specific situation I actually do need to show a system action I'll add "System" to the front of it, i.e. "System calculates current price and displays it". I try to avoid doing that but sometimes it helps the development team to know that hey, they have to have this data by this point.

A step can have as many arrows are necessary to start it. If eight other steps on the diagram all lead to the current step, eight arrows go in. (I like applications that stack the lines so it looks like only one arrow is going in. Makes it easier to read.)

Now for some pedantry: arrows can only go in to steps from the left side of the step or the top of the step. This forces your diagram to flow from top left to bottom right. Why does that matter? Because (here in the United States at least), the vast majority of readers read from left-to-right and top-to-bottom. They also interpret comics and other sequential art that way. Whether you want them to or not, it's the way they're going to try to interpret your process map... so make life easier on everyone and build your diagrams top-left to bottom-right consistently by only allowing incoming arrows in the top and left of the steps.

Similarly, an arrow can only come out of the bottom or right sides of the step. Note that I said an arrow. If it's a step, it can only go forward to one other step.

I've had a lot of people argue with me on that one. They'll say things like "But when the user hits submit something goes to the server and an email goes out at the same time" and I say "nope, try again" because computers don't actually parallel process like that. (Ok sometimes they do, but for the purposes of our diagrams they don't."

A huge number of weird error states that we catch in our diagrams happen in those spots where people swear that two things happen at the same time. "They both happen at the same time? So if the server returns an error that says it can't process the transaction did you still send the email to the user telling them it was a successful sale? No? Then the email's actually dependent on the server response huh? ..."

Sometimes this does make your diagrams harder to draw. I'm sorry.

On the other hand, this does make you think more like a computer. I'm sorry.

Computers don't just think in straight lines, though. The power of a computer is the ability to make logic-based decisions. So we need a logic shape, and for that we use a diamond.

Here's my pedantry again: whatever question you put in the diamond should be a yes/no question because those are the only two labels you can use on the two arrows (and exactly two arrows) coming out of the shape.

Why so strict? Well, two reasons.

First, it makes me really think about what conditions move the user through the system. I can't fall back to "What color do you like?" and have arrows for "Green" and "Pink" and "Yellow" and all these other things there. I have to think like the computer does "Did you choose green? No, OK well did you chose pink? No? Then you must have chosen yellow." Breaking down the logic to that level can help you do everything from decide what kind of interface elements you're going to use to how to break up the page content. ("Did you choose green? Yes? and did you choose pink after that? Yes? OK then we're going to need checkboxes and not radio buttons because the user can make multiple choices.")

The second reason is because it makes the diagram SO. MUCH. EASIER. TO. READ. Seriously, you take one shape and twist eight lines out of it and send them all in different directions it's almost impossible to ensure that your labels are readable and your flow understandable. If you stack eight yes/no questions, though, each of those questions has an established "lane" of space, and the labels are always either "yes" or "no" so even in the worst of diagrams space is not an issue.

Speaking of diagram neatness, your "yes" arrow is always going to come out of the right corner of the diamond, and your no arrow is going to come out of the bottom. Why? Because this usually puts your happy path in the top row of shapes! This means when you're explaining the diagram to other people you can start with "in the best case..." and rattle through that top row and everyone's like "ooooh ok so I get what we're trying to do!"

Then you go back and show them all those edge cases and weird bits and error states and alternate flows which are tucked below the happy path (and which your astute team members are already eyeing up warily) so that they understand the complexity of what happens if something goes wrong.

So that's rectangles, diamonds, and arrows, which leaves us with circles.

A circle is generally a start or end shape. (I prefer to use an oval and write "start" or "end" in it, but if I see a circle I know what it means.)

A circle can also be a jump point. Let's say you have a step near the beginning that other steps may come back to if something specific happens. For example, you have a process that's got a hub of choices coming off of it and the user could keep going back to that hub multiple times. Alternatively, you've got two branches of a process that are both going to end with the same 10 steps, but with a lot of very different steps in the middle. In either situation, having long arrows that run backward to the previous step can make the diagram a mess. Instead, create a circle, label it A, and then create a step where you need it that says "Go to A". Do this for each time you need to go backward or return to something far away, so that you have jump points of A, B, C, etc.

Laura's diagram showed a step with two bars on it to identify a module that, presumably, she breaks down on another page or another spot on the page like an inset on a paper map. Sometimes I'll do those, and sometimes I'll use jump points to accomplish the same thing.

Visio and Omnigraffle and the like also come with sometimes-prelabelled things like a cylander to display a database or a rhombus for input/output mechanisms... but we're talking user process flows, not the detailed engineering process flows that our developer friends might do. (And TBQH most of the ones I know weren't taught either one!)

So keep it simple. Start, steps, decisions, end. Emphasize making it easy to read. Emphasize displaying the information the users are looking for, even if it means you don't diagram the whole system.

And then when you get good at that, that's when you can start fiddling around with the rules.

Additional Resources

Information Architecture: The Structure Behind Your User Interface by Nathaniel Davis on UX Matters