StUX - IA Summit 2005 - Peter Boersma

  • 6,367 views
Uploaded on

Presentation delivered at the 2005 IA Summit on StUX (Standards for User Experience), an addition to RUP developed by the author at EzGov.

Presentation delivered at the 2005 IA Summit on StUX (Standards for User Experience), an addition to RUP developed by the author at EzGov.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
6,367
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
0
Likes
27

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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 ).
  • 3. 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
  • 4. 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
  • 5. EzGov organizational chart User Experience Solutions Engineering Quality Assurance Product Mgmt. Sales & Marketing People & Finance Delivery Mgmt. Mgmt. Team Service Delivery
  • 6. 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
  • 7. UX department responsibilities
    • The User Experience department works on:
    • Requirements Gathering
    • Content Analysis
    • Information Architecture
    • Interaction Design
    • Information Design
    • Visual Design
    • Usability Evaluation
  • 8. EzGov uses Rational Unified Process (RUP)
  • 9. 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 .
  • 10. RUP isn’t enough
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. EzGov’s Fix: StUX
  • 15. 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)
  • 16. StUX = deliverables diagram and descriptions
  • 17. 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)
  • 18. StUX deliverables diagram (2/3)
    • Integrates standard RUP artifacts with EzGov UX artifacts
  • 19. StUX deliverables diagram (3/3)
    • 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
  • 20. StUX = deliverables diagram and descriptions
  • 21. 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
  • 22. 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.
  • 23. Introducing StUX to the company
  • 24. 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
  • 25. StUX promotion materials (1/2)
    • The UX department developed these materials:
    • Three posters with deliverables by System Analysts, Information Architects, Visual Designers
  • 26. StUX promotion materials (2/2)
    • A poster of the Deliverables Diagram
  • 27. StUX Impact & Future
  • 28. EzGov organizational chart (zoomed in) Information Architects Visual Designers Solutions Engineering Delivery Mgmt. Quality Assurance Systems Analysts Service Delivery User Experience
  • 29. 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
  • 30. 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
  • 31. Lessons Learned
  • 32. 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.
  • 33. 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
  • 34. AOL/Netscape
    • Specified relationships between deliverables, as well as conventions (styleguides) for deliverables.
    http://www.leacock.com/deliverables/
  • 35. PeopleSoft
    • http://www.visualvocab.com/projects/peoplesoftuescm.html
  • 36. Nose
    • Document with high-level overview for customers. Interpretation of RUP.
    http://www43.nose.ch/nose/ref_portfolio.php?id=3
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. IconProcess.com
  • 41. Cooper http://www.cooper.com/content/why_cooper/the_process.asp
  • 42. 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
  • 43. Summary
  • 44. StUX = deliverables diagram and descriptions
  • 45. 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 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.
  • 46. Questions?
    • Peter Boersma Senior Information Architect EzGov De Schinkel Rijnsburgstraat 11 1059 AT Amsterdam [email_address] http://www.peterboersma.com