• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Rich User Experience Documentation - Update

Rich User Experience Documentation - Update



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

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



Total Views
Views on SlideShare
Embed Views



5 Embeds 155

http://wunderlandgroup.com 98
http://www.wunderlandgroup.com 35
http://www.slideshare.net 17
http://www.linkedin.com 3
http://www.e-presentations.us 2


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.


11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Why did you remove the UX brief?
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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 Rich User Experience Documentation - Update Presentation Transcript