Tom/list,

We have carried out UX familiarization and training for our development
groups at my company. Ssome of the most important things I learned were: 

- Understand the needs of the people attending the training. Will they be
responsible for conducting their own usability evaluations, or will they be
calling on you and/or your UX colleagues (if you have any at your org) to
conduct evaluations? The answer to this question obviously affects what
information you present and how you structure the training.

- Align your content with the SDLC (systems development life cycle)
processes in place at your org. Give concrete examples of how you envision
the product managers and R&D folks utilizing you. Walk them through an
idealized engagement, and if you have time also walk them through how they
can engage you on an upcoming project.  

- Run as many exercises and share as many practical examples as you have
time for. Give attendees a chance to apply the knowledge and practice their
new skills. 

- Evaluate and improve your training. Use the attendees' feedback to iterate
the content, your approach, the examples and exercises, etc. 

Here is a general outline for a 1.5 day session introducing user-centered
design at my co. The intended audience was engineering leads, product
managers, and folks who had been doing design in the "old school" way; that
is, without iteration or utesting (or any substantive user feedback before
release), and heavily intertwined with functional requirements and business
logic documentation. This latter group included RA's, BA's, "designers", and
technical communicators. Some of these people were being rebadged as UCD
contributors. 

We have followed up this intro training with more specific, deeper dives on
various topics such as rapid iterative prototyping, user research, usability
testing facilitation, etc.

------
The goals of training: 
(At the end of training, you will be able to:)
-Recognize how users' cognitive / perceptual strengths and limitations
affect how they interact with systems. 
-Design interactions that are appropriate to the tasks being supported,
using the tools and techniques of user-centered design. 
-Evaluate the usability of the interactions using quick, inexpensive
("guerilla") usability methods. 
-Design usable, useful screens to support the interactions being designed
for the system.
-Evaluate the usability of the system's information architecture,
interaction design, and associated screens. 
-Know how to set up, hire for, and work within/lead a user-centered design
program.


Training outline:
Introduction:  Goals, agenda, overview of graphical UI's 

Part 1. Human information processing and decision making
1.1. Human perception and cognition 
1.2. Human memory and attention
1.3. Human problem solving and decision making
1.4. Skill acquisition
1.5. Users' conceptual models (mental models)

Part 2. Principles guiding well-designed human-system interaction
2.1. Paradigms for interaction 
2.2. Principles to support usability 

Part 3. Designing effective interactions
3.1. Researching and planning the interaction
3.2. Documenting the design of the interaction  
Exercise - identifying target users and designing the interaction (not the
screens)

Part 4. Assessing and validating interaction designs
4.1. Usability methods
Demonstration / exercise - usability testing

Part 5. Designing screens to support interaction designs
5.1. Principles of effective layout
5.2. Writing for the screen
Exercise - designing the UI

Part 6. Implementing user-centered design at [your org]
6.1. What is user-centered design? 
6.2. How does UCD apply to my organization?
6.3. Examples of UCD in action
6.4. Implementing UCD
   -Staffing 
   -Budget
   -Competencies
   -Engagement models
Exercise - planning your UCD implementation

Part 7. Discussion, wrap-up, course evaluation
------


HTH,
Paul Sherman



-----Original Message-----
My boss has asked me to do some usability training sessions for our
development team. Obviously this is a good thing, he wants them to be
thinking of the tools available to them and how they can utilize me better.
I would have to present to a group of about 25-40 people. They will be
developers and QA people mostly.

Can anyone share what they have done in the past in this regard? Certainly I
don't want to bore people or get into the details of how things are built,
but rather how the tools and methods themselves can help make their projects
better (for example, how a persona would benefit their project).

I do have the one-sheeters I made, I could use those as a starting point I
suppose. I'm just wondering what the best way is to present this material,
open to any and all opinions, or examples if you have them.

________________________________________________________________
*Come to IxDA Interaction08 | Savannah*
February 8-10, 2008 in Savannah, GA, USA
Register today: http://interaction08.ixda.org/

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [EMAIL PROTECTED]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

Reply via email to