Hagan Rivers is a walking encyclopedia of web app design knowledge. A frequent speaker at our events, she has an amazing knack for making the highly complex digestible and easy to understand. Examining the structure of your application can reveal the places where your users struggle and provide you with opportunities.

In today’s UIEtips, we’re reprinting an interview that I had with Hagan about web application design. It was a fun discussion, talking about how she’s come up with the concepts, such as hubs, interviews, and her technique for diagramming the structure of web apps.

Read the article, Discovering Web App Structure: A Discussion with Hagan Rivers.

Hagan will also be bringing her expertise to an upcoming UIE Virtual Seminar, Designing Dashboards: The Do’s, Don’ts, and D’ohs!. She’ll show you a bunch of dashboards. And she’ll give you tips for helping stakeholders understand the implementation benefits and drawbacks of seemingly simple components, from graphs to customizable panels. You won’t want to miss it!

I asked (on the Twitters, of course) what was the first application to use the pull-to-refresh gesture. My world of followers suggested it was the original Tweetie app, which was then acquired by the Twitter overlords. Since Tweetie, it’s shown up in a bunch of apps on my iPhone. I’m told it’s also on apps all over those Android phones that everyone talks about.

What’s interesting about the pull-to-refresh gesture is how natural it feels. Need more stuff, pull down on the list. Very simple. Very intuitive.

Well, it’s only intuitive if you know about it. You see, the problem is the gesture has no affordance (a hint or clue that the function exists). There’s no way to know where pull-to-refresh is implemented. Anyone who has learned the gesture has probably experienced the pull-to-do-nothing function in all the apps where it’s not implemented. Suddenly, something that’s novel has become a basic expectation, just like Kano taught us it would.

If you didn’t know about pull-to-refresh, how would you learn it’s in your app? For the most point, it requires you learn it from someone else.

Someone who leans over and says, “Hey, did you know you can update your list by just pulling down on your thumb?”

“No Way!” is the usual response, followed by the now-common thumb maneuver. “Cool!” is what comes next.

And it happens. Just like that. We’ve just transmitted the functionality, socially.

Pull-to-refresh isn’t the only socially-transmitted functionality. In years past, it’s how I’ve seen people learn about drag-and-drop in applications. It’s how they learn about special keys, like F5 for refresh or F1 for help. A lot of functionality has been transmitted from one person to the next, socially.

There’s nothing wrong with socially-transmitted functionality, as long as it’s not something the user needs (they can use the design just fine without it) and you have users that talk with each other. The problem comes from when you, as a designer, know about an functionality that only transmits socially, it’s hard to realize that people around you haven’t caught on yet. Just because it’s in your pattern library doesn’t mean your users will know about it.

[A note about accessibility: socially-transmitted functionality is rarely accessible in itself, as it usually has no way for a screen reader to work. For accessibility reasons, you probably want alternative access.]

In a recent site visit, I watched users struggle with navigating around a web app because the return-to-main-menu function was a not-obvious icon that looked like decoration to the untrained eye. All the developers observing the visit knew about it, but this collection of users hadn’t been infected with the knowledge of the functionality, and therefore didn’t use it. Their alternative: sign out of the app and back in again, which returned them to the top-level menu. (Boy, did that ever elicit a sigh of wonderment from the observation party!)

Do you have socially-transmitted functionality in your design? Are they things that users can live without and will be delighted when they hear about it from a friend?

It’s easy for applications to get overcomplicated and bogged down with data – especially in an enterprise setting. It’s hard to keep track of so many different things. When dashboards and widgets are employed, the goal is to make your life easier, but often that’s not the result. The solution—simplify these applications for specific use cases and give the right people the right information they need for their given task.

Hagan Rivers, of Two Rivers Consulting, spends her time meeting with teams to show them exactly how to streamline these complex applications. Whether it’s an app for managing purchase orders or hospital patients, there is a lot to consider. Hagan expresses the value of taking a step back and sifting through the complexity. This allows you to untangle the necessary bits to arrive at a better focus.

We have 8 full-day workshops at the User Interface 16 Conference in Boston, November 7-9. Hagan is bringing her expertise to one of those workshops, showcasing the methods she uses to create consistent, beautiful applications. For more details about the conference visit UIconf.com.

Here’s an excerpt from the podcast.

“…there are certain expectations we have about where buttons should be. The “OK” button is the one that’s bigger and brighter and more clickable, and the “Cancel” button is less so and they’re in a certain position. And toolbars go above tables. And the first thing is usually new or something like that. Like, if you didn’t have the language cues, how much of just the layout and the organization and the arrangement of things would lend the pattern to you.

And sometimes I show people screenshots of Japanese GUIs. And I ask them to really look at it, because they get so used to just reading the labels, especially the developers. They’re very good about actually reading everything on the screen. Users are not.

But the developers read the text on the screen. They say, “Well, it’s obvious, it says in the help text right there.” Yeah, but, OK, don’t read the text, just look at it and see what you can learn…”

Tune in to the podcast to hear Hagan address these questions:

• How do you identify and prevent unnecessary complexity?
• What is the value of “hand-holding” when a customer is experiencing a product for the first time?
• If a design isn’t in a standard pattern, can consistency alleviate any potential confusion?
• Are there exercises that teams can do to develop patterns?
• What is the best way to implement dashboards?
• Are there patterns on mobile that are making their way back to the desktop and other places?

Do you have experience with complex applications? Share your thoughts with us in our comments section.

Recorded: September, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Welcome, everyone to another episode of the SpoolCast. I am very happy, because today I have one of my favoritest people in the entire wide world of the UX space, Ms. Hagan Rivers, who is going to be speaking at the User Interface 16 Conference, which is going to be in Boston November 7th through 9th, and she’s doing a full day workshop on the 9th called “Simplifying Complex Applications.” And I’m very excited that we get a chance to talk to her today about just this topic. Welcome, Hagan.

Hagan Rivers: Thank you, Jared. It’s good to be here.

Jared: So, I have a question for you which are why we’re doing this, because I have a bunch of questions for you. Lately I’ve been working with these teams that have these designs that have been going on six, seven, eight years, right? So they’ve been around for a while, and they’ve got dozens of designers and developers who are working on this.

And just a few weeks ago, we’re watching actually a training video, so it’s a video of a customer being trained. And it’s a beautiful way to watch people use a design, because you see what the trainer is doing. They’re walking the user through the various aspects of the design, and you get to see the screens. You get to see how the new user is responding to all these things.

And one of the things I’m noticing is that as every part of the interface pops up as the trainer is walking through it. Each one has sort of a different signature look. They’re all maintenance screens, right? So, you know, one’s a customer screen – these are places where you have classes, so one’s a class setup screen, one’s an instructor screen, and each one has a capability to make changes and save, but the way you make changes and save in one screen is a “save” button, let’s say, and it’s at the top of the screen.

On the next screen, it was an “update” link that was at the bottom of the screen, and each one was different, and as we went through these, I began to realize that I could actually start to pick out which developer had probably developed which set of screens. I didn’t know the developer by name, but I knew that screens one, seven and nine were all probably developed by the same guy, because they had the same basic look to them, but screens two, five and six were done by somebody else.

And, of course, all this made the trainer’s job that much more crazy, because every time they had to sort of explain a different way of doing it. And so I’m realizing that entropy takes over and these designs become this giant hairball of complexity, and I was wondering, do you have any suggestions? What could you tell teams to do that would sort of prevent this hairball from growing as nattily as it does?

Hagan: To make it never happen in the first place?

Jared: Well, maybe, but at least to start to identify that it’s happening and maybe prevent it. I don’t know.

Hagan: Yeah. I mean, I see these apps all the time. When I meet with new clients, they demo their apps, and I see the same thing. I can tell which screens which parts of the development team did. I can tell you how many different developers there are working on the GUIs, you know?

Jared: Exactly, exactly, yeah.

Hagan: And each one has their little pet peeve about they don’t like to call it the “OK” button. They think “save” is clearer, so they always say “save,” or whatever. They all have their thing going.

And as new features get added, especially as you talked about in the preferences and stuff like that, that’s where the developers tend to do a lot of design work. They just sort of throw whatever they think works onto those screens.

So, actually, it’s interesting you talk about the training, because I did some work with a client last year, and I went and took their training. I acted as a customer and I just said, “I want to attend your training classes.” And I got so much great material there, because as we went through screens, there were all these places where the trainer had to stop and tell us what was weird about that screen, and I would take notes. I’d go, “OK. We need to fix that.”

And we’d go to the next, and they’d say, “Well, on this screen, you have to be sure to click this button first.” And I’d go, “OK. Well, we got to fix that,” you know?

Jared: Yeah, so one of the things we’ve been doing with clients is when we take these video tapes and we actually start dividing up the tape into pieces, and any place where the trainer is in essence helping the customer get value – so, in other words, that particular thing, like the customer setting up their first account or their first class or putting in their first instructor, right? They’re getting value from that, and so we call that “goal time.”

But the places where the trainer is sort of explaining – like there was one option that took about – we counted it – it was about six minutes to explain that you should always keep this number set to one. Whatever you do, don’t change it, but then went on to explain why it was there and why it might not be one for people who weren’t you, but you should always have it as one.

Hagan: Yeah, don’t touch it.

Jared: Exactly. And so we call that “tool time,” right? So that’s the time that you have to just sort of deal with the tool. And you can actually measure how good your UI is doing by the ratio of tool time to goal time, right?

And if you keep reducing tool time and increasing goal time during the training session, you’re getting real value, because there is value to hand-holding a customer through their first experience for some of these high end products. But that hand-holding is different than mine field avoidance lessons.

Hagan: That’s right. That’s right. Yeah, I mean, a lot of the apps I work on are really complicated. They’re not apps that you can typically just hunt through the web and find them. They’re the kinds of apps that are installed in enterprises, so apps for managing purchase orders or patients at a hospital or ticket systems for managing help desks – stuff like that. I mean, big, big apps, and they’re complicated, and they do often have training.

And you’re right – there’s this tool time is like just spent trying to dig through what is quirky about this app. And there are always a lot of internal inconsistencies, and I always tell folks, like, “Just pick one.” I mean, in a way, it doesn’t even matter which pattern you pick for your forms – just pick one and use that one again and again. Like, yes, they obviously can make improvements later, but the inconsistencies just throw everybody for a loop.

It hits you in training, but it hits them in QA. It hits them in documentation. It hits them all the time when they are being inconsistent.

Jared: Yeah. I think there is something to that, right, because you can have something that is illogical but consistent and it works, right? The old start button on Windows XP, right? It didn’t make sense that to shut down your machine, you press the start button except that once you learned it, it just work. It just always worked.

Hagan: That’s right. And so, if your app has, the OK button as a link on the upper right hand corner, you know that’s not how most folks do it. That’s not the standard pattern. But if you do it in every one of your screen, people will learn it and will just do it. It will be fine. But if you change it every single form, you are creating much more work. And the other thing is you are creating more engineering work. I mean if you have to recreate how you deform submission for every single form, that’s a ton of effort that’s wasted.

Jared: Well, one thing that gets me is on the American Airline site. I can go on for hours about the American Airlines. I mean but on the American Airlines site; they have this convention where the OK button is a red button. How do you like that?

Hagan: I love that.

Jared: In the lower right hand corner, it’s the farthest most right button, except occasionally, the start over button is that button.

Hagan: I’m sure the ramifications of clicking that are a lot of fun.

Jared: Yeah. If you are like me and you are trying to make a reservation quickly and you do it 20 times a year, it drives you nuts when you hit start over and you didn’t mean to. It’s like, “UGH!”

Hagan: Yeah. To answer your first question like the hair ball of complexity. I think if you do what I do. When I first meet with a client, I go around and I talk to the folks in their sales team. I talk to the folks in the support engineering. I talk to the folks that helped us. I talk to trainers and as I talked to them, they’ll tell you about these inconsistencies and they know them because they are working directly with the customer trying to deal with them.

They spend a lot of their time dealing with them every day. And you know, I see those and that’s why I know why the products got the hair ball of complexity in addition to looking at it myself. One of the first things we tackle is these patterns. They are trying to create very standardize ways to do things that you use throughout your application. The one way to do a form, one way to do a chooser, one general way to present a toolbar over a table, so that you don’t have to reinvent that all the time.

You don’t have to retrain people all the time. These complicated Apps, it’s hard enough just to understand how to work the App and do the real tasks. Much less have to wade through a complicated, difficult to use UI.

Jared: Yeah, I think they are creating a library of patterns. It’s really a good idea. People ask me this. There are now a handful of sort of general purpose patterns that people put together. Jennifer Tedwill put one together. There’s a guy in Germany who’s got a really extensive site. I don’t remember how to pronounce it. It’s German so everything I know about German I learned from Hogan’s Heroes. Which is probably not the best way to model an entire culture.

Hagan: I think that was all deliberately mispronounced.

