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
... stop designing by committee.
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.
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.
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.
iRise
Looked promising.
What about it are you reviewing? Is it the layout? Is it how it has been styled (colors, fonts, etc.)? Is it all of this? What is your design process on the front end? Do you create "wire frames" while designing the application? Is this a web application?
-fragbait
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.
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.
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
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
Just because the problem is common and recurring doesn't mean it must have a neat solution. It could be a (np hah!) hard problem. With respect to UI review, I believe this is the case. It's just *hard*. I have not seen very many short cuts work in this area. The best advice I can give you is to listen to your users. Also, UI by committee has not been the easiest path in my experience. We have found that putting someone in charge of the UI, with respect to standards compliance is important, and that the customer can still have their needs met without sending their entire management team into the meeting.
Less "tweak this, move that" more "is or is not functionally correct" evaluations.
Best of luck.
See http://en.wikipedia.org/wiki/Oh_Brother,_Where_Art_Thou%3F for details.
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".
You would be better off hiring a product manager and a UI specialist.
The key job is balancing the forces of user requirements, development capacity and then being smart about packaging this into a UI. The first part can be done by a product manager, the second by a UI specialist.
Developers shouldn't go anywhere near designing UI with some (rare) exceptions. The main problem is devs failure to put the user's hat on (apart from thinking they know best). Developers focus is elsewhere, unless they are also the users of the software.
If you can't hire, try to delegate two team members to do the job, maybe with some training. Anyway, do away with the meetings. Too expensive, little chance of success.
Hope this helps
Indeed, use it. Take a set of powerusers and a couple of dummies. Give them various assignments. 1) Track and trace their eye-movements (use GUI-students at universities) 2) Track and trace cursor-movements (google for ajax tools for visualizing in-browser-measurments) 3) Track and trace number of clicks 4) Track and trace users' routes to solutions 5) Track and trace time to complete their tasks 6) Take time to ask and hear what they have to say about it
Collect a bunch of test subjects that are either the 'expected users of the software' (e.g. within a company) or randomly (e.g. for a game with a broad market appeal) and conduct interviews with them to find out their computer usage skillset, try to get a good mix of user skills (depending on your app).
Then create a bunch of different tasks that the test subjects should achieve, then have them perform these tasks using the user interface while you videotape it/record their interaction. Do not offer then any assistace or similar, but give them instructions as to what to do when they have attempted to solve a task within a time frame, but failed to do so (e.g. continue, open a help file, etc). In addition the test users should write down any notes they made themselves during each task.
You should then review this data, as well as conducting interviews with the users after they did the test. You cou
Or.. if its an open source application, you can pretty much let the coders do the GUI, and it will pretty much be on par with anything else from the open source movement (i.e. crap).
To get impressions for good UI design look at Maxis 'The Sims' game, or Blizzard 'WoW', or even some Apple applications.
Well, kinda. The only way (that I know of) to refine and evolve UIs is to look at them and discuss how they work or are supposed to work, and whether or not a given change affects functionality or is even technically feasible.
But you need to get some users into the equation. Normal users of your application(s). Color me skeptical whenever a developer wants to design a GUI all by himself because "he knows" what something is supposed to look like or behave. We developers are the absolute worst group of people to be involved in usability, because most of us can't think like users if our lives depended on it.
So follow the cycle with your dev teams and technology people, but involve users often and early. That is the difference between a good app that's usable and a good app that no one wants to run because it looks like crap, is confusing, etc. See Lotus Notes for more details on this /rimshot
Anyway, good luck with that. Truly good graphical interfaces are hard to achieve.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Hi:
If your technical writers are raising concerns about UI processes that should be one step, but in fact need several steps, you may wish to revisit the UI.
The last piece of software I worked on had, as its default install, 93 unlabelled icons. The devs were convinced that this was an 'Apple-like' software.
Windows can be made to quickly reshaped to the Aspect Ratio of the screen.
An Education is the Font of All Liberty
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.
GOMS is a useful tool for examining a UI. (Link: http://en.wikipedia.org/wiki/GOMS ) It's a method to analyze human-computer interaction in various programs, so it wouldn't hurt to take a look.
Site slashdotted out? Use SharePapyrus under Site Directory
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
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.
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
We've got one of those reviews scheduled for tomorrow.
For four hours.
"My eyes! The goggles do nothing!"
As a programmer, I like to make an option that allows the user to set up the interface as they would like it to be. This can be quite complicated to set up first, but reusing the code thereafter makes future programs simple. I think a really nice thing to do is to make button placement and/or menu item options for some or all of the programs processes and functions. This is what major programs like OpenOffice do. Then you can set up the program the way you think it should looks for distribution with full instructions on button/menu item placement options.
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
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.
I don't think that's possible when it comes to UI design.
Any project where it's possible that a large group of people will be using the software, you have to put in a huge amount of effort to make sure the interface can accommodate as large a range of preferences as possible. Everything from the background color to how many times you have to put your hand on the mouse can have a major impact on a user's productivity.
The downside to this is the only way to know for sure is to make the UI, get some people using it, and respond to the feedback.
It should be a very social process, and sending one guy off on his own to do the whole interface will win you nothing but an interface suited to his tastes alone.
http://library.gnome.org/devel/hig-book/stable/ is a pretty nice guide for the basics.
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
We trimmed 1/2 of the the stuff they had available. You know what they said? "too busy" People want an app that has capability to do anything imaginable, yet the simplicity to do what they need right now. I say KISS.
Keep it simple software
-DW
How much is your data worth? Back it up now.
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.
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.
and have your UI developers defer to the designer. Problem solved!
For the former: as others have said, ask the users. And ask them again. Joel Spolsky recommends asking your family or pulling random punters off the street, asking them to perform tasks and observing how easily they do it.
For the latter: there are a number of numerical methods available, see e.g. Jeff Raskin (http://books.google.co.uk/books?id=D39vjmLfO3kC&dq=jeff+raskin+humane+user+interface&pg=PP1&ots=COnFa27TZ3&sig=JvLaCeIsjG06dGVH4HlY0D_h4dc&hl=en&sa=X&oi=book_result&resnum=1&ct=result) or Constantine and Lockwood (http://www.amazon.com/Software-Use-Practical-Methods-Usage-Centered/dp/0201924781).
A combination of both is ideal, but if you can only do one do the former.
Uhm, that web page hurts my eyes. Are you sure you recommend this as UI interface design reference.
Get a copy of Inside Steve's Brain, and read the section describing how they designed one product. (The book is loaned out to someone else, so I can't give you page numbers.)
Basically, the technique was to print lots of transparencies, and to stand around a conference table and argue. Repeat until done.
In my experience doing UI design, teaching a grad course, and working with others doing it, you can either spend a whole lot of time working to get it right, or you will end up with a mediocre product. For some uses, that's good enough. For others, you have to spend the time.
Pat
The basis of this book, and of most writing on UI, is that the designer can only do so much. Once a best effort is made, the interface must go into usability testing. The interface decisions then need to be made on the basis of these tests, not on the whis of the designers. p. It also sounds like The Mythical Man Month might be in order, and a design book, like the classic composite structured design, as it appears that there are many unresolved and extravagant dependencies.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
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.
Xzzy has a very good point.
In that vein, some things I have seen in some Windows programs, as well as in OS/2's WPS GUI are the options of selecting "Beginner, Intermediary, Advanced" for how the menu system is created... Beginner showing the most common choices, while Advanced shows everything including the kitchen sink.
Without knowing too much more about your software - or what features are insisted upon being easily available, I dont know if that applies.
StarTrekPhase2 - The Five Year Mission Continues!
You might be asking in the wrong place.
In all matters of opinion, our adversaries are insane. -Oscar Wilde
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
additionally, (this is especially true if it is an in-house program) you can follow the unix tradition of separating the UI from the workings of the program. the GUI should, in reality, do practically nothing, merely call back to the real code.
if you have your application set up in that manner you can solve disputes by having each person design their own gui and then everyone demonstrates their in a group, people will see things they like and didn't make and you can start making or modifying a gui that takes what you learn from everyone else. the grouches who only want things exactly their way can still do it their way, without affecting how the project really works.
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."
Why not one of your customers instead of your CEO?
I worked QA for a small time software company and they had a special relationship with one large scale customer who elected to be a beta. Actually, they really weren't the beta at first, but they requested several features and offered to pay big money for it.
It turned out the special features they requested were popular with the regular customers and the developers started to include some of the features with the regular builds.
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
One interesting area of exploration would be the European Unions requirements for user interface design. EU Directive 90/270 covers this. I attempted to provide a link, but most of the commentary seems to be in PDF form.
Pretend I said something meaningful or insightful here.
[sarcasm] If there's one thing a UI needs it's ribbons. Don't worry whether or not your users like it. A new fancy feature will earn you more money because more people will upgrade. [/sarcasm]
http://yetanotherpoliticalrant.blogspot.com
No doubt user experience of UI will be quantified by software more clearly over the next few years - in the same way that shops are now analysing footfall and even eye contact with product. I think you're looking for the wrong solution though - nothing beats testing the system with the public. Your Mum, your Grandma, your mates, your girlfriend - even (though I hesitate here) focus groups. You'd be amazed how little your amazing technical back-end systems mean next to nothing to a typical user. Even if you've created the most awesome, useful system, people will get confused if the login box is too small or the logo is a bit too harsh color-wise. Stick it live, wave the big Web 2.0 beta flag, and be amazed at the feedback. And stop listening to the people who think they understand what a UI should be.
If you have tech support for the product, use their experiences on the phone to refine the UI. Have them put in categories for "user confusion" (or whatever) and have them document what the confusion is. Then send a member of the dev team over to debrief them once a month on the problems that are generating the most calls and fix those as a priority.
This dev/tech support increase in interaction has a couple of side benefits. One is that you get to see the faces of tech support people when they figure out you're really listening to them and fixing "their" problems. The other is when the dev team figures out that their "brilliant" design (UI and otherwise) may be brilliant, but it's also a mess.
For Maximum Entertainment Value on UI design, find an Apple developer who's had to deal with their UI guys in the design phase. Some of those, um... "interactions", have been Epic.
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.
that's pretty dumb.
most CEOs are not your typical user, have little to zero interaction with your typical users' tasks, and would rather focus on metrics data than actual data. they also are usually less computer savvy than your business users and can barely work a browser.
so if you want software that doesn't meet your users needs and meets the lowest common denominator of technical requirements - definitely take that approach. it's great way to get promoted though!
seriously, validating how well a UI works is best left to putting it in front of users in a sane way with practical measurement techniques and boiling down the data to convince your CEO blood will run in the halls if you don't meet their needs.
Check out the following "guides" and tools. Apple still has the legacy stuff out there.
http://developer.apple.com/documentation/macos8/mac8.html
IBM:
http://www-03.ibm.com/able/resources/ueresources.html
http://www.alphaworks.ibm.com/tech/raven
http://www.alphaworks.ibm.com/tech/ezweb
DOD:
U. S. Army Weapon Systems Human-Computer Interface Style Guide (WSHCI), 1999
DoD Human Computer Interface Style Guide
DoD Design Criteria Standard - Human Engineering, 1999
Ameritech Graphical User Interface Standards and Design Guidelines
Sun:
Java Look and Feel Design Guidelines, 2001
Java Look and Feel Design Guidelines: Advanced Topics, 2001
I'm a developer and while most GUI apps that I've written have been mostly for myself, there were a few things that were requirements of my software.
Granted, the average user might be more picky than I.
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!
Whatever you do, don't use Eggplant (Redstone software). It sucks, it's terrible, and it's only for Mac Os.
... and they were all offtopic. this guy is asking for a review system not a UI how-to. He wants a piece of software that allows him to take notes for each of the UI elements and store them so they can be reused when redesigning the UI.
and i don't even program UI anymore. but when I did I was doing it alone and for myself as exercise so good luck trying to find one.
AC because there are still 75 more comments to read and maybe someone did get the point though.
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.
Hey Champ.. I am currently studying Software Development in Denmark. We have a teacher involved in the field of UI design. He has written a book, which i believe can help you a greate deal. It has concrete methods of measuring and testing the usability factor of UI's. The book is called "User Interface Design", Soren Lauesen. Chech it out: http://www.amazon.com/User-Interface-Design-Engineering-Perspective/dp/0321181433/ref=sr_1_2?ie=UTF8&s=books&qid=1217368487&sr=8-2
I suggest looking at UI development for the following open source projects. They are this crowd's favorite ;-)
1) LaTeX
2) emacs
3) vi
4) Dia
5) xterm
My best advise is to just get somebody good at doing layout to design your UI. This will most likely NOT be a technical person.
Or you can continue throwing loose ideas from a the committee branch.
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 insensitive clod!
Jenifer Tidwell has a great site with Human Computer Interface Patterns. If you are using patterns for the rest of your code (and even if you are not), consider this:
http://www.hcipatterns.org/
Absolutely, this person's problem is not lack of software, it's too many people. Good UI comes from small groups of no more than two or three people (I try to pair an artist and a programmer), or one true visionary. Big groups with lots of people reviewing it tend to come up with nonsense like this: http://www.youtube.com/watch?v=kU9YeOQm3Y0
Or the idea of clicking a button labeled "Start" to shut down the computer.
Self-selecting based on skill level is usually a very bad decision. Users cannot properly assess their own levels of skill at a program. A successful method for doing something similar is to offer optimized, or even single-click, paths through common tasks (such as "Convert video for iPod"), while giving users that need or want more functionality alternate ways to configure the flow through the tool.
Of course, this isn't what the poster is asking about, so I'll shut up now.
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
A good start: http://www.positivespaceblog.com/archives/pdf-documents-designer/
Going back to the original subject, we developed a tool for UI reviews. It's an issue tracker + image reviews. You can create tasks and publish an image (ie a a screenshot) for each task. Once the image is published, you can use a pencil to highlight the errors/reviews. There is also a built-in version control, so you can publish several versions of the same image. The software is in english but the website describing the product is spanish only for the moment; if you manage to register in spanish, you will get access to the english-application. The url: http://www.creationflow.com/
Jacob Nielsen stayed WAY behind the times. It's good that he emphasized usability, but he did not adapt. Just for fun, some guys did some comparison on search, and Jacob's page came dead last - using some very interesting methods which seem to be standard on usability testing (Eyetracking):
http://www.uxmatters.com/MT/archives/000068.php
I found this webpage more useful than Nielsen's when I was designing a form that has to be filled 30.000 times every day (and this guy Luke Wroblewski seems to know what he's doing, even though his seminars are way too expensive):
http://www.uie.com/
There are three kinds of lies: lies, damned lies, and statistics.
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
One shortcut might be to learn from the hideous mistakes of others:
http://www.math.leidenuniv.nl/~xmath/mirror/www.iarchitect.com/mshame.htm
http://office.microsoft.com/en-us/help/HA100898951033.aspx
http://www.youtube.com/watch?v=ZegWedG-jk4
http://www.cs.rutgers.edu/LCSR-Computing/some-docs/emacs-chart.html
There are about ten million tools you could use now to mock up a UI in almost any language.
Just being able to press on a button that does nothing tells you more than a screenshot ever can.
You don't even have to use the mockup in any way in the final product, but let a user or designer be able to sit down with the UI arranged as people think they would like it to start with and then evolve.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Here is my plan that I wish every corporation would adopt for near perfect design...
Try applying at Apple.
1. Re-evaluate your GUI design process. The job of deciding what goes where best goes to an Information Architect, usually.
2. A Prototyping tool which is made for collaboration and decision making. Logs comments and allows stakeholders to make comments on widgets and layouts
http://www.protoshare.com/
Yea, I listed those backwards. Anyway, all big software companies use test groups. They usually represent 'average users'... which is why most software sucks. But everyone can 'use it'... and complain about it.
In this case, GNOME project has some guidelines:
http://library.gnome.org/devel/hig-book/stable/
http://developer.gnome.org/projects/gap/guide/gad/
http://live.gnome.org/Accessibility/GetInvolved
http://developer.gnome.org/projects/gup/
Go ahead. Try it. No matter how hard you rub, no matter what compounds you use, when you try to polish a turd, the net result is a pile of shit.
If any part of the project is crap, the end result will be the same no matter how much testing and tweaking you do. Good luck.
All pass beyond reach of medicine. None pass beyond the reach of love.
Only a human can do that because your target user is a human (sorry if I'm assuming too much)
To evaluate a design, first make a functional mockup that can be clicked on and used. If you're designing a web page, then html lends itself nicely to the task. If you're working in games or productivity apps, then do your mockup in something that lets you iterate quickly (flash or html or something similar) iterate, get feedback. don't worry so much about the back end of the design - just hint at or suggest enough of the content so the reviewer understands the context of what they are doing.
Get as much feedback from the end user as possible but don't put them in charge of the design or you'll loose control of your design process - put your mockups in front of people who don't know anything about your product and see what they do. make sure they know the designer is not there! that's really important. get someone else to present it or suck it up and pretend your not connected to the design process. That way, you get more honest feedback. Let them make mistakes in usage and make sure you learn and address the things that made them err in their understanding.
good UI design is rarely easy - so managing expectations throughout the process is a sizable chunk of the designer's job.
I have designed about 30 applications from Commodore 64, Amiga, BBC Arhcimedes, Windows 3.1, n64 through to Vista and Embedded deivces
1. Do you have a vision or not? And who is going to use it.
If you don't then use a committee method to design your UI. Say bye-bye to what you want.
1. If you do have a vision then get your needs/features down on paper
2. Define the platform/platforms you are planning your application to run on. (things like screen aspect, minimum/maximum resolution and input device are very important considerations.
3. Start to mock up designs and position the features you are planning
4. Start to create working mock-ups of key interface elements
5. Start to get feedback on the two or three ideas you have (try getting people to see the idea you like the best - explain why)
6. Do a prototype (even if it ends up as a commercial prototype)
7. Evaluate the issues people have and the way people use it. Create a new version if your prototype is unusable - otherwise let it grow as much as it can.
A shrubbery
You needs a very small team that understands what the product is supposed to accomplish, not how it is supposed to accomplish it. The user interface flows from there.
From http://www.counselormagazine.com/content/view/674/55/
It was 1995 and a man was walking around with a wood block in his shirt pocket. Occasionally he would take it out and fiddle with it as if he were checking appointments. Some might have thought him crazy, but he was not.
The man was Jeff Hawkins, and he would soon revolutionize the technology industry with a device known as a Personal Digital Assistant, or PDA. It would be called the Palm Pilot and sell over one million units in its first 18 months alone. Jeff Hawkins didn't invent the PDA, but his Palm Pilot would be the first to attain widespread acceptance. There were other PDAs before the Palm Pilot: Apple produced one that came to be called the Newton in 1993, but it failed to achieve the success of the Palm Pilot due to its high price and the fact that it was just too large to fit inside a pocket; a Windows-based PDA was introduced around the same time as the Palm Pilot, using a software called Windows CE, which enabled one to open and create Word Documents and Excel Spreadsheets. The interface resembled Windows 95 with the familiar Start menu. Unfortunately, these devices were much more expensive and drained way too much battery power.
The block of wood in Jeff Hawkin's pocket represented an approach to design that would serve him well. He did not want to just design yet another electronic gadget, but something that was eminently usable; a tool. His experiments with the block of wood helped him to determine the right size for the Palm Pilot -- small enough to fit in a man's shirt pocket.
Nothing for 6-digit uids?
Isnt that what microsoft did when they had gates?
IranAir Flight 655 never forget!
For web based prototyping iRise is pretty good.
It will let you do some quick html and build the workflow. The outcoming is a semi functional thing that you can put in front of users.
Load New Commander (Y/N)?
A better way to avoid taxingly long decisions about what's best for people's needs?
I think that's called upper management.
Or the Senate.
Your code shouldn't have high coupling, neither should the UI. Organized by role/user, by usage, the UI probably doesn't need to let your users do super-cross-functional things in the same bit of screen real-estate. If the UI does need to let your users do super-cross-functional things in the same bit of screen real-estate then the coupling is really just cohesion + complexity, deal with it.
If you can get rid of UI coupling, you only need subsets of the UI team on the reviews.
And you'll end up adding in UI cohesion while you shake the UI design around.
So separate the bits and find a way to reuse your UI elements, at the very least reuse-by-usage across different role/users (so people can graduate to power user without re-learning your UI).
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!
The Magic Ink link begins thusly: "Firefox and IE cannot print this webpage. If you like reading on paper, please download the PDF."
This gives me pause about the advice to follow.
Comment removed based on user account deletion
Nice plan, if it weren't for this part: "make him use it every day or get a new CEO" Everywhere I've been so far, the making goes the other way around.
You're letting developers write a user interface? Congratulations, your user interface will be riddled with little inconsistencies, bizarre error messages, labels that don't make sense, input that's too permissive or too restrictive, and just plain weird layout.
If you call them "UI developers", you're just lying to yourself. They are developers. There's nothing UI about them.
You need to hire a human interface expert. They know how people work with computers. Your developers, on the other hand, know how developers work with computers.
How about cultural considerations? Are your users from one culture and your developers from another? You know what I'm talking about. Don't pretend you don't. There are cultural differences in interfaces.
You won't take my advice, though, because you don't want to hire someone with the correct qualifications for the job. But hey, don't let that stop you from creating yet another frustrating interface.
OK, now that we've determined that you don't want to hire the expertise you need, let's see what we can do with what you have. Find the "UI developer" that has the best graphic design skill. Make that person in charge of the UI, and don't let anyone else have any input, because they will just screw it up and make things inconsistent. BTW, if you really do have a developer that also has graphic design skill, cherish them because they are worth more than one developer and a separate graphic designer. Have that UI lead document the rules of how each and every input works, and what they will and will not accept. Have the UI lead also document all error conditions, what happens on those error conditions, and what messages are displayed to the user. When you're done with your first iteration, give that document to a tester that is not one of your developers. Have them ensure that everything works as documented. Don't let the UI out of the shop until all UI bugs are resolved.
Good luck. You'll need it.
Towards the Singularity.
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 haven't had the need but when I do was going to take a look at the recently released Yahoo design stencils to see if they are useful for this kind of task:
http://developer.yahoo.com/ypatterns/wireframes/
What, you're not using agile/rapid development tools/techniques??
you had me at #!
"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
By Chris Espinosa, Joanna Hoffman, et al. The manual was called Inside Macintosh, the draft I received is dated 1983, lovingly daisywheel printed, and apparently it's what the rest cribbed from (Command-Z,X,C,V for Undo, Cut, Copy, Paste was one of the rules established by IM).
you had me at #!
Asking the user is like a cook asking his diners how he should alter his recipe. If he is at that level, then he is not a great cook. If you are still asking your users about what to fix in your interfaces, you are not a great UI architect. This is a good workaround if you do not have one, of course.
We follow this in my company, except it goes something like this:
While I agree with the idea, it does have it's flaws.
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.
I understand the OP's concern, and it isn't simply a matter of "let the user win."
There's a stage in the product life cycle where one would like to get a draft of the design approved so that you can can pay someone to build it. Until that happens, there isn't anything to put in front of a user. It's also much faster and cheaper to start with a good design and refine it than to continually chip away at a bad design with X+1 revisions. To provide that draft, I would recommend a process that uses one or two human factors / user interaction / HCI specialists with the understanding that they will make recommendations that the user testing can improve.
If you intend to gather the input of a group against a proposed UI, you need to ensure that your medium is flexible enough to convey the details that need review. If you need to provide hand gestures and impromptu sound effects to communicate the experience, you have an interaction that needs more than a screenshot or poster.
"By asking the users what they did NOT like about the original... & guess what?"
What they disliked the most where your awfull usage of grammar and strange caps and signs. Wasn't it?
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.
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
A very entertaining and interesting presentation is the story of the ribbon http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx It gives a lot of examples of user interface design practices. This includes watching users and building in tools to track usage and some advice on testing with users. You can also higher a user experience consultant to do user experience and usability tests. They can provide grounded feedback based on interview and observations. There are also a lot of other material on the topic. Look under Uesr Experience, Human Computer Interface, or Interactive Design. Some companies offer 1 to 3 day courses in various cities. I have not tried this but they are probably OK to getting started yourself. Obviously there is no magic bullet but there are existing systems to keep from going off in the wrong direction and starting with the big picture.
You can do this with two or three people, one of which should have a background in HCI.
http://www.useit.com/papers/heuristic/heuristic_evaluation.html
First of all: Is this "legal correspondence" or my last will & testament?
ANSWER = NO!
Secondly: Do you have a PHD in English??
ANSWER = PROBABLY NOT.
Lastly: Are you employed as, or have been professionally been, an editor for any reknowned & respected written publications???
----
CONCLUSION = YET ANOTHER /. 'wannabe' english professor/writing critic (complete w/ his lack of degrees & experience as a professsional editor for years no doubt)
----
NOW - CORRECT ME IF I AM WRONG HERE (anyone reading): Is this a forums on computing & a topic on computing, specifically coding related... OR, an English grammar/spelling forums & topic?
ANSWER = NO (to the latter, this is NO english grammar forums OR topic, period)...
Thus... YOU ARE OFF TOPIC DOLT!
LOL! "Spelling & Grammar Nazis", too TOO easy to dispense with, easily... too easy.
APK
P.S.=> Opinions vary, but, yours? Without either professional credentials (odds are as an editor OR educator in the english language), or @ the very least, a PHD in the English language??
Man - YOU don't EVEN COUNT!
Not that it'd matter even IF you had 1 of those qualifications... I've only been speaking & writing this language for over 41 yrs. now... & this certainly isn't a time where "perfect grammar" (FOR WHATEVER THAT MEANS, purely relative) or spelling etc. et al, is NOT mandatory!
Clue - it's an online forums... wake up, smell the coffee, & realize that if this is the best you have to contribute here? You're not, not @ all - it's a topic on COMPUTING (specifically coding) - NOT AN ENGLISH GRAMMAR/SPELLING FORUMS, you fool! apk
I see what you are saying here.
For a lot of people, the User Front End is the most important thing next to the speed of the application. Not having a bloated program is better than one that is slow and not worth it.
I know that with the Fedora, the front end was designed and tested by women. As a result, they saw it as successful.
My biggest problem when I was coding C was getting the UI going so that people could use what I coded. Much of the time, things take collaboration. I can see from your post that it sometimes leads to disagreements.
Actually, have select users test the system. The CEO might be removed from a core system that is not part of his role.
This works well in my experience. With rich Winform interfaces (where various features perform complex data manipulation) the developers can't test all feature combinations (I'd love a tool that could).
As well, each individual user has a specific style, a set of keystrokes, a workflow. The users selected for testing should be advanced, and new users should test as well (different types of style, including learning).
Anyway, that's what I do...
UI_Developer <> UI_Desiger: different skill sets.
It's the bomb when you can find 'em rolled into one, but there aren't enough gurus to go around.
The general case: Jack of all trades, master of none.
Instance: a good graphic designer is most likely a terrible copywriter.
P.S. When did 3 unicorns meet the criterion to be a planet full of unicorns???
People are fricken complicated. Many orders of magnitude more complicated than large parallel-processing computers like Blue Gene/Q http://en.wikipedia.org/wiki/Blue_Gene#Blue_Gene.2FQ/.
So you should expect that finding the most-efficient algorithm/program for a person to run (i.e. "selecting the best UI") is going to take a lot longer than it took to write the code for the less-than-amoeba-level CPU your developers write to.
But if you're willing to settle for probably-good-enough you could take an approach similar to what's done for software architecture if you think of the published Apple and IBM UI standards (you got links in other posts) as UI Design Patterns and limit your UI discussion to selecting one of those and living with the fact that it won't be exactly the optimal UI for your particular program.
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'd do basically the same thing but instead of the CEO (who doesn't really do much real work), I'd give it to the following people: 1) my mom - who is computer illiterate, 2) the most senior "real" user, and 3) the most novice "real" user.
If my mom can figure it out, it's solid UI design.
If the most senior user can use it, it's fully functional.
If the most novice user can use it, it fits the task.
If it passes all three of those tests, you're done. Take two weeks off and start your next project.
Layne
How do you flamebait an anonymous coward? Mods: you must be kidding.
Paper Prototyping is the way to go.
NO UI designer is smart enough to know what users will do when they get hold of your designer - because it's not a problem your designer can solve with smarts. You MUST test prototypes with users.
Sometimes you need domain-SME users (all I'd want if I was doing a medication dispensing system or an Air Traffic Control system).
For many non-mission-critical things (phone number entry and validation is a perennial...developers always want to screw this way the fsck up for users), you can get some Joe off the street or some Jane from your cube farm who haven't seen the prior iterations of your design. Chances are if you can make it work well for Joe and Jane, it'll work well for your domain-SME users too. Testing with Joe and Jane beats testing nobody at all by several light-years.
(Important tip: Make sure you tell Joe and Jane that THEY are not being tested, and it's not possible for them to make mistakes with the design - anything they do with it is fine with you. You must make clear that you and your design staff are effectively the test subjects - In working with the design, Joe and Jane are testing you to see how well YOU have done).
Suggestion: read "Don't Make Me Think" by Steve Krug. It's a very short read, all signal, no noise, and the best first book on Web usability out there. While much of the book's advice is web-centric, it can be generalized in great part to application design - particularly on testing.
If you test, you can bring numbers, science and analysis to the table to buttress your arguments. It's a good way to trump "we've always done it that way" and "expert" opinions that have nothing substantial behind them. You can estimate and demonstrate success before you write a line of code.
Remember:
- Design
- Prototype
- Test
Not perfect? Repeat.
There's a lot more you can learn. I recommend Bruce Tognazzini's "Interaction Design 101" 3-day course from Nielsen Norman group (offered recently at Usability Week SFO 2008). He teaches a method you can use to solve the problems you're describing. NN/g also has a worthwhile DVD on paper prototyping if you haven't seen or tried it before.
Also make mockups. A lot of them. Any tool will work for the mockups.
I heared that is the way Apple does it.
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.
Usability is inversely proportional to the number of mouse clicks for the user desired feature.
Don't let managers do it.
(However, I'm still struggling with how to implement that rule.)
I'd like to subscribe to your newsletter.
Wait, no, I won't.
... is a great book by Steve Krug (no connection, just a satisfied reader). He advocates *very* simple usability testing and gives practical advice on how to do it in Chapter 9: "Usability testing on 10 cents a day". I've followed the advice given and it worked well. Like the useit.com suggestions above, Krug's site is useful too: http://www.sensible.com/
Too many cooks, as it were.
How about Tool Petra? http://petra.cleverlance.com
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...
Depends on the type of application. What if it's for fiddling your stock options or keeping track of your golf scores?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Best Open source tool you can use here is user community, of course filter and pay attention to constructive comments only.
There are plenty of methods an techniques for the design of user interfaces.
Most of the methods rely on the "user-centred design" approach (http://en.wikipedia.org/wiki/User-centered_design).
Another point of view is the design of user interface by following a model-based approach (http://www.arpuerta.com/pdf/ieee97.pdf). In this approach a systemtic process is followed to generate the user interface (in a similar fashion as we do with model-driven development for general software). This approach still lack some flexibility in the design, but I think it is the future.
That's exactly what I was going to post (bring on the -1 redundant).
The only way to test a user interface's effectiveness is to sit down and watch users using it.
I don't know how many times I've pushed changes to a piece of software after watching someone doing things with it, and thinking that there is a better way for them to do that.
If you want to be really professional, set up a usability lab, where you record both the screen, and the user watching the screen, and give them a list of tasks to complete (preferably ones that they're familiar with through their job role).
You can then sit down, watch the video, and deal with any problems. If they clicked around 5 windows to find something, reduce that if possible. If the video of their face showed them swearing at the computer, fix whatever caused that.
There really aren't any shortcuts to fixing a UI.
To get an idea of what I'm talking about, have a look at Silverback, which is designed for Mac OS, but appears to do this the best way I've seen. I'm not affiliated with them, just loved the look of it.
I kidd, I kidd- honestly play around with IB in xCode and it'll let you prototype ideas and keep them clean quickly. Then you can move your model over to the native tools on your platform.
You need the UI architect/lead
Allow me to recommend this guy!
Isn't this pretty much how Apple works?
Quite Impossible. I wanna bet that one year after you've given him the app, he still comes up with changes and diffrent idea's. There's always this tiny detail you'll be able to do better and if it changes it can still be improved or something else will start to bother him. It's a street without end.
You'll need to work with the employers who asked for the program. Let em work with it and see if they have changes they want implemented. I suggest that in the contract it sais that you'll provide this service for 6 months after the product has been finished and if they want it for longer than that period of time, they'd have to pay extra under the influence of a maintenance contract.
It is the best application out there for Usability studies. Put 10 people through some set of tests on your application and by the time you analyze your recordings and data you will understand where your customers are getting stuck/confused. A great thing to add is to have your developers watch the sessions live as remote observers, just hearing people's thought process if your tester keeps prodding them is invaluable. http://www.techsmith.com/morae.asp
You should probably read up on Human-Computer Interaction. Wiki has a pretty good article that includes some common design practices and heuristics. http://en.wikipedia.org/wiki/Human-computer_interaction
Just do it the old fashioned way.
Start with a script for each action/task your users will want to take. These are called Use Cases.
Diagram it out showing all the options along the way, the inputs and the outputs (sounds like UML you say...)
Then create Wireframes which include all those inputs on a screen layout.... put them up on a big wall with strings connecting them representing your earlier diagram.
Fourth, you can Prototype it using something like Axure, which is prototyping software... - only works on Windows ;-(
Have a bunch of people follow the scripts that you wrote and see if they can accomplish the tasks. This is called User Testing.
Fifth, have a good designer look at it. They will make suggestions about whitespace, cluttered menus, colors to use, fonts, etc.
Add the graphics into your prototype (it's fairly easy with Axure)
Now do another round of User Testing.
If the first or second set of User Testing gives you significant feedback, incorporate it into your Use Cases, Wireframes and Prototypes and repeat these steps.
Finally, UI design is very much like Software design.. if you do all your planning up front before you ever start coding or designing... you will save tremendous amounts of time at the end by not having to re-code everything when you find out it doesn't work correctly or your users hate it.
The UI is as important as any other part of the software... take the time to do it right and use every tool in your engineering, programming, design and project management toolkits.... by design I mean architecture design, not pretty colors design.
Oh and BE CONSISTENT... users want things to be in the same place every time they look for it... so don't hide things, disable them... don't move navigation around.
One more thing, less is more. Google was very successful giving people one input box to do search... follow their example where possible.
A fool throws a stone into a well and a thousand sages can not remove it.
You certainly got your ass handed to you by that reply prior to yours to which you replied. The poster was right on the mark in regard to your being off topic here and lacking the credentials in education or professional status to be telling anyone how to write or post on a forums it seems. I am going to have to remember those points he used and take a play out of his playbook versus garbage like your kind spews on the page here on this and other websites.
Also, for all your developers, do you have a designer? UI development = graphic design + industrial/interaction design.
Pretty much every web site I've ever been to that was created by a graphic designer was a beautiful, unusable piece of crap. Food for thought...
Thomas Galvin
But one user was constantly struggling with getting her entries in on time. Then one day I was helping her with one random issue with the DB and asked her to walk through it. My heart sank as I saw her using her mouse to move from field to field, rather than using the tab key - the tab order of the UI being one of the details I sweated over.
One more detail to add to the instruction sheet, and another proof of the ingenuity of fools.
Prisencolinensinainciusol. Ol Rait!
Many of the replies have very good suggestions for "the cycle" of UI. There is more psychology than most people would like to deal with when creating a user interface, but the simple fact is that it must be dealt with in order to make a usable interface. The suggestion of a mock-up application and have users test it is the best way to go. And like many people have said before, don't guide them in performing some action, rather give them a simple task and see how easy or difficult it is for them to perform. It's much different for a new user to have to create a new file or account versus the developer saying, "oh, it's really easy to create a new thing, you just have to press ctrl+shift+alt+N, duh!"
There are many UI standard guidelines available for Window/OSX.
You can possibly follow those.
You can make an educated guess about how much pointing/clicking/typing a user who is experienced with the program would need. Interface Designer Jef Raskin recommended that method in his book "The Humane Interface" and it's cheap, too.
http://en.wikipedia.org/wiki/KLM_(human_computer_interaction)
The OP wanted to know if anyone knew of a tool for doing a REVIEW of a user interface.
This has not to do with user interface design or testing.
Look at it this way. You design your UI, you build it, now you need to compare the design with the implementation. Is there a tool for that?
This would be particularly important in cases where you are updating an existing UI. Suppose the tasks are X,Y, and Z. Now you need to determine if those tasks have been properly accomplished. Do the new UI elements propery integrate with the look and feel of the rest of the UI? Do they properly implement the workflow. Was the design of these changes/features what you really wanted?
You need to review the thing, just like you would review a piece of source code. Is the job done right, that is the question to answer.
So IMHO such a tool would allow people to view and interact with the UI and to annotate it in some fashion. Then they can show everyone what they like or don't like, and any errors or inconsistencies, which can then be fixed and reviewed again.
Some of this might fall under the heading of UI test automation, but that only really checks the functionality, not the consistency and feel of the thing.
Personally I don't know of a purpose built tool for this. It could be a nice thing to have, especially in larger shops.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Sorry about the long post, but everyone here has touched on pieces of the whole...
Ideally you would have a UI Designer, IA (Information Architect), or someone with experience in both fields (Programming and Design) on staff. Someone that can come to the table and understand why creative wants the buttons grouped and centered, and why the developers want the 22 functions available on screen. Not folding to one side or the other of the fence, but can come up with a solution that gives both a compromise and doesn't hurt usability or functionality. Ultimately this person is the one with the final choice and power to say this is the interface and these are the reasons why. Neither designers nor programmers, with strict thought processes in either field should be laying out the interfaces; both tend to hurt either usability or functionality.
During the (initial) phases of a project, it is inevitable that everyone will have an opinion of what "they" would like to see. While this is helpful from a creative and progression stand point, you have to be sure not to surpass the scope of what you are attempting to accomplish. If people's (internally) toes get stepped on because the buttons aren't where they wanted it... so be it. It's not them using or buying the application... it's your customers. People who regard the user as "stupid", "not to give the user control", or say "they don't know what they are doing" are of the wrong attitude. If the user is having problems with your application or can't figure it out, then it's your fault and you should feel like the stupid one. You can build the fastest search engine in the world, but if its not usable, no one will touch it. People may not have a clear understand of other people's roles and tasks. They do have a clear understanding of their own; as they do it day-in-day-out. This should be taken into account in any UI design. This is called user-centric design, you don't necessarily give the user full range to design your application, but you understand their workflow and patterns; creating the interface around how they work. This is why a product fails, or you hear people in the office day-to-day, "it's just a quirk of the program, we just live with it", or "this program doesn't make sense, who thought of this... it's stupid".
Back to the question at hand, with regards to a process, there should be one defined, and a single person should be in control of the it. If these are brainstorming sessions then everyone sitting around a table, debating, makes perfect sense. Otherwise, someone should be sitting down and with the functional requirements and creating a document and doing preliminary (user) testing. Only after completing a draft should there be a meeting with the group to obtain feedback and gather new changes.
Prior to making the document something to note; a mistake made when creating a document is doing so without defining rules or having a reason to backup why the layouts are the way they are. This should be gathered before giving it to a group for discussion; having sound and logical reasoning behind the structure and layouts gives no one a reason to debate (besides the fact they like to argue). The document should, at the very least, cover these sections below:
1) Project/Document Scope - This sets up the document and discussions. Try to only outline what is in scope, rather than focusing on what is NOT in scope. I say this because it raises questions why it shouldn't be in scope at this time. The simple answer to this usually is budget, time, and/or resources. Anything that is out of scope can be stopped immediately when brought up shouldn't be discussed at that time. It can be noted for future release, or additions to the document, if critical. But the scope should be have been clearly defined prior to the start of the project to correctly allocate resources.
2) Sitemap - everyone mentioned wireframes, but nothing of sitemaps. Diagram of screen flow; hierarchy/tree diagrams, or web diagrams work here. You are trying to identify the f
Well maybe they should get out of their 'When you're a hammer' mentality and learn some interaction design.
Just like 99% of thick client UI developers and usability engineers should get of their 'When you're a hammer' mentality and learn some graphic design.
Why do people find it so hard to admit they don't know everything, and that they could do well learn something from other people??
Well, if it is Linux, you please do make sure it is accessible from CLI.
Rethinking email
When I was fifteen (I'm now forty-seven), my dad taught me the rudiments of structured programming. He was a programmer himself, for the Star-Tribune.
Something he said has always stuck with me. He said, what usually happens is this: Management issues some directives; the programmers fulfill the directives; the end users try to use the programs -- and things go wrong because the end users were never consulted about what kind of tools they need to do their jobs.
The successful programmer, dad said, is the one who first goes and sits down with the end users, talks to them about their jobs, finds out what they really need -- then integrates this knowledge with Management directives. He called this "going native" (before he was a programmer, he took his degree in anthropology).
Link.
-kgj
A committee cannot design a good interface, and neither can any piece of software. One extremely good designer should be placed in charge of the GUI, and his word should be scripture.
www.blueapples.org
How is this a Troll? Apple follows the steps in the GP to a tee.
Jobs was very involved with the design and UI of the iPod.
A&B testing helps a great deal when dealing with responses that can't be measured very accurately or easily. You could go the scientific route of trying to measure user reactions with predefined metrics such as time spent on page/window, tracking of user eye movement, etc. but this can be costly and as stated above can often yield results that don't perform as well as what a designer could put together.
Have your design team create a few options and run some A & B tests to see the responses. Use that as your litmus. Many corporations do this actively on their live sites with new marketing material or ui design.
Good luck.
Essentially "Hallway Usability Testing", right?
..which is why you pair Devs up with Users to create a good UI. Without understanding the users workflow, you can't design a good UI for anything of more than basic complexity.
It is a tedious process to review the whole UI, and often we don't even have the resources to integrate all resulting design changes.
I usually recommend a business-driven approach where you use the business objectives to align the UI to the business. The usability review will be then scenario-based, with a business objective in mind. You hence also can benefit from an incremental approach to cover your site, based on your biz priorities.
I find it easier this way to manage resources as well as the scope of the review/changes when you have a large UI.
You have to be careful to manage scenario dependencies.
Best,
Laurence
http://uiboutique.com/