My Designs: Process Mapping through Prototyping

Created: Tuesday, 20 January 2009 Written by Gary Elsbernd Print Email

My wife doesn't know what I do at work.  I tell her all the time, but her eyes glaze over sometime into the second paragraph like mine do when she discusses her work in the neonatal intensive care unit.  I find my work endlessly fascinating, but I'm in the minority.  What I do is develop user experience designs from which talented developers create world class web applications.

The job is part psychologist, part librarian and part artist.  I have to understand organizational objectives and personal motivations, catalog knowledge and design components, and weave them together into a interface that so closely supports the intended task that it becomes invisible to the user.

I learned my craft over the past two decades after being exposed to a variety of methodologies and techniques.  My current practice most closely resembles the Performance Centered Design methodology developed at Ariel Performance Centered Systems and documented by Barry Raybould.

Business Process Mapping - A clear understanding of the current and desired business process, including what the business needs out of the process and how the user is incented to perform the task, is needed to develop a system that satisfies everyone.  These flow charts are then broken down into information needs for each step to ensure the user can make the right choices.  I don't usually have to do the process maps myself, but I usually influence them and must understand them.

Scenario Development - A scenario describes a single instance of a use case in as much detail as necessary to tell a story.  The scenario provides a narrative that can objectively be assessed to ensure the prototype solves the problem.  A number of scenarios are developed to cover variety of tasks, user groups and work contexts.  Sometimes I share these with my team, but often it's just a structure for me to demonstrate the prototoype.

Prototyping - The processes are divided into screens to support the task and an interface flow is developed to show how the screens interact.  HTML prototypes of the screens are developed and linked to support the story developed in the scenario.  The evaluators can see how the task progresses from screen to screen with as much fidelity in the data and functionality as necessary to understand the intended design.

Evaluation - Users review and identify holes in functionality, information or the process.

Refinement and documentation - After iterating through the prototype, the design will solidify and coalesce into an accepted design.  That design is documented with an annotated powerpoint of the prototype and user interface specification describing every control, behavior and data element present in the prototype.

Maintenance - inevitably, the scenarios don't cover anything, and sometimes technical limitations require compromises in the design.  As a designer, I stay involved through testing and deployment to ensure the system works in the real world.