[Editor's note: The "german guy" is actually dutch and his name is Martijn van Welie. The site is welie.com. Apologies for not getting that right in the recording.

Jared: You're probably right. There are all these third party pattern libraries that are emerging. But I still feel like there's a lot of value in sort of crafting your own library as a team, because you have a lot of really useful discussion about what is a pattern and what do we call that, and it creates a language, which I think is really important.

Hagan: Yeah. I find the same thing. If you just kind of hand an organization a pattern and say, "Here's your pattern library," they don't use it. They just shelve it. It's not their pattern. It is a pattern library, but it doesn't always apply to their apps and it doesn't make sense and they haven't even agreed to use it. So you know, we try to do a conversation with the development team, and I'll go through and I'll find the six different ways they do a chooser screen.

And we'll put them all up on a screen and we'll look at them together and we'll say, "Well, which of these do we think is the best and why?" And I'll tell them why I think which one's the best, and we'll pick one and then we'll get it recorded down in a pattern and we'll start migrating to using that for everybody.

Jared: Do you do an exercise when you do that, because I've done this with teams? Do you do an exercise where you actually say, "OK. Let's just make a list of what's different - let's not assign good or bad here. Let's just make a list of what's different between these different variations so that we can make a catalog of why each one of these things sort of existed?"

Hagan: That's right. You'll learn things, like some chooser that someone did is really good for that particular situation, because he's choosing between maybe hundreds of thousands of items, whereas another one might only for choosing amongst 50 items or a 100 items, and they do different things. And so you say, "Well, OK. When you identify these, it's not that they're good or bad. It's that they're solving different problems."

You start to build your pattern library, say, "Well, whenever we need a chooser for more than 5,000 items, we'll use the giant one, and whenever it's less than that, we'll use this one. And so if you do an exercise, you get them to think about what's making that work? Why did they choose to design it that way? And what's the purpose? What problem is it solving? How does it help the user? Then they understand why they would reuse the pattern. I think that's much stronger way to start building a pattern library than to just grab a book off the shelf.

Jared: I'm thinking this doesn't have to be a difficult thing, right? You could take, like, 15 minutes of a weekly staff meeting and just put up a chooser one week and a form next week, the way you do login authentication the week after that, and just do one a week for 15 weeks and all of a sudden you've got the start of a library.

Hagan: Yeah, it doesn't have to be super hard. I think what happens is a lot of folks get very married to the patterns that they've created and they really feel they've got the best solutions. So sometimes you do need to go out and talk with users and talk with the support folks and see what's really working for people. But most of the time when you ask people to sit down and really look at the design, and compare it to other designs solving similar problems - they're pretty quick to pick up on what needs to be done.

Jared: I have this friend who was a real film buff, and he went and studied all these film classes and would watch every DVD extra where they talked about how they made the thing. And he always wanted to go off and be a filmmaker himself. And I would go to the movies with him, and we'd be sitting in the movie theater, and this exciting thing would be happening on the screen and he'd hit me on the shoulder and he goes, "Did you see that tracking shot? That was like an awesome tracking shot!"

Or we'd be watching a video at home and he would make us go back and rewind something because the zoom was particularly good. And, it's like, "Dude, I just want to watch the guy get the girl." You know?

Hagan: What guy? What girl?

Jared: Yeah, exactly. He had stopped paying attention to any of that. He was looking at what the cameramen was doing the whole time. And so, "I figured out how they did that." And like, we'd have to watch the same scene 15 times.

Hagan: He was interested in the craft, not the product.

Jared: Exactly. Exactly. And I'm wondering if, in fact, that's what we're trying to do here with developers. They can't log into, you know, PayPal without noticing exactly how PayPal does their authentication screen, now, because they're going to pay attention to that level of detail, because we've dissected it.

Hagan: That's right. Yeah, I mean, I think, you need to be able to, kind of, step back. Like, I always think it would be fun to take a piece of software and replace all the English in it with gobbledygook. And see how much of it you could drive.

You know, there are certain expectations we have about, like, where buttons should be. You know, the "OK" button is the one that's bigger and brighter and more clickable, and the "Cancel" button is less so and they're in a certain position. And toolbars go above tables. And the first thing is usually, like, new or something like that. Like, if you didn't have the language cues, how much of just the layout and the organization and the arrangement of things would lend the pattern to you.

And sometimes I show people screenshots of Japanese GUIs and stuff. And I ask them to really look at it, because they get so used to just reading the labels, especially the developers. They're very good about actually reading everything on the screen. Users are not.

But the developers read the text on the screen. And so, they're just like, "Well, it's obvious, it says in the help text right there." Yeah, but, OK, don't read the text, just look at it and see what you can learn.

Jared: That's interesting. I actually found myself in a Dutch police station once in Amsterdam and watched the cop fill out a theft report, a friend of mine had had her purse stolen. And so, we're watching him fill out the theft report, and of course, the screen was entirely in Dutch. And yet I had no trouble following along with what he was doing, because it did follow those sorts of conventions that we're used to.

Hagan: That's right. And I have a theory that if a pattern is working well, the labels are irrelevant. They add supporting information, but you should be able to figure out how to use it without being able to read them.

Jared: Yeah, I think that makes an awful lot of sense. It is really interesting that this idea of being able to use the design independent of the language that's there. And can you drive it that way, basically, through just convention. Makes a lot of sense.

But at the same time, a trap that I see teams falling into, I don't know if you've seen this, is when they try and come up with generic designs and they use "Lorem ipsum" style text. And then, when they plug the real design in.

Hagan: It's just too generic.

Jared: It's too generic. And it doesn't handle the special cases, which is why you need the patterns for the 50,000 item selection, or is this the 3,000 item selection?

Hagan: Right. We'd worked on an app last spring. It had a bunch of wizard based forms for editing. There were a whole bunch of different objects in the system. So, they had, like, 20 different tabbed wizards for editing these 20 different objects.

And so, they all looked the same. I mean, once you opened one up, it was really hard to distinguish them. You know, I told the engineers, we need to put labels at the top, we need to repeat these labels. Like, instead of just saying, "Name," we would say, "User's name." So, it was very clear what name we meant. Or "System's name" or whatever name we were asking for. And they said, "Well, they should know by the context they're in."

And I said, "Well, the language is what gives them the context." We saw regularly, people would open up a screen in our usability study and they would forget what screen they were on. The language is the thing that gives you those cues, oh, I'm working on this. Oh, it needs to know this. And being repetitive, like, there's this real tendency to be really lean in language on some of these apps. And sometimes it's confusing.

Jared: Every pixel costs, right? So, you want to save on those characters.

Hagan: You've got to save, I know, because it might, burns out your monitor. I don't know. But yeah, it's like, there's this appreciation for brevity that doesn't really help users at all. I mean, obviously, you can swing the other way and have full sentences all the time, and that's too much. But there's this desire to be really, really concise in the language, and I think it's disorienting, sometimes.

So, yeah, I don't mean to say, if you use the pattern without seeing words that it would be perfect. But the sort of placement and arrangement of things can be very suggestive. And then, the language kind of adds to the whole context and the behavior layer on top of that. To, sort of, tell you what is this thing? How does it work? What's its relationship to other things in the system? What can you do with it? And that's what the language layer kind of gives you. Of course, the language is really critical.

Jared: Yeah, I think that the more we understand about interfaces, the more we realize that we're basically creating a language that is both visual and verbal with our users. And that the combination of the two is really important.

We saw this early on with icons, where there was this big push to have visual symbols for everything and no words. And we were working on this tool for software developers. The team had come up with this hatchet dripping blood. Which was the "Execute" program icon?

Hagan: Yeah. That'll translate well.

Jared: Yeah, exactly, yeah. A visual pun that just does not work. The funny thing was that we'd have these usability tests and all the male developers that we had come through went, "Oh, that's really cool." And all the female developers go, "Ew. Why?"

Hagan: Ew. [laughs]

Jared: So, that one really split down gender lines. But what we found early on was that when you just had pictures, often people didn’t know what the picture meant. And when you had just words, it wasn’t as good. But the picture and the word together, actually seemed to really work best.

Hagan: Yeah, the pictures give you a differentiator, so when you’re using your kind of positional memory of the toolbar in your head, you remember it’s kind of the fourth or fifth one in, the picture kind of gives you a reference point for your eye to grab onto. At least that’s my theory.

Jared: Well, you know, what was really interesting was we experimented with that. We started moving the icons around, and we found that the position wasn’t as prominent as we thought. In the early Microsoft Office apps, for example, the first icon was open and the second one was save, and the third one was print, or something like that.

But we found that if we moved them around a bit… I mean, if you completely reversed it, if you put open and close on the far right instead of the far left, people would have trouble with it. But if two icons appeared before open and close, nobody was freaked by that. It didn’t have to be the very first icon.

Hagan: Yes, I don’t think positional memory’s that absolute. I think it’s just sort of like, “it comes first-ish neighborhood” memory. But it helps. It’s an important piece of finding stuff again and again, especially in an app you use all day long.

Jared: So what’s your take on dashboards? We have a lot of clients that are doing this sort of dashboard thing, and it sort of starts with some executive declaration of, “I just want one screen that tells me exactly what my business is doing.” And the next thing you know…

Hagan: Wouldn’t that be nice?

Jared: Yes. You’ve got odometers, and speedometers, and temperature gauges. Every physical skeuomorphic gauge that man has ever come up with is now a visual element on this opening screen that nobody understands.

Hagan: Yeah, they’re trying to really create the pilot’s dashboard, which works great for pilots, but not so much for most other folks.

Jared: Except that pilots are intensely trained on those dashboards.

Hagan: That’s correct. That’s why it works for them. They need to know where things are and what to click and what to look at, whereas we present someone with something just as complicated as a pilot’s dashboard and say, here, this helps you know what your whole business is doing! And they scream and run out of the room.

So, dashboards. I can usually tell if a client knows who their users are and what they do just by looking at the dashboard. To me, I think of the dashboard as like an extra layer of navigation, actually. Like, a whole screen devoted to navigating to key parts of the application and bubbling up information from key parts of the application.

Jared: That’s interesting.

Hagan: Yes, so if you know your users, your dashboard, it reflects it. I’ll give you an example, because this is this new idea that I’ve been working on for the last year or two.

So, we worked on an app a couple months ago for managing mailing lists, email lists, and stuff like that. And they had a dashboard, and when you logged in you got this screen, and it showed you your user profile. So it showed you your first name and your last name, and a place to change your password, and those things. And then it showed you a list of the mailing lists you were subscribed to.

This dashboard was the dashboard for the administrator of the mailing lists, mind you. Not an end-user, but the administrator, the person who actually sets them up. So, there was nothing on this dashboard that was of any use to this person. And they had little meters and metrics and stuff, but it was useless. They all clicked right through it and went off to doing stuff.

So we went and talked to some of these users, and we talked to them about what do you do the most often? If you talk with them, after a while they said, well, the biggest problem they have to deal with is updating other people’s email addresses. That’s their number one problem. Like, they send out a message and a bunch of them bounce back as having failed. And they need to know who those people are so they can get it up to date, and they have to look up and manage those users and deal with the failed deliveries.

And then the other thing they do a lot is they send out these mailings. So when we were done, the dashboard now had a quick way to get to a list of users who have disabled email addresses due to delivery failures. So you could just say, 150 people right now, their emails are no good, click here to go straight to them. A quick way to look at users who don’t have email or are out of sync however with the system. We even had a little box right there where you could type in an old email address and a new email address and just push a button, and it would just look it up and do the swap.

So that was, again, we were looking, what’s the common task? And then we had a place for starting new messages and sending them out. So we went out and said, what’s done really commonly, what’s really hard to do, what things do you have trouble finding? And those were all the things we bubbled up and put on the dashboard. And we had some reporting stuff too, but it was mostly like, how many mailing lists do you have, how many total users on each mailing list? Just some very simple metrics, and they were not giant dials, they were just some very straightforward numbers.

So the idea is that the dashboard is like storytelling. It tells you the story of what the app does, and the most frequent things you’re going to do with it. And it navigates you very quickly to those key places to support those tasks. Most dashboards don’t do that.

Jared: Yes, that to me makes a lot of sense. So, you could have it, for instance, if you had items that needed attending, you could have it put the number of items that need your attention in red for those things, much like the way unread messages show up on an iPhone, or something of that sort.

Hagan: Right. For instance, in a lot of apps, you’ll have a list of stuff and you can filter that list. So it’s possible to go in and set up whatever filters you need to find something out. But on the dashboard, you could put five links to the most important filters that the user’s going to need a lot, and it just immediately takes you to that page and applies those filters and gets you up and running. And you don’t have to do anything more complicated than that, it just gets them going and gets them started on their work.

Jared: Yeah, because I think a lot of these sort of visual elements, though, they might demo well just from an “Ooh, that’s very impressive,” the dials and gauges and stuff. I think the amount of information that they communicate for the number of pixels that they use, that sort of data-to-ink ratio is probably pretty low.

Hagan: Yeah, it’s very low. We’ve done a lot of work cleaning those up to try to increase the information density, and it’s really low. The other thing is I think, at least I’m finding with our clients’ customers, you know, a year or two ago, they would just be really wowed by seeing a dashboard covered in these controls. But now, when I go and sit in on sales meetings, I hear them saying, “Well, what is this for? What is it telling me?”

So, the customers are starting to become more critical of these flashy screens and really asking what they’re good for. And I think that’s going to be what drives improvement in the design, is that the customer is getting a little jaded about all those bells and whistles.

Jared: So, we have this definition of the word “clutter.” Every so often, you’ll be sitting in a usability test and a user will tell you, “That screen feels really cluttered to me.” And what we’ve realized is that clutter doesn’t mean high information density. Clutter means there’s a lot of stuff on the screen that I either don’t understand or I don’t care about. And there’s very little stuff that I care about.

And I’ve actually seen screens where we did a before and after of a design. And the before, the user told us, was much more cluttered than the after. But the after had more information on it than the before did. And what made it less cluttered was that all the information we had designed to be relevant to something that user needed.

And so, I think what I’m hearing you say is that these dashboards that don’t do well, that the users are now saying that maybe that’s that clutter effect, right? They’re looking at this dashboard that has a lot of stuff on it, but it’s not stuff that they are interested in in running their business or doing their job or whatever their operation is. And if you replaced it with stuff that was actually, really important.

So, one of the things is, we have this client who has this application. It’s a subscription thing, it’s a monthly subscription thing. So, every night it goes and runs a batch of credit cards for the people who are renewing on that day of the month.

And the first thing every one of these business owners of these customers did is that they would go to the report that told them how that job did, which credit cards got declined, how many got declined. Because that pretty much set their to-do list for the day of who they had to contact and say, “Hey, your card is expired,” or “Your bank’s not accepting this charge anymore and we need a new card or we’re going to have to shut off your service.” And that wasn’t on the dashboard. Right? Yet it was the most important thing that pretty much every customer we went to visit did.

Or just checking to make sure the job ran at all, because there are random nights where, for whatever reason, things don’t go well and nothing was charged, right? And the batch is left hanging, because of some technical error.

And so, having this thing that says, yeah, last night, we ran 23 credit cards and every single one of them cleared, would save, like, A, six clicks, and give something incredibly useful that that person wants to know when they first login in the morning.

Hagan: That’s right. And that’s what I mean about it being kind of a mechanism for bubbling up key information and giving the user a quick way to get into, maybe, deep places in the application to do tasks that they have.

So, I have this funny exercise I do with clients now where we do a demo of their product very early in the process. And they bring up their dashboard screen. And I say, “OK, let’s take a look at this. I’m going to go through this screen, and I’m going to tell you what I think, based on this screen, are the most important things in your app.”

And we go through the screen and it’s mostly garbage. I mean, it’s just sort of like random stuff we’re able to tell you, but has no bearing on things you do, or things you care about. And they quickly realize that they really haven’t given it much thought. They just sort of threw everything on there that they had, rather than spending any time thinking about how people use the app.

Jared: Your content management system has 47,000 letter E’s in it today.

Hagan: Yes, exactly. And those are the kind of stats they’ll give you. And it’s like, thanks.

Jared: Sixty four percent of words are spelled correctly.

Hagan: Yeah. One million three hundred and twenty two pages. Great. OK. Why isn’t it 323? I don’t know. Like, it’s just data and they’re just sort of flooding you with this firehouse of data. And it’s not useful.

Jared: So, you really have to get into the head of the user to figure out how to do a dashboard right.

Hagan: You really do. I mean, you can build your app and never put a dashboard on it. The dashboard is a completely separate layer. It doesn’t do anything that the app doesn’t already do. It doesn’t tell you anything that the app already doesn’t have in it.

So, the question is, why are you putting it on there? If it’s just to be a sales gimmick, yeah, I guess. But I think the clock’s running out on how much people are going to love that in sales calls.

You really want to say, we know our app is complicated, we know there’s a lot there, and we’ve really spent some time studying what our users need to know, and what they need to do, and we’ve incorporated those things here.

Jared: So, one of the things that we’ve been doing when we go out on customer visits is we say, OK, so what’s the first thing you do every day? And we have the person we’re visiting actually walk us through those sorts of first steps. So, if we start to see patterns from one visit to the next, of a first thing that everybody does each day, that, to some extent, is telling us what a good dashboard entry might be.

Hagan: That’s right. And that’s why I say, I can usually tell if my customers know their customers just by looking at their dashboard. If they know what they’re users are doing with their app, and they know what information their users need to have, then their dashboard will show it.

Jared: I wonder if this is one of those places where self design, you know, designing an app that you also use yourself on a regular basis, actually really helps, because you know what you want to see. And if your behavior matches your users’ behaviors, you know, which doesn’t happen that often, but programmers creating tools for other programmers. People who are business owners creating something for other business owners. It does happen.

You can get away with that. But if you’re not in that space where you’re not a user of this thing, the odds of you coming up with what those dashboard things, without doing serious research is probably very slim.

Hagan: So we worked on a help desk application a couple years ago. This was an app where we had some really different types of users, different personas that we were working with. A help desk tickets come in. End users have problems, they submit tickets, and then there are the people running the help desk.

There are the folks that answer the help tickets, the front line worker. What they do with the app is they go through their list and they work through their tickets, right? I mean, that’s their job. Then there’s their manager and their manager might manage 20 or 30 of these people and they want to know things like who’s doing the fastest job of going through these tickets?

Who’s got the longest back log? What do I do when this person’s out on Tuesday and I need to redistribute his tickets? And they were using the same dashboard for both of these user types and they had totally different needs, you know? And so we separated it out. We had two different dashboards.

Sometimes the managers did answer tickets so they would use the ticket answerer’s dashboard sometimes which was a list of your tickets that you were assigned to and helped you deal with that. What’s the highest priority, things like that.

Then there was this separate place that managers could go that would show who are your top performers. Who has the greatest back log of high priority tickets, things like that and they could look it up and find that information really quickly. All that information was already in the app. You could have gone and gotten it any way you wanted but the dashboard collected it all together in one place.

Jared: I would think, also, that the dashboard would be an opportunity to plug other things in that may not be part of the app like server up time statistics and things like that, that would be specific to, “what is the current state of a given server right now” so that if all of a sudden a slew of calls comes in, “hey the system’s not working”, you have this up to date information that says, “oh yeah, we know.”

Hagan: Exactly. The router’s down, we’re dealing with it. Exactly. You can bring in that information. A lot of folks, especially in IT, they like for the dashboard to include information about the app itself. Is the app running properly? Was it able to contact everything it needed to? Sometimes the problem is the app itself is breaking down and so they love to see that information.

Jared: Right. It seems to me that things like dashboards and stuff are going to be moving to mobile platforms, that there’s an opportunity to have a way to bring this up. Are you seeing… now that people are using things like iPad and Android and stuff like that are there patterns there that are coming back into the desktop?

You know, Apple just recently with their newest release changed the direction of scrollbars. Are we going to see some of those visual tropes that have been happening with the IOS operating system are we going to see those starting to come back on the desktop and other places?

Hagan: I definitely think so. They didn’t just change the way scrollbars work, they now hide the scrollbars when you’re not in the scrolling area which is a direct lift off of the IOS platform because they don’t have many pixels. They don’t want to clutter it up by showing you a scrollbar.

Jared: Yeah, I wonder how long that’s going to last because you need some sort of visual clue that there’s more.

Hagan: Yeah, I mean I think the number of patterns we have is always increasing. We always have new problems to solve and the patterns are really just an expression of what we commonly do to solve these problems. And as the interactions evolve and we use different preferences, we use touch, we use different things, the patterns adjust and what we consider normal, changes.

One example on the IOS devices is for instance in a list of phone numbers, so I’ll have a list of people’s names and they’ll have a row for the name and then they’ll have a little circle on the end on the right. If you click anywhere in the row you make the phone call. If you click on the little circle you go edit the address book card for that person, right?

That’s a completely new pattern that was developed on mobile and it would not surprise me if in a year or two we see that coming back to desktop. Stuff like that. So yeah, the pattern space is always increasing. Interestingly, I’ve been putting this class together and a lot of the patterns from desktop from 30 years ago and from web still apply in the mobile space.

So, there’s an enormous amount of overlap between them. I think they’re all converging into one big pattern space that just keeps growing.

Jared: Any of those 30 year old patterns that really shocked you like oh my God we still use that?

Hagan: We still use this basic desktop form for tables. A table with a toolbar above it. That has not changed. Mobile has a little trouble with tables because they’re wide. And so mobile is using more of what I call a list where you don’t really have columns you kind of wrap stuff into thick rows but they still have a toolbar at the top or the bottom. It’s the same idea.

Jared: Yeah, OK. Yeah, it’s true. That goes back to almost pre-Windows days where, yeah, using DOS and character based displays.

Hagan: Yeah. And honestly you look at the design for tables. You click on the header to sort it. Sometimes you can click on the header, right click, and you open a little menu of other options. I mean, those patterns really haven’t changed and they work really well. Why fiddle with them?

Jared: Yup. That makes perfect sense to me. Well, Hagan, it is wonderful talking to you. I’m really excited about the class that’s coming up in November. I think it’s going to be a lot of fun. I’m really looking forward to learning all sorts of great stuff.

It sounds like the perfect class for folks who really want to get a handle on how to get that stylistic essence of their individualistic design traits for each developer out of the design so it feels like it was written by one person.

Hagan: Yes. We’re going to work on consistency but we’re also going to work on it being beautiful and elegant and solving people’s problems.

Jared: That sounds excellent. I’m looking forward to it a lot. Thanks for taking the time to talk to us today.

Hagan: Thank you.

Jared: So if you want to take Hagan’s workshop it’s easy. You just go to UIConf.com and you sign up for the three day event and you have to sign up right away because her session’s going to fill up. I got to tell you that. It always does. So UIConf.com. That’ll be November seven through nine.

Hagan’s going to do a full day workshop on the ninth on dealing with complex applications, how you make complex applications so much simpler. So I’m looking forward to that. Thank you Hagan for spending the time with us today and I’d like to thank the audience for once again encouraging our behavior. Take care. We’ll talk to you soon.

Back in the early days of PC computing, we were interested in how people used all those options, controls, and settings that software designers put into their applications. How much do users customize their applications?

We embarked on a little experiment. We asked a ton of people to send us their settings file for Microsoft Word. At the time, MS Word stored all the settings in a file named something like config.ini, so we asked people to locate that file on their hard disk and email it to us. Several hundred folks did just that.

We then wrote a program to analyze the files, counting up how many people had changed the 150+ settings in the applications and which settings they had changed.

What we found was really interesting. Less than 5% of the users we surveyed had changed any settings at all. More than 95% had kept the settings in the exact configuration that the program installed in.

This was particularly curious because some of the program’s defaults were notable. For example, the program had a feature that would automatically save your work as edited a document, to prevent losing anything in case of a system or program failure. In the default settings for the version we analyzed, this feature was disabled. Users had to explicitly turn it on to make it work.

Of course, this mean that 95% of the users were running with autosave turned off. When we interviewed a sample of them, they all told us the same thing: They assumed Microsoft had delivered it turned off for a reason, therefore who were they to set it otherwise. “Microsoft must know what they are doing,” several of the participants told us.

We thought about that and wondered what the rationale was for keeping such an important feature turned off. We thought that maybe they were concerned about people running off floppies or those who had slow or small disks. Autosave does have performance implications, so maybe they were optimizing the behavior for the worst case, assuming that users who had the luxury to use the feature would turn it on.

We had friends in the Microsoft Office group, so we asked them about the choice of delivering the feature disabled. We explained our hypothesis about optimizing for performance. They asked around and told us our hypothesis was incorrect.

It turns out the reason the feature was disabled in that release was not because they had thought about the user’s needs. Instead, it was because a programmer had made a decision to initialize the config.ini file with all zeroes. Making a file filled with zeroes is a quick little program, so that’s what he wrote, assuming that, at some point later, someone would tell him what the “real defaults” should be. Nobody ever got around to telling him.

Since zero in binary means off, the autosave setting, along with a lot of other settings, were automatically disabled. The users’ assumption that Microsoft had given this careful consideration turned out not to be the case.

We also asked our participants for background information, like age and occupation, to see if that made a difference. It didn’t, except one category of people who almost always changed their settings: programmers and designers. They often had changed more than 40% (and some had changed as much as 80%) of the options in the program.

It seems programmers and designers like to customize their environment. Who would’ve guessed? Could that be why they chose their profession?

(Big takeaway: If you’re a programmer or designer, then you’re not like most people. Just because you change your settings in apps you use doesn’t mean that your users will, unless they are also programmers and designers.)

We’ve repeated this experiment in various forms over the years. We’ve found it to be consistently true: users rarely change their settings.

If your application has settings, have you looked to see what your users do? How many have changed them? Are the defaults the optimal choice? Does your settings screen explain the implications of each setting and give your users a good reason for mucking with the defaults?

What happens over time with applications is a design entropy sets in. As new features are added, they are glued on top of old ones, often with slightly different interfaces. Slowly, the application starts to develop a Frankenstein look-and-feel, which hurts the users and the business.

Teams can avoid all this. Using established, well thought out, and proven user interface design patterns, teams can hedge these problems off before they become unmanageable. Even the worst applications can benefit from the careful hand of applying the best design practices.

There’s no one who knows how to deal with hedging off design entropy than Hagan Rivers. I first met Hagan back in 1995, when she was working for Netscape as one of the world’s first web application designers. Since then, she’s become a world expert in interface design, helping hundreds of teams get their application UIs under control.

I’ve had several opportunities to work with Hagan on various projects. Each time, I walk away learning new design techniquesn and feel smarter about how to tackle even the most complex hairball of an app.

Hagan probably has the biggest collection of application design examples I’ve ever seen. Everytime she delivers her workshops and presentations, she brings out these stunningly amazing sets of both good and bad examples. You can instantly see how changing a design in just a few simple steps can immediately make for a better user experience.

This year, I’ve been working with Hagan on her full-day workshop for the User Interface 16 Conference. She’s putting together a intense program, where you’ll walk through practically every type of interface element, from tables and lists, to working with trees, forms, and wizards. She’ll tackle the gnarly topics of simplifying a complex navigation scheme and creating an effective dashboard display.

Anyone who is fighting design entropy, trying to get their application’s UI under control will be riveted by this in-depth workshop. I’m so happy Hagan’s on our UI16 program and I know you’ll love her session.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

The last stop of the UIE Web App Masters Tour is in Minneapolis, June 27-28. Hundreds of web application designers, from all over have found inspiration from our world-class experts. Experience it yourself later this month. And below, you’ll find a special offer to help make attending this Tour stop a little easier.

The UIE Web App Masters Tour is coming to an end. I’m sad because I really wish we could keep going, bringing this merry band of thought leaders to designers all over the world. I’m excited because every tour stop gets better than the last. Minneapolis is sure to be our best.

But don’t just take our word on how awesome this Tour is. Here’s what some past attendees had to say:

I received valuable, instantly applicable action items that will improve my products with regards to design and user search.
– Seattle attendee

I went to #UIEWAMT to find a direction and you guys definitely provided me with one. Many, many thanks.
– @PattiHermoso

We loved our experience at #UIEWAMT and found the content very valuable for our current environment. Thank you to all the presenters!
- @cognitionstudio

Absolutely one of the BEST conferences I’ve been to. Each speaker brought valuable lessons we can take away with us.
- Philadelphia attendee

This Tour Changes the Way You Design

Across two days, nine leading experts in web-based application design share their experience and wisdom, to show you concrete examples on how to take your work to new levels. They tackle the issues of mobile strategy, data visualization, design patterns, engagement, and process best practices. Attendees come away with a full brain and a pile of new ideas, ready to start making improvements right away.

These 9 Masters rock this Tour.

Stephen Anderson shows us how to engage users by presenting information in a clearer and more precise manner.

Josh Clark tackles the question of building a web-based interface or implementing a native app.

Luke Wroblewski dazzles us on how to think about and design for Web organization, actions, inputs, and layout on small screens.

Noah Iliinsky demonstrates how to turn mountains of data into beautiful visualizations.

Bill Scott shares his collection of design patterns and best practices for creating immersing and rich experiences.

Kate Brigham describes how PatientsLikeMe translates data that is mind-boggling in complexity into useful simplicity.

Aviva Rosenstein gives you a peek on how Salesforce.com take advantage of cutting-edge UX techniques.

Mike Lee explains how his team at AARP incorporates a design strategy through major organizational changes.

Jared Spool shares the latest UIE research in two presentations.

Read all about each Master’s session on the web site.

Special Deal for Our Blog Readers

It would be downright awful if you missed this last tour stop. So we’ve put together a special deal. Just use the promotion code TOURBLOG when you register and you’ll get the $895 price – $200 off from the final price. Be sure to register by June 21 to get this discount.

Don’t miss the event of a lifetime. Join us in Minneapolis and inject new energy and inspiration into your designs.

Pam Rodriguez and Luke Wroblewski did a nice job of posting their notes. Thanks guys!

• Steve Portigal on Design Fieldwork: Uncovering Innovation from the Outside In – Pam’s notes, Luke’s notes.
• Kate Brigham on PatientsLikeMe: Adventures with Data Visualizations – Pam’s Notes, Luke’s Notes.
• Luke Wroblewski on Designing Mobile Web Experiences – Pam’s Notes.
• Mike Lee on AARP: Designing a Strategy for Organizational Transformations – Pam’s Notes, Luke’s Notes.
• My presentation on The Essential Principles behind Great Design Principles – Pam’s Notes.

As you can see from the #UIEWAMT Twitter stream, everybody had a great time and we all learned a ton.

There’s one more stop on the 2011 tour – Minneapolis on June 27-28. Use the promo code BLOG and get $100 off the registration price.

See you there!

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Minneapolis

Blogger Pam Rodriguez has done a tremendous job summarizing the first day’s sessions. You can read them here:

• My talk: Mobilism & UX: Inside the Eye of the Perfect Storm
• Bill Scott’s talk: Designing for Mice and Men
• Josh Clark’s talk: Mobile Apps: Native or Web-Based?
• Noah Iliinsky’s talk: The Steps to Beautiful Visualizations
• Julie Zhuo’s talk: Facebook: Data-Informed vs. Data-Driven Design Decisions

Our own Web App Master, Luke Wroblewski, also has some great summaries:

• My talk: Mobilism & UX: Inside the Eye of the Perfect Storm
• Bill Scott’s talk: Designing for Mice and Men
• Josh Clark’s talk: Mobile Apps: Native or Web-Based?
• Noah Iliinsky’s talk: The Steps to Beautiful Visualizations
• Julie Zhuo’s talk: Facebook: Data-Informed vs. Data-Driven Design Decisions

Thanks to Pam and Luke for taking such great notes.

You can follow along with the second day by following the #UIEWAMT hashtag or the UIE Web App Tour attendee and speaker Twitter list.

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Seattle · Minneapolis

Great design principles guide your team to creating designs that delight your users. They are well thought out and often based on research. Having a set of great principles will allow your team to turn ordinary design into extraordinary design. But not everyone has great design principles. What even constitutes a great design principle?

Jared Spool understands what it takes to create good design. In his talk The Essential Principles Behind Great Design Principles, from this year’s Web App Masters Tour, Jared dives into our latest research on what teams are doing it right and which are missing the mark.

Great design principles are born out of research and observation. If you sit and have a meeting to discuss “what you want to be when you grow up”, you might end up with vague or convoluted principles. You’re not basing your decisions on your actual users’ experiences. Conversely, the Windows 7 desktop team collected a large amount of data on the failings of Windows Vista to develop their principles and by all accounts, turned out a much better experience.

Creating a set of great design principles shouldn’t be about striving for vague goals like being “universal” or “clean”. They should be developed to solve problems and address real issues with your product. Principles are the guide to getting your team to the project’s end goal and fulfilling the vision you had for it. As Jared says, “if you know where you’re going, it doesn’t matter how fast you get there.”

Conducting field research and gathering data can help you determine your top priorities. Once you make that determination, you can then take steps toward developing design principles that will ultimately guide your team in making great design decisions.

Don’t miss Jared in either of his two talks at the Web App Masters tour. The tour is making stops in Seattle in May and Minneapolis in June. For more information on Jared and all 11 Masters, visit UIETour.com.

UIE Web App Masters Tour:
Get $100 off the Seattle Masters Tour with the promotion code BLOG.
Last Stop! Minneapolis

Recorded: March, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

In this week’s UIEtips, we reach back into the articles archives and look at some of the challenges we’ve seen users encounter in our usability tests. These are challenges to look out for when users interact with your applications. I hope you enjoy it.

Read the article, 3 Important Usability Challenges for Designing Web Apps.

At UIE, a big part of our research agenda focuses on how to create web applications that delight users. We feel it’s so important that we created a conference focusing on web applications. It’s the Web App Masters Tour.

During the 2 day conference, you’ll hear from 9 Masters on mobile design strategy, data visualization and design best practices. Get all the details on the Seattle and Minneapolis stops at http://www.UIETour.com.

Analyzing data is a great way to make design decisions. But when your analytics log contains billions of clicks, how do you distinguish which ones you should use in forming those decisions? Users’ behavior and activity can provide you with great information and insights. But when do you look to that and when do you trust your own instincts?

Julie Zhuo is the Product Design Manager at Facebook. In her talk at this year’s Web App Masters Tour, Facebook: Data-Informed vs. Data-Driven Design Decisions, Julie discusses Facebook’s design process. The Facebook team uses data to learn about users’ pain points and to support their own intuitions.

Facebook’s deactivation page shows you pictures of your friends to encourage you to reconsider.

Julie and her team know there are downsides to being too data-driven. Numbers and metrics can always look good on paper, but they don’t necessarily speak to your users’ emotions about your brand and image. If you’ve implemented a change that, from an analytics standpoint, works and is successful but leaves a bad taste in the mouths of your users, is it really as successful as initially thought?

Facebook faces some unique design challenges. With 600 million users all over the world, it’s impossible to predict how each individual is going interact with Facebook. Implementing a design or functionality change may thrill many users, but it is equally possible that it will disappoint others. They have to balance user interests against network interests, and certain rules need to be in place to encourage the right types of interactions between people.

Ultimately, data and metrics are great for making design decisions, but they’re only part of the process. Especially for a social network like Facebook, there are many other factors that need strong consideration. How you interpret and use that data is especially important. Having a sense of what your team values from certain endeavors will go a long way to helping inform your decisions.

Come see Julie discuss more of how Facebook confronts these challenges at the Web App Masters Tour. She is one of 11 amazing Masters sharing their insights. The Tour is coming to Seattle in May and Minneapolis in June. For more information visit UIETour.com.

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Last Stop! Minneapolis

Recorded: March, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Josh Clark is a designer and author of the book Tapworthy. In his Virtual Seminar, Mobile Design: Designing Tapworthy Mobile Apps, Josh suggests that designing for mobile is becoming more a question of ergonomics and industrial design. Our audience had so many questions that Josh couldn’t answer them all during the session. So, he met with Adam Churchill to discuss those remaining questions for this podcast.

Here’s an excerpt from the podcast.

“…you really are doing kind of an exercise in industrial design. All these touch-screen devices, they really are blank before you turn them on, before you fire up an app.

So what that means is that it’s really waiting for you to impose an interface on it. And because it’s a physical device, something that’s meant to be worked with hands and fingers, your interface becomes physical, too. So you have to think about where do your fingers and thumbs fall naturally?

And it also means kind of following industrial design precepts. It actually turns a lot of our preconceptions about what design should be for the web or for software in general, literally upside down. We’re used to having primary controls and navigation at the top of the screen where it’s sort of most visually prominent.

It turns out in mobile that the best place to put it ergonomically is at the bottom. If you’re holding the phone in one hand, as we typically are, that means that you’re basically using just your thumb to tap through this. And sort of the comfortable area for the thumb is on the opposite side of the screen and at the bottom. So if you’re holding it in your right hand that means that the most comfortable area to tap is the left side and left corner of the screen, which means [the bottom] is a great place to put primary controls.

And this, like I said, follows sort of a basic principle of industrial design, that you always want to put controls at the bottom and display at the top, for the simple reason that you don’t want your fingers covering the content.

It really means that the primary area for controls and sort of the main buttons are at the bottom of the screen instead of at the top. And that’s, I think, one of the big takeaways. While it’s common sense, it doesn’t necessarily hit people while they’re working on their designs, usually in a desktop setting…”

Tune in to the podcast to hear Josh cover these additional points:

• Should mobile websites actually feature different content from their big screen counterparts?
• What’s your opinion on native iPhone applications versus web applications?
• What do you think of using web technologies like HTML and JavaScript, as examples, for cross platform native apps?
• How does the difference in the sizes of Android devices affect the optimal function?
• What do I need to consider for left handed users?
• What differences are there when it comes to designing for tablets?
• What impact does loading performance have on an app user experience?

Recorded: April, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Transcript Available ]

