 |
|
|
|
|
|
| |
GUI Articles List
|
| |
<<Previous | 1
| 2 | 3
| 4 | 5 | Next>>
|
- Use a group walkthrough for best results. Walkthrough testing with
prospective users is inexpensive (comparatively) and you can set it
up quickly. You get a clear evaluation of the task flow early in the
design process. You can evaluate competing solutions before committing
money and time to development.
- Keep walkthroughs within 60 to 90 minutes. Start with simple tasks
to get the brainstorm juices flowing. Cover several core functions across
a range of tasks. Make sure you get to areas that have raised concern
elsewhere. Your goal is to get user feedback – not to defend yourself!
Avoid drawn-out, exhausting battles of opinion.
- Invite a wide range of user types. As a brainstorming session, you
need to hear a variety of viewpoints. It's okay to have supervisors,
managers, as well as end-users with various job descriptions. However,
if employees may feel intimidated around managers, use separate sessions.
- Create a storyboard to illustrate your task flow. Avoid detailed screen
designs – they inhibit assessment of the big picture. Start with
an outline of the task flow. Represent each step graphically for basic
functions, basic navigation, and basic screen flow. Use specific examples.
Be creative. Cartoons are OK! (See Figures 7
and 8.)
|
|
Figures 7. Get discussion on your concept
of the task. Only after you get agreement on a diagram such as this do
you have the material from which to design a high level architecture,
the first screen that connects everything together. (See our article in
The X Journal, Nov-Dec, 1995.)
|
|
|
Figures 8. You can capture the task flow
in a high-level architecture with a "storyboard" like this.
We use this picture in our exercise on improving high level architecture.
It has a ton of problems. Your task design walkthrough would catch such
problems! Include your development colleagues in walkthroughs that have
design challenges. Users may not catch them. By the way, you often find
problems yourself just by doing a storyboard early in the design process.
|
|
- Run the walkthrough like a brainstorming session. Remember how to
do brainstorms? Have a colleague keep notes on a flip chart. Let participants
see progress so they don't return to old topics. Encourage alternatives
and questions. Be flexible. Be solution oriented within practical limits.
Users perform a great job just pointing out problems. Don't get bogged
down demanding solutions during the sessions. Keep things moving.
- Avoid brainstorming pitfalls. No negativity
(it inhibits creative thought). No defensiveness
(users do you a favor by criticizing). No
ego involvement (good luck)! No technical
jargon. Don't ask users how they would
handle some detailed design. Keep to the big issues! Don't
make decisions on the spot.
CONCLUSIONS When you run into a bad case of management
cryptotestiness, now you can steer things in a positive direction. Apply
soul to the question of when to get user feedback (get it early). Steer
your management towards early testing of functions and task design. Users
excel in providing the critical feedback you need early in the development
life cycle. (We said "early" three times!) Avoid at all costs
the crytopitfall of getting user preferences only at the end of your development
– it's tantamount to agnosognosia – the "disease of knowledge."
|
| |
<<Previous | 1
| 2 | 3
| 4 | 5 | Next>>
|
| |
GUI Articles List
|
| |
|
 |
|
