April 2009

In construction, there are “weight bearing” support structure – if this support is knocked down or otherwise compromised, the whole building can come down on your head. Also, if you “overload” these weight-bearing supports with two much weight… well, same thing can happen. Obviously, this is a Bad Thing.

I have recently discovered a similar principal in UI design – each screen, based on its purpose, has a “bearing weight” it can maintain before failing the users. Let me explain:

I recently designed and tested three types of screens, and two of the screens tested well – the participants understood what the screen should do and were able to accomplish tasks with no questions or problems. The third screen was different. Users looked at this screen and were completely lost. They understood, to some extent, what they could “do” in the screen, but they did not know where to start.

It was cognitive overload, due, to a great extent, to exceeding this screen’s “bearing weight” – there was too much to process, and the participants “shut down.”

Was this the primary cause of the participant’s confusion? No – there were other usability issues observed and factors at play (for example, a different layout from the two “sister” screens was used). But the fact that it had one module too many was important, especially looking at the intended use of the screen. It was a forecasting/analysis screen that users would be able to access to do planning activities. Several sections of the screen DID NOT SUPPORT that task, and this extra “cognitive baggage” it reduced the total usability of the whole UI.

Naturally, this “bearing weight” of any UI will vary based on context and purpose – the screen for a mobile application, or a log-in screen, may have a “single-threaded” task that should have no distractions or additional design elements – it’s “bearing weight” is low, one widget at most. The opposite end of the spectrum could be software stock brokers use to track the market ““ these users want as much information as the screen can provide, and therefore the screen can “bear” a lot of content areas and/or functional modules.

When in doubt, start simply, and then add layers of complexity based on design reviews and usability testing. Just as architects have to make sure the proper materials are used when planning weight-bearing walls, application designers must also find the right combination of functionality and content to make the screen work – without it crashing down on the user’s head.

Follow Joseph Dickerson on Twitter.

{ 0 comments }

I recently tested some designs for my company and thought that a screen design I came up with (a UI module that gives users better visibility into their finances – in a sense, “how are things going?”) was rock solid. It was building on a couple of earlier iterations of the design and I considered the testing to be a mere formality.

Boy, was I wrong.

Testing began, and before I showed the first participant the design in question I exposed the participants to other designs in the prototype system, screens which allowed them to move money around and do things. Then, I got to that “how are things going?” screen.

Blank stares. Confused looks.

EPIC FAIL.

Whenever you have to explain to a participant how something works when they can’t, after some consideration, you tell yourself “well, you see that big thing on the wall over there? It’s called a drawing board, get back to it.”

(And, obviously, the majority of your users will not have the opportunity to have a tall bald man sit next to them and tell them how stuff works – though anything could happen).

After seeing the same reaction occur, again and again, with the remaining participants it became pretty obvious the design was NOT “rock solid” and in fact had some significant issues. What was simple and obvious to me, the designer, was not at all to the participants, who all represented typical users of the existing system. Again, this is why you test designs with users (probably preaching to the choir, but still).

After analyzing their responses and the notes my lab partner took, I discovered a major problem with the design. It was intended to be “interactive“ in that, if you saw a data point on this screen that was a cause for alarm, you could click it, open the item, and change it. The participants did not see this AT ALL. They thought, due to the location of the screen in the navigation structure and the content surrounding this design that the screen was only a helpful “report” = Informational, NOT functional.

Why? Well, it was because the navigation structure that was applied in the proposed design. The UI modules that supported the primary functions (moving money around) were on other pages… the participants expected that they needed to go to one of those pages if they saw something “wrong” instead of doing it on the page itself.

In other words, the participants separated the system into two spaces: the “doing” space and the “reviewing” space, and mixing them in this screen caused an unexpectedly high amount of confusion.

How to fix this? Well, I’m still working on it, but a possible solution is to place a smaller, more streamlined version of the “how are things going?” module on the functional pages, as “thermometer” to help users understand their current situation (and making sure to not duplicate functionality that already exists).

This was a good reminder to me, and hopefully you, kind reader, to remember: Every screen, like a scene in a movie script, should have a point to it, a purpose, to help support the goals of the user. What I did was the UI design version of mixing a dialogue-heavy exposition scene with a big action sequence… it was a muddled mess. Live and learn.

Follow Joseph Dickerson on Twitter.

{ 1 comment }

This article is a short version of my presentation on the topic, which I can present to anyone interested. I do Bar Mitzvahs and weddings, but kids birthday parties are off the table. Sorry.

I’ve tested a LOT of different designs with users over the years, working in varying environments – from one extreme to the other. I’ve ran usability tests for companies who paid tens of thousands of dollars just to rent the (high-tech) facilities we used, and I’ve walked through design concepts with customer service reps in their break room. I’ve also helped set up three permanent usability labs, and through that process I’ve seen a lot of really expensive gear that several consultants said you “have to have” to really run an affective usability test.