Business needs can be complex. They come from all over the enterprise, originating from initiatives (like marketing campaigns), infrastructure (like inventory constraints), and regulations (like export restrictions). Suddenly a simple task, like paying for a product, becomes crazy-complicated.

In today’s UIEtips, we look back on an article from January 2010 where I discuss how the best designers thrive within this world of wacky constraints, coming up with ingenious ways to meet the business requirements while ensuring a delightful user experience. If you design web apps, this should be interesting.

Read the article, Web Apps – Where Business Needs and User Needs Collide.

Web app design is at the forefront of our minds this month. We just finished our Philadelphia tour stop, and it was a huge success. Our next stop is Seattle on May 23-24 and then Minneapolis on June 27-28. We’re wicked excited about the program, and I’m betting you’ll be too as soon as you check it out. Go see it at http://www.UIETour.com

Hear the Masters’ Insights on mobile design, data visualization, and design process. Visit UIETour.com

Here he tells the story of his brother and how it inspired him to look into the data of 45,000 people who are reporting their daily status with the diseases, drugs, and treatments in their lives. The end result is a “time machine”-like report that helps understand what can really improve the quality of people’s lives. I loved the 1-page summary of their health that patients can take to their doctors, to show exactly what they’ve been doing and how it’s been working.

This video encapsulates exactly what Stephen Anderson talked about in his podcast, The Quest for Emotional Engagement. If we can find a connection between the data we have and what’s meaningful in people’s lives, we can really make a difference to them.

