Rich User Experience Documentation - Update
âąAls PPT, PDF herunterladenâą
31 gefĂ€llt mirâą1,942 views
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)
Empfohlen
Empfohlen
Weitere Àhnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (16)
Ăhnlich wie Rich User Experience Documentation - Update
Ăhnlich wie Rich User Experience Documentation - Update (20)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (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
- 28. Â
- 29. Â
- 30. Â
- 31. Â
- 32. Â
- 33. Â
- 36. Â
- 37. Â
- 39. Â
- 40. Â
- 41. Â
- 42. Wireframes
- 43. Â
- 44. Â
- 46. Visual Design
- 49. Â
- 50. Â
- 51. Â
- 52. Â
- 54. Â
- 55. Â
- 56. Â
- 57. Â
- 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
- 63. Â
Hinweis der Redaktion
- 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.