Rich User Experience Documentation - Update


Published on

Presentation to Chicago Interactive Design and Development Meetup, 17 Nov. 2009.

Published in: Design, Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Offices in Chicago, New York, and Boston Founded in 2000.
  • This is the “shock and awe” slide where we show you all our impressive clients.
  • This change is partially about time (we couldn’t do all this stuff before). But also about project type (there’s still a place for more static or content-based sites). So that stuff is a challenge to document.
  • The output of this can be surprise. How do the stakeholders know what they’re going to get? The visibility is much better in the first version. Not so say surprises are always bad, but we prefer to surprise our clients by giving them more than they expected—not something different than they expected.
  • From a recent “medium” sized project. Despite appearances, we do have some women at our company.
  • The term “concept map” is used to cover a wide variety of visuals.
  • These concept maps were used to discuss the “identity” of the site, i.e., what aspects should be prioritized over others. (They all have the same “buckets.”) There were three of these.
  • This one is almost a user flow—except that the stops don’t really represent screens. These two large blue ovals represent the two main consumer mindsets (determined via user research).
  • This gets a little more concrete. We wanted to talk about a strategy of starting from the “core” of the site—rather than top down information architecture. However, we’re still not really talking about the actual structure.
  • This map was part of the early design for a medical association application. We wanted to show how a physician would both use—and be the subject—the site, at various levels of access.
  • This is the most structural of the examples. It was important to establish because this company had a history of creating “microsites” that don’t fit cohesively in with the rest of the site. The most important issue was how the holiday content—which is transient—fits in with the permanent parts of the site.
  • Clients are already itching to see what the site will look like. So why do we keep holding back?
  • Despite some recent talk about the death of wireframes, they’re still at the core of our design documentation. But…
  • Some of our pre-eminent experts have identified the fact that wireframing is not easy to do for more interactive applications. Before we get too far into that subject, let’s take a step back and talk a little about what wireframes are.
  • This is the speech that we’ve been giving our clients for years. The first question is still “do the links have to be blue?” or “can our logo be bigger?” It’s funny, but it illustrates the challenge: Wireframes have the same challenge as other deliverables, in that there’s still quite a bit of abstraction compared to the final product.
  • This is a wireframe from a project I worked on six or eight years ago, in the pharmaceutical world. Pretty basic stuff.
  • And here’s the finished site. Notice anything? No surprises. (Again, these kinds of sites still exist and are completely valid for certain products.) That’s a pretty extreme example—it’s a content-only site.
  • Here’s another example, on a page that actually has a decent amount of functionality.
  • We have a technical name for this in the business…
  • We have a technical name for this in the business…
  • (Those are my kids.)
  • Starting with a fairly simple example… We wanted to show an area that was highly variable depending on user interaction. (I want you to try to remember these examples, because we’re going to see how they ended up later)
  • We used color to code the different areas and assist the viewer. (No, the design won’t be pink.)
  • Back to Zeldman—this is the rest of the quote.
  • Here’s an example of a wireframe from a mobile phone manufacturer’s site. Based on our user research, we determined that different users research phones according to different criteria. So we decided to let them browse in multiple ways, without a dominant taxonomy. So we took this area…
  • In this situation, we think of different parts of the site as modular. We first show the big picture, then dissect out the pieces we need to show in detail. This set of illustrations would be accompanied by its own annotations. Then later on, we did the same with the other parts of the interface.
  • A couple more examples… In this example from an online banking system, the user choice can cascade down to additional states.
  • I mentioned before that I was trained as a medical illustrator. This technique is not unlike what you see all the time in medical illustration. Now I’ve justified my master’s degree by showing you that.
  • Here’s an example where a lot can happen within a single page. Traditionally, all of these states may have been treated as separate pages.
  • And a similar issue here—again from banking—where we have lots of overlays, which themselves can have multiple states. On subsequent pages of the document, we’d treat each of these modules separately and describe how they work. But this is a good orientation view, so that the context isn’t lost entirely.
  • A few other notes about wireframes. Some of these aren’t specific to RIAs—just good procedures to follow.
  • Visual design is where many stakeholders really “get it.” Everyone knows what a design comp is, so I just want to talk a little about their role in a richer documentation process. We can’t hire print designers.
  • Visual design is where many stakeholders really “get it.”
  • Sometimes the comps are treated similarly to wireframes, in that many “states” need to be shown to explain how it will work—both to stakeholders and developers.
  • Sometimes, the wireframes don’t really give stakeholder the confidence that we’re going in the right direction. Visual design is where many stakeholders really “get it.” This program is very functionality-heavy (even though this page is not) so we wanted to use this page to set up the program.
  • Here’s what the wireframe looked like. While we had diagrammed out the experience in the wireframes, a lot of the interest in this page had to do with the way the interface responds to the user–as well as trying to carry the emotional element over to a very powerful search/browse tool.
  • While we had diagrammed out the experience in the wireframes, a lot of the interest in this page had to do with the way the interface responds to the user. Still though, you don’t get the true interaction. We’ll talk more about that in a minute.
  • Once you select a family, you can see their whole story and their Wish List. This is a best-case scenario. During the comping process, we needed to explore other scenarios—no photo, a shorter story, longer and shorter wish lists, etc. In some projects, e.g., a banking application, one you’ve seen one screen you get it. In others, there’s a lot more variation.
  • Prototypes can jump in when our other documentation techniques can’t pull through.
  • This was stolen from Fred Beecher. It shows that there are lots of varieties of prototypes. The “right” kind to do obviously depends on your goals. User research? Showing a develop how to do it? Getting client approval? In our company there’s a lot of variation too. But we tend to do small proofs of concepts. These let us see if a certain approach is feasible in two ways: technically and usability-wise. Sometimes we CAN do it a certain way, but that doesn’t mean we SHOULD.
  • Here’s how we use prototypes, most often. Let’s look at a couple examples.
  • Just a couple more examples that are more at the extreme end.
  • UID: FastUser PWD: FastPass
  • The Avis iPhone app was an interesting case in that we sold the “finished product” to the client. So in this case, seeing the real thing—or close to it—was a necessary part of the process. This is built in to the iPhone experience—using it is a lot of the impact. I don’t imagine there was a lot of wireframing at Apple.
  • Rich User Experience Documentation - Update

    1. 1. Rich User Experience Documentation John Yesko
    2. 2. About Roundarch <ul><li>Roundarch is a specialized consultancy focused on designing and building websites and applications for the world’s largest organizations. </li></ul><ul><li>Key Facts </li></ul><ul><li>We serve mainly Fortune 500 and large government organizations. </li></ul><ul><li>We specialize in balancing user centered design with enterprise class technology to ensure our solutions are easy to use. </li></ul><ul><li>We are a recognized leader in developing rich internet applications (RIAs). </li></ul>200 employees in 3 offices
    3. 3. Select Engagements Strategy, design and implementation for prime brokerage portal; Global Wealth Management web strategy and design; Design & development of Stock Plan Services site and next generation Financial Advisor desktop. Design and development of the 2008 and 2009 Holiday campaigns, as well as ongoing gift-giving related initiatives. Design and implementation of the next generation AVIS site. Includes research, persona development, design, user testing, technical architecture, SEO and implementation. Redesign of Motorola’s B2B and B2C sites; global content management strategy. Currently developing a rich internet application for phone diagnosis and repair. Implementation of the and development of a rich timeline with a focus on driving more broadband content usage and broadband advertising. Development of an interactive marketing platform and redesigned website ( and several brand sites) including the development of a promotion platform.
    4. 4. Selected Clients Financial Services Government Consumer Manufacturing Healthcare/ Transportation Media & Communications
    5. 5. About Me <ul><li>Now </li></ul><ul><li>User Experience Lead at Roundarch </li></ul><ul><li>Responsible for user experience design on large-scale Web projects </li></ul>1993 Web Designer 1995 2000 2005 2010 Information Architect / UX Designer Medical Illustrator My Background Web!
    6. 6. The Premise
    7. 7. User Experience Shift Page-based Paradigm Static Websites (content) Dynamic Websites (content + applications) Rich Internet Applications and “2.0” Paradigm Shift Roughly one event or content topic per page More complex interactions Motion and transitions Dynamic content (e.g., user-generated) Single state per page RIA Paradigm Multiple states per page
    8. 8. User Experience Design Shift Information architecture / interaction design Final product Visual design and production Final product All kinds of surprises Then Now Visibility: Good Visibility: ? Information architecture / interaction design
    9. 9. User Experience Design Shift <ul><li>More collaborative / simultaneous design processes (less sequential) </li></ul><ul><ul><li>Information architecture >> interaction design >> visual design >> production no longer works </li></ul></ul><ul><li>Longer conceptual / ideation process </li></ul><ul><ul><li>More time establishing the foundation before we start making magic </li></ul></ul><ul><li>Expanded team </li></ul><ul><ul><li>And / or more experienced team </li></ul></ul>
    10. 10. Typical Team Chris Account management Karl Project management John User experience / IA Gary Technical lead Zach Visual design Rob Visual design Chris HTML / front-end Shailesh Development “ Brazilians” Development (3) Ted Copywriting (1) Unit One Nine Game animation (2) External Resources Scott Creative direction
    11. 11. Documentation Practices
    12. 12. Why Does Documentation Matter? <ul><li>Clients need to understand what they’re getting </li></ul><ul><ul><li>Level of trust varies </li></ul></ul><ul><li>Designers and developers need to know what to create </li></ul><ul><ul><li>Level of accessibility and control varies </li></ul></ul>
    13. 13. This is… <ul><li>A discussion about a couple types of deliverables that we use </li></ul><ul><ul><li>Why we use it </li></ul></ul><ul><ul><li>What makes a good one </li></ul></ul><ul><ul><li>Why it’s key for Rich Internet Applications (RIAs) / “2.0” sites </li></ul></ul><ul><ul><li>Limitations and challenges </li></ul></ul><ul><li>Lots of visual examples </li></ul>
    14. 14. This is not … <ul><li>A comprehensive discussion of every documentation technique in existence </li></ul><ul><li>The whole process (I’m skipping several steps) </li></ul><ul><li>About tools </li></ul><ul><li>The only way to do things </li></ul>
    15. 15. Concept Map
    16. 16. Concept Map / Model <ul><li>Big picture approach </li></ul><ul><li>Relationships between ideas or concepts </li></ul><ul><li>Intended to generate more discussion, and gain early consensus </li></ul><ul><li>Not usually a “final” design document </li></ul><ul><li>Wide variance in level of detail </li></ul>
    17. 17. Concept Map
    18. 18. Concept Map
    19. 19. Concept Map
    20. 20. Concept Map
    21. 21. Concept Map
    22. 22. Concept Map – In Practice <ul><li>Good opportunity to illustrate the “core” of the experience </li></ul><ul><ul><li>Get away from “top-down” approach </li></ul></ul><ul><li>Requires information design / illustration skills </li></ul><ul><li>Need to keep it (somewhat) simple </li></ul><ul><li>Some audiences have a hard time understanding how it turns into a site </li></ul><ul><ul><li>“ What am I agreeing to?” </li></ul></ul>
    23. 23. Concept Map – Why? <ul><li>Leap from start to finish is much bigger. </li></ul><ul><ul><li>so… </li></ul></ul><ul><li>We establish our approach early on, so there aren’t as many surprises. </li></ul>User experience design Final product Better visibility Fewer surprises
    24. 24. Wireframes
    25. 25. Wireframes <ul><li>Still the core method of documentation </li></ul><ul><ul><li>We spend the bulk of our time on them </li></ul></ul><ul><li>Relative Time Spent on UX Deliverables </li></ul><ul><li>(Pre-visual design) </li></ul>UX Brief Concept Map (s) Site Map Wireframes <ul><ul><li>High-level requirements </li></ul></ul><ul><ul><li>User research results </li></ul></ul><ul><ul><li>Personas and scenarios </li></ul></ul><ul><ul><li>User flows </li></ul></ul><ul><ul><li>Organizing principles </li></ul></ul>
    26. 26. Wireframes <ul><li>&quot;Wireframing AJAX is a bitch.” </li></ul>Jeffrey Zeldman Happy Cog & A List Apart
    27. 27. The Wireframe Speech <ul><li>Wireframes do… </li></ul><ul><ul><li>Show relative prioritization of elements </li></ul></ul><ul><ul><li>Suggest grouping / relationships between elements </li></ul></ul><ul><ul><li>Document labeling (but probably not final content) </li></ul></ul><ul><ul><li>Show functionality </li></ul></ul><ul><li>Wireframes do not… </li></ul><ul><ul><li>Suggest creative / visual design </li></ul></ul><ul><ul><li>Show precise layout </li></ul></ul><ul><ul><ul><li>Tell you what’s above the fold </li></ul></ul></ul><ul><ul><li>Illustrate transitions, motion, etc. </li></ul></ul><ul><li>Just the right amount of “design” </li></ul><ul><ul><li>Not confused with visual design </li></ul></ul><ul><ul><li>But it looks good and sets some expectations on general layout </li></ul></ul>
    28. 34. <ul><li>“ Coloring in wireframes” </li></ul>
    29. 35. Wireframes – In Practice <ul><li>How have our wireframes changed? </li></ul><ul><li>Illustration techniques to document interactions: </li></ul><ul><li>Color </li></ul><ul><li>Multiple states </li></ul><ul><li>Exploded views </li></ul><ul><li>Interaction sequences </li></ul>
    30. 38. Wireframes <ul><li>&quot;Wireframing AJAX is a bitch. </li></ul><ul><li>The best our agency has come up with is the Chuck Jones approach: draw the key frames. </li></ul><ul><li>[But] Chuck Jones had an advantage: he knew what Bugs Bunny was going to do. We have to determine all the things a user might do, and wireframe the blessed moments of each possibility.&quot; </li></ul>Jeffrey Zeldman Happy Cog & A List Apart
    31. 42. Wireframes
    32. 45. Wireframes – In Practice <ul><li>Real vs. fake data </li></ul><ul><ul><li>Use both </li></ul></ul><ul><ul><li>Important for comping / prototyping </li></ul></ul><ul><ul><li>Heads off questions from the client </li></ul></ul><ul><li>Establish visual language / patterns to use consistently </li></ul><ul><li>Don’t try to document things that can’t be documented well </li></ul><ul><ul><li>Transitions / motion </li></ul></ul><ul><ul><li>Precise mouse interactions </li></ul></ul><ul><ul><li>Visual / creative design </li></ul></ul>
    33. 46. Visual Design
    34. 47. Visual Design <ul><li>More important to the user experience design process than ever </li></ul><ul><li>Brought in earlier </li></ul><ul><li>Work more closely with both UX and development </li></ul><ul><ul><li>Inseparable from both </li></ul></ul><ul><ul><li>Designers need to understand other disciplines </li></ul></ul>
    35. 48. Design Comps <ul><li>Establish creative look and feel </li></ul><ul><li>Communicate brand </li></ul>
    36. 53. Design Comps – In Practice <ul><li>Communicate emotional element </li></ul><ul><li>Extend interaction design documentation (beyond wireframes) </li></ul><ul><li>Anticipate user-generated content </li></ul><ul><li>Prominence depends on type of project </li></ul>
    37. 58. Design Comps – In Practice <ul><li>Same challenges as other types of UX documentation </li></ul><ul><li>Motion / transitions </li></ul><ul><li>Multiple states </li></ul><ul><li>Dynamic content </li></ul><ul><li>But one step closer in fidelity… </li></ul>
    38. 59. Prototypes
    39. 60. Prototypes Visual Fidelity Functional Fidelity Paper wireframe prototype Page sketches Image mapped sketch scans Clickable wireframes Paper JPEG prototype (comps) Image mapped JPEGs (“slap & map”) Graphically “skinned” interactive prototype Interactive wireframe prototype Production-ready prototype “ The Dimensions of Fidelity” Fred Beecher, Evantage Consulting Proof of concept
    40. 61. Prototypes - In Practice <ul><li>Fill in where previous deliverables fall short </li></ul><ul><li>Can act as internal proof of concept </li></ul><ul><ul><li>Technical feasibility </li></ul></ul><ul><ul><li>Usability </li></ul></ul><ul><li>Can be leveraged for user research </li></ul><ul><li>May or may not be throw-away </li></ul><ul><li>Examples… </li></ul>
    41. 62. Prototypes - In Practice <ul><li>Expanded team may be necessary </li></ul><ul><ul><li>More work for everyone </li></ul></ul><ul><li>In user research, need to determine how much role fidelity plays </li></ul><ul><li>Need to decide if the wireframe or prototype is the document “of record” </li></ul><ul><ul><li>Prototypes are better at communicating than documenting </li></ul></ul><ul><ul><ul><li>“ Design Tool” vs. “Deliverable” </li></ul></ul></ul>
    42. 64. <ul><li>Avis Car Reservation iPhone App </li></ul>
    43. 65. More About Documentation <ul><li>Book: Communicating Design by Dan Brown, EightShapes </li></ul><ul><li>IxDA Discussion Board </li></ul><ul><li>UIE Podcast: “Roughing it with Interactive Prototypes” </li></ul>
    44. 66. <ul><li>John Yesko </li></ul><ul><li> </li></ul><ul><li>[email_address] </li></ul><ul><li>Twitter: @jyesko </li></ul>Thank You Roundarch [email_address]