It’s no accident that we’re talking about this at this year’s Web App Masters Tour. I think this is a critical conversation we need to have about how we bring the most out of our designs. On this topic alone, I’m pleased that Stephen Anderson will explore this idea of emotional engagement, Noah Iliinsky will how us how to create great visualizations like the ones Jamie demonstrates, and Kate Brigham will share what it’s like leading PatientsLikeMe’s UX team — making all this a reality for their 45,000+ users.

Register with the promotion code WAMT by March 11, 2011 for any of the Tour cities and pay just $795.

Up until now, mobile has been elusive for us. You see, we don’t talk about a subject just because it’s the latest fad. There are plenty of sources for hype-ridden design topics.

Instead, we wait until real expertise starts to take form. We keep looking for people who have a broad range of experience — the kind of folks who can answer all the difficult questions our audiences will throw at them.

When a topic is in its infancy, at best, the most advanced folks have experience doing one, maybe two designs. They don’t have the breadth of experience to deal with all sorts of difficult situations, only those situations they happened to encounter in their short-lived experience.

Our approach is to wait, to see what comes from it. If it’s just hype, then it goes away quickly, to be replaced by something new. But if it’s real, well, we can identify some experienced talent.

Mobile Emerging

Last year, a new book was all the rage: Josh Clark’s Tapworthy. We loved the book. At last fall’s IDEA conference, I was excited to share the stage with Josh. Turns out, Josh blew the audience away with a presentation on putting together a mobile design strategy. It was clever and information rich — which is perfect for a UIE program. I knew we had to have Josh on our program.

Luke Wroblewski was a top speaker from last year’s inaugural Web App Masters Tour. We had to have him back. Because of his shift from being Yahoo!’s Chief Design Architect to founding his own startup, he’s been thinking a lot about designing for mobile. He’s putting together a great presentation on what’s he’s learning about designing for a mobile experience first. We’ve been working through his outline, and the presentation is quite exciting.

