Slashdot Mirror
Software, Tools, Or Techniques For UI Review?
Comatose51 writes "Does the Slashdot crowd know of any software, tools, or even techniques for reviewing the UI of an application? Right now at our company this is a long and arduous task of looking at slide after slide of pages and menus from our UI, and taking notes and arguing over what should go where or how the UI elements should behave and interact with the user. It takes many, many hours to do this and with all our UI developers involved, it adds up. This has to be a common and recurring problem so there must be a better way to do this. If there is open source software to help, great, but any helpful suggestion would be appreciated."
Too many cooks, as it were.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
I'm not a programmer, but I'd still like to offer my opinion.
Ask the users. The people who will be using this software have certain expectations about where something should and should not be located.
Of course, that should not be the end-all of your research, but it should be an excellent starting point.
Those who believe the Internet is private,
find their privates are on the Internet.
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.
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.
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".
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
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
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!"
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.
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.
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!
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
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.
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.
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.
Agreed, I don't really see a lot of CEO's using Visual Studio, Eclipse, Photoshop, Dreamweaver, Quickbooks... Its not that the products aren't usable, its because they have no point of reference.
Sure, they should be able to QA something like a web browser or office suite, but that's about it.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
This is also supposing that a given CEO actually KNOWS the business he leads. Too often, it's marketing and sales people that end up in the top positions of many businesses. This often means that they have little or no appreciation or understanding of the usage or applications, products or services this company may offer. Companies lead by sales and marketing types often have little respect or regard for what they offer and concern themselves only with the numbers. The is a terrible trend as quality often suffers when component and ingredient substitutions are made, support services are outsourced or H1Bs are used to reduce the cost of manpower. The results and the quality invariably suffers from these bottom-line oriented tactics and only show short-term improvements as a drop in sales resulting from decreases in production quality rarely show immediate responses by the customer.
I have gotten off the point here a bit, but what I'm saying is that CEOs often have little or no idea what is best for the products or services of a company. (My CEO is different, but mainly because he's not a marketing or sales guy.... he was involved in the production side of things before he took over the company, so he knows what qualities are important to the future and well-being of a company... sadly those types are rare these days.)
You 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
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
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.
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)?
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!
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.
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.
"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.
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???
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
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.
... 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/
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."
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!
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
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.
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!
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, 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.
..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.