Slashdot Mirror
Software, Tools, Or Techniques For UI Review?
Comatose51 writes "Does the Slashdot crowd know of any software, tools, or even techniques for reviewing the UI of an application? Right now at our company this is a long and arduous task of looking at slide after slide of pages and menus from our UI, and taking notes and arguing over what should go where or how the UI elements should behave and interact with the user. It takes many, many hours to do this and with all our UI developers involved, it adds up. This has to be a common and recurring problem so there must be a better way to do this. If there is open source software to help, great, but any helpful suggestion would be appreciated."
used the number of mouse clicks to perform any given task as the metric to determine if Office 2007 had a good UI. It seems the impact of that choice is debatable.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
We hired this company, who $3mill later gave us a wireframe mocked up in Photoshop of what the UI should look like. The execs LOVED IT. One problem... the tools which had already been decided on and purchased couldn't produce anything that looked remotely like the mocked up UI. Guess who got blamed? Management? No. Developers? Yes. Because they couldn't produce a UI that looked as "cool" as the wireframe.
Form follows function.
You first have to work out the flow of the program (or web site). Which options are on which screens? What's on the list that takes a user to a detail page? Is the delete button on the list or on the detail page?
For the above, I found the best way is paper, pencil, pushpins, and yarn. Find a big wall in a conference room, and start sketching it out. Quickly draw the data elements and input fields on the paper. Use one piece of paper for each web page. Use pushpins and yarn to show how the user navigates. This approach is 1) inexpensive (doesn't take a coder), 2) easliy understood by everyone and 3) easily changed.
After the function is nailed down, then the designer can take this and select fonts, colors, etc. and mock up a few pages to give back to you, the programmer, the style to apply to each page. That is, of course, if you have a graphic designer at your disposal.
sig: pv qid
Not in the least. Lord no. Perhaps have them polish up and make things look pretty after the UI is decided upon, sure, but leave the UI design to people with a background in it. That's the equivelant of telling a baker to to cook you a steak. They might both make food, but the thought process is totally different.
If you have a technical writer working on the project, give him/her a shot at it. Their job is to make the complex simple and to make it fit in as small of a container as possible. They'll also be the ones writing the manual on the stupid thing and, more often than not, many design flaws come out in the process of writing the manual. You'd be surprised what kind of input they might have.
Other than that, do you have a corporate psychologist or HR person with a background in psychology? They might also have valuable insight.
Other than that, as far as viewing the UI for a review, have someone make a mock up, clickable UI in Flash or even HTML. It shouldn't take long and will give you a good idea of what the user experience before it's all coded in.
Wise men say, "Forgiveness is divine, but never pay full price for late pizza."
You know what's better than asking the users?
Not asking the user.
What you really should do is watch the user. If you ask them, they'll tell you what they think they'd do, or what they think you want to hear, or what they think they'd like to see... everything except what is most important: what they really do.
(And I'm not the only one who thinks so.)
JJ
Give the program to the average secretary & watch where she stumbles or otherwise looks confused.
The government is not your daddy. Its purpose is not to raid middle-class neighbors' wallets and give it to you.
In this section in particular -- past the comic -- there is an example of a redesign.
Raise your hand if you would rather try to point at a specific location on a map than simply choose it for a list.
And you know what? By the time you're using this form, you know the date, as text. It's going to be quicker and simpler to enter it via the dropdowns -- even quicker if you can simply type. The calendar widget only helps if it can show me events I've already placed on a calendar -- otherwise, there's no point.
I don't know if that's a representative sample, but it makes me very reluctant to read the rest of the paper.
Don't thank God, thank a doctor!
Yes, parent is exactly correct. On a very large project we were running, we actually hired one (maybe it was two) "human factor engineers". As I recall, the woman had a PhD in human factors and was extremely useful in putting things in perspective.
If you're on a large project with a correspondingly large budget, an HFE will be money saved, in order to free up the time of your developers.
Human factors is one of the most overlooked aspects of an app, and having a programmer design it is bad for a number of reasons. HFEs will enable you to get less "it just doesn't work" phone calls at the help desk for your new app, because of stupid UI confusions on the part of the users.
It's a net gain
If you can read this... 01110101 01110010 00100000 01100001 00100000 01100111 01100101 01100101 01101011
Also have the programmer themselves have to use the application for 'a day', in a real-world example - the guy who knows the UI in and out, so training is not a problem.
But as a programmer he/she will see what doesn't work when they have to enter data live (i.e. entering client data with client sitting across the desk) - and they will get a pretty good idea of what needs fixing and how to get it done. For more complex concepts they may have to be the keyboard pilot with an expert telling them what they want done, but having that hands-on dose of reality will help smooth out the worst bits.
I program for a small NP, and have to use my programs as well, it gives me a lot of perspective for the end user as well as the clients we serve while the staff use the system.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
Use a rapid application development package... Visual Basic is fine for that job, even if I lose all credibility by saying so... and do a mockup.
Get a few users. They should be people who are not members of your group. They should be vaguely typical of the people who will really be using the real application. They should not be managers or anyone with power to dictate their preferences as requirements.
Give them absolutely minimal directions. Let them try to use the application. Watch them. Resist the temptation to say anything unless they get so very stuck that there's no longer any hope of learning by watching them; then coach them just enough to get them unstuck.
See what they do. See what they assume. See where they make mistakes. I guarantee you you'll learn more in ten minutes than in hours of having people familiar with the code review slides. The places where you think they'll get stuck are the places they'll breeze through. The places where they do get stuck will surprise you completely. And you'll suddenly see glaring, obvious, easily fixed goofs in the UI design that you didn't notice in any review.
If you want to do a big formal megillah with one-way glass and video typing and people with psychology degrees, fine, but that's not important. The important thing is real users really playing with a functioning application.
Reviewing slides is nuts. Having people who develop the application review slides is nuts. You can't possibly figure out how something is going to work and feel by looking at slides. It's like figuring out whether a car will be fun to drive by looking at a static picture of the dashboard.
Some years ago someone was showing off an application... one of those GUI-like database applications that ran on character-oriented screens... that his group had done. I was playing with it. He was bragging about the screen refresh, the way they'd implemented scroll bars with characters, and so forth.
I noticed that three successive screens required me to key in the identical piece of information three time in a row. I also noticed there wasn't even a copy-and-paste function.
I pointed it out to him. He said, "Yeah, I know." I said "Are you going to fix it?" He said, "No." He whipped out a 3/4" thick spec. He said "It took six months of review to hammer out this spec. It's done. What you saw is what the spec says."
I said "You mean nobody noticed that problem during the review?" He sighed. "Apparently not."
"Well," I said, "why not just fix it?"
"Look," he said, "it took six months to get this spec signed off on, we're not going to open it again or it will take more months, we need to get this through SQA, and what SQA will be doing is checking to make sure we conform to this spec.?
"How to Do Nothing," kids activities, back in print!
A good UI is not cute, cool, or pretty. It is one that makes
functionality obvious while itself remaining invisible.
You can make a good UI cute, cool, or pretty, and you may get praises
for it, but it isn't what makes it usable.
There is a fundamental paradox is usability testing. If you ask about
usability, you are asking what people notice. But the best UIs are those
that are not noticeable. You should never test a UI. You should only
test the usability of the application, and measure things like confusion
and task completion speed.
These people really designed a UI that becomes usable after some training. Great take aways...: 1 Use the simplest method possible to control something.
2. Dont add buttons.. On My Imac there is a small remote 2 buttons, and an outside ring.. This is FAR more powerful than the 50+ button remote for Dad's TV+dvd player remote.
3. Dont Hide controls too deep.. look at vista.. changing an ip address Start->CP-> network ->Internet properties-> oh that meant browser properties SOB -> Manage network connections -> now either magically know to right click "wireless connection",, or notice the double arrows at the top for more options because it opens too small by default and choose "change the settings of this connection".-> then choose ipv4 -> properties -> set it to the correct value.
up until you get to the wireless connection right clicking is useless. right click on network, poof no properties.. right click on this computer-- nothing.
If you add in a spiffy trick for the users, embrace it.. to the bitter end. once users expect the right click to get them "under the hood" it's a cruel thing to yank that out from under them.
4. Dont make it too easy to do things people dont want to do all that often..
in explorer when your launching a program,, it's far too common that it's trying to rename the file.. and your waiting, and poof you hit space, blank the filename.. and hit esc hoping that the damn box will repopulate. This is where F2 or right-click are appropriate.
5. Dont ask for input.. you will end up with the car that Homer built, if your lucky. I'll admit it was pretty cool... but the idea stands... the customer will ask for features and spite the elegance of the interface.
Storm
In all the tests I've done in asking vs. watching, the users complain about inconsequential things, while the real problems they had aren't even mentioned.
I had someone complain about what a button looked like for 5 minutes; the button was too small, not visible enough, and had an obtrusive font. Yet actually watching that same person use the app revealed they had no problems finding the afore-mentioned button (and using the associated feature), while another feature had them completely and utterly confused--yet they didn't mention the part that actually caused real problems.
Interesting how users many times don't realize (or remember the realization about) the problems they experienced and therefore don't relay them properly. A camera and a tool that records their activity on the screen is probably the most invaluable tool for usability (so the user doesn't worry about somebody standing over their shoulder, which actually alters the way that user works).
Sanity is like a condom: rather have it and not need it, than need it and not have it.