I also reached out directly to Bill Scott, another of last year’s tour top speakers. He’s back at Netflix, now working on their sign-up experience. As we started discussing ideas for his topics, he shared what he’s been working on: making Netflix easy to sign up and manage on a multitude of devices — everything from iPads to Playstations. He’s been deep in making the subtle interactions work, like how you deal with hover and scrolling, with a range of input devices. (Does your app work with an internet-enabled TV remote control?) Turns out there are many general principles that every designer needs to know.

Our tour always includes people in the thick of designing their web-based applications, so we can hear their experiences. AARP has done an amazing job of keeping a 50-year-old organization completely state of the art. Mike Lee and I started hashing out what he could share, and guess what? AARP’s new efforts of shifting their publications and services to a mobile platform was the big story. He’ll share the trials and tribulations of turning the cruise ship to meet the new challenges of the mobile world.

While all of this was going on, I was thinking about what’s happening with experience design overall. It’s clear that there’s an energy around UX design that is far more vibrant than ever before. I wanted to know where that was coming from. As I dug into our research, I realized there are multiple forces making all this happen. And right in the middle of these forces is the world of designing for mobile. These forces are really strong, which means they’ll affect all of us. Want to know what they are? I’ll tell you at the tour.

When I set out for this year’s program, I didn’t expect half of the sessions to have mobile at their core. But here we are and I’m really excited about it. It’ll be a much deeper treatment than any we’ve seen before, which is perfect for the mission of the Web App Masters Tour — to prepare every web-based application designer for the intense challenges ahead.

