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!
"Absolutely ask the users. There is no better way of evaluating your UI." - by hardie (716254) on Tuesday July 29, @04:49PM (#24391601)
Hardie?
Agreed, 1000%, here!
Man - I had a job with an insurer 2 yrs. ago (almost) as a programmer/analyst (title I had), whose majority of developers ACTUALLY SAID & THOUGHT their users were "dumb" (etc.)...
Man - well, know what?
Those people ARE OUR LIFEBLOOD, as coders, & WHO YOU WORK FOR in this field of endeavor, first of all.
Secondly, I was tasked (as one of my assignments/projects there I delivered successfully of the 4 I had) to redo an ASP app into ASP.NET (& make it more secured + userfriendly)...
So, how'd I go about that?
By asking the users what they did NOT like about the original... & guess what?
All along the way, each week, I would take the MAIN user @ first, & let her tell me "I like this/I don't like that" etc.
(When asked why she did not like a particular feature, I would listen & then make it how SHE wanted it... then, after her, I let the other users (in order of importance and usage of said app) take shots @ it)...
In the end??
Well, in our morning MIS/IS/IT meeting on the day of its delivery???
Their people came into OUR meeting & said "THANK YOU" to me...
(Big surprise it seemed, the MIS/IS/IT dept. apparently never had THAT happen for them before (& rightfully so - their philosophy? Doesn't have to be 100% done & working well + easy to use, just get it out the door "the XXXCO way" is what they called it)).
I am GLAD I don't work there anymore though, as building "junk" is NOT my style, but instead, building the BEST I CAN POSSIBLY DO, is!
( ... & the only way I have personally determined that is 'doable', is to address it with YOUR USER AUDIENCE - because, after all, they are the ones that will BE using it!)
Makes total sense...
GOOD post hardie, you're "110% dead-on correct & bulletproof + bugfree" on your statement by all means, imo @ least (16++ yrs. as a professional developer, & multiply degreed in this field as well as internationally published now around 10x).
APK
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
After trawling the web I found a checklist which I use as a template for UI testing. Not all are required for every app. I also pass it on to the designer to make sure things are as they should be.
http://it.civil.aau.dk/it/education/reports/he_cklst.pdf
I work as a usability engineer, and I'd echo what other people have talked about with testing. Doing a dozen week-long iterations, each of which culminates with testing the interface in front of a bunch of real, actual, live (no imitation!) users is worth more than a pack of developers arguing about the placement of buttons. Because all you'll ever get is an argument if everyone is using their gut instead of data or logic. The reason people use their gut is that it's really hard to mentally anticipate the effect of your interface on end users due to the huge number of input variables that a human is operating on. And your ability to emulate the decision making process of an average human starts out crippled if you happen to be one of those rare people who can understand math and complex logic and who therefore thinks nothing like 99% of the population. But why bother trying to emulate their decision making processes in your mind when it's cheaper and more accurate to simply watch them use it? Your boss has got a gut feeling that a button should be labeled X? Show 'em that 85% of novice users and 70% of domain experts found Y less confusing. You might still have a discussion, but at least you know some of the facts now.
So in that vein, I'd recommend prototyping applications. It doesn't have to work for real, so I've hacked prototypes together using OmniGraffle Pro, Flash, JavaScript, Interface Builder, even HTML and powerpoint. I know some people use Visio, VB, and Denim too. The only dedicated usability application I've used (we can't afford eye tracking here, but that could also be useful) is CogTool** which can be useful for modeling expert behavior.
*http://dub.washington.edu:2007/denim/
*http://www.cs.cmu.edu/~bej/cogtool/ Full disclosure: While I'm not affiliated with this tool, I was friends with some folks who worked on it.
The biggest problem with UI is... there is no perfect UI..... a UI is always in the eye of the beholder, some like this, some like that.. Some people like to work with toolbars, some with ribbons, and others with menu's... All manuals I've read so far about UI design is always from the perspective of the writer, 'his/her way would be best', well it's not... Also some methods may work for Application A, but it won't for Application B, hell sometimes it even doesn't work in the same application... So no matter what tool you try to use, it is always based on someones opinion.. I'm realistic enough to say that it's just not possible to create a UI that fits everybodies needs/wants.. and someone who claims he/she can is wrong and nothing more than expressing his/her opinion.. So to get to the most 'wanted' UI you need input from a lot of people...
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.