Discovering Web App Structure: A Discussion with Hagan Rivers

Hagan Rivers has worked non-stop pioneering design techniques for creating stylish and useful applications and has remained on the cutting edge of application design technology.

Most recently, she’s been busy writing a comprehensive, 54-page report that deconstructs some of today’s most complex web applications.

UIE’s Jared Spool recently managed to get a little of Hagan River’s time to discuss her newly published report called “The Designers Guide to Web Applications, Part 1: Structure and Flows”. You can listen to the podcast of the discussion at the Brain Sparks Audio Library.

The following is a transcript of a discussion between Jared Spool and Hagan Rivers. To keep true to the original discussion, we’ve only made minor edits.

Jared Spool: Welcome everybody. I am talking today with Hagan Rivers and she has just published a report called “The Designers Guide to Web Applications Part 1: Structure and Flows.” And we are going to talk about that report a little. Hi, Hagan.

Hagan Rivers: Hi, Jared.

Jared: I really enjoyed reading this report. It is really a neat concept. What I really liked about it, you know it has stuff in there as before, you talk about sort of different types of structures that a web-based application can have. It was not until I started sitting down and reading this report that I realized that designers really have options and the choices they make can have dramatic effect on the results.

Hagan: Yeah, we have lots of options. We have too many options, way too many. And it is hard to sift through them and figure out what to choose. There are lots and lots of different levels to the design and they are all interconnected. So the first report is about structure, it is about the bottom level. Which is almost, almost invisible in many ways in the design process, but it has a huge effect on the rest of the design. I find that the structure stuff can be the most difficult, because it is hard to visualize. It is hard to see exactly what you are talking about. So that is one of the reasons I wanted to write the report.

Jared: Now, one of the things you talk about in the report is this idea about hubs and interviews. Can you say a little bit about what those are?

Hagan: Yeah, well I started noticing we do a lot of consulting with different software companies helping them design their software. I have worked on lots and lots and lots of products. And one of the neat things about working on such a variety of products is that you start to see patterns emerge. You see similar things, even though they are solving very different problems, they are using a lot of the same design structures in order to be able to solve those problems. So I started noticing this structure, which I called the hub, which is like this central page, were usually there is a list of stuff on the page. Not always, but usually and there are commands. And the user sits at the hub and they issue a command and they go to a spoke on the hub like the spokes on a wheel. They do the things they are going to do and then they come back to the hub and they see the list updated. And this basic structure, I find it in pretty much every single web application that is out there. And some of them are using the structure, but they are not using it well. And so, they do not really understand what structure it is they are using. So I hope to reveal some of that in the report. And then the other one is interviews, which is, I guess, better understood as a wizard in the desktop applications. And that is really a step-by-step process for gathering information and completing a task. And that is another structure that is widely used.

Jared: And so these. It is not a matter of choosing one or the other, you have to actually look at the specific part of your application and say is one a hub? Is one an interview? Right?

Hagan: Yeah, exactly. In fact they are probably not interchangeable in most places, but I find these two basic structures can be used to build just about any application.

Jared: Right. So I was working, just the other day, after reading the report, I went and I actually ordered flowers from proflowers.com, which I think is a wonderful site and has gotten me out of much trouble in my life. I have often thought that they should just start the home page with a pull down that says just how much trouble are you in?

Hagan: We will help you. [laughing]

Jared: Just the right help from there, but as you are ordering the flowers it is basically a typical order entry application, so it is an interview structure were they first start with things about the flowers you are ordering. Do you want balloons? Do you want chocolates? Do you want to upgrade for, to get twice as many roses, because really for what you just said, you are going to need the twice as many roses.

Hagan: That is right.

Jared: So they have that, but then they go on to the shipping information and who you are shipping it to and things like the card. And then they go on to billing information. They get your credit card information. They ask for your billing credit card. And then they have a confirmation page. And so that is all an interview right there. But what was interesting about the confirmation page was that it showed all of the sections that we had just entered. And it had a little edit button next to each one of those.

Hagan: Yep.

Jared: That was a hub design.

Hagan: That is right. Yeah, that is a blend between an interview and a hub. And we see that a lot in very long complex interviews, where you get to the end and the user may need to go back and change something. So, what you do is that summary page becomes your hub and at that point each step in the interview becomes an individual spoke that you can return to and make changes to. It can work really, really well. It is a pretty straightforward structure. Very effective and well understood by users.

Jared: Now, one of the things that has always annoyed me about profiles is that you get to that page and you say, “Oh, oh you know what, the card does not quite say what I wanted to say.” So you click the edit button next to it. It brings you back to page that was a card, which was the second of four in this interview. But then when you are done editing the card, it makes you fill out your billing information.

Hagan: [laugh] Woops!

Jared: Like we need to look at that screen one more time. And so, they did not quite get that that was a hub at that point.

Hagan: Right. That is right. They talked of throwing you back into the interview.

Jared: Exactly.

Hagan: Yeah. That is definitely a key mistake. I mean, at that point the user has already answered all those questions. All they need to do is go back and fix that one thing. So, it is a little more engineering work, because you have to present screen in two different ways. One way is with a next button and another way is with a done button. But you know what? It is not that hard to do.

Jared: Exactly. Yeah, as we say in the trade, it is just a simple matter of programming.

Hagan: [laughing] how hard can it be?

