Hagan Rivers – Crushing Enterprise App Navigation Issues Live!

UIE Brain Sparks

[ Transcript Available ]

The only job of application navigation is to get users to the right screen. Ideally, all of your users should find what they need in 10 seconds or less, and with only a few clicks. But many enterprise app navigation systems fall short. If you’re facing a much-needed navigation overhaul and don’t know where to start, it can be overwhelming.

Hagan will show you where to start, how to approach the problem, and what success looks like. You’ll get a feel for the philosophy that guides her work, the decisions she makes during the process, and the types of user research she regularly employs. You’ll go home with a whole new outlook on enterprise navigation.

To see the video of Hagan’s talk, visit the UX Immersion: Interactions section in our All You Can Learn Library.

Recorded: April, 2016
[ Subscribe to our podcast via ?This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

---

Hagan Rivers: Are you ready? You’re ready. All right. Let’s go. We’re going to talk about navigation issues and crushing them. Very violent today. We’re very violent. I’m going to start you with an idea. Go from violence to serene.

This idea that I have, I’ve talked about this for a few years now. My idea is that the navigation system in you applications is really just its own little, tiny application, living inside your broader application which is doing whatever it does. Finance, health care. Take your pick.

But the navigation is this little application that lives in there. It has basically one task to accomplish. That is to get the user to the right screen without error, quickly. It’s an application with only one task? How hard can it be to design?

Yet, it’s very challenging to get it right. Jared alluded to our history of looking at websites and web applications coming from what we know about designing websites and the shopping experience. We have a ton of knowledge about that.

I want to illustrate this by walking through how I see it in my mind, my mental map of how navigation looks on a typical shopping site versus how it looks in an enterprise class application or really any application.

This is what you might think of as a typical, albeit very small, site map of a shopping site like Amazon. There’s this big dot at the top. That’s the home page. There are these little other dots underneath. Those are department. Then, all of the little pages of products underneath.

If we talk about someone who’s going shopping — I’m going to go shopping. I get to Amazon’s home page. There it is at the top, all lit up. I decide I want to buy some socks. I need socks. Bare feet are cold.

I head over to the clothing department and I use my filters and searches. I look around and I find a pair of socks. Eventually, I get down to a product page. The truth is I probably looked at many pairs of socks before I pick, but I find a pair of socks that I like, and I say, “I’m going to add that to the cart. Toss that puppy in there.”

I’m not done yet. I also need to get a toy for my dog. I head over to the pet’s department. I look around, and I head down into the toys part of the pet’s department. I look around at some toys. I scroll, I filter, I look, and I find a toy that I like. I grab that toy and I throw that in the cart.

Now it’s time for me to check out. I go to the cart. I have to give my shipping address and all of that information. This is going to be a gift, so I gift-wrap it and put the tag on it and all that stuff. Then I have to give the payment information. Then I finish the checkout, and I’m done.

Conceptually, this is shopping. Even as shoppers, we’ve experienced this. It’s this process where you start at the top where there’s all of the available products. You window down into this place where you have the things that you want.

As designers, we’re trying to get them to actually make the purchase. We try to smooth the process so they finish the checkout and they get done.

A lot of the navigation examples that we all have to work from out there are based on this site, or shopping site. But this isn’t how I picture navigation when I picture applications. I picture something very different. I don’t picture the big, flat tree.

I’ll walk you through this and share my weird, little picture. Let’s imagine this is an enterprise application. I’m working at a help desk at a company. My job is to answer phones, take tickets, and solve problems. This is the application that I’m using.

I’m sitting at my desk. I log in, and I get to the home page, which is my starting point. That’s great. My phone rings and somebody has a problem. I say, “OK. Let me take this down.”

I pop over to the new ticket wizard. I type in the person’s name and a description of the problem. The thing might come back with some suggestions. I say, “No. None of those will fix it.” We go to the next part of the wizard. The user sends me an attachment and I throw that under the ticket.

I finish chatting with him, and I say, “Listen, I know who to assign this to. They’ll take care of you in a few minutes.” I’m going to hang up the phone. We’re good, but while I was on the phone, I realized that I never set up the information for those 10 new offices that were added on the second floor. I just thought of it.

As soon as I hang up the phone, I pop over to the list of locations for my building and I’m looking at that little circle. That’s a list of locations.

I’m looking at these locations, and I go to the second floor stuff and I hit “Add.” Then I open up this tiny window for adding. I add an office, and I add another office. I add another office. I do this 10 times, 10 offices. That’s good. I took care of that. That was something I remembered I needed to do.

Now, I think I’d better go look at my tickets and see what’s waiting for me. I head back to the home page, and it says that I have 15 tickets to deal with. I head over to the list of tickets, and up comes my list of tickets that I have to deal with. This looks nothing like shopping. [laughs] I’m bouncing all over the place, and it’s on my whim.

No one’s trying to funnel me into a purchase. I’ve got things I’ve got to do, and the things I need from a navigation system are really different. A shopping site’s trying to direct me to this goal, but the goals here are mine. I need the navigation system to help me get those things done. It’s very different from shopping.

I head over to my list of tickets, and I open up a ticket, and I read it, and I say, “Huh. I think maybe we did a software install that I need to back out, but let me go look.” I go to the list of all the software installs, and I look at that thing. Again, I’m popping around.

I find one that needs to be dealt with, I go back to the list of tickets, I merge all the tickets into one in the merge screen, blah, blah, blah. I jump around all the time.

Fundamentally, this is how I see application navigation. It’s very, very different from shopping. That large circle’s the home page, but each of these little, middle-sized circles, these are lists of stuff that the user works on. Some of these lists of stuff are interrelated, some are not.

The user jumps around between them to accomplish their tasks, and they need to be able to move quickly through the application to get to the information and the data they want. This is not about narrowing.

Enterprise applications, in particular, have a lot of screens. [laughs] I’ve worked on some with hundreds and even thousands. We got any thousands in the audience? Anybody with an application with a thousand-plus screens? A couple. Hi. Drinks later?

[laughter]

Hagan: [whispers] I need one. Those are scary. [laughs] If you break away from your traditional what I know about navigation, how do you start to think about navigation for a big site like this? I have this thing where I say it, and then I get to the summary slide, and I go, “Damn it, I already said that.” It’s lunch. I had too much lunch.

Shopping is this series of steps that we go through to win out. You choose categories and subcategories, and it’s really just a big filtering process.

Enterprise apps are about completing the users’ tasks, and that’s why we spend so much time studying users, and learning about their tasks, and figuring out their goals, and trying to understand what they’re trying to do. Then, we have to design a navigation system that supports all that. That’s the trick.

The principles I work from is you’ve got many screens. If you think of navigation as an application, and every screen has a name, and the screens can be categorized and grouped together by category, and some screens are used more often than others, and some screens are more important than others.

You’ve got this list of screens. Surely you should be able to design an application that will help the user find the right screen quickly. That’s fundamentally what you’re trying to do with navigation.

The big thing is that once the user gets to the right screen, the navigation system has to get out of the way and let them work.

I thought what I’d do today, since I got the post-lunch slot, is spend a little time. I’m going to tell three stories, and they’re all examples of applications I’ve worked on that had broken navigation systems that we fixed. I’m going to show you the befores and afters, and talk about what we learned from that process.

Hopefully there are nuggets embedded in here that will be useful for you. That’s my plan. Let me know how it worked out in the reviews.

In our first story, we’re going to talk about monsters. Feed me, Seymour. [laughs] In particular, I’m talking about navigation systems that just keep growing, and growing, and growing. This is a little hard to read. I made a few slides where I zoom in on this a bit. This is an application we worked on, and it has a lot of navigation on the screen.

In the top right corner, you can see there are some links for profile, support, and all that. Across the top, there’s this tab bar, the yellow one that’s highlighted. Then, on the last, there’s a list of links called actions, and those are all the actions for the page I’m on right now. On the bottom, there’s a list of recently viewed, so that’s the last 10, or so things that the user touched.

Right in the middle, there’s a couple of tabs.er touched. Then, right in the middle, there’s a couple of tabs.

These things, all taken together, are the navigation system for this application. Basically, the function of all those things on the top, and the edges, and even the tabs is to get the user to the place where that thing in the middle is the screen they wanted, or to get them to the next screen, if you like, haven gotten here.

I’m going to draw a box. Well, I’m not going to draw a box. I’m going to push a button, and that’s going to draw a box. That’s the space the user has to actually do their work. Once the navigation system gets them there, that’s what’s left over for pixels. You want to take a gander at the percentage? How many? Guess? Yeah, you guys are good.

The navigation system is taking up more than a third of the pixels on the screen. For the moments when I’m trying to get to this screen, that’s great. For the moments when I’ve gotten to this screen, it’s not so great.

They had identified to us that that was a problem, mainly because they were going to be adding another hundred or so screens, and the navigation system was going to get even bigger, and because the density of information on the screens was increasing. They were feeling the pain of having these tiny, little areas. They asked us to help with that.

We also talk to the users a lot. I actually attended, for this client, all the training that they had for their software. I sat in on the training classes. It was very interesting. I highly recommend it. I sat in on the training. I talked to users. I talked to folks in the company.

We came across a whole bunch of problems, but a couple I’ll highlight here. One was that you notice on this page where it says select a capital need. You’re trying to create something. On the left, there’s no actions links. Those are gone, because there aren’t any actions here, and we still have the recently viewed, which doesn’t really make sense.

There’s wasted space all over the place. Things would be there that didn’t need to be there. It was this sort of pattern that they had that they were using all over the place.

The other thing we ran into was this little yellow highlight. These are tabs up at the top here, and they were highlighting the current tab-ish. We’re not really on the capital needs screen, which is the main screen of this section of the application. We’re on some little subset screen. We’re in the neighborhood of the capital needs screen, so they had highlighted the tab.

This just killed the users, because they were like, “Can I click that? It’s yellow. It’s not blue like the others. What do I do? I can’t go there. How do I get to the screen?” They would agonize over this. The response from, of course, the developers was, “How will the user know where they are? We have to tell them where they are or they’re lost.”

Maybe we can find another way that won’t confuse people. I call these kinds of cues like this, this yellow box, these are orientation cues. Navigation has two jobs. It’s to get you around, but while you’re moving around, sometimes you need to stay oriented. Where am I?

There are lots of methodologies you can use to help the user be oriented. Highlighting a tab when the tab isn’t really the screen is probably one of my least favorite. That’s an orientation cue. We end up with a better one here.

I’m going to spare you the agonizing amounts of months of research that we did, and talking to users, and studies, and fieldwork, and everything. I’m just going to show you the before and after. [laughs]

This application’s getting bigger. You can see the space in the middle, it has four boxes in it. You don’t really even need to know the details, but this thing scrolled down, like, four screenfuls. They were dying for pixels, and the navigation system was killing them. That was with the tabs across the top to break it up.

It was really a struggle for them to try to fit, and they had more information to add.

What we did was we took the entire navigation system and reworked it into a menu bar. I happen to use the menu bar a lot in enterprise application design. I find it’s very flexible. It’s compact. It can hold a lot of items, and it does a pretty good job. As with all navigation systems, it has its pluses and minuses, but I felt it was a good fit in this application.

First of all, you can see right away, there’s a lot more space for the data, which, of course, the users were thrilled about. Let me walk you through some of the other changes. On the bottom right is the before, and the top behind it is the after.

A few of the things we did, for example, the tabs that were here in the old design, they’re still here in the new design. We didn’t really change that. It seemed to be working, so the tabs are still there. We changed how they look, but that’s it.

When we got to the list of actions, instead of having them on the left, we made them into a toolbar. Some of the lists of actions, like this one, were very long, so the toolbar, we had some menus in it. Keep it short. That’s the toolbar up there.

This thing where we show the current screen, we got rid of that. The menu bar just shows the top-level menu items. We didn’t try to worry about showing what the current screen was in the menu bar. Instead, what we did was added a title to the page that shows the user the title of the page they’re currently on.

A tiny, little bit of breadcrumbs underneath. Not full breadcrumbs, but just back to the main list you were on before you got on this page for shortened breadcrumbs. That took care of our orientation needs.

Then, we had this section where we had the recently viewed items. We put that up in the menu bar under a menu item called recent. Let me talk about recent menus. Sometimes you will work with users who tend to work with the same small group of stuff for 30 minutes, 60 minutes at a time. Other times, you work with users who are bouncing all over the place.

In this application, it was very common that someone was building a capital need or a purchase order that they would revisit the same four or five objects again and again over the course of the day. This menu was something they had added to allow the user to get quick access to those elements that they would need to complete the work.

It was great. Users loved it. We kept it. We just moved it into the menu bar. Don’t run home and say, “Hey, we need a recent menu.” Sometimes you need a recent menu. If that’s how your users are working, that’s great.

If your users are taking phone calls, and entering data, and then passing it to the next person, they are never looking back. They don’t need a recent menu. That’s not useful to them. For these users in this application, this is what worked.

The other thing I’ll have you notice is this first little item in the menu bar where it says capital. This isn’t really actually a menu item. It’s kind of a tab. It’s a weird little tab. If you open it up, there were three things inside — capital, accounting, and admin. These were the three main modules of the whole application, and we’re currently in capital.

When you switched between those, the rest of the menu bar would change. A good menu bar can probably hold a hundred screens. With this switcher, we could get 300 screens or more as they added more modules. Suddenly, we had a navigation system that had room for growth for them.

We also had, now, I counted, 95 percent of the pixels available for the user to actually work, which was a big win.

We took some lessons from this work. We all know, as these applications grow, the navigation gets bigger, the features get bigger, there’s just more stuff. You need to find a navigation solution that doesn’t take up a lot of screen real estate. Tabs are not it. I find the menu bar works very, very well.

There are many ways to show users where they are. You don’t have to be obsessed with showing it in the navigation. Page titles are a great orientation cue that you can use.

The big one I learned in this one, and I knew this, but I thought this was a great example, that the reason the user’s using the software is to work with the data, not to use your navigation system.

As pleased as I am with my design work there, it needs to be out of the way and not bother users so that they can do their work.

That was our first story. Are we still awake? It’s very quiet. [laughs] Very quiet out there. Is this rapt attention or dozing? It’s very hard to tell the difference from up here, I’m telling you. [laughs]

Story number two is about trees. They’re very menacing, my stories. This might have been a dark time. Crushing and monsters and trees. I have been watching “Buffy” with the kids, so it might be that.

Trees. [laughs] Engineering loves trees, don’t they? [laughs] They just love those things. Oh my god, so many trees to chop down. This is a help desk application that I actually worked on. I’ve actually worked on several now.

In these applications, the users are basically managing tickets. That’s all they’re doing. This sounds like a terrible job. Sitting at their desk all day dealing with ticket after ticket. It’s like emptying the dishwasher 40 times a day. A never-ending task. It’s truly horrible.

In this thing, they had a tree on the left. I’m going to call it a tree on the left. Bear with me. I know some of you are correcting me on slack right now, but it’s a tree. In this application, every screen that was in the application, as engineers love to do, every screen you could get to was in that tree. If it was a screen in the application, it was in the tree.

You can see that we’re in one section of the tree, and the first one that’s there, I can’t even see it. It’s blue, it’s barely blue. It’s selected. That’s the screen we’re on. If you wanted to navigate around, you opened and closed the tree, you clicked on the screen, you saw it on the right.

Oh, look, an arrow. It’s like I’m phoning it in, people. This isn’t really a tree. It’s an accordion, but it behaves like a two-level tree. You have your parents and one set of children under each one.

I actually have to say, if you have to have a tree, better two levels than more. The expand/collapse thing is annoying enough without having to dig down deeper and deeper into it. I’d rather have a long group.

The thing about trees is as the tree gets deeper, it’s bad, because it indents, so your labels have to get shorter. As the tree gets longer, it’s bad, because things scroll. Basically, only short, shallow trees work, which is why are you using that?

These guys had a tree. Again, they were adding more screens, and they felt like maybe this wasn’t working. They were right. I spent some time observing the users of this application, and I discovered something really interesting, which was that users fell into two categories.

The first category was the obvious ones I expected, and these were the people who managed tickets. They only used that part of the tree. They never touched the screens in the rest of the tree. I was like, “That’s interesting.” Spent some time observing them, and learning about them, and learning about the product.

As I started to understand the product better, I started to understand that this navigation system was a little crazy. You’re on the home page here. We’re in the section called home, and we’re in the first thing there called list of tickets, which is the main screen of the whole application. It’s kind of in there.

You’ll notice, as I’m listing the tickets, there’s this column here that says type. There are these little three-letter abbreviations — INC, and CHG and TSK. If you look on the left in the navigation, you’ll see incident management, change management, and task management. Basically, tickets had types. There were different types of tickets.

If you went to this screen, the list of tickets, you would see all the types together. All the other four places in the tree, they were just filters on the same list. If you went to change management, you just saw the change tickets. It was still the same screen. They were just filters.

I was like, “These aren’t even separate screens. You’ve got this whole navigation system. How many screens are actually being used by these users?” The answer was, like, eight. They had this enormous navigation system. Most of the time, they were on the list of tickets. Sometimes they filtered. Sometimes they added or edited tickets, and that was it.

One of the other things you’ll notice is under here, there’s a bunch of other screens. There’s change password and update preferences. This is one of the things I really dislike about trees, and there are lots of things I dislike about trees. The thing about them is they make everything look similar, of the same importance, of the same value.

The list of tickets is the core screen of this entire application, and it’s basically presented to you as of equal importance as change password. That’s, I think, really a place for me, in terms of the user understanding the application, where trees really fall down. You need to present, in navigation, a sense to the user of what’s important versus what’s not.

We started with this group of users who work on tickets. Again, I will not bore you with all the details of the interviews. This was the design we had afterwards. We used the menu bar again. You’re all going to leave today and say, “Hagan says to use the menu bar for everything.” Not true. I’ll show you some other examples. [laughs]

We used the menu bar again. We added this big, green button to create a ticket. Oh, shoot. All right, I have to go back. There’s a key thing that made me crazy here. If you wanted to make a change ticket, because there are different types, you had to first click on change management. That would slide up, and then you had to say create a ticket under there.

You couldn’t just say create a ticket from the top. You had to navigate to a section of the tree and choose the right create a ticket. This really messed with the users quite a bit. They had a lot of the wrong kinds of tickets being created.

We added this new, big button that said create a ticket, and the first thing it did was say, “What kind of ticket do you want to create?” Seemed really obvious to me, but they thought I was a genius. Some days it’s easy. Some days, not so much.

We added that. That was good. They liked that. Then, we basically had this one core screen that is the list of tickets. Frankly, most of the users worked here. We kept the menu items as filters for the other flavors of this screen in this mock-up, but by the time this thing shipped, those were all gone. We basically just had this list of tickets with some filtering controls.

The user could work on tickets here, make new tickets. 80 percent of the user’s work was happening on this screen, and they didn’t have to use navigation very much at all, which was great. I worked myself out of a job there.

The other thing we did was we added this menu for new. Although, we had the big, green new button, that was only on that one screen. If you were on other screens of the product, and a phone call came in, and you needed to make a new ticket, you need to be able to get to that screen really fast, without having to navigate around first.

We added this menu that lets you create the different types of tickets. If you didn’t know which one you wanted to make, you just said new, and it would walk you through it. If you knew which one you wanted to make, you could jump to it.

In environments where users have a lot of interruption and they have to unexpectedly create new things, I find a new menu is a great benefit to them. It saves them a lot of time.

There was an interesting fallout from this, which was users would open the menu and say, “Oh, I didn’t know you could make that.” It became almost a guide to what we could make.

As they added new features to the application and new items appeared in that menu, that helped users. It unlocked some of the features of the product for the users. I acted as if I had totally planned that. Totally planned that. It was awesome.

What about the second group of users? The rest of the navigation system was taken up with administrative tasks. Things for setting up and configuring this piece of software. At each given installation, there were maybe two users who did this, tops. Other than setting it up the first time, they might touch this once a month, twice a month. Very rarely in here.

Here was this whole application with this dedicated space for stuff that, essentially, hardly anybody ever used.

The other thing was that these users were rarely the help desk people. They worked in the IT team, but they didn’t directly answer phones and deal with tickets. They were more on the back end. They didn’t even really need a list of tickets. None of that was interesting to them.

What we did for them is we buried it. We buried admin. Up in the corner, there’s a little link…Does this work? It works. Where’s a cap? It says configure. You click on that link, and you would go to this page. I just have this as a wireframe. I don’t know what happened to the final version.

This page is basically just a list of links to every administrative screen there was. This is how admin is. You come in, and there’s one little task that’s two screens, and then you’re done. This just lists all of them. They’re all in one place. You can just scan the screen, you find them, you do it, and you’re done.

I wouldn’t do this for the people making the tickets, but for the admins, it was great. They could find it all there. If it could be done, it was listed on this page. I call that thing, by the way, a link field, and we’ll talk about those tomorrow.

What did I learn? I still hate trees. Really, really hate them. They do make things seem equal, which I don’t like. There are screens that are more important than others. The trees, because of all the clicking and opening and closing, it’s hard to find targets.

In a menu bar, I don’t know if you’ve ever seen this, but I’ve seen users move up to the menu bar, and you could blindfold them. They know where they’re putting their mouse to click on a thing, and they open it, and they know exactly how far down to go to select an item.

With a tree, because it’s scrolling and you expand and collapse, you never know where anything’s going to be, so you’re constantly doing this hunting thing. It was really tedious for these poor users to switch between all of six screens.

The big thing I learned here is navigation doesn’t have to be the same for all the users of the application. If you spend some time studying them and how they use it, you can support different use styles. In this case, we had two really disparate, non-overlapping groups of users, and we created independent navigation systems for them.

As proud as I am of my work, it’s OK to bury parts of the navigation so that most people never see it. That’s OK. The new menu was a great, unexpected benefit. That’s story number two.

Number three. Not quite as dire. I went in one of those once. I don’t recommend it. It looks all simple from up here, but when you’re down there and it’s just a sea of green, good luck. It’s Harry Potter all over again.

This is our third and final story, although I have a little at the end. The thing about navigation is if you do a bad job of it, users can get really lost. It can make it hard for them to find what they’re looking for.

One of the things we have to keep in mind is that there are different ways people approach this little application. Sometimes the user knows exactly what screen they want to get to. They know what it’s called, and they know where it’s located, and they just go to the navigation system. It’s really just a matter of how quickly can I click through it.

We spent a lot of time designing for those people, but there are a lot of people who don’t know if the screen even exists, and if it does, they’re not sure what it’s called or where you would put it. They have to browser, search, find.

This is where a lot of navigation systems fall down. They’re really designed around the person who knows what they’re doing and not so much around the people who are exploring. You need to support both. Both frames of mind are going to arrive at your navigation system pretty much every day.

This was a very unusual application that I worked on in manufacturing. Anybody from manufacturing? Manufacturing’s fun. This application, after you log in, this is the first screen you see. We’re looking at the navigation system. Bear with me. I’m going to have to walk you through a couple of these. I began to refer to these, at our first meeting, as “The big buttons.”

The story here was that about 20 percent of the users were on the factory floor or the loading dock, and they were using this GUI on tablet. Even though they only needed to access a handful of screens, they had to use the navigation system to get there. As a result, the navigation system had these enormous buttons.

They were having problems, because people were getting lost, and they didn’t know how to find this. You would log in, and you would get this list of buttons. You’d tap on one or click one, depending on who you were, and you’d get another list of big buttons.

Basically, those first big buttons were all just categories. None of those are screens. None of these are screens, either, although you can’t tell. It doesn’t let you know which ones are screens and which ones are categories. There’s no breadcrumbs, either, so you can’t tell where you’ve come from.

Although, there is a teeny, tiny back button up there, which causes me much humor, because I’m picturing the guys on the loading dock in their gloves trying to hit that thing. I’m like, “You made the big buttons, and the back button is, like, four pixels high. Seriously? I have an idea. I know how to make it better.” [laughs] Sometimes you need a consultant to help you. [laughs]

You would start at the top level, and you’d click on a category, and you’d get here, and you’d click on another category. Then, you’d get here, and you’d just keep clicking through categories until, at some point, you’d get to your screen. Some of these here are screens and some are categories.

Here was the kicker. All of these menus were configured differently at different installations. Every site had their own navigation system. They all use the same methodology for navigating, but they had their own organization of the screens, so reorganizing their navigation system was not going to be an option for me.

I had to come up with a system for presenting the navigation system that would support the users. These labels, the users picked them. Those horrible, horrible icons, the users picked them.

That green back there, somebody put that back there because Joe could never find reporting, so they made it green and told Joe, “When you get to this page, hit the green button, Joe.”

[laughter]

Hagan: This is how they wanted it. The users wanted it. The users wanted it like this. I came in, I was appalled, like, “Please let me design a better…” They were like, “No, we like our bit buttons. We like the green. Joe needs green. We’re good.” I was like, “OK. Why am I here? What am I going to do?”

I started small. I started trying to say, “What can I do with what they’ve got to make it better?” We just started working with users and making little sketches and mock-ups and showing it to them. They would get really excited about some of them, and other ones, they had no idea what I was talking about.

One of the first things we did, we kept the big buttons. The big buttons live in the product to this day. We added a breadcrumb menu. This mock-up is a little small. A couple of the mock-ups you’re going to see, it’s a little small. We made it big enough to work on a tablet.

Not only do we have breadcrumbs, the breadcrumbs are menu items. That might seem like overkill, except that what I learned in talking to the users was that they tended to work in the same area of the product.

Having navigated to a particular screen, it was very likely that they were going to stay in that family of screens, either the parent, the aunts and uncles of that screen, or the great-aunts and uncles of that screen, if you will. That’s why the users could design the navigation system, so they could set that up.

The guy who worked in the loading dock, once he was on the screen, tended to stay near the screen. We made not only breadcrumbs, but a menu that opens up to show you the siblings of the parent of the current screen. That was our first mock-up.

Then they showed me something, absolutely blew my mind. They have this thing called menu search. The thing about the big buttons, you probably inferred this, but let me just say it out front. If you know what screen you’re getting to, the big buttons are great. You’re just like tap, tap, tap.

If you don’t know what screen you’re getting to, you go tap, tap, tap, back, back, tap, back. It’s a nightmare to search this menu. It’s not browsable, this navigation system.

They decided to add searching for the menu system, which that seemed like a good idea. The way you got to it was you clicked on the company logo, your company logo, which took me a bit to find. Then you chose menu search.

I watched a user. I was on the phone one day watching a user using the product, and she searched for consignment. She wanted to go to a screen about consignment. This is what came up. I said, “I have way underbid this thing.”

[laughter]

Hagan: “Oh my God. How many screens are in here? We need to talk.” [laughs] She was totally calm. She was like do, do, do, and she clicked. I was like, “Back up, ma’am.” [laughs] We went back through it. She explained it to me. Of course, she’s not a designer, so she doesn’t know my weird lingo for talking about this. She’s walking me through it.

Here’s what I learned. All these screens in red, they’re all called consignment inventory, and they’re all the same screen. You got it yet? All these things in blue, what were those? I have them written here, because I knew I couldn’t read that. Customer consignment inventory. That’s also one screen.

There’s a third screen called supplier consignment, which is in very pale yellow. There’s only three screens, so my bid was good. Maybe a little good.

There’s only three screens that match this search, and I thought, “Why on Earth would you show this as search results when there are only three screens that match?” Here was the thing. The woman knew that she wanted to work on the consignment inventory screen, but she knew that when she was done, she was going to go to purchasing.

She would pick the path to the screen that included purchasing so that when she was done, she could hit the back button twice to get to the screen.

[laughter]

Hagan: Otherwise, she’d have to go to the home page to the big buttons and go down, down, down, down, down. That was tedious. I had to agree, that was very tedious. This was terrifying.

Every single person I saw use this product, this was probably the only time I’ve ever seen users actively thinking ahead. What am I doing when I’m done with this screen? It was so odd. They did. They were very actively choosing. “Oh, shoot, I didn’t mean to click that one. I need to go to office next. Darn it.”

We talked a lot about removing it. We did a lot of sketches that didn’t have it. I ran into a lot of really pissed off users. Frankly, they were very well-trained to use it this way, and I argued it was confusing. I argued that new people would need lots of training.

Here’s what we ended up doing. If you search for part list and there are four part list screens, we list the four. Then, under them, we list the paths to them. You can just click on the first thing where it says part list and go to that screen, or manufacturer part list, or supplier part list, or VP part list. That would take you to each of the four screens directly.

I don’t actually know what path. I don’t know what would happen if you hit the back button in that case. I can’t remember, anyway. You could also choose a path if you wanted to. In later versions, we actually collapsed these down. The user could open it up if they wanted to be specific about paths, and they could leave it open if that’s how they liked the app.

For new people who are coming on-board who are more used to Google, where you only need to mention a target maybe once in a list instead of 15 times to get to it, that was more comfortable for them.

We struck a balance between the people who were using the product now and the people who were coming on-board.

We worked on a ton of other stuff in this piece of software. Navigation was just a small part of the work. It was a really fun project. When we were done, the navigation system all fit in this little blue bar at the top and hundreds and hundreds of screens. You might think it’s a menu bar, but it’s not. There’s a couple of menu items there.

What I did here is up at the top left corner, there’s this compass. You know, I really don’t like the compass icon, because I worked at Netscape, and that’s what they used. I always thought that was stupid, but that’s what they really wanted. They wanted the compass icon.

They had the compass icon in the corner, and when you clicked on that, it opened this thing that I think Jared called at first a mega menu, and I love that name. Mega menu. This is what it opened up.

This is navigation as an application. It’s this little application that I stowed away, because I’m busy and I’m working. When I open this up, now I can go and find the screens I need to get to. There’s the big buttons. They’re a little prettier, and they have prettier icons, but it’s still the big buttons for the folks on the floor who want to use it.

The breadcrumbs are up here. Let me see. I have the menu. They have menus, so you can go back up. Again, we made all of those a little bit bigger for the factory floor folks. All the breadcrumbs are there so you can see how you got to this current set of big buttons and move around.

Over on the right, we added recent items, because that turned out to be a thing that their users liked. If you did a search, we had our presentation of our results that would expand and collapse to show you the different screens. We had some help embedded in this whole little navigation system.

There was a third area, which I didn’t even talk about today because I don’t have time. We did this tree. I did a tree. [laughs] It’s basically this site map. What I learned from talking to a lot of the folks who sat at the desks was they had arranged the navigation systems so that they only accessed maybe 15 or 20 screens in a given site.

They would open this up, and then open up the sections of the tree that they used, and they’d just leave them open. When they opened this, the part of the navigation they needed was right there in front of them, and they would just click. Then, they would close the navigation app. The next time they opened it, the tree’s still there open.

Now you have navigation that can retain state. It can remember what was the user last navigating to. What did they need to know at that point? It left it exactly as the user last touched it. Huge success.

I particularly enjoyed the process here, because the users were heavily involved throughout. My instinct would have been to rip out the whole navigation system or replace it with what I thought was the right thing based on 25 years of doing this [laughs], but I was wrong. The users had a very strong idea about what they wanted.

The design process was about supporting that and making sure that it did a good job of meeting their needs.

I learned navigation really is an application. I built the application. It’s OK to be unconventional. Having the weird search results, it was fine. Figuring out ways to improve on what they did, adding the breadcrumbs, organizing the search results, those things helped them a lot.

I particularly liked using the mega menu in this application, because it really could let the users return to navigation again and again between tasks and hold state.

That’s my three stories. One more little bit to talk about. I usually design navigation systems last, after I’ve done the designs for all the screens in the product or, if the product already exists, after I’ve worked through all the screens in the product, either redesigning them or just studying them.

Most of the clients I work with, and maybe in your organization, the first thing they want to do is navigation. They always tell me that. “Let’s start with the navigation system.” It’s a bit of a fight at the very beginning of a consulting gig, which is always fun, to argue with a client right off the bat, but we wait.

The best way I have to explain this is to compare it to writing. If you’re writing a book, you write an outline. An outline is not the finished product, not by far. You start writing, and you adjust the outline. You keep writing, and you tweak the outline.

You rearrange the chapters, and you rearrange the outline, and you slash sections, and you cut stuff out, and rename things, and you keep writing. When you’re all done and it’s been reviewed and vetted, then you write your introductory section, or your abstract if you’re writing a scientific paper.

At the very end, you make the table of contents, once it’s done and you know where everything is and nothing’s going to move anymore. You can make the best judgment about how to show the contents of this thing you’ve created.

For applications, it’s the same. I go through first looking at the lists in the application. I make sure I understand what are the things the user’s working with. Look at all those lists. Maybe it’s customers, or tickets, or a fleet of cars, or financial transactions. It doesn’t matter. Look at the lists of stuff.

These are like the chapters of the book. Go through them. Make sure each screen is meeting the users’ needs.

For each of these lists, there’s going to be a screen, most likely, where you add or edit the thing in the list. Those are all your forms. Go work on those. Fix those up. Get patterns together. Get what you like. Fine-tune your writing, if you will, for the book analogy.

For every list you’ve got, you’ve probably got a chooser. On other screens, if you’re filling out a form ticket, I need to choose the customer from the customer list, so I need a chooser for the customer list. I go through and I design all the choosers.

I do all the other little screens, the exports, and the imports, and the prints, and all the little bits that need to be there.

Finally, I work on the home page. It might be more than one home page, but I work on that last. That’s like the introductory chapter. Now that I know what’s all there, I know what’s useful, so I can talk about that. Finally, I turn to the navigation system at the end.

We looked at some cool stuff. Today, I shared stories. Tomorrow is much more about patterns, and practice, and cool things like that. I’m going to talk about some of the things we discussed today, menu bars and mega menus, but also talk about tabs, and a little more about trees, and link fields, and some other stuff, too. That is what I have for you today.

Thank you.

[applause]

Jared: Thank you, Hagan.

Hagan: Did I finish too quickly? You’re all the way back there.

Jared: No, no. You finished fine. You were in good place. Do we have questions for Hagan here? Yes, we have a bunch here. We have one over here, one up here. Start back there.

Audience Member: Hello. Can you say a few words about typography in these applications, which tend to have very tiny type spread all over the place with no hierarchy?

Hagan: You’re talking about in that mega menu that was there?

Audience Member: No, just in general.

Hagan: Of the examples I showed here or across all applications?

Audience Member: Across all applications in general.

Hagan: Sorry, I can’t see you, but I’m going to be 50 soon. I know your pain. Eyesight problems, yeah. I do find there’s a tendency to use small fonts. The designers love the gray text as opposed to the black. Thanks, guys. Can’t see. [laughs] You have to look at your users.

Certainly, in installations where you have a user base that’s all in their 40s and 50s, you need to pay special attention to font size and readability. I always strive for readability where possible. I’ll say, for the stuff I showed here today, it’s been shrunken to fit on the screen, so it’s not at actual size, but I often find type is hard to read. Yeah?

[off-mic comment]

[pause]

Audience Member: Hello?

Hagan: There you go.

Audience Member: You touched on this with the last example, where they were using the application on the mobile device. In terms of for this discussion, a website or a computer application versus a tablet application, are there any things that you tend to do on the tablet versus the website kind of thing?

You don’t necessarily have as much space for navigation on a tablet, especially when you have to consider orientations and such.

Hagan: Tablets are challenging. Phones are even more challenging. You end up with a very small screen. You end up with a design that looks a lot like that big-button design where you’re drilling down, and down, and down.

There are things I do in mobile. I didn’t want to talk about that today. I would say keep in mind that there are going to be people approaching your mobile navigation system who don’t know what they’re looking for or where to find it, and just tapping on things and getting to the next level in the navigation is going to be a super frustrating way for them to find it.

At the very least, I would consider a search system. Also, interconnecting your screens so that users can move from connected pieces of data to another. If I was looking at a ticket and the customer was on the ticket, if I could click on the customer to get to that without having to use the navigation system.

Link your data up so that they don’t have to rely on navigation, going to that application, so much to get there. Mobile’s challenging, especially on the phone size.

Audience Member: On that last example, you had to go with the mega menu, but you had alluded to possibly you would have done it differently if you weren’t forced to do the mega menu. What would have been your…?

Hagan: Menu bars all the way. No.

[laughter]

Hagan: I find breadcrumbs a little difficult to understand in applications. When you’re surfing Amazon and you’re filtering down through product, the breadcrumb path makes a lot of sense to me, but the idea that a screen only belongs in one place in an application is very odd to me.

To these guys’ credit, they thought the screen belonged in 12 places. [laughs] At least they had done that. I find really strict breadcrumbing to be confusing to people. The truth is you can get to the list of users in your application a lot of different ways.

The breadcrumbs, in particular, I would have moved away from, from thinking about the application that hierarchically, and concentrated more on what are the important work areas that they need to get to and work from that.

I probably would have added some home pages there and more of them, so that someone who worked in purchasing would go to the home page for purchasing and work from that space. That’s not what these users wanted, so it’s OK. Yes? Thank you for pointing.

Audience Member: Hello. I have a question about business justification. You’re brought in midway through the process. Do you have any idea what metrics were used earlier in the process to actually justify the cost of overhauling navigation?

Hagan: Sometimes. Metrics-wise, what folks often look at is fast movement through a series of screens before you work for a while on a screen. That’s hard. I find it’s hard to use metrics to track down navigation problems. They can give you a sense of the problem, but you need to go watch the users to really get it.

Typically, people who call me looked at the metrics after they knew there was a problem, and they found it. They found supporting information.

Audience Member: I was trying to figure out if they did a cost benefit analyses that it would save 10,000 hours of employees time of navigating through the application, so then we can engage in this overhaul.

Hagan: Certainly sometimes, yeah. I worked in applications where there’s a lot of data entry. The time it takes to navigate from screen to screen, you can really measure the cost to users if it’s taking too long.

A lot of times, companies will wait to fix a navigation system when they’re adding a whole bunch of new features. It’s clearly going to break what they’ve got. So they think, “Now is the time to step back and look at it.” That’s good timing. It’s a good time to look at it.

But there are definitely places where you can say, “You know what? This is killing us. It’s too hard. It’s too many steps, and we need to fix it.”

One coup I always run into is in sales demos. One of the things I do with clients is sit in on a few sales demos. I always notice that there are parts the sales guys skip — the parts that they don’t want to show anybody. After the demo, I always say, “Show me that.” It’s the ugly part.

It’s usually navigation. It’s too many clicks to get to a thing and they don’t want to show that to a customer. That’s a good place for me to start working.

Audience Member: Hi. I was interested in your last point about designing home page and navigation last. You mentioned that it’s always a fight. I was wondering if you have recommendations on how to have that conversation with the clients.

Hagan: Yeah. It really depends on the client. Sometimes I tell them, “We’ll design navigation first,” and I do this really slapdash job of it, and then tell them that we’re going to revisit it at the end, and they’re happy, and I get to work. Then at the end, I change everything. I talk to the engineers and say, “Don’t implement this.”

[laughter]

Hagan: Otherwise, they get really mad. You don’t want to make them mad. Sometimes, you move through it. You give them what they think they need and you move through it.

Other times, I’ve really talked about…I’m thinking of a client I worked with last fall. What I did with them was I designed them three totally different navigation systems — each with very strong pros and cons. They were like, “We don’t know which one to pick.”

I said, “That’s because you don’t know yet what the application’s going to look like. You can’t actually weigh these pros and cons because you don’t know yet what’s important. We need to finish evaluating the users, and the tasks, and the goals, and making the screens. You can’t decide this now.”

We tabled it. Then, we went back to the designs at the end. We were able to actually pick amongst one of them and then work with it.

It varies a lot by the group you’re working with. Sorry I don’t have one answer. Yes.

Audience Member: I was wondering, do you have a rule of thumb indicator that will help us decide if an application is suitable to transition to mobile as in tablet or smart phone?

Hagan: Some thresholds you mean, for deciding that?

Audience Member: Yeah, like number of layers in the hierarchy, or complexity, anything. [laughs]

Hagan: I don’t think there are going to be any hard and fast rules. Maybe the best ones are around time. If it’s taking the user more than 10 or 15 seconds to get to a screen that they know they’re looking for and they know where it is, you’ve probably got a problem. You could design different navigation systems to support that better.

Audience Member: I meant more like something that wouldn’t indicate not to even try going down that path when you say, “This application is simply not suitable to be a mobile application.”

Hagan: That’s a much bigger question than just the navigation system. Whether or not to move to mobile, you have to start with a discussion about the users. Why would a mobile solution be useful to them? How will it help them accomplish their goals? Are they trying to accomplish the same things on mobile that they do at their desktop?

The last example with the folks on the loading dock, they had a very clear need for a set of features to be available to those users. I argued a lot that for those users, they should never see the rest of the application. Even if they navigated to those screens, they couldn’t do anything with them once they got there. That was for them to decide.

Navigation’s part of the argument. Certainly when you start trying to design navigation for a big mobile app and you see how hard it is, that’s a good point of discussion with them. Have you answered the question about, “Is it useful? Is it usable to these users? Do they have a need for it?” That’s where you have to start. Am I out?

Audience Member: Thank you.

Jared: One more.

Hagan: One more. Who’s the lucky winner? Right down the spotlight.

Audience Member: Can you speak about the information architecture side of things? I know we front load our information architecture towards the beginning of the process to try to figure out what it even is. I understand doing nav at the end, especially with brand new builds or places where you could start from scratch or start fresh.

Can you talk about how those two play together?

Hagan Rivers: There’s a difference between designing your navigation system and thinking about navigation. In the example of the book, I started with an outline. That’s where the information architecture comes in.

It’s very useful to start thinking about, “What screens have we got? What’s related to one another? How do these fit together? How often does the user visit this screen versus that screen?” Those are all part of your outline. You could expect that will be very fluid and will change a lot over time.

The navigation system is the table of contents at the end. It encapsulates the outline and then makes it easy for the user to find something. Thank you everybody.

[applause]