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.
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.
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
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.
The Kruger Dunning explains most post on
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.
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.
Maybe you shouldn't have purchased the tools to build something before you knew what that something was.
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
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.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
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 often suffers when component and ingredient substitutions are made, support services are outsourced or H1Bs are used to reduce the cost of manpower. The results and the quality invariably suffers from these bottom-line oriented tactics and only show short-term improvements as a drop in sales resulting from decreases in production quality rarely show immediate responses by the customer.
I have gotten off the point here a bit, but what I'm saying is that CEOs often have little or no idea what is best for the products or services of a company. (My CEO is different, but mainly because he's not a marketing or sales guy.... he was involved in the production side of things before he took over the company, so he knows what qualities are important to the future and well-being of a company... sadly those types are rare these days.)
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.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
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
If you think all a graphic designer does is "make things look pretty" you might want to read that article.
and if you live in a world where you think people still read manuals, you might want to find out what a UI designer actually does.
Actually I'll tell you. A lot of it is helping a user discover, understand and use features and data without having to read a manual. And coincidentally guiding the way someone discovers and understands visually (like on a computer screen) is graphic design. The use part falls interaction design. Read the article.
Comment removed based on user account deletion
I've worked in a similar situation to that and let me tell you, it's a nightmare.
The software gets horribly warped to the individual flights of fancy of the CEO who is such a bizarrely unrepresentative user that their input is almost useless.
They also expect that anything they say should be implemented at the drop of a hat so you drop everything and do stupid useless hacks that just to keep the idiot CEO happy.
The only people to give you feedback on your product are it's intended users and you must do everything you can to ingratiate them into helping you perfect it.
I hope the conclusion you reached is that developers should be involved in UI design from a requirements perspective. At the very least, the consulting firm should have known what your tools were capable of. Secondly, good UI designers can take feedback like "it would be easier to do things this way," for example, if you already have a UI and you're trying to minimize changes. Your development team should have had engineering management on top of it who were aware of the consulting firm and should have injected themselves into the conversation. Even if it's a lead developer, it's easy to make the argument that engineering must be involved within the role required of it.
I sincerely hope your argument isn't against user experience consulting firms, because that wasn't the problem here, and designing an interface isn't always something that requires a permanent staff.
my blog