Full Transcript

Adam Churchill: Welcome everyone to another edition of the SpoolCast. Last week, Hagan Rivers joined us for her seminar, "Designing Dashboards." In it she showed us a whole bunch of dashboards and she gave the audience tips for helping stakeholders understand implementation benefits and drawbacks of seemingly simple components from graphs to customizable panels. We talked about all sorts of fun stuff.

This seminar has been added to UIE's user experience training library which presently has over 85 recorded seminars from wonderful topic experts just like Hagan giving you the tips and techniques you need to create great design. Hi, Hagan. Welcome back.

Hagan Rivers: Hey, Adam. It's great to be back.

Adam: So Hagan, for those that couldn't join us on your seminar can you give us an overview of what you covered?

Hagan: Sure. I'd be happy to. One of the things I wanted to talk about a lot in the seminar is that I see dashboards as being about more than just reporting. I wanted to show examples of dashboards being used to help users do activities. Go to windows, create new things, stuff like that. I introduced with this concept that it is about more than reporting.

And then, I really talked about the three pieces that make dashboard design great. The first is great visual design is important because dashboards are honestly what most people see first so what it looks like really matters. The second thing is having great data visualizations, also really important. And although I mentioned these things, I didn't really cover them in my talk.

I really focused on my third one which is knowing who your users are and their tasks. I had some examples where I showed dashboards that looked good and have nice visualizations but they're not very useful so making it useful is really a key piece. Then we ran through a lot of examples. I showed inspirational examples, dashboards that had some great ideas that you might want to grab from, little nuggets to use, and then I showed examples of stuff you probably don't want to do, some mistakes.

We closed by talking a little bit about customizing dashboards and I tried to convince as many people as possible not to do that but if they decided they wanted to I also pointed out some of the pitfalls and things they'd have to think about in that design.

Adam: Excellent. There were a lot of questions. We tackled plenty in the seminar but there were some left over that we didn't get to. Let's take a poke at some of the ones that we have in front of us.

Hagan: Sounds great.

Adam: Adam asks about the detriments of visual noise like pie charts and 3D. He doesn't like to use them but people that he work with insist upon them or contend that the customers want them. He finds that his data supported objective replies are insufficient to convince people like stakeholders and other folks that he's working with. I think he's feeling like he has to justify his dashboards with those visuals. How do you suggest that he approach that?

Hagan: [laughs] He's got a tough job ahead of him. So there's a few things I can suggest here. First of all, trying to persuade people of something that they haven't seen can be hard. So, I often find if your data-supported objective arguments are not enough them the best thing to do is to just show them. Sit down with Photoshop and mock it up how it would look without the noise and the pie charts and the 3D and see if you can communicate... I guess the thing I look for is not only can I communicate just as much information but can I communicate more information in the same space and show it to them and see if that persuades them.

We had a client we did work for, this was three or four years ago, and they had a dashboard and they had like 16 pie charts on the front so the whole thing was basically pie charts.

It was just covered in them and they weren't telling us a lot of data. There was a little information in them but for density it wasn't that good. We actually took those 16 pie charts and turned them into a really simple bar graph with 16 bars in it and we were able to actually show much more information in about a sixth of the space. It was so persuasive.

Up until then, they said, "We love pie charts. We've got to have pie charts." When they saw that just said, "Oh my God, this is so much better." So you know, try to really demonstrate it, don't just talk about it, and see if you can persuade them that way. But at the same time you've got to realize you just can't stop people from sticking beans up their nose.

If they're determined to do it they may be not able to listen to any of your arguments so you may have to accept defeat.

Adam: Says the mother of two boys.

Hagan: [laughs] Exactly.

Adam: Jim asked if you could speak a bit about the features for pod control and specifically, he offers up things like minimizing, restoring, maximizing, drag and drop.

Hagan: Right. So, he says pod. Lots of people use different words to describe that box on the dashboard. Some people call it a widget, some people call them pods, I called them elements in my talk, but there's no agreed upon term for this. I worked with a client who called them apps that you install on your dashboards, sort of hearkening to Apple.

