Rich User Experience Documentation - Update
•Descargar como PPT, PDF•
31 recomendaciones•1,942 vistas
Presentation to Chicago Interactive Design and Development Meetup, 17 Nov. 2009.
![About Roundarch ,[object Object],[object Object],[object Object],[object Object],[object Object],200 employees in 3 offices](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Destacado
Destacado (16)
Similar a Rich User Experience Documentation - Update
Similar a Rich User Experience Documentation - Update (20)
Último
Último (20)
Rich User Experience Documentation - Update
- 1. Rich User Experience Documentation John Yesko
- 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 historychannel.com 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 (Hersheys.com and several brand sites) including the development of a promotion platform.
- 4. Selected Clients Financial Services Government Consumer Manufacturing Healthcare/ Transportation Media & Communications
- 6. The Premise
- 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. 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
- 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
- 15. Concept Map
- 17. Concept Map
- 18. Concept Map
- 19. Concept Map
- 20. Concept Map
- 21. Concept Map
- 24. Wireframes
- 42. Wireframes
- 46. Visual Design
- 59. Prototypes
- 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
Notas del editor
- 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.