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."
Perhaps the most comprehensive guide out there. Not a GUI but if you want a GUI, use Xcode. http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/chapter_1_section_1.html
This is my sig. There are many like it but this one is mine.
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
StarTrekPhase2 - The Five Year Mission Continues!
Umm... the only way to know if one way of doing this is better or worse in UI is to try it. Look up the term Guerilla User Testing or read Don't Make Me Think and follow his approach. This is pretty standard practice on the web. Woe to rich client GUI if what you described is standard in that area.
While it's not a tool, Joel Spolsky has written a long and detailed series of articles on how to correctly design a user interface. It's worth your time to check it out, even if it doesn't speed things up.
Here's the first chapter
useit.com, Jacob Nielson's site. Everyone having anything to do with interface design should read the whole thing.
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
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.
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/ ... 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)
First of all, it sounds like you have way too many people involved in the UI decision-making process. You need the UI architect/lead, the guys who are gonna implement it, and an end-user or two (or maybe QA guy if you don't have any end-users around). That's it. Non-technical bosses don't need to be involved, marketing doesn't need to be involved, technical co-workers who don't have a hand in implementing this don't need to be involved (that includes other UI programmers). Meeting bloat was the biggest headache I had at my old job; we ended up designing our UI essentially by committee, and it sucked.
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 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.
the coolest club on
Also, for all your developers, do you have a designer? UI development = graphic design + industrial/interaction design. Read Magic Ink: Information Software and the Graphical Interface
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.
"So long and thanks for all the fish."
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.
don't cut it off www.mgmbill.org
1. Design your UI on paper. Bring in a usability expert to do this. If you have no usability expert do it yourself.
2. Test your paper UI on users. Ask them to do the tasks your software is supposed to support. Shut up, take notes. Test on 4-8 users.
3. Refine and repeat 1-2 above until users are happy.
4. Develop the UI in software.
Step 1-2 can be done in a week at a low cost. If you try to do the same with a software UI it will be much more expensive.
Is is amazing how developers still think they know better than the users that the software is for. Remember that the benefit of software is created WHEN IT IS USED. Until then it has just cost a lof of money.
I wouldn't expect your plan to get adopted anywhere. The art in delivering software is providing a useable solution within tight budget, time and quality constraints. You're looking only at quality and usability without any consideration for time and budget.
No project would ever finish if you kept asking the users what else they'd like to change.
Hi
I am actualy a Software Developer and i specialise in User Interface Design and Programming (mostly in Java). I have done Userabilty Engineering, this is the study of how a UI will be used, how to evaluate an effective UI and how to compare UIs. It go through how to recruite a sample of users and test their reactions to your UI. Using paper based examples, proto type interfaces and such.
But the answer boils down to, 'Ask the Users'.
Also you should remember that most western languages read top,left to bottom,right so if a UI flows in that direction users find it easier to use. Also try to reduce the mouse milage (eg. last thing you need to do on the page is at the bottom, but the ok button is at the top). Having a table row you need to click, but there is a hyperlink on that table row that takes you somewhere else that is wrong (people will click the link, even when they have done it some many times before).
The http://www.nngroup.com/ Nielsen Norman Group are pioneers in Usability Engineering.
Puggs
Access Point Live Mapping Access Points with Google
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.
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 of time all you have to do is find a way to make that as easy and straightforward as possible.
Personally I love the new Office 2007 layout. Everything is broken up into actions and sub actions. That's how we work. Design the UI by speaking out loud. "OK I'm going to create a new document... where do I click to create a new document... Ohhh there is a big button in the top left that says "New" I bet that does it. Ok I'm wanting to make something bold... what are my options let's see... formating that's what making something bold would fall under... ahhh here it is a Bold B" etc etc etc.
Then once it works. User test, User Test, User Test, User Test, User Test and make sure your users speak out loud while doing it. Stream of consciousness stuff. The longer it takes lots of people to find something the more likely you need to make it more obvious.