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."
Too many cooks, as it were.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
I'm not a programmer, but I'd still like to offer my opinion.
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.
Those who believe the Internet is private,
find their privates are on the Internet.
http://en.wikipedia.org/wiki/Paper_prototyping
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.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
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.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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.
Just callin' it like I see it.
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.
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.
-- Will program for bandwidth
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.
If you believe everything you read, you'd better not read. - Japanese proverb
Comment removed based on user account deletion