StUX - IA Summit 2005 - Peter Boersma

Peter Boersma Senior Information Architect for EzGov [email_address] IA Summit 2005, Montréal, Canada, Sunday March 6, 4:15 – 5:00PM This StUX! integrating IA deliverables in a web application development methodology

Peter Boersma, EzGov

Senior Information Architect EzGov European headquarters in Amsterdam.

Training in Human Computer Interaction, combined with 10 years of experience with analysis, structuring, functional design, UI design, and evaluation of online, interactive applications.

Active member of local and international HCI/IA/UX networks; organized and presented at information architecture and usability related conferences.

Peter organizes IA Cocktail Hours in Amsterdam.

[Beep] ( http://www.peterboersma.com/blog ).

Agenda

Who’s EzGov, and what’s RUP? 5 min

RUP isn’t enough 5 min

EzGov’s fix: StUX 5 min

Promoting StUX 5 min

Impact and future of StUX 5 min

Lessons Learned 5 min

Examples of other approaches 5 min

Discussion 10 min

EzGov transforming the business of government

EzGov [easy gov], e-Government Technology Specialists since 1999, designs, delivers and maintains transactional web applications .

offices: Atlanta, Washington, Amsterdam, London

services: Consultancy, Design, Development, Hosting, Training, Partner Program

software: FlexFoundation® core, business transaction manager, developer studio, payment & gateway plug-ins

clients: USA Customs & Excise Immigration and Naturalization Services (DoHS) Small Business Administration State agencies (Georgia, Mississippi) UK Inland Revenue Department of Work and Pensions Justice Department

EzGov organizational chart User Experience Solutions Engineering Quality Assurance Product Mgmt. Sales & Marketing People & Finance Delivery Mgmt. Mgmt. Team Service Delivery

EzGov organizational chart User Experience Solutions Engineering Quality Assurance Product Mgmt. Sales & Marketing People & Finance Delivery Mgmt. Mgmt. Team Service Delivery 5 20 70 10 15 8 14 40 8

UX department responsibilities

The User Experience department works on:

Requirements Gathering

Content Analysis

Information Architecture

Interaction Design

Information Design

Visual Design

Usability Evaluation

EzGov uses Rational Unified Process (RUP)

RUP = a software development methodology

IBM’s Rational Unified process (RUP) is a configurable software development process platform.

RUP is iterative (phases & iterations) and role-based (disciplines)

Includes software tools to change the default process, add corporate knowledge, and view & distribute the results.

Nobody uses the tools , but everyone uses the artifact templates .

RUP isn’t enough

RUP doesn’t support User Centered Design

“ User experience and interface design in the context of creating software represents an approach that puts the user, rather than the system, at the center of the process. This philosophy, called user-centered design, incorporates user concerns and advocacy from the beginning of the design process and dictates the needs of the user should be foremost in any design decisions.”

From Microsoft’s MSDN Library, User Interface Design and Development section at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_uidesigndev.asp

RUP isn’t enough

The Rational Unified Process (RUP) was not developed for front-end heavy projects: “For systems with a significant amount of user interaction, the development team should also create a UX model and storyboards within that discipline. This integrates usability concerns into the RUP development approach.” From “ User experience storyboards: Building better UIs with RUP, UML, and use cases ”, Jim Heumann, Requirements Evangelist, IBM Rational

RUP’s UX Model isn’t enough

Rational’s fix, the User Experience model, was not developed to model the non-technical aspects of the user experience: “User-Experience (UX) modeling [...] is used to describe the technology aspects of the user’s interaction with a Web-based system.” From “ Transforming User Experience Model To Presentation Layer Implementations” , Wojtek Kozaczynski ( [email_address] ), Jim Thario ( [email_address] ), Rational Software Corporation, USA

EzGov’s Fix: StUX

EzGov’s non-technical additions to RUP

EzGov added non-technical roles and deliverables :

Main roles: Information Architect, Visual Designer (but also: system analyst, usability & accessibility planner/tester, content designer, interaction designer, information designer)

Main deliverables: Screenflows, Wireframes, Mockups (but also: field-level requirements, personas, usability test strategy, content inventory, visual elements, styleguide, and more)

We mapped these user-centered design roles to the RUP process and described the deliverables and their relationships, leading to EzGov’s Standards for User Experience (StUX)

StUX = deliverables diagram and descriptions

StUX deliverables diagram (1/3)

Maps deliverables to RUP phases Deliverables are either mandatory for projects (solid line) or optional (dotted line)

Shows input/output relationships Relationships are either implied (horizontally aligned) or explicit across roles (arrows)

Integrates standard RUP artifacts with EzGov UX artifacts

Defines non-technical competencies, spanning three EzGov job-descriptions

Systems Analyst Requirements gathering and management, mostly RUP-based

Information Architect information architecture, interaction design 1 , usability & accessibility testing, content design

Visual Designer visual design, information design, interaction design 1

(1) shared between Information Architect and Visual Designer

StUX deliverables descriptions (1/2)

One-page description for each of the 28 (*) deliverables:

Place in process owner, phase, input/output, etc.

Contents goal, description & detailed contents

Quality aspects reviewers, signoff

Pointers templates & instructions (under construction)

(*) or 41 if you count different versions for different phases

StUX deliverables descriptions (2/2)

Inception Phase Deliverables - Vision, Use Case Model, Supplementary Specification - Glossary, Use Cases, Requirements Management Plan - Interaction, Usability, Accessibility, Content & Visual Requirements - Task Analysis, Personas, Scenarios - Content Inventory, Screenflows - Usability Test Strategy, Test Plan, Test Report - Moodboard, Concept Presentation

Elaboration Phase Deliverables - Field-Level Requirements, Requirements Reports - Visual Elements, Mockups - Wireframes, J-Flow - Style Guide

Some deliverables appear/develop in different phases, e.g. “high risk screenflows” are developed in Inception, “all screenflows” are developed in Elaboration.

Introducing StUX to the company

StUX design process (first 2 years)

Initial inventory (Q4 2002) - brownpaper + post-it™s - inventory of artifacts - suggestions for order in the design process

Diagram design & evaluation (Q4 2003) - small team sets up diagram design - small team of seniors evaluate order

Descriptions writing & evaluation (Q2 2004) - small team writes descriptions, fine-tunes diagram - larger team collectively reviews descriptions

Promotion materials (Q3 2004) - small team designs promotional artifacts - display in public spaces - slowly incorporated in overall process

StUX promotion materials (1/2)

The UX department developed these materials:

Three posters with deliverables by System Analysts, Information Architects, Visual Designers

StUX promotion materials (2/2)

A poster of the Deliverables Diagram

StUX Impact & Future

EzGov organizational chart (zoomed in) Information Architects Visual Designers Solutions Engineering Delivery Mgmt. Quality Assurance Systems Analysts Service Delivery User Experience

StUX impact

UX Department

speak the same language

develop consistent deliverables

have access to examples

Delivery Managers, Solutions Engineers, QA-people

use consistent deliverables

know what to expect in new projects

begin to speak our language

Sales, Management

see our posters, are getting curious

begin to speak (but abuse) our language

use sample deliverables & process in pitch materials

StUX future

UX Department

improve templates from examples

develop metrics & measure

improve estimates based on measurements

Delivery Managers, Solutions Engineers, QA-people

speak our language

improve our deliverables

link processes together

Sales, Management

stop abusing our language

develop business cases for UX

use UX as differentiator

Lessons Learned

What can you do?

Don’t copy our diagram/deliverables the value is in creating your own, with your people

Set up your own standards team a few motivated people with some spare time is all it takes

This should scale up & down the only limitation is paper size, and that can be fixed by taping pieces together

It will take time brainstorming, consolidating, documenting, deciding on name conventions, endless tweaking to make it clear, promotion, etc.

Others have done it before

In-house:

AOL/Netscape (USA)

PeopleSoft (USA)

Nose (Switzerland)

Rabobank (The Netherlands)

Brooks Automation (USA)

Consultants:

Satama (Finland)

IconProcess (USA)

Cooper (USA)

Tools:

Stencils for UCD activities and deliverables

AOL/Netscape

Specified relationships between deliverables, as well as conventions (styleguides) for deliverables.

http://www.leacock.com/deliverables/

PeopleSoft

http://www.visualvocab.com/projects/peoplesoftuescm.html

Nose

Document with high-level overview for customers. Interpretation of RUP.

http://www43.nose.ch/nose/ref_portfolio.php?id=3

Rabobank (no, not Rob-a-bank)

Just started working with standardized list of deliverables, selecting a set for each project. Gathering examples, mapping to both RUP and SDM methods. thanks to Joris van Gaal

Brooks Automation Inc.

Standard Operating Procedures specified in document “Usability in Software Projects”. Described roles, tasks, outputs and high-level metrics. Based on Agile/XP approach.

thanks to Bruce Brolsma

Satama

Extra Phase, extra role. Booklet with all deliverables. Training materials. Intranet with templates and examples for deliverables. (disclaimer: I managed the development of this at Satama at some point)

http://www.satama.com/english/index/How_we_do_it/Basis_of_operations/Process.html

IconProcess.com

Cooper http://www.cooper.com/content/why_cooper/the_process.asp

Tool: Omnigraffe stencils for UCD

“ These two stencils were created to help communicate user-centered design activities and proposals to clients and development teams.” thanks to Todd Zazelenchuk and Elizabeth Boling

Summary

What can you do?