[By the way, we're just a few weeks away from our Philadelphia stop on the tour. We're also stopping in Seattle and Minneapolis later this spring. Register for any stop by March 11 with the promotion code WAMT and you'll get $300 off the final registration price.]

Register with the promotion code WAMT by March 11, 2011 for any of the Tour cities and pay just $795.

Subscribe to our podcast via

With mobile quickly emerging as a viable and practical source of web based content, designers need to know how to adapt and keep up. With the sheer number of different devices out there it can be a daunting prospect. When do you need a mobile website? When should you have an app? What tools and techniques should you employ to address the needs of your users?

Josh Clark is a designer, developer and author of the book Tapworthy. He will also be joining us as one of the masters on our 2011 Web App Masters Tour this spring. And not only that, he will be presenting a Virtual Seminar with us in March. Josh joins Jared Spool in this podcast for a discussion about making the decision between mobile web and native apps.

Here’s an excerpt from the podcast.

“…in the same way that the phone demands a very different interface than the desktop, this middle ground area of tablet really does as well.

So one way that I think about it is that you have your mobile phone when you’re on the way to the coffee shop, but it’s your iPad that you use at the coffee shop.

The iPad is a device of calm and contemplation. It’s something that I’ve observed. A lot of people, if they’ve got an iPad on their desk, they’ll literally pick it up and go and sit in a more comfortable chair.

It’s something for a calmer state of mind for longer sessions than the iPhone.

And of course with the form factor too, it means that your hands and fingers rest in different areas. You have to use more of your arm than just a flick of the finger as you would with the phone.

So in fact when you’re designing for touch, this is one of the biggest things that I think is new for designers when they approach a touch screen platform, is that you really have to think about the physicality of the device.

To press a button on the iPad isn’t just a flick of the wrist like it would be to move the mouse on a desktop. You have to haul your arm over.

So there are honest to God issues of ergonomics to consider when you’re designing for touch devices. It’s entirely new to designers who are accustomed to the desktop.

So what you find a lot, I think, is that it’s not just a challenge of graphic design, which we as software designers on the desktop are often largely accustomed to. It’s really a challenge of industrial design because these devices are just blank slates with no interface to speak of until you impose one on it.

And because your interface defines the physicality of this device because it’s going to be worked by hands and fingers, then it means that you have to have all these ergonomic considerations of button placement. Where’s it going to be easiest for your hands to get at quickly?

Is it large enough? Are the things spaced out enough for fingers? It’s really like designing a physical handheld device in a lot of ways…”

Tune in to the podcast as Josh also covers these points:

• Are the basic principles of mobile design going to stay the same for a while or are they changing?
• How does a designer keep up with all of the different sizes and form factors of mobile devices?
• Is it good practice to make a browser version to test limitations and get a better idea of what the native app needs to be?
• What are the benefits of creating native apps for all the different platforms?

We’re really excited about the 2011 Web App Masters Tour. We’ll be coming to Philadelphia, Seattle, and Minnesota. Josh and 8 other Masters will share their insights and knowledge when it comes to designing web applications. We hope you’ll join us too.

Register with the promotion code WAMT by March 4, 2011 for any of the Tour cities and get $100 off.

Subscribe to our podcast via

The number of places that you can access the web grows every day. People can see your content on TVs, tablets and mobile phones as well as the more traditional desktop and laptop. But are you designing for it? How do your users see it? And more importantly, how are they interacting with it?

Bill Scott is the Director of UI Engineering at Netflix. He is responsible for making sure that the Netflix service looks as it should and works properly no matter how you access it. In this podcast, Bill joins Jared Spool and discusses the challenges and a few of the surprises that come with designing for multiple platforms.

Here’s an excerpt from the podcast.

“…Luke Wroblewski, as you know, and others have started the “design for mobile first” which is really “design for constraints first”. You take a more-constrained view of what you can do in the application, either through input or screen size, maybe you’re on the go, and it forces you to think of the main things first. What are the most important items, tasks or goals that the user has, and design for those.

With the living room, with the left-right-up-down [of a remote control], something’s always focused. And you’re always moving from one item to the other. But then, when you move to a pointer-based [system], nothing necessarily has focus. You have random access to things on the screen; you can get to something quicker. With left-right-up-down, your keyboard is usually virtual, on the screen, and those still need a lot of work. We’re doing some A/B testing in April on some different on-screen keyboards to see what’s the right layout.

And then when you move to mobile and tablet, your input becomes more of the finger, thumbs and, swiping gestures. And then when you get back to the laptop, of course, you have the mouse and the keyboard. Mouse really is both a blessing and a curse, because it’s an indirect method. You can move it around just on either the trackpad or on your mouse pad. But you’ve got scrollbars, and scrollbars are really an indirect way to scroll. They’re not as direct, as physical as flicking your finger.

All this leads to that end of the screen. If I’m sitting across the living room, say 10-15 feet away from a television, what kind of text can I read on it? You have to think about how you design the text. Then the mobile, the screen’s small but it’s right there in front of you. And then the laptop, which you’ve got real high resolution. So you’ve got this output, the screen changes a lot.

And even the navigation. When I’m sitting in a living room, and I’m especially browsing for media content, I tend to be in a little bit lazier mode. I want things to kind of show up for me. I don’t want to have to work real hard to find something. If I’m on a desktop and I’m doing some research or something, I’m may be willing to click a lot, maybe type a lot. So, then your whole posture changes.

I think of input, screen navigation, and the posture of the person, not just the physical posture but their mental posture, as they start to use the application in those different scenarios…”

Tune in to the podcast as Bill addresses these additional points:

• How has the changing landscape affected the way you think about design?
• What are the things that you immediately have to take into account when going from a desktop experience to a mobile experience?
• Is there a way to know what types of content need to be on which devices?
• How have you been using Hack Days and how successful have they been?
• What are the advantages of allowing users to do things like, sign up, directly from their devices?

Bill is also one of the Masters that will be joining us for the 2011 Web App Masters Tour. We’re coming to Philadelphia in March, Seattle in May, and Minneapolis in June. For more details such as dates, pricing, and agenda, visit UIEtour.com.

Register with the promotion code WAMT by February 23, 2011 for any of the Tour cities and get $100 off.

Subscribe to our podcast via

Just around the corner from our UIE offices is the fantastic design consulting firm Two Rivers Consulting, operated by David and Hagan Rivers. In his Virtual Seminar, David discusses a number of considerations for creating or updating your application’s visual design. Much of David’s experience is with large and complex web applications that are trying to accomplish many things for many users for large chunks of their working hours.

Web applications live in a strange world―half application, half website. Making a command look like a command can be tricky. Do you make it a button? Should it be a link? In this podcast, David answers remaining questions from the session.

Here’s an excerpt from the podcast.

“…when you have a lot of things that seem equally important, it’s really tempting to make them all look the same because it’s logical for things to be consistent. You make all of your headers look the same; make all of your sections or portions of a portal or a dashboard look the same so that everything seems like a unified design.

And there is definitely some merit to making things look like they belong together, look like they’re a unified design, but that doesn’t necessarily mean that they need to look identical. So I talk about using subtle differences between them so that there’s additional cues that help people find the things that they need.

Sometimes it’s positional. Sometimes it’s color. Sometimes it’s use of borders or lack thereof or providing similar amounts of space around things. So in the case where things are incredibly configurable―I wouldn’t be surprised if Merrill’s talking about a dashboard here―it seems like it might be an insurmountable problem. But it really isn’t.

Because users can configure it, that’s what makes it work. People can still put things where they want them to go. They can still size them the way they want to often. But if you wanted to provide some extra UI for them, you could allow them to pick from a few different visual styles for each configurable thing. And those styles could work together as a family so that some might have borders, some might not. But they work together as components in an overall design that they can cobble together so that things work together as a whole.

But, like I said, the positional placement of things is what really works for them when you’re making things configurable. So that really handles the issue of having things that are otherwise equally important but different enough so that people know what to do with them and how to use them…”

Tune into the podcast to hear David answer these questions.

• How can you handle attention when competing with banners?
• We have a design where there can be a number of things that are equally important, but it’s so configurable that we don’t know how to group them. Any advice?
• What would you recommend as a minimum font size for a web app?
• What would you recommend to make grids look and feel better or more user friendly?
• In web apps do you prefer fluid design or fixed?

In the podcast, David recommends the book Computers as Theatre by Brenda Laurel.

Share your experiences with web application design or any questions in our comments section.

Their mortgage screen contains this list of menu options, with one of my most favorite menu options ever.

As asked in the comments, this is the default presentation when you first view the menu. (Some commented it would make more sense if the See more choices option were the default, but alas, ’tis not the case.)

What is the user scenario behind this menu option? “Whoa! I need to think about my mortgage for a second. Let me get rid of these extraneous menu options so I’m not confused.”

In case you’re wondering, here’s what the “fewer choice menu” looks like:

Aahh! That’s much better.

Seriously, I can’t imagine why someone thought this was the right design treatment for a too-many-choices scenario. This should’ve been a red flag to the designers.

Of course, there are places where I could see a See fewer choices function coming in quite handy. This one, for instance:

Subscribe to our podcast via

For years, the mobile web experience was little more than an afterthought as most design teams focused on catering their designs to the desktop. As Luke Wroblewski explains in his session “Why You Should Design for Mobile First” from the User Interface 15 Conference, this is becoming an increasingly backwards way of thinking.

In the past, the constraints of mobile were a hindrance. This made the mobile web was a painful experience. But things have taken a dramatic turn in recent years. As the capabilities of the mobile web continue to progress, it allows for the constraints to now become beneficial in the design process.

The first constraint Luke mentions is screen size. Because the screen size of mobile devices is significantly smaller than on a desktop, you have to remove roughly 80% of what is on the screen. There is simply no room. So you must focus on what’s important and make decisions on what needs to be included. This leaves you with a prioritized list that you can apply in multiple situations.

Luke goes on to talk about the performance speed of mobile devices. If you’re on the go and need to use your device to access the web, you don’t want it to become cumbersome. When you take this into consideration, a focus on speed and performance is a necessity. By consolidating your code and being aware of the size and amount of things that are being transmitted, you can really increase your speed and “get down the number of things you’re throwing over the wire.”

Luke also talks about context as a constraint. In other words, how people are going to engage with their mobile devices. Mobile devices are with us all the time and are constantly in use. When designing for mobile, think about how people use the device all day, wherever they are.

This brings up the idea of simplifying your interface so that a user on the go can complete a task “with literally a thumb.”

Web applications on mobile devices are no longer just ported from their desktop versions. In some ways, they perform even better than their counterparts. As Luke says, designing for mobile first can actually help refine and improve the desktop experience.

The full recording of Luke’s discussion about designing for mobile first is available, along with the seven other Featured Talks, and Jared Spool’s keynote as part of UI15 OnDemand. Also included are all of the handouts and presentation slides from the talks as well as those from all 8 full day workshops. Get more information or place your order for UI15 OnDemand.

Luke is also one of the Masters joining us for the 2011 Web App Masters Tour. We’re coming to Seattle on May 23-24, 2011 and Minneapolis on June 27-28, 2011. For more details on the agenda and other Masters visit UIEtour.com.

It’s a tough question because the answer often is Yes and No. Yes, good design practice is good design practice and it applies no matter what you’re designing. You need to know who your users are, what they are trying to do, and how they expect to do it. You need to watch the users work with the designs you create, so you can learn where the designs are working for them and where they are failing.

But No. Designing for web apps is a different type of animal. It lives in a browser, it has complicated activities and edge conditions, and little things can have big implications, especially when they go awry. You need to know different things when designing for web apps than when designing for any other type of interaction.

Then again, that’s what makes design interesting. Understanding the problems and fitting them into the constraints is the fun part of design.

In today’s UIEtips, we look back at an article from November 2006 that still rings true today. I talk about five usability challenges that web-app designers face. While these are not unique to web apps, designers will find themselves dealing with problems and constraints they’ll rarely see other places.

Read the article: Five Usability Challenges of Web-Based Applications

Part of the challenge in web applications is the visual design of a web application. David Rivers tackles this challenge in our next UIE Virtual Seminar: Visual Design for Web Applications, tomorrow, November 18. David shares real-world examples and insights that you won’t want to miss. Learn more about the virtual seminar.

What challenges have you faced when developing web-based applications? How have you overcome these? We’d love to know. Leave your thoughts in the discussion below.

Visual design problems affect an application’s success in a variety of ways. In the mildest form, they slow users down and distract them from their task. In the worst cases, they confuse users to the point of giving up or needing assistance. If the application is in the organization’s revenue stream or helps reduce costs, we’ve seen visual design issues can dramatically affect the bottom line.

For some time now, we’ve been fortunate to work with the design consulting firm, Two Rivers Consulting. UIE virtual seminars from Hagan Rivers have taught you to design better navigation and her Web App Masters talk shows you techniques for navigation in web applications. Now, we are honored to share with you the other half of this talented team, David Rivers.

On November 18, David will present a virtual seminar—Visual Design for Web Applications. He will help you improve your application’s visual appearance, while taking into account those real-world considerations we all face. David will show you how to create or update your application’s visual design to make it successful and delightful.

Join us on November 18 for David’s seminar. It’s chock full of real-world examples and insight that you won’t want to miss!

What is your toughest challenge in designing visual appearance of web applications? Got some tips to share? Let’s hear ‘em. Share your stories below.

I was really disappointed with their 1996 approach to the salary survey. The AIGA is filled with talented designers, yet they opted for an impossible-to-use book reader to display their hard work.

Locking the survey up in a proprietary, unusable reader was a huge mistake. It’s hard to use, not lending itself to the richness of the data that’s available. It’s like looking at the entire ocean through a small porthole.

But it’s not just the reader that’s the problem. You can download the PDF (after registering), but that doesn’t make it it much more modern.

The big problem is that the book is all about the presentation of the data, but not about the knowledge within.

The salary data that AIGA has at this point is really rich. They’ve got thousands of respondents surveys, going back to 2000. It would be awesome to really dive into this data.

AIGA is all about graphic arts. But in 2010, graphic arts has a huge responsibility to communicate interactively. How cool would it be to have a Mint.com-style drill-down interface, that would let you compare variables, such as whether salaries in Austin for the last five years have grown/shrunk the same as salaries in Boston?

How about letting people doing cross-tab analysis. For example, how does years of experience play into the salary changes? Does it change for job type? Region? Are there some regions that pay off more than others? And has that changed over the years?

By presenting the data as a flat book (or worse with the silly antiquated issuu interface), AIGA is saying that the understanding of the information is secondary to how it looks when they present it.

I don’t think this is the message that AIGA wants to send about graphic artists. As the premier organization for representing the future of what graphic arts can be, it would be nice to escape flatland and get to the core of communications.

The other big missing piece from the AIGA Salary Survey is the ability to export the data. How cool would it be to pump it into IBM’s Many Eyes project, letting people come up with dynamic interpretations on their own? How cool would it be to put together a student competition that focused on new and novel visualization techniques? Such a competition would accentuate the profession while demonstrating what the new wave of talent can bring to the world.

I get the AIGA is a membership organization and, in such organizations, it’s the volunteers making things happen. But this was a funded survey. (And the AIGA has this weird position of people not doing work for free—despite the fact they regularly ask me to volunteer my time to speak for free at their events.) They should’ve funded the project (or bagged the no-spec-work policy) to get the presentation portion as part of the project.

Overall, I’m really disappointed that the AIGA is stuck in this 1996 view of graphic arts. If the goal of the survey salary is to help promote the profession and demonstrate how valuable the organization’s members are to their companies, the best way to do that would be to take advantage of state-of-the-art thinking in that presentation.

Hopefully the AIGA will see that there are huge possibilities they’ve completely ignored. I’d love to see a state-of-the-art salary survey from them soon.

Subscribe to our podcast via

Web applications can get wild. You know the kind; something that’s on your corporate intranet with an obscure purpose, hundreds of screens and some kind of navigation kudzu growing in every direction. Hagan Rivers is one of our favorite wranglers of such apps. When these types of applications have reached the critical point, companies turn to her to help regain the upper hand.

So what do you do with navigation that is out of control? Hagan brings her pruning shears. That’s one of her three crazy ideas about conquering out-of-control navigation: design without navigation!

Hagan is always a crowd favorite at our conferences, and we wanted to share with you a sample of her presentation, Escaping Navigation Hell, from the 2010 UIE Web App Masters Tour. Listen in and follow along with the downloadable slide deck, or check out some highlights below.

[ Download the complete set of this section's slides and follow along. (2.4 MB PDF) ]

Crazy Idea #1: Design Without Navigation

• Design screens in the application without the navigation system.
• Hagan builds and tests the screens without the navigation.
• She concentrates her energy on the tasks that are performed within that function of the application.

Crazy Idea #2: Navigation in an Application

• Treat navigation as its own application, with its own requirements and goals.
• If your application is going to be complex, so likely too will your navigation.
• Design it as a functioning whole and test it that way.

Crazy Idea #3: Design Navigation Last

• Design navigation systems last, separating them from the rest of the application design.
• It’s easier to design the nav last because you’ll have a better picture of what your users will need to navigate.

30k view

• When starting redesign projects, Hagan maps out the existing site she’ll be overhauling.
• Get a “big picture” of all that the application does.

Screen Tagging

• To identify components of the application, she has a fixed set of descriptive tags she uses to label each node on the map.

Example of tags for a page in the WordPress admin area.

Mapping video

• Here’s a video of Hagan building an Application Map

See all the slides for this section in the downloadable PDF.

In the talk, Hagan references this excellent UIE Virtual Seminar she did for us on web application navigation, which you can still access.

If you enjoyed this taste of Hagan’s talk, why not join us in Seattle for the final stop on the UIE Web App Masters Tour? See Escaping Navigation Hell, and all the other fantastic talks for yourself!

Want to learn more from Hagan? See her entire session at the Web App Masters Tour and get $100 off your registration with promo code TOURBLOG.

Forms are crucial for users to complete many online transactions, ranging from sign-up forms for introducing new customers to your site, to checkout forms for finalizing your users’ purchases.

In this week’s UIEtips, we’re republishing part 1 of an article written by Luke Wroblewski. He’s one of our favorite experts on web form design. Luke discusses tips for improving web forms and impacting user success. Stay tuned next week for Part II.

Read Luke’s article: Web Form Design in the Wild, Part 1

Web forms are one of the most challenging design problems. In our next UIE Virtual Seminar, Luke shares his thoughts and solutions on 6 important aspects of web form design gleaned from hundreds of questions and issues designers presented to him. Learn more about Luke’s webinar, Answered! Your Top Questions on Web Form Design.

Do you have any best practices for designing forms? What usability problems have you encountered with your web forms? I’d love to hear about your experiences. Share your thoughts with us and join the conversation below.

Subscribe to our podcast via

Ken Kellogg

There’s plenty of pressure on web designers to groom the corporate website. You have the politics of keeping stakeholders happy and the responsibility of rolling out improvements that don’t decrease revenues. But what if your website was responsible for $6.5 Billion of revenue last year?

Such is the life of Ken Kellogg, the Director of User Research at Marriott International. Ken leads the user research team that is responsible for the experience 12 million people a month have at Marriott.com. The first day on the job, Ken received the first directive: Do No Harm.

In this podcast, Ken discusses with Jared Spool how he:

• Navigates the design process from within a large corporate world
• Partners with his executives to gain access to the most useful tools
• Keeps the site moving forward with a lot of customer research.

Ken starts by telling us the genesis of the current redesign project at Marriott:

Our research kept telling us that we might be missing out on a key segment—and those are folks that are a personal traveler, a leisure traveler. Of course, a business traveler can be a leisure traveler anytime. But, we’re really thinking about folks that don’t normally travel for business, or a spouse of a frequent business traveler who wants to plan a vacation.

What we were seeing over and over was these folks would come to Marriott.com and they’d get lost. One of the old rules about usability is you never get two chances to make the first impression. If someone gets lost, they will go some place else, that is still the truth. Everything kind of started from those two facts.

The needs of their main customer, the business traveler, are somewhat different from the leisure traveler. They had to find a way to cater to this group without alienating their bread-and-butter demographic.

…one of the first things that you’re indoctrinated with when you start working in e-commerce at Marriott is that you do no harm. It’s the Hippocratic Oath. You do not hurt the frequent business traveler. So, we have painstakingly done our best to make sure that we don’t put any stumbling blocks or any delays in the paths of our frequent business traveler.

Ken has a lot more to share in this podcast on the research and decision process that went into the redesign. And Ken’s presentation at the Web App Masters Tour in San Diego, Care and Feeding of a Corporate Cash Cow, received rave reviews. You can still catch him at our Minneapolis, Philadelphia or Seattle tour stops.

Want to learn more from Ken? See his session – Care and Feeding of the Corporate Cash Cow at the Web App Masters Tour

Are you designing within constraints of a large corporate environments? How are you bringing innovation to your site, while coloring within the lines? Let’s hear about it in the comments.

Subscribe to our podcast via

Jason Fried

Jason Fried brings a unique viewpoint to any design discussion, one informed by years of success with his company, 37signals. Recently, Jared Spool was able to chat with Jason about 37signals’ current work. If you’re joining us at the UIE Web App Masters Tour in Minneapolis or Philadelphia, Jason will go into even more detail. Among the topics they’ll cover in this podcast include:

• the design and development process behind 37signals ID, their single-sign on feature for their four major web applications which serve more than 3 million customers.
• what they’ve learned about controlling ballooning projects
• their on-going experiment with rotating design and development teams

37signals is known as a organization that does little, if any, testing with users prior to launching a feature. Since UIE advocates user research and usability testing as common components to most design projects, sometimes folks wonder why we’re so interested in the process at 37signals, and why we’re excited to have Jason to speak at our events. We don’t believe there’s only one right way to run a design project, and it’s hard to debate the success Jason and his team have had with their process. In this podcast, Jason discusses their experience with building the 37signals ID, and what role testing played in this project:

…we don’t really do any formal sort of usability testing. I think that usability testing, or bringing outside people in to look at this, it clearly would help in some ways, but… you only kind of really get this when you’re going through the real process.

…you can bring people in to read a screen or to kind of fake go through the process, but it’s only when you’re hurried and you’ve just logged into Basecamp and you need to check a new to-do list, and all of a sudden you see this screen, for real… that’s the only time you can really evaluate whether or not this is clear or not. And so I think it’s really hard to simulate those situations.

After listening to Jason’s thoughts on testing and process, how do you feel they would work in your organization? Share your thoughts on their process and your experiences in the comments. After listening to the podcast, you won’t want to miss Jason’s presentation, Backstage at 37signals, at our Web App Masters Tour in either Minneapolis or Philadelphia. We look forward to seeing you there!

Want to learn more from Jason? See his session – Backstage at 37signals at the Web App Masters Tour

Subscribe to our podcast via

Julie Zhuo

When Facebook tweaks anything, it gets coverage across the IT and design realms, and sometimes the Wall Street Journal and New York Times. If the users don’t like the changes, they form protest groups… how can a team operate under such a public microscope?

Julie Zhuo knows. She is the Product Design Manager at Facebook. As the principal designer behind the Facebook Platform and Facebook Connect experiences, she’s contributed to the last two major site redesigns. She also leads the front-end user interface engineering team. On her watch the site grew from 8 million college kids to 350 million people across the globe.

Jared Spool had a chance to chat with Julie recently. The stories she shared, from behind the scenes, are fascinating. When was the last time a throng of people gathered outside your office because you changed a feature on your site? Julie tells that story in the podcast, plus touches upon:

• The early years of innovation and launching features fast, and without testing
• Taking major design risks in front of a large, passionate audience
• How they moved to a strong routine of metrics, A/B tests, usability testing and staged rollouts
• …and much more

Julie talks about the transition from the run-and-gun design strategy that Facebook once used to roll out new features fast, and how it evolved to a more measured approach, while still moving quickly:

We are cognizant of the fact that every time we make a change, the initial user reaction is going to be a little bit negative. That’s why listening to feedback really matters. If all of the feedback is basically, “I don’t like this change because it’s different,” then maybe that’s a sentiment that will go away once people use it regularly.

But if the feedback is, “I don’t like this change because now I can’t find my applications,” or “I can’t find chat,” or “I can’t find messages.” Then that’s a real wake-up call for us that we really need to examine this change and see if we’ve regressed in making it easier and better for users.

They progressed to a test first, launch second strategy, that in some sensitive cases involved a lot of testing.

Last December we launched a change to privacy, and so when you logged into Facebook one day, you got a little privacy dialogue that said, “Hey Facebook is making some changes to privacy. Please revisit your privacy settings.”

That is not going to take that long to build. Right? It doesn’t take that long to design, it’s just one little dialog. But the process for us getting to that final point was months and months, because we knew privacy is such a sensitive topic for people that we wanted to be absolutely sure that what we were doing people would be comfortable with. It was the right thing to do.

Maybe four or five months prior to our launch, we were already bringing people in. We hadn’t even started building the pod. It wasn’t really even designed. We were just showing them a little text dialog with the language that we were going to use and with a lot of different options for how we would present this messaging to them.

These are like paper, low-fi prototypes, nowhere near what the final product will be. But prior to us even building and getting nice mocks from everyone, we already had at least five sessions with a bunch of users testing about 30 different versions of the language and the messaging for this dialog.

So many companies struggle with building the proper amounts of user research into their design process, but so few do it with so many users and so much public attention. Julie’s stories are fascinating case studies that should prove valuable to your own organization.

Julie has many more stories from behind the scenes at Facebook which she’ll share with us in San Diego at the UIE Web App Masters Tour. Join us for her Design Lessons from 350 Million session.

Are you struggling to balance the need to launch features fast with the necessary user research? Let us know in the comments.

Subscribe to our podcast via

Bill Scott

If you’re using advanced, or “rich” interactions in your web applications, then it’s likely you have Bill Scott and Theresa Neil’s Designing Web Interfaces on your desk, if not your bedstand. Published in 2009, it is perhaps the definitive tome on rich interactive design patterns for the web. Bill has dedicated a significant portion of his career to dissecting such interactions, creating the Rico JavaScript library, curating the Yahoo! Pattern Library and now overseeing UI engineering at Netflix—one of the first companies you think of when you think of Ajax-y web interfaces.

It’s hard for us to picture talking about web apps without talking about Bill and his research into design patterns. His new book is full of examples where he slows down time to explore each micro-stage of an interaction. Our Jared Spool got together with Bill to discuss his ideas about the nuances of Interesting Moments.

Jared and Bill discussed,

• Bill’s experience of aggregating successful interactions in the Rico JavaScript and Yahoo Patterns Libraries
• How his challenges at work lead to him writing Designing Web Interfaces
• How his interface research lead to better ways to capture interactions for documents and prototypes.
• Dancing Hamsters
• …and more

Bill speaks about both patterns—successful interaction models for common interactions—and anti-patterns. By showing what not to do, anti-patterns often provide insight on the right way to do something.

A good example [of an anti-pattern is from] the old Yahoo Photos site[…] dragging several photos into an album, there’s no indication that the photos actually dropped into the album folder, and there’s no feedback that says, “Oh, there was three, but now there’s six items in the folder.”

The designers had dropped in two extra “idiot boxes”, which is a great anti-pattern. The first idiot box says, “Do you really want me to drop these items into the folder that you so carefully managed to use your mouse dexterity to get to?” Not quite that message, but that’s gist of it.

Then there’s another pop-up that says, “Hey! Guess what? We did what we said we would do. We actually put those items in the folder.” It’s sort of, as Alan Cooper calls it, “stopping the proceedings with idiocy.” The missed moments were just those little, subtle feedbacks that could have been done, instead of the hammer approach, by having those boxes pop up and interrupt the user.

The take away for our work is that this interaction was backwards. It gave no indication that you were doing something successfully while you were doing it, and then penalized your time after completion with dialog boxes to confirm your success: “You did it!” After dismissing the dialog, you were left with an interface that didn’t reflect any of your changes.

By adding clues that the move was happening during the action, and then reflecting the changes with interface cues afterwards, we can make the experience smoother while avoiding “idiot boxes” altogether. (This interaction is detailed in chapter 5, “Overlays” of Designing Web Interfaces)

There are many more pearls of Bill’s wisdom available in the podcast, please tune in!

Don’t miss Bill’s full presentation, “Designing for Interesting Moments“, at our Web App Masters Tour. He’ll be with us in San Diego, Minneapolis, Philadelphia and Seattle.

Let us hear your questions about interesting moments in the comments below…

The business needs can be complex. They come from all over the enterprise, originating from initiatives (like marketing campaigns), infrastructure (like inventory constraints), and regulations (like export restrictions). Suddenly, a simple task, like paying for a product, becomes crazy-complicated.

In today’s UIEtips, I discuss how the best designers thrive within this world of wacky constraints, coming up with ingenious ways to meet the business requirements while producing a delightful user experience. If you design web apps, this should be interesting.

Read the article, Web Apps: Where Business Needs & User Needs Collide.

Web app design is at the forefront of our minds this month. That’s because we’ve just launched our 4-city UIE Web App Masters Tour. We’re wicked excited about the program and I’m betting you’ll be too as soon as you check it out. Go see it at www.UIETour.com.

Have you bumped into business constraints in your web app designs? Have you come up with a creative way to work around them? We’d love to hear your experiences. Leave your thoughts below.

Joining the other seven presenters for our two-day deep dive into all things wonderful about Web Apps will be:

Hagan Rivers

I’ll say it: I love Hagan. She’s an amazing designer who knows her stuff. And, unlike many designers, she’s really great at explaining the why behind her design. She’s presented at our previous Web App Summit and User Interface Conference events, always delighting the crowd.

Hagan was involved in the first web-based applications, back when she worked for Netscape in ye olde early days, where she was the lead designer on versions 1.0 through 4.0. You don’t get much more in-the-trenches experience than that. Now, she’s at Two Rivers Consulting, where she’s still pushing the envelope in web app design.

Luke Wroblewski

I think of Luke as a wunderkind. Like Hagan, he started in the early days of the web, working at NCSA where the original Mosaic browser was born. He then moved on to eBay and is now Chief Design Architect for Yahoo!, where he works on designs used every day by Yahoo!’s 700 million users.

Luke’s first book, Site Seeing: A Visual Approach to Web Usability, was what brought my attention to him. But it’s his most recent book, Web Form Design: Filling in the Blanks, that I think really shows his talents. You’d think a book about Web Forms would be boring, but from the first words (“Forms suck.”), he had me. (In fact, I just noticed my copy of his book has gone missing—again! This will be the third time I’ve replaced it. Keep good track of yours as they like to walk away.)

Luke’s been speaking at our events for years and is also one of our top-rated speakers. So we’re thrilled he’ll be joining us on the tour.

Both Luke & Hagan will be at all four stops on the tour, starting in San Diego.

Get Notified As More Details Come Along

What’s that? You want to be notified on additional details and registration? No problem, just leave us your email address and we’ll send you a quick note when we have more information.

Stay tuned as the next thing is to announce the San Diego schedule and what each of our masters will be speaking on. I can’t wait to hear them!

We’ve lined up two more Masters for our UIE Web App Masters Tour. We’re thrilled to announce Bill Scott and Ken Kellogg will be joining us.

Bill Scott

First, let me say this: Bill is the nicest person on the entire planet. You’ll notice this the moment you talk to him. But that’s not why we invited him.

I wanted him on the Masters Tour because he’s brilliant, particularly when it comes to design patterns for web-based applications. Bill spoke at our Web App Summit a few years back and dazzled the audience with his presentation on Anti Patterns—things you shouldn’t do when designing.

In addition to co-authoring the book, Designing Web Interfaces: Principles and Patterns for Rich Interactions, Bill is also the Director of UI Engineering at Netflix. All of these things add up to one thing: you’re going to love his insights. Bill will be with us in all four cities.

Ken Kellogg

Managing the design of a $6.5 billion a year website is no easy challenge. Especially when that website is owned by one of the oldest, most respected brands in the world. While many of us deal with the battle of old ways against modern thinking, this is on an epic scale.

That’s why I wanted you to hear from Ken Kellogg, who sits directly in the middle of that battle, as the Director of User Research for Marriott International. Ken is currently guiding major design changes through Marriott.com and will report, first hand, what that has been like. His stories will inspire you. You can hear Ken talk about his experiences at every stop on our tour.

It’s coming together.

Bill and Ken join a great slate, including Doug Bowman, Stephen Anderson, Julie Zhuo, and Christian Crumlish. Oh, I’ll be there too (but you probably knew that).

Just a few more presenters to go and we’ll have a full program. This is getting exciting now.

Get Notified As More Details Come Along

What’s that? You want to be notified on additional details and registration? No problem, just leave us your email address and we’ll send you a quick note when we have more information.

Julie Zhuo

The designers at Facebook try hard to make Facebook users happy. It’s a hard-to-please audience, and there’s 350 million of them. As Facebook’s Product Design Manager, Julie is at the front of the storm, designing for the site that’s grown from 8 million college students to its current worldwide audience.

She’ll be sharing some of her team’s successful and not-so-successful design experiences, so we can all learn from their experience. The interesting part is that many of the problems they face are just like the ones we face, and their solutions are quite creative. You’ll hear Julie’s experiences at our San Diego stop on the tour.

Christian Crumlish

Many web applications, whether on intranets or public facing, involve making connections with other people. From the address book and contact list, to messaging and content sharing, we see more web apps helping people communicate and collaborate.

We can’t think of a better person, to introduce social features into your web-based applications, than Christian. Working with his co-author, Erin Malone, they have compiled an amazing library of patterns in their new book, Designing Social Interfaces. We’re excited to have him as one of our masters on this tour and can’t wait to hear what wisdom he’ll be sharing with us. We’re fortunate that Christian will be at each stop of the tour.

Stay tuned. We should have more additions to the program tomorrow. And we’re adding more to the site every day, as we get ready for the launch in a few days! Watch along at uietour.com.

Here’s the facts:

We’re going to 4 cities between March and July, 2010: San Diego, Minneapolis, Philadelphia, and Seattle. We love these cities for the vibrant tech communities.

We’ve put together a team of leading designers of today’s top web-based applications. We call them the Masters. In each city, we’ll have them unleash two days of inspiring presentations. These folks are the best in the business and we’re thrilled you’ll get the chance to learn first-hand from their experience.

Who are the Masters?

I can tell you about two of them today:

Doug Bowman

What do Google, Wired, Blogger, Capgemini, Mighty Goods, and Adaptive Path all have in common? They’ve all seen the fine work of Doug Bowman, one of the most influential designers on the web. Now, Doug is the Creative Director of Twitter, where he’s helping change the world, one hundred and forty characters at a time. Doug will be sharing his design experiences at the San Diego and Seattle tour locations.

Stephen Anderson

Stephen gave a mind-blowing presentation at the 2009 IA Summit. He discussed how the basics behind game mechanics can help users become more engaged in other types of applications. The minute I walked out of his talk, I knew we had to have him at one of our events. His writing at PoetPainter.com, his presentations, and his work for clients, such as Nokia, Frito-Lay, Sabre Travel Network, and Chesapeake Energy all demonstrate the new insights he brings to application design. We’re thrilled that he’ll be presenting his thoughts in all four cities.

By the way, I’ll be opening and closing each of the events, so you’ll have a chance to hear from me, in addition to Doug, Stephen, and the other presenters we’re lining up.

We’re putting everything about the event at www.uietour.com. Stay tuned for more news…

Take that two-way communication out of your process, and the design that emerges from the development process doesn’t work the way we thought it would.  You increase your development costs, and deliver a product that’s lost all of it’s interactive goodness.

Unless you’re doing your own implementation, practically impossible for a serious production application, you need to find a way to succinctly communicate what’s important and how it should all work. In this week’s issue of UIEtips, I bring back an article, Getting the Most from Design Deliverables, that discusses how the best design teams go about successfully communicating their ideas to the development team. I think you’ll really enjoy it.

Also, we think this article ties in nicely with our upcoming UIE Virtual Seminar: Comps vs. Code: Case Studies on Collaboration Between Site Designers & Developers with Ethan Marcotte.  On July 30, Ethan will use four case studies to teach some insightful lessons about the collaboration between designer and developer. See a preview.

How do you hand off projects at the transition phases in your organization? What types of reviews do you build into the transitions?  Join the discussion below.

Subscribe to our podcast via

This week’s episode features a shadowy UI Designer by the name of Jamis Charles, from a secretive organization located somewhere in Texas. Honestly, that’s all we know about him. Cloak and daggers aside, he brought an intriguing challenge to the show.

Jamis, if that is his real name, asked,

Should link treatments vary for different methods of displaying content to the user? For example, on a single page I have several links. The first one takes me to another page when I click. The second shows a hidden layer with more content if I click. The third shows more content if I hover.

If these links should be styled differently, should the treatments be organized by type of content, or by the user interaction method?

Tune in to see how our hosts answer this challenge while our guest and his project maintain their anonymity. And to hear Robert wax nostalgic for a steak he once ate in Texas.

Have a serious UX question? Send it in and Jared Spool and Robert Hoekman, Jr. will answer it with a healthy dose of levity. Please send your deep, vexing questions to us at userability@uie.com. We’d love to feature you on the show! Till then, if your’re in a situation like Jamis, let us know how you would handle it in the comments!

Subscribe to our podcast via

Hagan Rivers is one of our favorite go-to people for web app design, and we recently had her host a UIE Virtual Seminar on Designing Better Navigation for Web Applications. The seminar (which is still available) was brilliant, and we asked her back to answer some audience questions we did not have time to discuss during the seminar.

Here’s the list of the questions we discussed,

• How do you conduct your user research?
• How do you measure user confidence in the navigation?
• What are your thoughts on activating menus with a click versus “on hover”?
• What is your opinion on breadcrumbs? What about advanced breadcrumbs, like on lonelyplanet.com?
• How do you scale navigation for larger web apps or sites (circa 40,000 pages)?
• What are your thoughts on user segmentation, and navigation based on that (for example, UT’s Be A Longhorn)?
• At what point during the project do you design the global navigation?
• Are there different considerations when you’re educating users about a new process or activity?

During our discussion of the user research question, we recommended Indi Young’s Mental Models as a great book on the topic. Don’t miss her UIE Virtual Seminar on Mental Models, either.

Tune in for the meaty answers. This podcast had almost as much information as the seminar! Still have questions? Discuss them in the comments below!

Subscribe to our podcast via

This week Robert Hoekman, Jr. joins us to discuss Design Frameworks. Drawn loosely from the idea of coding frameworks that software developers use to more efficiently build software, design frameworks are an aid to assembling a design.

Frameworks sprung from research into web ROI that Robert conducted after a parade of clients came to him looking to improve their conversion rates. In the case of these clients, he needed to find the essential elements that encourage people to sign up for a web app.

From there, he applied that process to other areas, like search elements. What combination of essential design elements had to be assembled for users to successfully obtain their goals?

You can compare frameworks to design patterns, although patterns tend to be smaller, more specific solutions. Frameworks, when built out, can contain design patterns. Robert wrote a five-piece blog post series for Peachpit on his development of a sign-up a framework, called Five Tips in Five Days. Robert will detail the full story in a new book, co-authored with me, coming soon from New Riders.

Frameworks help create consistency in interface elements to help solidify the UX. Robert uses frameworks on all his current projects. He starts out with a check list of all the main elements what will help a person accomplish a goal. Projects will require frameworks for many different parts of the project and they need to dovetail with one another. Robert shared with us a story of what happens when they do not. It winds up that examining where frameworks clash can act as a diagnostic tool for some usability issues.

Tune into to the podcast for more details and a preview of the full-day workshop the Robert will be conducting at the UIE Web App Summit, entitled Web App Anatomy: Effective Interaction Design with Frameworks. We hope you join us April 19-22, 2009 in sunny Newport Beach to learn more about this useful new design method.

Subscribe to our podcast via

Without planning, web apps have no where to go. Planning documents for web app projects are often overlooked, despite their importance in the success of the product. As a designer, no matter how great your research is, or how amazing your programmers are, if your planning documents do not develop well, your project will fail.

One of the great user experience success stories in the U.K. is the Brighton-based agency Clearleft. They’ve developed successful, sophisticated methods of planning for their projects. I was able to get a hold of two of their talented crew to discuss those methods in this episode of the SpoolCast.

James Box (UX) and Richard Rutter (Co-founder and Production Director) have been working on ways to plan highly interactive web apps that make the process more efficient. And that’s exactly what we spoke about during the podcast.

James and Richard first told me that they hold back from traditional deliverables, and show clients what they call ‘design tools.’ Some clients prefer tidy deliverables, but many clients like these rougher documents. The advantage to these is that they stress design as a process, rather than set in stone. Sometimes overly polished documents can make a solution appear complete, without the client being able to change its course.

This method aids the flow of dialog between the designers and the client. Rough prototypes help your client stay focused on the core issues you’re demonstrating, like interactions, while avoiding getting caught up on visual elements that aren’t important at this very moment. As an example, when possible, they leave color out altogether.

A key element to the success of their design tools is that prototypes are interactive. They make many prototypes with HTML and enough jQuery to demonstrate the interaction. They don’t feel this process takes any longer than using relatively static tools like Visio or OmniGraffle, and offers more utility. They’re always looking for ways to improve the process with reusable pattern and code libraries.

There were more quality nuggets in the conversation too, so please tune in for more on peer reviewing, prioritizing usability testing and real code production.

James and Richard will be joining us in California this April for our Web App Summit, where they will be conducting a full-day workshop on “Wireframing and Prototyping for Highly Interactive Web Apps.” If you enjoyed this conversation, please join us to learn how their techniques can help in your organization.

Have you moved to interactive prototyping for expressing complex situations? Let us know in the comments.

Subscribe to our podcast via

When I tell people that one of our most popular conference sessions of all-time is about Web Form Design, people think I’m pulling their leg. Those people, of course, haven’t actually attended a workshop conducted by Luke Wroblewski.

Luke Wroblewski is a Senior Principal of Product Ideation & Design for Yahoo and has his own shop, LukeW Interface Designs. He is the author of two books, the new top seller Web Form Design: Filling in the Blanks and the popular Site-Seeing: A Visual Approach to Web Usability.

Since writing a popular book on the subject, Luke has found himself inundated with questions tall and small about form design problems. He shared his two most asked questions (and answers) with me.

How many pages should my complex form be?
Of course, there’s no easy answer to this question. A key point to consider when resolving this challenge is context. If you met the person filling out your form in person, how would you ask them these questions? That will help you arrange the questions, and if you find natural groupings for many questions, these may be natural pagination points. If they don’t naturally break, perhaps that’s an argument for one long page.

Luke discussed Matthew Frederick’s 101 Things I Learned in Architecture School at this point in the conversation. He was particularly interested in the concept of parti.

Dynamic Forms, are they a good idea?
Forms where the site assists the user, when done well, can really help relieve stress on your user. A classic example of this is choosing a screen name for an account. No one wants to pick a name, password and hit submit, only to be told it’s not available and bounced back to the first form, with all the fields emptied to start from scratch… and still not knowing if the next name they choose will work! Live database queries for items like these can be a godsend. Additionally, language presented during these rich interactions presents the opportunity for a pleasant human interaction.

Good examples for dynamic interactions with forms can be found in the search box of Apple.com and the signup form for Jeremy Keith’s Huffduffer.com

Luke will be presenting his popular full-day workshop Web Application Form Design at our Web App Summit, this April, 2009 in Newport Beach, California. Why not come see what all the excitement is about?

Web forms have you down? You can always take comfort in the comments below… if you can endure our form.

Take a multi-step dialog sequence, such as, say, signing up for a new account. Each step will have the content — the fields the user will fill in, including their name, address, and billing information. Yet, each step also requires some user interface chrome — those design elements that move the user to the next step (or back to the previous one, when something needs revisiting).

What I find interesting is, often in the design process, we focus more on the chrome than on the content. Yet, it’s the content that is most important to the user — the part of the UI they need to focus on most. The chrome, when it’s working well, should seem invisible and natural.

In today’s UIEtips article, Previous and Next Actions in Web Forms, Luke Wroblewski shows us what we need to know to make an important part of that chrome invisible: the Previous and Next actions. He’s done a fabulous job of dissecting the problem and talking about exactly what needs to happen to make the interface seem natural to the user, which, in turn, lets them focus on the content.

Luke, of course, is *the man* to talk to when thinking about these things. His brilliant book, Web Form Design: Filling In The Blanks, is chock-full of great insights. We’re pleased he’ll be repeating his full-day seminar, Web Application Form Design, at our upcoming Web App Summit.

What’s been your experience with the sticky problem of Previous and Next actions? Do you have a solution that works well with your audience? We’d love to hear your experiences and questions. Leave a comment below.

That’s why we’ve put together a series of podcasts with some of the experts in the field: Dan Brown, Molly Holzshlag, Steve Mulder, Riccardo LaRosa, and Nathan Curtis. In these interviews, we talk about documenting design, web standards for web apps, Web 2.0 design strategy, and using patterns and components. I’m sure you’ll find it both interesting and insightful.

You can subscribe to the podcast through iTunes, or you can listen directly on your PC.

By the way, Dan, Molly, Steve, Riccardo, and Nathan are all presenting full-day workshops on these topics at the UIE Web App Summit.

Documenting Design with Dan Brown

If you ask designers what the most frustrating parts about designing a project are, one of the top answers would undoubtedly be “communicating and documenting the design process.” And with good reason… it’s not easy.

That’s why we interviewed Dan Brown. I don’t know of anyone who knows more about solid design communications than Dan, the co-founder and principal of Eight Shapes, a UX firm in Washington, D.C. Dan wrote the excellent book Communicating Design: Developing Web Site Documentation for Design and Planning, one of our favorite design resources.

In this interview, Dan and I explore the documents that help make large design projects go smoothly. We discuss how these important docs can become living documents (one that evolves when necessary) and how
Dan believes there’s value in seeing them as actual team members. That may sound weird unless you think about large teams and the meetings. Sometimes, it’s easier to “ask the document” how something should work instead of figuring out who would be the best person to ask. At meetings, these documents can sit at the table and answer questions, as well!

In the podcast, we spent some time with two documents he cover’s in his book: concept models and flow charts. These particular documents are intriguing because they don’t cover concrete ideas (which are easier to document), but instead cover the higher-level abstract ideas that often power the site invisibly.

Listen to Dan’s interview.

Web 2.0 Strategy and Design with Steve Mulder and Riccardo LaRosa

We love to talk to Steve Mulder (from Molecular) and Riccardo La Rosa (from Isobar) about building out a Web 2.0 strategy and incorporating elements, such as social features and highly-interactive elements to the design.

Steve and Riccardo work with mainstream organizations. In this interview, they told me about the solutions they worked on with Reebok (a sports apparel company) and HumanaOne (a direct-to-consumer health
insurance company). We talked about the challenges they faced on these projects and what they needed to do to overcome them.

During the podcast, we discussed how to determine what features to build, how to tell if the features are working as expected, and how results changed over time. We talked about how starting small and iterating is most successful, but not an easy sell in many situations. You’ll want to listen to hear how they overcame this challenge and other Web 2.0 adventures they had.

Listen to Steve and Riccardo.

Web Standards for Web Apps with Molly Holzschlag

UIE reached out to Molly Holzschlag, to discuss the cutting edge of web standards as they apply to web application development. Molly is the unsinkable author of, what seems to be a million, books on web development, is a noted teacher, and an in-demand consultant in the field. There’s likely no one better to ask about web standards than Molly.

In this podcast, Molly and Jared discuss a number of new standards, such as HTML5, JavaScript, and other advancements, and the impacts it’s having on web application design and development. Also discussed is the tremendous benefits building with standards (or even a subset of them) brings to the lifecycle of a product.

In this podcast, Molly and I discussed the impact these and other advancements are having on web application design and development, along with the tremendous benefits building with standards (or even a
subset of them) brings to the lifecycle of a product.

Listen to Molly.

Achieving Pattern and Component Reuse with Nathan Curtis

Dealing with real-life web app production isn’t as glamorous as some aspects of design in the digital realm, but it is full of challenges and can honestly make or break a project. There are ways of truly optimizing certain aspects of the production so that you can create a product with consistent quality at a faster pace. To find out how, I turned to Nathan Curtis.

Nathan Curtis is a principal and co-founder of Eight Shapes in Washington, D.C., where he is spearheading research into design patterns and component libraries. Eight Shapes turns out great work in the UX and IA realms with some impressive clients.

In our discussion, Nathan and I first define design pattern libraries and component libraries. A pattern library is a repository for ideas and solutions to design interaction problems. Component libraries are comprised of actual functioning parts, with real code. If you’re designing even a moderately large site, having repositories can save you tremendous production time. You can multiply these savings if you have multiple teams working on different portions of the same property. Each team doesn’t need to invent their own wheels and engineer them from scratch.

We go into more detail in the podcast and also compare these to style guides, which were the first step towards this idea—one that is too often broken, over restrictive, and simply ignored.

Tune in to hear how pattern and component libraries can help you.

This week, our long time friend, Molly Holzschlag, joins us to discuss the cutting edge of web standards as they apply to web application development. Molly is the unsinkable author of a metric ton of web development books, is a noted teacher, and an in-demand consultant in the field. There’s likely no one better to ask about web standards than Molly.

There are a number of new standards that have come out recently, HTML 5 being perhaps the most notable for web applications, because it was brought forth with applications in mind. New features, like canvas, are designed to improve dynamic interactions between the presentation layer and the behavior layer, for example, with things like ECMAScript, more commonly known as JavaScript. JavaScript’s usage has really matured and become nearly indispensable as developers have really begun to exploit its full capabilities. JavaScript’s importance to front-end developers continues to grow.

In this podcast, Molly and I discussed the impact these and other advancements are having on web application design and development, along with the tremendous benefits building with standards (or even a subset of them) brings to the lifecycle of a product.

(During the episode, Molly and I touched upon the critical security exploit that effects all versions of Microsoft’s Internet Explorer for Windows. Please be careful out there, folks.)

If you found this podcast interesting, you’ll be happy to know that Molly will conduct a full-day workshop for web application developers on harnessing the power of web standards in their work at our Web App Summit in April 2009. Please join us and take your work to the next level!

We’re curious to see if any of our audience is venturing into the HTML 5 waters, or using other newish standards in their work. Won’t you let us hear your story in the comments?

Yesterday I attended an outstanding seminar by Joshua Porter produced by those great folks at UIE (yep shameless Ak’ing there.):) The topic was Designing for Sign-up. What struck me the most about the presentation, as a UX geek, was that the issue was not about the mechanical process of making the sign-up easier, but around the socio-psychological issues of helping users make a commitment.

Read Deb’s entire post.

We love to talk to Steve Mulder (from Molecular) and Riccardo La Rosa (from Isobar) about building out a Web 2.0 strategy and incorporating elements, such as social features and highly-interactive elements to the design.

Steve and Riccardo work with mainstream organizations, which may not be as familiar as, say, a Silicon Valley startup with what the state-of-the-art is for these types of features. In this interview, they told me about the solutions they worked on with Reebok (a sports apparel company) and HumanaOne (a direct-to-consumer health insurance company). We talked about the challenges they faced on these projects and what they needed to do to overcome them.

During the podcast, we discussed how to determine what features to build, how to tell if the features are working as expected, and how results changed over time. We talked about how starting small and iterating is most successful, but not an easy sell in many situations. You’ll want to listen to hear how they overcame this challenge and other Web 2.0 adventures they had.

Enjoy the podcast? Well, you can join Steve and Riccardo for their UIE Web App Summit full-day workshop, Web 2.0 Strategy and Design, and learn how to apply the elements of social media, openness, rich interfaces, and emerging digital interactions to your designs.

Over at Semantic Foundry, designer extraordinaire, Will Evans, has a wonderful essay explaining how he uses wireframing as both a problem setting and a problem solving approach.

I pick my primary audience and the one activity which allows them to solve one goal quickly, effortlessly, elegantly. In this case, the primary audience wants to easily find the best cruise, at the right time, for the right price. I don’t even look at the requirements document or competitive analysis until after I have sketched a couple of ideas either on paper or using Omnigraffle, which explores the primary goal. I’m not looking for solutions at this point because the first round of wireframes provide a space to engage in a dialogue with other designers, stakeholders, and the wireframes themselves.

It’s a great description of how Will tackles a design and he’s provided his work products for you to download.

Read Will’s essay: Shades of Gray: Wireframes as Thinking Device