This a transcript of the UIE Podcast "Escaping Navigation Hell with Hagan Rivers" available at This podcast is brought to you by The UIE Web App Masters Tour, an inspiring, intensive two days with today's leading web app designers. Coming to San Diego, Minneapolis, Philadelphia and Seattle. See the Master, Topics and Dates at http://UIETour.com --- Jared Spool: Hello, everyone. Welcome to another episode of the SpoolCast. I'm very happy today, I'm talking with Hagan Rivers, who is from Two Rivers Consulting. She's a fabulous designer, particularly when it comes to web-based applications. You probably don't know this. Well, Hagan, you know this, but everybody else probably doesn't know this, which is that you've been around since the beginning of the Netscape days, very early, version 1.0 Netscape browser and things like that, right? Hagan Rivers: That's right, in all its glory. Jared: Yeah, yeah. And you're now still out there doing very cool stuff with web-based design. You're going to be speaking at our upcoming UIE Web App Masters Tour. You are one of our masters, which I think is an apt title. Welcome. Hagan: Well, thank you. It's good to be here. Jared: Now, I wanted to talk to you about something, because I was reading some of the materials you were giving us to prepare for the Web App Masters Tour, and in the materials, you made an interesting statement. And the statement was that navigation is its own application. And that's really an interesting idea. Where did that come from? Hagan: Well, it started a few years ago. I would be working on relatively complicated applications, and I found a lot of our design discussions would get really mired in the navigation. And the problem was, because we hadn't fully worked out what was on each screen, we were kind of co-designing two things in parallel: how to get to the screens and what would be on the screens. And the two kind of affect one another, and so it was really hard to design these two similar objects at the same time. And so what I started doing was just leaving this big, gray block at the top of the screen that says, "Navigation goes here. Let's focus on the screen." And once I did that, I found it got a lot easier to concentrate on what goes on each and every screen and to think about the contents of those screens and what the user will accomplish on those screens. And we didn't worry about how did they get there, or would there be a pop-up window, or replace the previous window. We didn't even worry about any of that. And then, when all the screens were done, we would go back and do the navigation system. And it actually was a lot easier to design the navigation system at that point, because we'd already worked out the screens, we knew the best work flow, and the navigation system just really became the mechanism for getting the user to the right screen and to start that process. So it kind of happened accidentally. We just sort of stumbled upon it, because we were working with really complicated applications, and doing the two together was just really painful. Jared: That's interesting, because I think a lot of designers sort of start with that navigation, because they're trying to figure out, on a given screen, where I was coming from and where I'm going to, and how am I going to convince the person to go there and what happens if they want to go back. So you have all these questions about navigation that pop up. How do you not have all those questions about navigation pop up at that very beginning stage? Hagan: [laughs] Right. So the questions definitely come up, for me, as I'm doing the design work. And usually, I make a note of them. I kind of keep track of the issues as they happen. So I'll be working on a screen and I'll say, "Boy, the users probably want to get to this screen after having completed these three other things." So I'll make a note of that. But when I go to client meetings and we sit down to really review the design, I say, "Let's just not talk about how we got here. Let's assume that we got here perfectly, that the user absolutely found this screen correctly, and let's assume we get that right." And that was relieving, because then we could just talk about the screen, and then we would go back and figure out what the perfect system was. So, when I say design navigation as a separate app, it's not that I'm not thinking about it. It's just that I don't try to design it at the same time as the screens. As I build the screens, I'm building requirements for the application that is the navigation system. Jared: I guess I'm still a little stuck on this, right? Because if I was designing a house, I couldn't design the rooms without thinking where the doors would go. Hagan: Yeah. I'm not sure it's a good analogy, navigation systems and doors. [laughs] Jared: [laughs] But that's how people think about navigation, right? They think about every screen as its sort of own room, and we're moving from room to room to room. So what you're basically saying is think about the purpose of the room, think about what the user's function is going to be, and then figure out what order the room should be in and how you're going to get them from one room to the next. Hagan: Yeah. I often find, in design, it's often easy to start at the bottom level screens of an application. I never want to start with the home page because it's the most controversial, and what will be on it will depend a lot on what's underneath it. So I start at the bottom. And it's like that. I'll define a room in a house. I'll say, "This is the kitchen. And I want the layout of the kitchen to be like this." And that will suggest, at the end, that there's really only two good places for a door into the kitchen. Maybe with a little work, I can get three. And so, if I start at the bottom like that and I get each room perfect. I'm not saying I'd make a very good architect. [laughs] But that's sort of the analogy for what I do with the apps. I know, it's different. Jared: It is, it is. But it reminds me of some stuff. Years and years and years ago, I got a chance to work with Disney on some stuff in Epcot, and I got to sort of absorb a bit about the way they think about things. When they're doing rides, they're thinking about the story that they're telling, but they're not really thinking about how the ride is going to move through the structure. That comes much later. Their initial thoughts are similar. Even though you could think of the haunted house at Disney World as a series of rooms, the structure of those rooms actually comes much later. What comes first is what is the story that the visitor's going to have. And they, too, sort of start in random places and then start to plug things together. They don't start at the front door. Hagan: Right. Right. And I find that that's true. A lot of times, there's stuff you really already know about your app. So you're building an application to manage purchase orders. Well, you're going to have a list of purchase orders. You know that. So you can go ahead and build out that screen. What's the list going to look like? What kind of views will you have? What kind of filters? What kind of controls? You know that there'll be an "add a purchase order" screen and an "edit purchase order" screen. You can make all those screens and have a pretty good idea of what's on them without ever looking or thinking about what the navigation system will be. Part of the thing in design is to get yourself some momentum. Get the screens you're comfortable with and get moving on those and then start fleshing out the screens you're less comfortable with. And the navigation, I find, if you try to work on it too early, it can just kill your design momentum, because you suddenly are locked into looking at the big picture and the whole process and how you move around, and those things can be overwhelming early on in the process. Jared: I get this. This makes a lot of sense to me. And one of the things is, I was working with a company on a checkout process. And so a checkout process has the sort of standard elements of, first, you have to put in your shipping address. This was a gift-delivery thing, so you have to put in the delivery address for the person who you're shipping the stuff to, right? Because it's probably not you. Then you put in your billing address, and maybe there's a couple of up-sell items in there somewhere, and then you put in your payment information. And you have to put in a message for a gift card in there somewhere, right? So there's all this stuff. And you get to this confirmation page. And the confirmation page is gorgeous, and it has everything all laid out. And one of the problems was that the first step in the process was the shipping stuff, and if you got to the confirmation page and you realized, "Ooh, I got their name wrong, " or "I put in the wrong address," you press the edit button on that, you now actually have to walk through the whole sequence again. It's not just go to edit the shipping and then come back to this confirmation page. Because of the way they lock themselves into their design, they got stuck. Hagan: Right, and that happens a lot. You know, the navigation system becomes this structure that you feel like you have to shoehorn into. And so the neat thing about doing it as a separate design, as a separate application - I mean, I really think about navigation as a separate application - is that I can develop my own set of requirements for the application and I can create multiple designs. And I can usability test them, I can prototype them, I can sit them down in front of users, I can show them to the team. We can go back and forth on just the navigation. I give it its own application design process. Jared: I mean, that makes sense. In that scenario I pointed out, the gift thing, so would you have started with that confirmation page? And say, "OK, this is where everything's going to show up. I'm going to design this first." Hagan: Right, exactly. I'd have made each screen along the way, with no navigation, and the confirmation screen is key, because that's a point where you're going to want... The users are going to move forward, so that's not a big deal, the design, everybody has a pretty good idea of what that navigation might look like. But the last one is a place where you move backwards. So you want to leave off the navigation there and figure out what's the right way to move back and then once you get your requirements together -"Well, I need to be able to go back to page one, but I want to then return to the final page" - you get all those requirements together and then you build the navigation application. Jared: Interesting. OK. Hagan: [laughing] I think of it as like the little mini app within the app, and the job of that app is to get the user to the right screen. Jared: So, I mean, this is a really sort of radical way to think about it. When you're working with clients on this, do you get some amount of resistance initially? Hagan: Yeah, they really don't like the big gray box that says, "Navigation goes here." They really want to talk about it a lot. And so sometimes we do. We'll have a whole meeting where we just talk about... They've got ideas and they want to share those ideas. And we'll go through those meetings and I'll get those ideas down and record them. But again, I tell them, "We need to wait on this a little bit longer." And, you know, slowly they begin to see that they're not ready to design the navigation system. We have those meetings and they're contentious because we haven't worked out yet what's on these screens. And so, you know, over time they realize it's just not going to happen. And so we get toward the end of the process and then we start designing navigation, and they're always surprised at how easy it is and how quickly it comes at that point. It's like, "Well, we know the screens are really wide, they've got big, wide tables on them, and so left-hand navigation is just out. It's just not a possibility." So, we could have wasted weeks trying to design a left-hand navigation system before realizing it was never going to fit on this application. So that's what I mean about getting the requirements first and then building the app. Jared: That's really cool. And when you've done this and it's worked really well, do you feel like it's actually saving you design time? Hagan: Absolutely. Definitely. It's stunning to me how fast navigation goes, what a huge time sink it is if I try to do navigation early, and how quickly it goes when I do it at the end. I definitely save time. Jared: So as its own app, does it then get its own sort of design deliverables and design documents, or do you integrate those at the end? Do you end up putting together, for instance, some sort of 'rules of the road' document that tells you how navigation works for future enhancements and things like that? Hagan: Right, so the neat thing is you'll have your screens already. So let's say you've got your navigation, you're working on that, and you've got maybe three different designs for it that you're considering. And you've already figured out what the 'add a purchase order' screen looks like, so in each one of those cases, you can put the 'add a purchase order' screen, and plug it right in as a screenshot, into whatever your navigation system is that you're prototyping, and so you get to explore these. It gets its own design process, its own requirements document, all that stuff, and the earlier work you've done on making the screens just plugs in. And then when you're done, yeah, you create a separate user interface document that describes/specifies how the navigation system actually works and how it plugs into the rest of the app. Now, I do want to say though even though I'm designing it as a separate app, it's never really separate from the rest of the application. They are obviously interweaved. Navigation elements always appear sprinkled on pages and you know, where you go to will be affected by the navigation system and vice versa. And so you have to always design the navigation system with the rest of the screens deeply in mind, and you're going to be inserting little bits and pieces here and there. But it's still something you can design as its own freestanding thing. Jared: Now, one of the things that I see the teams that we work with run into is that they fall into this trap of starting with their data structures and designing the navigation. I mean, you mentioned, "Well, I got a purchase order and now I'm going to have to edit a purchase order. I'm going to have create a purchase order and then I'm going to have to delete a purchase order." So they just start with that as sort of their navigational structure, which works fine for simple applications, but when you have very complex data structures, you know, you've got a lot of tables that are linked in unusual unions and joins, and the next thing you know, you've got this really intricate thing. We've got users and we've got groups, and we want to add users to the groups, and we want to operate on the groups but we also want to operate on the users. How do we configure all these different things in our admin application? Does this structure simplify that by separating out the navigation separate? Hagan: Yes, it does. The nice thing about it, when applications get more complicated, what you end up doing is building sort of layers of navigation systems. So you might have a navigation system to help the user get to the right module within your gigantic application that you're working on, and then within that module, there might be 20 or 30 key centers or areas that the user needs to get to, and that might be a totally different navigation system layered underneath. So you might have at the initial level a single screen to pick a module with links on it, and the second level might be tabbed menus, and then as you get further down into the app, you might start seeing buttons or menus in place sprinkled around on the screen. So what you have to do in complicated apps is break it into these layers and that's exactly one of the things I'm going to talk about on the tours. How do you take this gigantic list of screens and start turning it into something that you can make sense out of? Jared: So when you're talking about layers, you're not necessarily talking about just magical Ajax light box effects, you're talking about logical layers, right? Hagan: That's right, that's right. And I think, that's something... You were mentioning the idea of these complicated apps with lots of different data structures. So one mistake that's really common is to build a navigation system that's a perfect reflection of the data structure. There's a list for each and every table that's available, and you have an add, edit and delete command for each and every table. The result is that in order to complete one task the user has to visit five tables and issue different commands at each table, and that gets the task done. That's exactly a kind of logic flaw with a navigation system, that it's not actually supporting the way the user thinks. It's supporting the way the application's built. Part of figuring out the logic of a navigation system is making sure you know your users, through all the usual mechanisms for that, and how they think about the application. Then the navigation system needs to reflect. It has to be a doorway in between the way they think and the way the application's built. It has to do this massive translation. So if the user says, "I need to start the purchase order approval process, " the navigation system can say, "Well, that means you're going to have to visit these screens, and you're going to have to do them in this order. I'll help you do all of that." Working through that logic, that's definitely the hard part. But, again, if you design the screens first, you're not going to want to make the user go to four database lists and say add in each one. Instead you're going to design some new screen or a wizard, that is, start the purchase approval process. So you'll solve that little train in the screen level. Then when it comes time to build the navigation system for it, you can say, "Well, we made a wizard for that issue. One command, we're done." Whereas if you had tried to build the navigation system first, you get really wrapped up in maybe we visit six screens in order, or maybe it's a wizard. We don't really know yet. Jared: So you're basically letting the meat of this thing create its own navigation system after the fact. Hagan: Yes. Jared: But doesn't that potentially open the door for some real cruft in terms of if you design the screens wrong, you end up with a potential navigation that could be much more hellish than if you'd started out at the beginning? Hagan: Right. You're never going to escape going and talking to the users. The nice thing about having them separate though is you can test your screens. You can test that one little process in front of the users as a quick prototype without having to worry about how they got there. Just do the "add a purchase order" process and see, did that work? If it doesn't, you can say, "Well, maybe the wizard's not the right approach. Maybe we need this different...?" I don't know. My example's kind of wearing thin here. Jared: No, no. I think I'm getting it. There's this notion of natural paths. There's an old philosophy in architecture about the apocryphal story that has to do with buildings in a campus. What you do is you don't pave any of the grass areas between the buildings when you put in a new area of the university campus. You don't pave any of the grass areas. You just wait for the grass to wear out, and that tells you where you should have paved. Hagan: That's right. That's a great analogy. Jared: The idea of paving over the used paths is sort of what you're talking about here. I could imagine taking a bunch of done screens to my potential users, maybe on paper or in some sort of mockup form, and actually talking to them about, "OK, let's create a purchase order, " and almost collaborating with them to see in what order things want to pop up for them. Hagan: Right, right. Because you don't have the navigation system in front of you, you're not being led by it. You've just got the raw screens. You know, sooner or later, to make a purchase order you have to collect certain information. No matter how the user got there, you know you have to collect. It's a bunch of forms to fill in. In what way does the user think about that? How do they get to those screens? What are they prepared with when they arrive there? What do they know? What don't they know? Do they need to quit halfway through sometimes because they have to go look things up? All of those things will tell you what the navigation system needs to be. Jared: That's brilliant. That's absolutely brilliant. That makes just so much sense now the way you've put it this way. I really get it. I've got one last question here. I'm going through, I'm creating my screens. At some point, I'm going to have to turn to the navigation. What is the thing that tells you, OK, we've gotten as far as we're going to go here. Now we have to take away that "navigation goes here" box and actually work on it. What's the trigger that gets us there? Hagan: I find it's usually somewhere between two-thirds and three-quarters of the way through making all the screens. It varies by application. But at some point, you're going to feel comfortable that you've nailed down the major screens of the product. You know where all the key centers are. You have a really good feel for how the user needs to use them. You've maybe sketched out some little micro-navigation that goes within these little wizards and other things that you know the needs for what you need to do there. Then you can start to say, all right. I've established these requirements. I know what the navigation needs to be, and I can start to prototype different applications for navigation. I think it's a point where you're feeling pretty certain about how the application's shaping up. Jared: That's brilliant. That's absolutely brilliant. Hagan: Thank you. Jared: You're one of the smartest people I know. Hagan: [laughs] You must not know very many people. Jared: [laughs] I know a whole lot. No, you're just awesome. Well, this is very exciting. This is what you're going to be talking about at the Web App Masters Tour, right? Hagan: Yes, it is, and I'm going to be really restraining myself to fit it to 75 minutes, but we'll see what I can do. Jared: Yes, yes. Because I get the sense you can talk about this for a really long time. Now if people want to get a sense, either people who are not able to make it to the Web App Masters Tour or people who want to hear what you talked about, you actually did a seminar for us a ways back called "Designing Better Navigation for Web Applications, " a virtual seminar which was fabulous, a fabulous seminar. That has some of the underlying stuff that you're going to be talking about, right? Hagan: Yes. I definitely introduced a lot of these ideas there. I went through a couple of examples, but the application I showed was pretty simple. It was a little library application. I wanted to keep it simple because I was bringing out these new ideas that had been there. In the tour, I'm definitely going to amp it up a bit. I'm going to show more complicated applications with more difficult structures and really try to poke at how you build these things, and what's going on with them and how you identify problems. If somebody says there are too many clicks, how do you turn that into knowing what to do? Those are the kinds of things I'm going to dive into. Jared: Fabulous. That sounds really excellent. Well, Hagan, I want to thank you very much for spending some time with us, and I'm looking forward to your presentation at the Web App Masters Tour. The first one's going to be in San Diego in March. We're just working on the program for that, and we're very, very excited about it. By the time this comes out, I think the program will be out and people can register. They can go to UIEtour.com to learn all about that. If you click on Hagan's name, you'll find all sorts of resources associated with stuff that she's done with us in the past, and the virtual seminar and things like that. Hagan, thank you very much for taking some time to really blow my mind about this navigation is its own application thing. Hagan: Well, thank you, Jared. It's always fun to blow your mind. Jared: Excellent. I want to thank everybody else for listening to my mind being blown right here on the SpoolCast. Thank you very much for encouraging our behavior. See you next time. --- Hagan is a powerhouse of information. That's why we asked (actually begged) her to give a full-day workshop at the User Interface 16 Conference, November 7-9. Hagan's full-day workshop, Simplifying Complex Applications, will help make your applications simple and intuitive. Learn more about her workshop and the seven others at http://UICONF.com .