February 1st, 2010
Duration: 25m | 14 MB
Recorded: January, 2010
Brian Christiansen, UIE Podcast Producer
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Transcription Available ]
We turn to Hagan Rivers for insight on designing challenging web applications year-after-year because she just keeps coming up with better and better ideas. When we were talking with her late last year, she mentioned she had another innovation in her web app design workflow, which sounded a bit strange at first blush: she designs the navigation as a separate application.
“How is that even possible?” we asked. Navigation is so central to the experience of the web that it frankly sounded like crazy talk. But we knew to hear Hagan out. Now we wonder how people do it any other way.
Recently, Jared sat down to talk with Hagan to discuss her somewhat radical notion, which she plans to discuss in detail at our upcoming Web App Masters Tour. Jared began by asking about the genesis of her application development strategy.
“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”
Of course, the primary application and the navigation are never truly separate apps. They’re always joined at the hip.
“They are obviously interweaved. […]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.”
Hagan brought up the idea of momentum in design, where inspiration doesn’t just appear on demand, but when the ideas do start flowing you don’t want to hamper them. Navigation is often a decelerator of momentum. Leaving navigation until later in the process doesn’t just ease addressing the primary tasks of the application. There are other advantages to having many of the app’s screens complete, prior to having a navigation system. For example, during your usability testing of prototypes,
“Because you don’t have the navigation system in front of [your users], [they’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.”
We feel that’s an powerful way to address the needs of your users with the navigation, gaining even more value from your research and testing efforts.
These are just a few tidbits from the interview. Be sure to listen to the interview to gain even more web app wisdom.
Obviously, we’re really excited that Hagan will be discussing this topic in depth at our Web App Masters Tour. Her “Escaping Navigation Hell” will be featured at all four stops on the tour, San Diego, Minneapolis, Philadelphia, and Seattle. You won’t want to miss it.
When do you address navigation when building complex web applications? Would Hagan’s idea help you in your situation? Let’s discuss in the comments!Tweet