Slashdot Log In
Software, Tools, Or Techniques For UI Review?
Posted by
kdawson
on Tue Jul 29, 2008 03:33 PM
from the visual-spider dept.
from the visual-spider dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Well, there's your problem. (Score:5, Insightful)
Too many cooks, as it were.
Re:Well, there's your problem. (Score:5, Informative)
Parent
Re:Well, there's your problem. (Score:5, Insightful)
Also, for all your developers, do you have a designer? UI development = graphic design + industrial/interaction design.
There is also the little concept of actually using the software. Here is my plan that I wish every corporation would adopt for near perfect design:
Of course this is from a user's perspective and from someone who writes software for myself. Profit may get in the way of a usable product, so I don't expect my plan to get adopted everywhere.
Parent
Re:Well, there's your problem. (Score:5, Insightful)
This is good advice for many consumer products but not for all software since some software is intended for users of whom the CEO is probably not representative. Software for technical people, for example, may trade a longer learning curve for greater efficiency or configurability for experienced users, and software for some tasks assume specialized knowledge of the task that most people won't have.
Good luck finding a CEO who will let you fire him if he doesn't test your software.
Parent
Re:Well, there's your problem. (Score:5, Insightful)
I think his point was more that the best way to design a user interface is to let the users actually... y'know... use it. Throw it out to a small but select non-developper beta, and take their suggestions about usability to heart.
A group of engineers sitting around, arguing about what should be where is just going to obfuscate things, and unless they get really lucky, it isn't going to result in something that's usable. Also... keep in mind the idea that nothing should be more than 3 clicks away, unless it's obscure. More than that, and users won't remember it. If it's something that they use frequently, it should be 1 click away. All about keeping the application efficient, but not cluttered.
My first thought, when I read TFS, was that he's out to lunch. He's looking for software to accomplish a task that, to my mind, should be a completely organic process. You can't write software to design your user interface for you, because people don't think like computers. You need to go through revisions and iterations until you get something that works. Oh, and sitting around watching slides is absolutely the wrong way to get a feel for how it's going to work, too. They should be presented with the actual user interface, or a mock-up if that's not possible, and actually go use it for a few days before coming back and talking about what was good and what was bad, and what needed improvement. And keep doing that until enough people are happy that you'd be comfortable unleashing it on the world.
Parent
Re:Well, there's your problem. (Score:5, Insightful)
don't take a single word of the user reports without some sort of usage pattern logs. users tend to concentrate on the latest bad experience they have had. measure time spent on windows, time spent on similar tasks, undo per windows and a lot of other metrics, as time between clicks on button, and filter the user reports trough the application log (and vice versa) most of the bad experience could be just automated away, hidden completely or better represented by some sort of flow management (as wizards).
Parent
Re:Well, there's your problem. (Score:4, Insightful)
You don't want your ceo to be representative. The average company with a CEO has at least 50 people. You really want that person to have the best leadership and organizational skills of those 50.
Parent
Re: (Score:3, Insightful)
This is also supposing that a given CEO actually KNOWS the business he leads. Too often, it's marketing and sales people that end up in the top positions of many businesses. This often means that they have little or no appreciation or understanding of the usage or applications, products or services this company may offer. Companies lead by sales and marketing types often have little respect or regard for what they offer and concern themselves only with the numbers. The is a terrible trend as quality oft
One better (Score:3, Interesting)
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 wa
Re:Well, there's your problem. (Score:4, Informative)
Of course, that is what Apple does with its software. If Steve Jobs doesn't like the user interface, it gets changed.
Doing this has helped Apple be the leader in user interface design and the stock remark recognized ths when news of his possible illness dropped Apple shares considerably.
Parent
Play some portal... (Score:3, Interesting)
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-
Re: (Score:3, Insightful)
Agreed, I don't really see a lot of CEO's using Visual Studio, Eclipse, Photoshop, Dreamweaver, Quickbooks... Its not that the products aren't usable, its because they have no point of reference.
Sure, they should be able to QA something like a web browser or office suite, but that's about it.
UI Development != graphic design (Score:5, Interesting)
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.
Parent
Re: (Score:3, Interesting)
technical writers should be involved at all levels of the spec writing process. Ofttimes, the specifications, functional/technical/implementation are loaded with ambiguities information and incomplete or conflicting requests.
The technical writers can bring a great deal of clarity and sanity to the table. Not every company can afford dedicated writers for every product/project, but every company should be asking the documentation group to read over the functional spec prior to using that to create any sort o
Yuck! (Score:3, Interesting)
In this section [worrydream.com] 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
Re:Well, there's your problem. (Score:4, Insightful)
Design by committee is a terrible process to endure and very often the outcome is of far less quality then a design done by someone who knows what they are doing.
Parent
Re:Well, there's your problem. (Score:5, Interesting)
Give the program to the average secretary & watch where she stumbles or otherwise looks confused.
Parent
Ask the users. (Score:5, Insightful)
Ask the users. The people who will be using this software have certain expectations about where something should and should not be located.
Of course, that should not be the end-all of your research, but it should be an excellent starting point.
Re: (Score:3, Insightful)
The users should be doing - or getting someone to do - mock ups. Use vb6/.net, or Access, or Visio, or anything else which lets you knock up some pages full of controls which look similar to what they're after. Doesn't matter what it looks like, as long as you can tell a listbox from a text box etc, and how much data they want per page (ie does it scroll, have next/prev buttons etc). It's not up to developers to either decide or guess.
Re:Ask the users. (Score:5, Insightful)
Absolutely ask the users. There is no better way of evaluating your UI.
Have your programmers watch users try the UI. Don't lead the witness--let them make mistakes (and fix that part of the UI).
You will be surprised what you learn.
Steve
Parent
Re: (Score:3, Insightful)
I am a programmer, and would like to offer my opinion.
DO NOT ASK THE USERS. FOR THE LOVE OF GOD, DO NOT ASK THE USERS.
Users don't have a damned clue about software design, and will always ask for something stupid. They might ask for something that seems simple to them but is hideously complex or impossible to implement (I once had a user calmly demand I should replace the entire complex app with a box where they could simply specify in english what they want and push the button and it would magically figure
Re: (Score:3, Insightful)
In my experience, users usually don't know what they want. Or worse, they'll ask for something, but really want something else.
This idea works better if you have a professional UI designer work up some designs and present those to the users.
You should use your users to generate ideas for your interface, and also as a checkpoint for your interface. But giving them too much input will screw up your end results.
Re: (Score:3, Insightful)
"Ask the users."
To recall Henry Ford: we would be trying to make faster horses instead of cars, then.
Re:Ask the users. (Score:5, Interesting)
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 [useit.com].)
JJ
Parent
Re: (Score:3, Informative)
Not to mention users are idiots. They don't know where they want things. What menus they want... etc etc etc... if you ask the users they'll tell you they either "liked it" or "were confused but are sure it wasn't their fault".
The MOST IMPORTANT thing a UI designer needs to work on is FLOW. The specs tell you what the application needs to do. "Color Correct a Photo", "Remove Zits", "Paint: change brush size, paint, change brush shape..." etc etc etc.
If you watch your users and see A) What they do most o
Apple Human Interface Guidelines (Score:5, Informative)
Re:Apple Human Interface Guidelines (Score:5, Funny)
Parent
Paper Prototyping (Score:4, Insightful)
http://en.wikipedia.org/wiki/Paper_prototyping [wikipedia.org]
Now, that may not actually address the problem. UI fights are intractable with **everyone** having an opinion and more than willing to resort to all kinds of dishonorable methods of getting their way.
The next step of the process should be interviewing as many paying users as possible, face to face, paper and pencil ready. From those interviews see if you can find some similarities and go from there.
Just Use It (Score:5, Insightful)
Nothing beats using it.
Years ago in my tech startup days, I remember spending hours just using our about-to-launch web application, doing my best to break it. Things are a bit different when you're not web-based, but doing this on a variety of computers is still a good way to find bugs, note slowdowns, discover any issues with running it concurrently with other software, etc. This is also a nice (and sometimes fun) way to involve ALL of your staff -- not just IT -- because there's going to be a wider variety of user experience levels there.
Re:Just Use It (Score:5, Informative)
useit.com [useit.com], Jacob Nielson's site. Everyone having anything to do with interface design should read the whole thing.
Parent
Re: (Score:3, Informative)
And they have a non-spammy newsletter that lets you know when new articles go up. If the OP can afford it then a seminar or two may also benefit them.
UI recommendations from a web page that looks (Score:3, Funny)
Uhm, that web page hurts my eyes. Are you sure you recommend this as UI interface design reference.
CUA/CUI specs (Score:5, Informative)
There are CUA guidelines for various operating systems. You can check out that documentation to determine where what components/options you have should be placed. They are pretty thorough.
IBM's was written in 1987, and updated since (and followed for the most part in the Windows and OS/2 world).
Microsoft's has of course recently changed with the advent of Vista and related v2007 programs.
For broadest use, I would choose the specs used in later versions of Windows for Windows based apps... for Linux, I am not sure where you would check - but am sure some sort of guidelines should exist someplace.
A place with links and references to IBM's CUA can be found here:
http://en.wikipedia.org/wiki/Common_User_Access
From there, or with similar searches, you can find references for related Windows CUA stuff
Re:CUA/CUI specs (Score:4, Informative)
For broadest use, I would choose the specs used in later versions of Windows for Windows based apps...
Should have read (changes in bold):
For broadest use under Windows, I would choose the specs used in later non-Vista versions of Windows (such as XP) for Windows based apps...
and (added)...
The CUA references should have everything including such things as keyboard shortcuts, etc (as well as main menu placement... ie: always starts with File, Edit, View - and ends with Help).
Parent
Guerilla user testing (Score:3, Informative)
Re:Guerilla user testing (Score:5, Informative)
And an app designed to help: http://silverbackapp.com/ [silverbackapp.com]
Parent
Uh... (Score:5, Insightful)
Not sure what you're getting at. If your action listeners are screwed up, that's an obvious problem with a straightforward solution, but if your UI just plain sucks, no program is going to tell you that.
You need to go find someone with aesthetic sense, and a minimum of technical knowledge, and you need to shut up and listen to them whine as they use your UI. When you've fixed enough stuff that they stop whining, bring in a couple more and listen to them whine. Eventually they won't whine, and at that point, you'll know you've got a good interface.
For gods sake though, don't get a fricking committee involved! They will all want to make a trivial change to put their mark on it, and all those changes will turn your unpolished interface into the sort of steaming crapheap that wouldn't meet the basic user-friendliness of the interface on a piece of stereo equipment.
So yea; get the users involved, distill their complaints, make changes, NO COMMITTEES. And the simpler the better. I should write a UI testing program that just runs for 10 minutes and then pops up, "Your interface has too many buttons. Simplify it please." The interface can almost always be simpler.
Joel Spolsky's writings (Score:5, Informative)
Here's the first chapter [joelonsoftware.com]
I think you're doing it almost right (Score:4, Insightful)
There's no way software can design or test a user interface. Use smaller design teams, and make sure there is at least one expert in useability.
It doesn't sound like you're doing too much too wrong.
Well I heard Microsoft... (Score:5, Interesting)
Director (Score:4, Informative)
A ton of commercial (and in-house) applications have had their UIs prototyped with Macromedia (now Adobe) Director. Especially with a third-party "xtra" called OSControl (which gives you access to OS-specific, well, controls like menus, tabs, etc.), Director makes building a UI prototype quick and easy.
Director's a little long in the tooth for real desktop application development. Still, I'm not sure that there's another tool that lets you build "quick and dirty prototypes" (with enough functionality to actually test with users) as rapidly as Director.
Avoid the latest version (Director 11) like the plague, though. It's an abomination.
BTW, as a process issue, a "look and feel prototype" is always one of the earliest milestones in our development cycle. The client has to sign off on the interface, and write a check for a progress payment, before we proceed into actual code-slinging. Saves a boat load of headaches to do it this way.
First rule of gui design (Score:4, Insightful)
Don't let developers do it.
Hire a professional to give you a framework, build from there.
Having a common framework will allow you to know when any screen is wrong, and it will be easier for your QA team to find errors.
I Can Tell You What NOT To Do... (Score:4, Interesting)
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.
Usability Engineering anyone? (Score:4, Informative)
i habe been reading /. for quite a time now and never read the word "usability" ever. (i think most FOSS guys also never heard of it)
Interface Usability is a whole science. There are plenty of books describing exactly what you are trying to reinvent!
For a start you might want to check out Jakob Nielsen's Alterbox Website, which is full of small articles regarding common usability problems.
http://www.useit.com/alertbox/ [useit.com] ... and if you like his style of writing you might also want to buy his book "Usability Engineering" (which is a must-have when you work in the field of usability IMHO)
get the right people, and only the right people (Score:3, Informative)
As far as a UI overview, again, there's nothing better than testing by actual end-users. Try to convince your boss to let you demo an early-ish prototype to real customers. If you can't, then hallway testing [wikipedia.org] is probably the next best thing. If a random cross-section of people can manage to perform simple tasks through your UI, your customers shouldn't have much trouble doing the same thing.
Simple is often best (Score:5, Informative)
1. Define what the software should do
2. Make the UI, even a mockup will do
3. Invite users to test drive the UI while video taping
(See (1) and ask the user to do each one(with no help))
4. Measure the users success (clicks, wrong clicks etc)
5. Score each screen with the predefined metric from (1) filled inn in (4)
Done.
Often the real problem is that nobody really knows (1): what the software should do. Marketing thinks it is "one click purchase" and engineering thinks it is "fully configurable shopping view". So agree on 1 first, and maybe your problems go away.
You need an expert (Score:5, Insightful)
If your UI has gone beyond the most basic of interfaces, you need to hire someone who has a background in "human factors". Expecting a bunch of programmers to design a good user interface is a very bad idea. Just look at all the crappy interfaces in the open source world.
Hoping for a program to automate this is as likely as getting your own pet unicorn.
Re: (Score:3, Interesting)
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 nu
Do a mockup. Let users play with it. (Score:3, Interesting)
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.?
What I've said earlier. (Score:3, Interesting)
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.