A lot of these little boxes have this header area on the top where they have controls for doing things like minimizing and maximizing, deleting, editing, things like that. And you know, they appear in this little header and it's funny. Sometimes, I see them as little icons in the header and if I've got users who spend a lot of time with dashboards perhaps in multiple products, then they probably get it. They probably know how to use these little icons.

They probably even know what they mean, the little X means close or delete and things like that, but it's not a lot of users who have that much experience manipulating and fiddling with dashboards. What I actually prefer to do is I have the header area, I have the title for the element, and then I put a little menu icon in there and the menu icon is universally recognized, the little down triangle. Everybody knows that that will open a menu and when you open that up now you can use words to describe the action.

You could say things like edit this widget or delete this widget or whatever you want to do. I think that's much clearer for people and you don't have to worry about what they understand and don't understand. Actually, in the talk I showed an example from Apple's support groups site and they have a customize your dashboard place and they do exactly that thing.

The header looks very plain and then you go into edit the dashboard mode and that little menu appears and suddenly, you get all these other options there. I think they do a nice job of that if someone wants to go look and see if they like it.

Adam: Our good friends over at UC Berkeley want to know more about the challenge of designing a more institutional portal dashboard where they're convincing lots of different people to go and there's potentially a lot of different tasks that those people would do there. They're doing lots of user research but wonder if you have any other suggestions on how to find dashboard widgets that help draw those people in that they've tried to push in that direction.

Hagan: They're specifically looking to bring more people to the portal so that's interesting. This is going to sound really pithy, I guess, but the best way to draw people into your dashboard is to be really blindingly useful to them. Even in these institutional portals, human resources and things like that, which seem dull. Sometimes, you can find things that go a little above and beyond what people are able to normally do.

Let me see if I can come up with an example. Let's say you're doing a dashboard for HR and one of the things the employee can do there is request vacation time. So you know, you've got some link that says request vacation time. But the dashboard could show, for example, maybe the entire year's calendar with company days that are off, holidays, and also what days the employee's taken and how many days they have left, a whole little visualization.

First of all, it's visually attractive so that is going to entice people to look more closely at it but it may be offering something that they have a hard time doing themselves which is like when did I take time off, how much did I take, do I have any days coming up that I know about? That helps them answer some questions.

So I would look for these places where you can take something, even something small, and really make it extremely useful and if you can also make it visually compelling at the same time that's a double win.

Adam: Mark asks a question. I think he's asking how you design for different users, different being, how they actually use your dashboards. Specifically, he says how do you design for users that have varying volumes of data and frequency of visits?

Hagan: Yeah. This is a really common problem. You design this dashboard imagining a user that might have, let's say it's a mail dashboard, that might have 50 or 100 messages a day but then you get some user who only has two messages a week and some other user that has 10,000 messages a day and the dashboard breaks because it's just not flexible enough to handle this. Right?

So you've got to think about how do you create a dashboard design that can accommodate this really varying amount of data. And I think the big thing here is to remember the dashboard is just a summary of what's going on underneath. I think in the talk I showed a dashboard for an application that was managing alerts that were being sent out to people and there's a list of alerts in the product that the user has sent out. There are hundreds and hundreds and hundreds of them but in the dashboard we only show the most recent two.

We just creamed off the top of the list and just took the most recent two. Now a different app might be five or 10 or 20 but you only show a few of the items and then you have a link to say, "Well, I want to go look at the rest." The nice thing about that is it scales really well. We had users in the that app who would send out maybe one alert a month so the last two would be what they did the last two months.

We had other users who sent out an alert maybe a day or two alerts a day and that was enough for them to be able to see their recent work, too. It scaled really nicely but it always showed the same amount of data. I suppose if you had a user that had never sent an alert, you still have to think about that initial state, that totally blank state of the app. But once you get a little bit of data coming in then it should work no matter what.

Adam: We had some folks that wanted to know more about, I guess, your opinion on scrollable dashboards. What do you think about them? Are they possibly more effective than dashboards that show all of the information above where folks might need to scroll?

Hagan: Right. Everybody's got this obsession with scrollbars. First of all, I'm not sure what the terror of scrollbars is about. Users are pretty comfortable with the scrollbar. They know how to use them, they're well understood, they're a widget that's been around for a while so I don't have this knee-jerk, "scrollbars are bad."

