Software, Tools, Or Techniques For UI Review? 246
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."
Well, there's your problem. (Score:5, Insightful)
Too many cooks, as it were.
Re:Well, there's your problem. (Score:5, Informative)
Re:Well, there's your problem. (Score:5, Insightful)
Also, for all your developers, do you have a designer? UI development = graphic design + industrial/interaction design.
There is also the little concept of actually using the software. Here is my plan that I wish every corporation would adopt for near perfect design:
Of course this is from a user's perspective and from someone who writes software for myself. Profit may get in the way of a usable product, so I don't expect my plan to get adopted everywhere.
Re:Well, there's your problem. (Score:5, Insightful)
This is good advice for many consumer products but not for all software since some software is intended for users of whom the CEO is probably not representative. Software for technical people, for example, may trade a longer learning curve for greater efficiency or configurability for experienced users, and software for some tasks assume specialized knowledge of the task that most people won't have.
Good luck finding a CEO who will let you fire him if he doesn't test your software.
Re:Well, there's your problem. (Score:5, Insightful)
I think his point was more that the best way to design a user interface is to let the users actually... y'know... use it. Throw it out to a small but select non-developper beta, and take their suggestions about usability to heart.
A group of engineers sitting around, arguing about what should be where is just going to obfuscate things, and unless they get really lucky, it isn't going to result in something that's usable. Also... keep in mind the idea that nothing should be more than 3 clicks away, unless it's obscure. More than that, and users won't remember it. If it's something that they use frequently, it should be 1 click away. All about keeping the application efficient, but not cluttered.
My first thought, when I read TFS, was that he's out to lunch. He's looking for software to accomplish a task that, to my mind, should be a completely organic process. You can't write software to design your user interface for you, because people don't think like computers. You need to go through revisions and iterations until you get something that works. Oh, and sitting around watching slides is absolutely the wrong way to get a feel for how it's going to work, too. They should be presented with the actual user interface, or a mock-up if that's not possible, and actually go use it for a few days before coming back and talking about what was good and what was bad, and what needed improvement. And keep doing that until enough people are happy that you'd be comfortable unleashing it on the world.
Comment removed (Score:5, Insightful)
Re:Well, there's your problem. (Score:4, Insightful)
You don't want your ceo to be representative. The average company with a CEO has at least 50 people. You really want that person to have the best leadership and organizational skills of those 50.
Re: (Score:2, Informative)
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.
Re: (Score:2)
One shortcut might be to learn from the hideous mistakes of others:
http://www.math.leidenuniv.nl/~xmath/mirror/www.iarchitect.com/mshame.htm [leidenuniv.nl]
http://office.microsoft.com/en-us/help/HA100898951033.aspx [microsoft.com]
http://www.youtube.com/watch?v=ZegWedG-jk4 [youtube.com]
http://www.cs.rutgers.edu/LCSR-Computing/some-docs/emacs-chart.html [rutgers.edu]
Re: (Score:2)
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.
Re: (Score:3, Insightful)
This is also supposing that a given CEO actually KNOWS the business he leads. Too often, it's marketing and sales people that end up in the top positions of many businesses. This often means that they have little or no appreciation or understanding of the usage or applications, products or services this company may offer. Companies lead by sales and marketing types often have little respect or regard for what they offer and concern themselves only with the numbers. The is a terrible trend as quality oft
One better (Score:3, Interesting)
Also have the programmer themselves have to use the application for 'a day', in a real-world example - the guy who knows the UI in and out, so training is not a problem.
But as a programmer he/she will see what doesn't work when they have to enter data live (i.e. entering client data with client sitting across the desk) - and they will get a pretty good idea of what needs fixing and how to get it done. For more complex concepts they may have to be the keyboard pilot with an expert telling them what they wa
Re: (Score:2)
Isnt that what microsoft did when they had gates?
Re: (Score:2, Insightful)
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 every
Re:Well, there's your problem. (Score:4, Informative)
Of course, that is what Apple does with its software. If Steve Jobs doesn't like the user interface, it gets changed.
Doing this has helped Apple be the leader in user interface design and the stock remark recognized ths when news of his possible illness dropped Apple shares considerably.
Play some portal... (Score:3, Interesting)
These people really designed a UI that becomes usable after some training. Great take aways...: 1 Use the simplest method possible to control something.
2. Dont add buttons.. On My Imac there is a small remote 2 buttons, and an outside ring.. This is FAR more powerful than the 50+ button remote for Dad's TV+dvd player remote.
3. Dont Hide controls too deep.. look at vista.. changing an ip address Start->CP-> network ->Internet properties-
Re: (Score:2)
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
Re: (Score:3, Insightful)
Agreed, I don't really see a lot of CEO's using Visual Studio, Eclipse, Photoshop, Dreamweaver, Quickbooks... Its not that the products aren't usable, its because they have no point of reference.
Sure, they should be able to QA something like a web browser or office suite, but that's about it.
Re: (Score:3, Funny)
Depends on the type of application. What if it's for fiddling your stock options or keeping track of your golf scores?
UI Development != graphic design (Score:5, Interesting)
Not in the least. Lord no. Perhaps have them polish up and make things look pretty after the UI is decided upon, sure, but leave the UI design to people with a background in it. That's the equivelant of telling a baker to to cook you a steak. They might both make food, but the thought process is totally different.
If you have a technical writer working on the project, give him/her a shot at it. Their job is to make the complex simple and to make it fit in as small of a container as possible. They'll also be the ones writing the manual on the stupid thing and, more often than not, many design flaws come out in the process of writing the manual. You'd be surprised what kind of input they might have.
Other than that, do you have a corporate psychologist or HR person with a background in psychology? They might also have valuable insight.
Other than that, as far as viewing the UI for a review, have someone make a mock up, clickable UI in Flash or even HTML. It shouldn't take long and will give you a good idea of what the user experience before it's all coded in.
Re: (Score:2, Insightful)
If you think all a graphic designer does is "make things look pretty" you might want to read that article.
and if you live in a world where you think people still read manuals, you might want to find out what a UI designer actually does.
Actually I'll tell you. A lot of it is helping a user discover, understand and use features and data without having to read a manual. And coincidentally guiding the way someone discovers and understands visually (like on a computer screen) is graphic design. The use part fall
Re: (Score:2)
Right, and who better to understand why a person actually has to RTFM than the person who writes TFM.
From personal experience, when the UI gets thrown to the graphics design team, it looks stunning...however, the depth is usually too short sighted to anticipate all of the required user interactions.
Frankly, a GUI professional would be optimal, but if your company doesn't have one, the tech writer is going to be the best follow up. If the program looks plain and uninspired, fine, so long as it's easily usab
Re: (Score:2)
Technical Writers are development's interface to the customer, and as such they are typically the "go to" people for such things in early development phases. Additionally, the technical writers often work in conjunction with (though perhaps not in an "official" capacity) quality assurance as another line of sanity testing.
While individual developers are tasked with completing certain portions of a project, or maybe tasked to smoke test chunks of code, it is often the technical writers who see the entire pro
Re: (Score:3, Interesting)
technical writers should be involved at all levels of the spec writing process. Ofttimes, the specifications, functional/technical/implementation are loaded with ambiguities information and incomplete or conflicting requests.
The technical writers can bring a great deal of clarity and sanity to the table. Not every company can afford dedicated writers for every product/project, but every company should be asking the documentation group to read over the functional spec prior to using that to create any sort o
Yuck! (Score:3, Interesting)
In this section [worrydream.com] in particular -- past the comic -- there is an example of a redesign.
Raise your hand if you would rather try to point at a specific location on a map than simply choose it for a list.
And you know what? By the time you're using this form, you know the date, as text. It's going to be quicker and simpler to enter it via the dropdowns -- even quicker if you can simply type. The calendar widget only helps if it can show me events I've already placed on a calendar -- otherwise, there's no point.
I
Re: (Score:2)
Actually come to think of it, pretty much all websites use fancy date pickers now
And the better ones provide an option to do an old-fashioned dropdown.
In fact, the best I can remember will let you type a date in m/d/yy form, but will popup a calendar -- and javascript syncs the two. (Click a date in the calendar, and it auto-fills the text field. Type in the text-field, and the calendar will update as you type.)
do you at least get what he's trying to say?
Well, the paper was fairly long, so I looked for screenshots/mockups, to see what the end result would look like. I didn't like those so much, so I didn't read the paper.
Re:Well, there's your problem. (Score:4, Insightful)
Design by committee is a terrible process to endure and very often the outcome is of far less quality then a design done by someone who knows what they are doing.
Re: (Score:2)
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 usi
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Well, there's your problem. (Score:5, Interesting)
Give the program to the average secretary & watch where she stumbles or otherwise looks confused.
Re: (Score:2)
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.
Ask the users. (Score:5, Insightful)
Ask the users. The people who will be using this software have certain expectations about where something should and should not be located.
Of course, that should not be the end-all of your research, but it should be an excellent starting point.
Re: (Score:3, Insightful)
The users should be doing - or getting someone to do - mock ups. Use vb6/.net, or Access, or Visio, or anything else which lets you knock up some pages full of controls which look similar to what they're after. Doesn't matter what it looks like, as long as you can tell a listbox from a text box etc, and how much data they want per page (ie does it scroll, have next/prev buttons etc). It's not up to developers to either decide or guess.
Re:Ask the users. (Score:5, Insightful)
Absolutely ask the users. There is no better way of evaluating your UI.
Have your programmers watch users try the UI. Don't lead the witness--let them make mistakes (and fix that part of the UI).
You will be surprised what you learn.
Steve
Common misconception. (Score:2)
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.
Re: (Score:2)
Also, pure graphic design photoshop/illustrator producers who think they can desi
Re: (Score:2)
"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?
Re: (Score:2, Insightful)
You often need a starting point prior to asking the users. While the users should be the final arbiters it is more of the case than not that the user can't really describe what is needed because they don't fully understand their own requirements. They can however critique something they've been shown and this will help them drive to requirements.
Re: (Score:2)
I agree, ask the users... depending upon the application will depend on the best way to ask.
If possible, have multiple teams of users each coupled with a designer... have the designers then sit down with what their teams came up with and find the common elements, these are must haves. Anything that is unique should then be presented back to the other user teams to see if they agree about the need, if so it's also a must have. Finally, the desingers seperate and create simple mockups that include all the m
Re: (Score:2, Informative)
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 bott
Re:Ask the users. (Score:5, Interesting)
Not asking the user.
What you really should do is watch the user. If you ask them, they'll tell you what they think they'd do, or what they think you want to hear, or what they think they'd like to see... everything except what is most important: what they really do.
(And I'm not the only one who thinks so [useit.com].)
JJ
Re: (Score:3, Informative)
Not to mention users are idiots. They don't know where they want things. What menus they want... etc etc etc... if you ask the users they'll tell you they either "liked it" or "were confused but are sure it wasn't their fault".
The MOST IMPORTANT thing a UI designer needs to work on is FLOW. The specs tell you what the application needs to do. "Color Correct a Photo", "Remove Zits", "Paint: change brush size, paint, change brush shape..." etc etc etc.
If you watch your users and see A) What they do most o
Add Ribbons (Score:2, Flamebait)
Re: (Score:3, Insightful)
I am a programmer, and would like to offer my opinion.
DO NOT ASK THE USERS. FOR THE LOVE OF GOD, DO NOT ASK THE USERS.
Users don't have a damned clue about software design, and will always ask for something stupid. They might ask for something that seems simple to them but is hideously complex or impossible to implement (I once had a user calmly demand I should replace the entire complex app with a box where they could simply specify in english what they want and push the button and it would magically figure
Re: (Score:3, Insightful)
IMHO you are only partly right. Asking for goals in functionality is the way to go in the beginning, but getting feedback on useability and design later in the process can be invaluable.
Sure, users can have unrealistic expectations, but it is the job of a project manager or interaction designer to interpret and manage those expectations.
Your example of a user who had completely unrealistic expectations actually creates a positive situation. If you had just given that user a finished piece of software it wou
Re: (Score:3, Insightful)
In my experience, users usually don't know what they want. Or worse, they'll ask for something, but really want something else.
This idea works better if you have a professional UI designer work up some designs and present those to the users.
You should use your users to generate ideas for your interface, and also as a checkpoint for your interface. But giving them too much input will screw up your end results.
Re: (Score:3, Insightful)
"Ask the users."
To recall Henry Ford: we would be trying to make faster horses instead of cars, then.
Apple Human Interface Guidelines (Score:5, Informative)
Re:Apple Human Interface Guidelines (Score:5, Funny)
Re: (Score:2)
Only useful for Mac OSX applications.
For Windows applications follow Microsoft's guidelines (even though they ignore it and it's quite difficult because of the many differences between each Windows version).
Simple rule: keep the UI consistent with the interfaces of the other applications that run on that system.
Re: (Score:2)
Paper Prototyping (Score:4, Insightful)
http://en.wikipedia.org/wiki/Paper_prototyping [wikipedia.org]
Now, that may not actually address the problem. UI fights are intractable with **everyone** having an opinion and more than willing to resort to all kinds of dishonorable methods of getting their way.
The next step of the process should be interviewing as many paying users as possible, face to face, paper and pencil ready. From those interviews see if you can find some similarities and go from there.
Re:Paper Prototyping - Mod Parent Up (Score:2)
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
Just Use It (Score:5, Insightful)
Nothing beats using it.
Years ago in my tech startup days, I remember spending hours just using our about-to-launch web application, doing my best to break it. Things are a bit different when you're not web-based, but doing this on a variety of computers is still a good way to find bugs, note slowdowns, discover any issues with running it concurrently with other software, etc. This is also a nice (and sometimes fun) way to involve ALL of your staff -- not just IT -- because there's going to be a wider variety of user experience levels there.
Re:Just Use It (Score:5, Informative)
useit.com [useit.com], Jacob Nielson's site. Everyone having anything to do with interface design should read the whole thing.
Re: (Score:3, Informative)
And they have a non-spammy newsletter that lets you know when new articles go up. If the OP can afford it then a seminar or two may also benefit them.
UI recommendations from a web page that looks (Score:3, Funny)
Uhm, that web page hurts my eyes. Are you sure you recommend this as UI interface design reference.
Re: (Score:2)
User Interface Engineering, and Eyetracking (Score:2)
http://www.uxmatters.com/MT/archives/000068.php [uxmatters.com]
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 wh
Re: (Score:2)
I remember spending hours just using our about-to-launch web application, doing my best to break it.
I don't think the OP is asking about "durability" of the UI, if that term exist for software. I think he/she is asking about how to make it intuitive. The creator of a product always thinks the fruits of his/her labor is intuitive. It's best left up to a third party to determine how intuitive the product is.
CUA/CUI specs (Score:5, Informative)
There are CUA guidelines for various operating systems. You can check out that documentation to determine where what components/options you have should be placed. They are pretty thorough.
IBM's was written in 1987, and updated since (and followed for the most part in the Windows and OS/2 world).
Microsoft's has of course recently changed with the advent of Vista and related v2007 programs.
For broadest use, I would choose the specs used in later versions of Windows for Windows based apps... for Linux, I am not sure where you would check - but am sure some sort of guidelines should exist someplace.
A place with links and references to IBM's CUA can be found here:
http://en.wikipedia.org/wiki/Common_User_Access
From there, or with similar searches, you can find references for related Windows CUA stuff
Re:CUA/CUI specs (Score:4, Informative)
For broadest use, I would choose the specs used in later versions of Windows for Windows based apps...
Should have read (changes in bold):
For broadest use under Windows, I would choose the specs used in later non-Vista versions of Windows (such as XP) for Windows based apps...
and (added)...
The CUA references should have everything including such things as keyboard shortcuts, etc (as well as main menu placement... ie: always starts with File, Edit, View - and ends with Help).
Apple's was written circa 1983. (Score:2)
Guerilla user testing (Score:3, Informative)
Re:Guerilla user testing (Score:5, Informative)
And an app designed to help: http://silverbackapp.com/ [silverbackapp.com]
Uh... (Score:5, Insightful)
Not sure what you're getting at. If your action listeners are screwed up, that's an obvious problem with a straightforward solution, but if your UI just plain sucks, no program is going to tell you that.
You need to go find someone with aesthetic sense, and a minimum of technical knowledge, and you need to shut up and listen to them whine as they use your UI. When you've fixed enough stuff that they stop whining, bring in a couple more and listen to them whine. Eventually they won't whine, and at that point, you'll know you've got a good interface.
For gods sake though, don't get a fricking committee involved! They will all want to make a trivial change to put their mark on it, and all those changes will turn your unpolished interface into the sort of steaming crapheap that wouldn't meet the basic user-friendliness of the interface on a piece of stereo equipment.
So yea; get the users involved, distill their complaints, make changes, NO COMMITTEES. And the simpler the better. I should write a UI testing program that just runs for 10 minutes and then pops up, "Your interface has too many buttons. Simplify it please." The interface can almost always be simpler.
Joel Spolsky's writings (Score:5, Informative)
Here's the first chapter [joelonsoftware.com]
I think you're doing it almost right (Score:4, Insightful)
There's no way software can design or test a user interface. Use smaller design teams, and make sure there is at least one expert in useability.
It doesn't sound like you're doing too much too wrong.
gui review is just hard (Score:2)
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 t
Well I heard Microsoft... (Score:5, Interesting)
Re: (Score:2)
Depends on who you are trying to make the app more usable for, which depends on what kind of app we are talking about.
If the app is a web site targeted to the general populace and has lots of new/casual users, then more important than mouse clicks is how easy it is to navigate to various tasks. Watch a few uninitiated users use your application. Give them tasks without telling them how to accomplish the task. See how they perform. I'll bet you'll find your problems that way.
If the app is for a set of us
Re: (Score:2)
So by that token, is a huge toolbar with buttons for every possible function more useful than a two-level hierarchy of well-organized menus?
Re: (Score:2)
Microsoft did more than that. They took the statistical data that they compiled from real-world users who opted in to "make future Office better" and used it to determine what features and functions were used most often, and prioritized their efforts on re-working the interface for those features based on that.
One of their leads gave a talk recently on the story of the evolution of Office's interface, starting from Word 1.0 through Office 2007. It's worth watching:
http://msstudios.vo.llnwd.net/o21/mix08/0 [llnwd.net]
Biggest UI want (Score:2)
Director (Score:4, Informative)
A ton of commercial (and in-house) applications have had their UIs prototyped with Macromedia (now Adobe) Director. Especially with a third-party "xtra" called OSControl (which gives you access to OS-specific, well, controls like menus, tabs, etc.), Director makes building a UI prototype quick and easy.
Director's a little long in the tooth for real desktop application development. Still, I'm not sure that there's another tool that lets you build "quick and dirty prototypes" (with enough functionality to actually test with users) as rapidly as Director.
Avoid the latest version (Director 11) like the plague, though. It's an abomination.
BTW, as a process issue, a "look and feel prototype" is always one of the earliest milestones in our development cycle. The client has to sign off on the interface, and write a check for a progress payment, before we proceed into actual code-slinging. Saves a boat load of headaches to do it this way.
First rule of gui design (Score:4, Insightful)
Don't let developers do it.
Hire a professional to give you a framework, build from there.
Having a common framework will allow you to know when any screen is wrong, and it will be easier for your QA team to find errors.
Re: (Score:2)
Don't let developers do it.
Hire a professional to give you a framework, build from there.
So you're saying that developers aren't professional? Or that developers can't build a framework?
Re: (Score:2)
I Can Tell You What NOT To Do... (Score:4, Interesting)
We hired this company, who $3mill later gave us a wireframe mocked up in Photoshop of what the UI should look like. The execs LOVED IT. One problem... the tools which had already been decided on and purchased couldn't produce anything that looked remotely like the mocked up UI. Guess who got blamed? Management? No. Developers? Yes. Because they couldn't produce a UI that looked as "cool" as the wireframe.
Re: (Score:3, Insightful)
I hope the conclusion you reached is that developers should be involved in UI design from a requirements perspective. At the very least, the consulting firm should have known what your tools were capable of. Secondly, good UI designers can take feedback like "it would be easier to do things this way," for example, if you already have a UI and you're trying to minimize changes. Your development team should have had engineering management on top of it who were aware of the consulting firm and should have i
Usability Engineering anyone? (Score:4, Informative)
i habe been reading /. for quite a time now and never read the word "usability" ever. (i think most FOSS guys also never heard of it)
Interface Usability is a whole science. There are plenty of books describing exactly what you are trying to reinvent!
For a start you might want to check out Jakob Nielsen's Alterbox Website, which is full of small articles regarding common usability problems.
http://www.useit.com/alertbox/ [useit.com] ... and if you like his style of writing you might also want to buy his book "Usability Engineering" (which is a must-have when you work in the field of usability IMHO)
get the right people, and only the right people (Score:3, Informative)
As far as a UI overview, again, there's nothing better than testing by actual end-users. Try to convince your boss to let you demo an early-ish prototype to real customers. If you can't, then hallway testing [wikipedia.org] is probably the next best thing. If a random cross-section of people can manage to perform simple tasks through your UI, your customers shouldn't have much trouble doing the same thing.
Form follows function (Score:2, Interesting)
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 ho
Simple is often best (Score:5, Informative)
1. Define what the software should do
2. Make the UI, even a mockup will do
3. Invite users to test drive the UI while video taping
(See (1) and ask the user to do each one(with no help))
4. Measure the users success (clicks, wrong clicks etc)
5. Score each screen with the predefined metric from (1) filled inn in (4)
Done.
Often the real problem is that nobody really knows (1): what the software should do. Marketing thinks it is "one click purchase" and engineering thinks it is "fully configurable shopping view". So agree on 1 first, and maybe your problems go away.
Re: (Score:2)
1. Define what the software should do
No.
1. Define what the user's goal is
Step 2 most important (Score:2)
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.
Just recently I had to do some UI tweaking for Drs (Score:2)
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
Usability Engineering (Score:2)
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 d
You need an expert (Score:5, Insightful)
If your UI has gone beyond the most basic of interfaces, you need to hire someone who has a background in "human factors". Expecting a bunch of programmers to design a good user interface is a very bad idea. Just look at all the crappy interfaces in the open source world.
Hoping for a program to automate this is as likely as getting your own pet unicorn.
Re: (Score:3, Interesting)
If you're on a large project with a correspondingly large budget, an HFE will be money saved, in order to free up the time of your developers.
Human factors is one of the most overlooked aspects of an app, and having a programmer design it is bad for a nu
You can't polish a turd (Score:2)
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.
Remember Jeff Hawkins (Score:2)
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/ [counselormagazine.com]
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.
Lower Coupling! Higher Cohesion! Reuse! (Score:2)
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
Do a mockup. Let users play with it. (Score:3, Interesting)
Use a rapid application development package... Visual Basic is fine for that job, even if I lose all credibility by saying so... and do a mockup.
Get a few users. They should be people who are not members of your group. They should be vaguely typical of the people who will really be using the real application. They should not be managers or anyone with power to dictate their preferences as requirements.
Give them absolutely minimal directions. Let them try to use the application. Watch them. Resist the temptation to say anything unless they get so very stuck that there's no longer any hope of learning by watching them; then coach them just enough to get them unstuck.
See what they do. See what they assume. See where they make mistakes. I guarantee you you'll learn more in ten minutes than in hours of having people familiar with the code review slides. The places where you think they'll get stuck are the places they'll breeze through. The places where they do get stuck will surprise you completely. And you'll suddenly see glaring, obvious, easily fixed goofs in the UI design that you didn't notice in any review.
If you want to do a big formal megillah with one-way glass and video typing and people with psychology degrees, fine, but that's not important. The important thing is real users really playing with a functioning application.
Reviewing slides is nuts. Having people who develop the application review slides is nuts. You can't possibly figure out how something is going to work and feel by looking at slides. It's like figuring out whether a car will be fun to drive by looking at a static picture of the dashboard.
Some years ago someone was showing off an application... one of those GUI-like database applications that ran on character-oriented screens... that his group had done. I was playing with it. He was bragging about the screen refresh, the way they'd implemented scroll bars with characters, and so forth.
I noticed that three successive screens required me to key in the identical piece of information three time in a row. I also noticed there wasn't even a copy-and-paste function.
I pointed it out to him. He said, "Yeah, I know." I said "Are you going to fix it?" He said, "No." He whipped out a 3/4" thick spec. He said "It took six months of review to hammer out this spec. It's done. What you saw is what the spec says."
I said "You mean nobody noticed that problem during the review?" He sighed. "Apparently not."
"Well," I said, "why not just fix it?"
"Look," he said, "it took six months to get this spec signed off on, we're not going to open it again or it will take more months, we need to get this through SQA, and what SQA will be doing is checking to make sure we conform to this spec.?
Get a human interface expert (Score:2)
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
Prototype it. (Score:2)
What I've said earlier. (Score:3, Interesting)
A good UI is not cute, cool, or pretty. It is one that makes
functionality obvious while itself remaining invisible.
You can make a good UI cute, cool, or pretty, and you may get praises
for it, but it isn't what makes it usable.
There is a fundamental paradox is usability testing. If you ask about
usability, you are asking what people notice. But the best UIs are those
that are not noticeable. You should never test a UI. You should only
test the usability of the application, and measure things like confusion
and task completion speed.
Re: (Score:2)
Mod this one up.
A couple of additional pointers:
Re: (Score:2)