Rich User Experience Documentation John Yesko

1. Rich User Experience DocumentationJohn Yesko

2. Background

3. About Me Background • Trained as designer and illustrator (pre-Web) • Began designing interactive applications in 1993 • Evolved from Web designer to information architect Now • User Experience Lead at Roundarch • Manage information architecture and user experience design for large-scale corporate sites

4. Client Sampling

5. About Roundarch Roundarch is a specialized consultancy focused on designing and building web sites and applications for the world’s largest organizations. Key Facts • We serve mainly Fortune 500 and large government organizations • We specialize in balancing user centered design with enterprise class technology to ensure our solutions are easy to use, a joy to use and highly scalable • This synergy of user experience design and technology has made us a recognized leader in developing rich internet applications and we have 20+ RIA projects on-going Key Figures • Founded in 2000 • Approximately 150 employees (and looking for more good ones) • Offices: New York, Chicago, Boston

6. Setup

7. User Experience Shift Single Page / “Stateless” / RIA Paradigm Page-based Paradigm Single state per page Paradigm Shift Multiple states per page (Roughly 1 event or content topic per page) Multiple events or content topics in one place Transitions and motion are more important DynamicWebsites (content + applications) StaticWebsites (content) Rich Internet Applications and “2.0”

8. Documentation Challenges of the New Paradigm • More complex interactions (e.g., motion, transitions, multiple states) • More dynamic content (e.g., user generated) • More collaborative / simultaneous design processes (less sequential) • Information architecture >> interaction design >> visual design >> productionno longer ideal • Longer conceptual / ideational process • More time establishing the foundation before we start making magic • Expanded team • And / or more experienced team

9. Why Does Documentation Matter? • Clients need to understand what they’re getting • Level of trust varies • Designers and developers need to know what to create • Level of accessibility and control varies

10. Outline of this Session • Talk about each key deliverable we use • Why we use it • What makes a good one • How it has changed with Rich Internet Applications (RIAs) • Limitations and challenges • Please interrupt with questions and your own experiences • Examples!

11. This Session Is Not… • a comprehensive discussion of every documentation technique in existence • about tools • about user research

12. Documentation Techniques

13. User Experience Brief • Early-stage strategic approach document • Summarizes what we know so far • Output of Discovery process • Used to gather consensus • May include: • Requirements • User research results • Personas / scenarios • Concept map (more later) • User flows (more later) • Organizing principles • Varies in length depending on needs

14. Concept Map / Model • Big picture approach • Relationships between ideas or concepts • Intended to generate discussion and gain consensus • Not usually a “final” design document • Good opportunity to illustrate the “core” of the experience (instead of top-down)

15. Concept Map – In Practice • Requires information design / illustration skills • Need to keep it (somewhat) simple • Some audiences have a hard time understanding how it turns into a site • “What am I agreeing to?”

16. Considerations for RIAs / Web 2.0 User Experience Brief, Concept Map • Leaps from deliverable to deliverable are bigger • Establish an approach so there aren’t as many surprises in each leap

17. Site Map • Establish scope • Make sure we’re not missing anything • Discuss “permanence” of labels at this stage

18. Site Map – In Practice • Multiple formats • Not very different for RIAs / 2.0 applications • Still a core deliverable

19. Wireframes • Still the core method of documentation • We spend the bulk of our time on them • Multiple options of complexitywireframes >> annotated wireframes >> user interface specification (“functional spec”) • Role of wireframes changes depending on context • Other deliverables, e.g., prototype • Accessibility of other disciplines (visual design, development)

20. Relative Time Spent on Each Deliverable

21. Wireframes – In Practice • Wireframes do… • show relative prioritization of elements • suggest grouping / relationships between elements • document labeling (but probably not final content) • show functionality • Wireframes do not… • Suggest creative / visual design • Show precise layout • Tell you what’s above the fold • Just the right amount of “design” • Not confused with visual design • But it looks good and sets some expectations on general layout

22. Wireframes – In Practice • Real vs. fake data • Use both • Important for comping / prototyping • Illustration techniques to document design • Color • Multiple states • Exploded views • Interaction sequences • Establish visual language / patterns to use consistently • Use of humor / personal touches – keep the audience involved

23. Considerations for RIAs / Web 2.0 Wireframes • Move in and out of “page” view to show key interactions • Don’t try to document things that can’t be documented well • Transitions / motion • Precise mouse interactions • Use prototypes / demos to fill the gaps in wireframes (next topic) • The gaps can be bigger if a prototype exists too

24. Design Comps • Establish creative look and feel • Communicate brand • Same challenges as UX documentation • Motion / transitions • Multiple states • Dynamic content

29. Prototype / Proof of Concept • Take visual design to the next level • Can act as internal proof of concept • Technical feasibility • Usability • May or may not be throw-away • Can be leveraged for user research • Need to decide if the wireframe or prototype is the document “of record”

30. References • Book: Communicating Design by Dan Brown • Yahoo Design Pattern Library developer.yahoo.com/ypatterns/