It's really, really difficult to predict when a scrollbar might appear in your dashboard. Screen sizes vary, we know that, but users resize their browser windows to all sorts of crazy sizes. Really short, really wide, really tall, and any one of those could cause you to need a scrollbar.

I always design in and assume that whatever dashboard I'm building will at some point need scrollbars. Now, that said, you've got to be careful because if you have a scrollbar and you have maybe 10 screenfuls of stuff in your dashboard now you have a problem because scrolling, it turns out, is not a great way to keep track of where you are on a page.

If you wanted to quickly jump to a particular widget on your dashboard, the scrollbar is a cruddy way to do that. So if your dashboard gets really, really big, you've got to start thinking about breaking it up so the scrolling is not the only way to do it. There are other controls you could use to deal with those broken up pieces but the scrollbar isn't the best way to find that stuff.

I let the dashboard scroll two or three screenfuls of my target screen size is fine but more than that I want to break it up. I don't have any particular fear of scrollbars. I think they're well understood.

Adam: David has a project where his client is very fixated on using tabs for different views of the data. He's not comfortable with that and wonders if you've seen tabs work on dashboard pages?

Hagan: Yeah. This is a subtle and complicated issue. Tabs definitely can have problems. Users don't see them, they don't even realize the other tabs are present. They don't realize that they can switch to other information. Right? So that's, I think, what he's alluding to as being his fear. Now, I just said when you have a really big dashboard at some point scrolling is not going to work anymore. If you've got a five or 10 page dashboard, you have to break it up.

Let's say you break it up into five pages. Now, you have five distinct screens and you have to have some kind of navigational control for moving between those screens and you've got some choices. Tabs is definitely one of the choices. You could use a dropdown menu or a menu bar. There's a bunch of different widgets that you could pick to switch between these pages and each one of them has strengths and weaknesses.

Tabs definitely have their own but the menus and the menu bars, they have strengths and weaknesses, too. So rather than saying I think tabs are bad because I've seen problems with them how I would approach it is I would say is there something we can do to overcome the problems we know tabs have? If we know, for example, that users miss them then is there something we can do in the design to make sure they don't?

Add some visual elements. Make sure that they're aware those tabs exist. And sometimes, you know, an arrow pointing up to the tabs and saying there's more information in here is really all it needs. So rather than just sort of saying, "I don't like tabs, they're bad." I would sit back and say, "OK, I know they have these limitations. What can I do to overcome those limitations?"

Or perhaps try one of those other widgets. If you really think tabs are bad try the dropdown menus. See what you find there and what their limitations are and how you might overcome those and see which design you might like the best. In the end, sometimes all I do is mockup the different ideas and then walk through them and see what's the most usable.

I've been doing this for 25 plus years and I still sometimes just mockup ideas and play them out on the screen and see what works for me.

Adam: Lots of dashboards suffer from crowded information, crowded data, and Frieda wants to know if you have any suggestions for dealing with the mouse hover tool tip to help with that?

Hagan: Yeah. So a lot of these very interactive, reporting dashboards have charts and graphs and stuff and they use hover to provide information that's normally found in the legend. So, if you hover on a pie chart wedge, for example, you could see that it's 19 percent and you could also see that it was $26,000 and you could see the name of the wedge too, that it's "earnings this quarter" or whatever. So, the hover would give you all this great information.

But there's a couple problems with the hover. First of all, as Frieda asks, when things are close together it's hard to get your hover target. If you're reading a line chart and the lines are right on top of each other and overlapping you can't be sure you're hovering on the right element so crowding is a big problem.

The other piece is you have to move the mouse around to get this information. You have to keep chasing after targets to try to learn stuff. So I do have hover in the charts and graphs that I create but I treat it as a secondary, kind of supplemental channel. I use the legends to show what the colors in the pie chart mean or labels or legends, something that's visible without me touching or moving the mouse on the screen.

I show numbers sometimes on the charts, if I think they're unreadable in some way. Then I let the hover expand on that. Maybe in the pie chart, I might show the percentage and the name in the legend but only on hover would I learn the actual dollar value, something like that if it's not information that's essential. The hover, it can expand on stuff but I've got to assume when designing it that the user will never think to hover on the graphic element and what would happen to my design when that happens?