Jared: Yeah, exactly. [laughter] As all the programmers slam down the phones and refuse to listen to anymore of the podcast.

Hagan: That is right!

Jared: Now, one of the things that I really liked about the report was that you came up with this really ingenious way of diagramming out hubs and interviews. And I had never seen that type of diagramming, but I could see how that would be extremely useful. And in fact, for example, the Proflowers people would almost instantly point out this problem that we just talked about.

Hagan: Yeah, this diagramming that I came up with is really my own little notation system that I have developed over the years as I would visit new clients.

Jared: I am betting that it was invented on a white board.

Hagan: Yeah, I would visit new clients and they would sit down in an initial meeting and show me their product. So I am seeing a brand new product for the first time and demos are usually very fast and very intense. I needed to try to remember what I was seeing. So what I would do is diagram it using these diagrams. I would create little hubs and interviews on the paper and just label them so that I could remember of the screens I saw, how they were related to one another. I discovered in the process of creating that diagram was that I could identify problems in the first hour or two of meeting a new client. Because I could see it in the diagram I was making. I could see just what you talked about the Pro Flowers that they had failed to create a hub that they needed to or that the interview wasn’t working right. I realized that it was good tool for communicating these structures. And they do show up on white boards. In fact, I have also had clients where they take screen shots of the windows in their applications and they hang them up on the wall and they put lines in between the windows to show the relationship. As soon as you do that, you have made a hub diagram, you can see that.

Jared: I have seen that. We walked over to one of our clients the other day and they had an entire conference room dedicated to diagrams much like this. And it was not just their design but all their competitors.

Hagan: Absolutely.

Jared: It was interesting because you could instantly from six feet away see how the competitors differed by just looking at this. So that diagramming technique is really cool. Another thing that you did in the report that I really liked was you took apart supports. Where did you find that application?

Hagan: [laughing] It was funny. I was trying to find a nice, straight forward, easy to understand application that would work well in the report that I could just kind of dissect it a little bit. I needed something with a lot of screens so that it had good structure but I didn’t want any one screen to be too complicated. I didn’t want it to take up a lot of time to understand how it was working. That was kind of the details that I was into right now as much as the structure. I was filling in a ticket at our web hosting company one day and I suddenly looked at the ticketing application and this was perfect, it was absolutely perfect. It was the whole application for communicating with IT, submitting a ticket for what is wrong with your website. It is a very simple application it has a lot of screens.

Jared: It really does. You know when you first showed it, I thought this is really just a simplistic application but as you started diagramming it out.

Hagan: There is a lot there.

Jared: There really is a lot there and I thought that was really fascinating. What is really neat in the report is that you then go and revise it. First by diagramming it out, and then changing the diagram, then going back and changing the screens to reflect the diagram. Is that the process that you normally use?

Hagan: It is one of the processes that I use. I often, you can uncover problems through the diagram. And as you talk about, maybe you try to run a task through and you see that a task is hitting a lot of bumps. Maybe just too many screens and it is just too hard to finish the task. A lot of times, I will just go back to the structure diagram that I have created and say you know what is wrong with the structure here that is making this task too hard to do? And rework the structure and then think about what would that mean for how these windows are arranged in relationship to one another. Sometimes, I do it the other way around. I will fiddle with the windows. Then I will think, gosh what have I done to the structure? It is a little back and forth but the diagram help keeps me grounded in how this application is organized. And you need that grounding because when you are making changes, you are changing a lot of things and you need to remember how everything relates to one another.

Jared: Right. Plus it feels to me like it is a great tool for the team to sort of keep in touch. You can show changes, for instance, in a different color so people can say, oh this is going to affect these components and that is going to cause these schedule changes.

Hagan: Absolutely, I have definitely used it working with other designers to communicate very quickly communicate structure changes. I have also used it with clients when we sit down and do a redesign. And I show the before and after structure to show what we have done.

Jared: OK. I also really liked how many different examples you used throughout this. We didn’t just focus on the supports and applications but you showed examples from dozen of different sites. Ones that we know of like Amazon and Microsoft Money and a couple in there that I had never seen before such as Power Way, Shutterfly, and you’ve got a lot of different examples out there.

Hagan: I am a collector of web applications. I love them. I take screen shots of just about every application I ever use. Which truly slows me down if I’m doing online shopping or anything because I have to stop and take pictures of it. I am a very visual person. When I learn, I like to see pictures. I like to see examples. They help ground the information for me. The reason I use all these pictures is purely selfish. I need them to be able to understand the problems and understand the solutions. And I found as I have been teaching seminars and stuff like that, that people really enjoy seeing the photos because it helps them immediately understand what I am talking about instead of in abstract terms. I try to put a lot of pictures in and put lots of examples there.

Jared: So now this is part one of a series. What are some future things that we can expect in subsequent parts of our series here?

Hagan: Well, one of the reports that I have been working on right now is a report on how to make lists and how to deal with tables of information. So sorting, paging, and selection and how to present information in tables and all that good stuff. There is also a sampler of web applications that I have been putting together that just sort of visits several different robust, pretty well designed applications. It digs down in their design and really looks hard at them and says what went well here and what might you want to look at and copy? So both of those are in the works.

Jared: Excellent. We look forward to those. Thank you very much, Hagan.

Hagan: Thanks for having me.