This link has been bookmarked by 9 people . It was first bookmarked on 28 Jul 2006, by Bernardo Schepop.
-
06 Mar 14
-
Understanding of the users themselves is equally important. An awareness of the users' background knowledge will help the designer answer questions such as what names to use for menu items, what to include in training packages and help files, and even what features the system should provide.
-
Effective task and user analysis requires close personal contact between members of the design team and the people who will actually be using the system. Both ends of this link can be difficult to achieve. Designers may have to make a strong case to their managers before they are allowed to do on-site analysis, and managers of users may want to be the sole specifiers of the systems they are funding. It's certain, however, that early and continued contact between designers and users is essential for a good design
-
The designer should identify several representative tasks that the system will be used to accomplish. These should be tasks that users have actually described to the designers. The tasks can initially be referenced in a few words, but because they are real tasks, they can later be expanded to any level of detail needed to answer design questions or analyze a proposed interface.
-
The rough description of the design should be put on paper, which forces you to think about things. But it shouldn't be programmed into a computer (yet), because the effort of programming, even with the simplest prototyping systems, commits the designer to too many decisions too early in the process.
-
In the early stages of a simple design, this concrete product might be as simple as a series of paper sketches showing the interface while a user steps through one of the representative tasks. A surprising amount of information can be gleaned by showing the paper mock-up to a few users. The mock-up may even reveal hidden misunderstandings among members of the design team.
-
The testing with users will always show some problems with the design. That's the purpose of testing: not to prove the interface, but to improve it.
-
A fundamental principle of this book is that interface designers should not be a special group isolated from the rest of the system development effort. If this principle is to hold, then the designer must have contact with users after the design hits the street.
-
One way to put designers in contact with users is to rotate them into temporary duty on the customer hotline. Another important point of contact for large systems is user group meetings. Managers also take advantage of these opportunities to see how real users react to the products they are selling.
-
Responsibility for the entire interface effort should be centralized. In particular, the designers who create the software shouldn't sign off on their product and hand it off to an entirely separate group that creates the manuals, who then hand off to another group that handles training. All of these activities need to be coordinated, and the only way to achieve that is through central management.
-
-
25 Apr 09
-
03 Jan 09
Paul HibbittsWeek 2 (Jan 11-15)
-
27 Mar 08
-
28 Jul 06
-
02 Apr 06
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.