If they miss critical information without hover, then that's not good. I want to make sure the hover is just supplemental stuff.

Adam: Jason asks what I think is a wonderful question because it's big, it's all encompassing, but ultimately it speaks to, I think, what we all want the perfect dashboard to do, right? He asks, "what if we know our users well enough to know that they all want something different on the dashboards?"

Hagan: [laughs] Yeah, that's a great question. It's funny because practically every client I've worked with that makes a dashboard makes that claim. They all tell me that. All of them. [laughs] I find, honestly, in like 90 percent of the cases, it's really not true. First, I've got to make sure that he's not part of the 90 percent. Think about the argument you're making. You're saying that not only is every user unique, which is a stretch, but that those users are going to be good at building dashboards.

It turns out the skill of building a good dashboard is not easy, even for people who know what they want. It's hard for them to assemble those pieces. So as the designers and the software engineers and the people who work on the project, you're actually in the best position to design, for that person, a great dashboard. Even if it was true that all of your users were unique, you would still probably design a better dashboard for them than they would for themselves.

First, I argue that. That you're really good at dashboard design. The second piece is your users probably aren't all unique. They might fall into a lot of groups. There might be 15 or 20 different groupings of users or types of dashboards that they want but there are groupings. I always tell these clients why don't we start by trying to identify, you know, the hundred dashboards you think your clients might want?

I start with 100. We usually end up with like 10 because after that they can't think of any more. They've exhausted every possible idea they have. I say, "OK, come up with a user who doesn't want to use these 10," and they can't so then, I know that first statement wasn't true. The users don't all want something different. There are a lot of cases but they are solvable and so we can design those 10 and make them really good.

So I've worked with clients where we did exactly that. One client we had almost 20 dashboards but they were all unique and solved really different problems and they were really good and we had no customization and their users never complained because they had what they needed. They were done. And I've also worked with clients who don't design any dashboards really, maybe one in initial one, and then they spend a lot of engineering time building all these customization tools and their users never customize dashboards. They never build them.

It's too hard or it's too much work or they just can't be bothered. That's not interesting to them. If you had to decide where to invest your time, I would invest it on the side of creating the dashboards for them.

Now, if you make the 20 or 15 or 100 dashboards and your users still want to customize then I think it's time. By then you've built enough of them that you know what kind of customization you need and it's time to think about that customization design. People do need dashboard customization but it's a much smaller percentage of people than they think.

Adam: Tom asks about mobile, curious if there are dashboards that you've seen for mobile that are good as a reference or any experience you have with this evolving piece of the puzzle.

Hagan: Yeah. Actually, we talked about this during the virtual seminar but at the time I said go look at Google images, which is a pass off of an answer. There are some really nice dashboards being created for mobile. The best ones are on the iPad, as you might expect, where we have more screen real estate.

There's a bunch being created for website management so Gecko Board is a common one, Go Squared, and I think it's Duck Board or Ducks Board, I can't remember. Those three are all basically for managing your website and they give you all sorts of real time information on who's visiting your website and all of that stuff. They look fantastic. They're iPad apps.

I think they have iPhone versions as well but they've done some really nice dashboard work there. And you know earlier I was talking about the hover stuff. The interesting thing is once you go to touch you lose all the hover information so your dashboard's got to be ready to work without any kind of hover at all if you're going to go to the mobile world.

Then also there are some apps like SalesForce. SAP has an app which I think is Business by Design I think it is and they also have built some dashboards that are really nice work both on the iPhone and iPad and on Android as well. Even Facebook, if you look at Facebook now they have this little sidebar that you can open up and it's got mainly navigational elements. It'll show you how many of your friends are currently available on chat and it'll have a count.

It's a little, tiny dashboard. It's not a very rich one. A lot of the home screens of iPhone apps and iPad apps are in fact, if you look closely at them, are little dashboards. They get you going using the apps and they give you a little bit of reporting data. Those are some examples that I didn't talk about during the seminar and now you've got them.

Adam: Excellent, Hagan. Thanks so much for taking time out of your busy day to circle back with us.

Hagan: It was a pleasure.

Adam: Thanks everyone for listening in and for your support of the UIE virtual seminar program. Remember you can get all of the details on our virtual seminars at uievs.com.