To which, I say – Poppycock. Balderdash.

(I’d add another archaic term of disrespect, but I can’t think of one right now – maybe later.)

Cost is not important – the testing is. “It’s not that important, we don’t need to test that,” is a phrase I have heard repeatedly, sometimes from peers (who should know better). What I’ve found in my experience, the moment you have a high degree of confidence in a UI and think that you have “nailed” some design problem – that’s the moment you HAVE to schedule a usability test, even if it’s just with friends and family.

You may be completely right, the design may be utterly appropriate to the user task – but as a certain ex-President once famously said, “trust, but verify.”

Usability testing is of vital importance to any design, and doing as many focused tests as you can afford results in a better end product. Of course, if you’re an interactive design professional, I’m preaching to the choir here. You know that focused usability testing is important, and you are probably promoting usability testing to your project’s stakeholders all the time.

What you DON’T have, in many cases, is the budget to do the testing you know should to get done. And even if you do have budget, in current economic conditions it may be – or has been – squeezed. And many outside of our domain look at usability testing as budget items that can be cut, not vital activities that help maintain quality.

I’ve been there, done that, got the t-shirt. So, how to get the same results you need, for less money? Here’s some tips on cost cuts and strategies that will help get your tests funded and done.

(NOTE: In this article I refer to new designs, but the approaches I recommend are equally affective if you are testing existing systems to get “baseline” usability results.)

Need users? Don’t pay a recruiter, use Craig’s List.
This one is somewhat obvious, but worth noting. Craig’s List is an awesome tool to get leads on ANYTHING, from used pool tables to replacement lamp shades. It can also help generate leads for potential participants for your testing. Keep in mind that, unlike a recruiter you pay to do the screening, this will mean that you need to screen the candidates yourself, so have a solid script/screener you can use.

I have actually had the misfortune of hiring recruiters who claimed they had an extensive database to pick candidate participants from – who used Craig’s List to fill their slots. If you are comfortable doing the work (and have the time to dedicate to screening recruits)- cut out the middleman, and do it yourself.

Build your own reusable participant list.
The more you test, the more opportunities you will have to meet different people in various professions that fits certain “niches” that you may need to revisit for future projects. If there are no “awkward moments” during the tests and the participants provide good feedback, then ask if they would be interested in coming back for future testing. If they are, add them to a “call-back” list you can go to later.

Test a lot of stuff at once.
Again, seems like a no-brainer, but worth considering. Several times I’ve “stacked up” a backlog of design concepts that do not need urgent consideration, some barely past the ideation stage. I don’t set up specific targeted tests for this work, but the functional prototypes are “at the ready” whenever we have the time to expose them to users. If the dry-run of the test protocol runs 45 minutes and you have the participants for an hour, bring them into the test.

Interns rock – get some.
If you have limited bodies at your disposal, contact a local university and get some more. Most colleges have intern programs that you can tap into, and you will often find some very passionate students that can help turn what was previously planned to be a short session with participants into a full test. Passionate, and cheap – a great combination.

The cool software is nice, but usually unnecessary.
Don’t have the cool eyeball-tracking software from Facelab or great broadcasting/note taking tools like Morae? Don’t sweat it. Get a cheap $300 mini-DV camcorder and a $20 tripod, position it next to the workstation (so the camera can pick up the screen or workspace as well as the participant) and hit record after you have the participant sign the video release (also, obviously, don’t forget to have them sign the release). Don’t take notes yourself, focus on facilitating the test and following the protocol – you can take notes from the tape later.

Can’t afford the camcorder? Get an intern to sit in the room and take notes. Again, they’re cheap.

When all else fails, use friends and family.
It’s never preferred, because you may have built up a personal relationship with the very individuals you may be walking through one of your designs, and biases will creep in to their reactions. Get around this by e-mailing colleagues at your company and asking for volunteers – and, if possible, get one of your peers to facilitate the session if you are too close to the participant(s).

Schedule the tests whenever the participants are available.
We need to accept that people have lives, and, while making sure that you get that design right under deadline (and, depending upon the project, under pain of torture) may be of MISSION-CRITICAL IMPORTANCE, the rest of the world doesn’t care. So, be flexible – work with the participant’s schedule. They are doing you a favor by coming out – never forget that.

Don’t cut the participant’s compensation
One last note: don’t try and save money on participant compensation. Pay them for their time, and pay them well – I think $100 for an hour of a person’s time is appropriate. Obviously, adjust based on your location, but make sure you pay better than minimum wage.

Hopefully, this has been helpful, and remember, TEST YOUR DESIGNS. It’s important to do, even if you have no funding to do it. Test even if you don’t have the approval – in my experience, it’s always been easier to ask forgiveness than acceptance – especially easier after your usability test results in a better design to go to market with.

Follow Joseph Dickerson on Twitter.

{ 0 comments }