User Experience from a Business Perspective
•Transferir como PPTX, PDF•
2 gostaram•883 visualizações
Presentation at CMSExpo, May 2012
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (9)
Destaque
Destaque (20)
Semelhante a User Experience from a Business Perspective
Semelhante a User Experience from a Business Perspective (20)
Último
Último (20)
User Experience from a Business Perspective
- 1. User Experience (UX) from a Business Perspective Daniel Mittleman danny@cdm.depaul.edu College of Computing and Digital Media Hi !
- 2. The Issues • Web CMS texts gloss over planning process for a site-- and jump right into design • But good UX is dependent on a strong user-centric planning process • How do we do this if we are planning for a CMS solution?
- 3. A Solution • Apply user-centric UX planning and analysis concepts to CMS site projects.
- 4. CMS Development Process Steps in the UX Life Cycle • Emphasis on PROBLEM SOLVING • Emphasis on CONTENT • Emphasis on USER EXPERIENCE
- 5. 1 Understand the business problem • What is the business objective of the site. • What is the business problem that your client is trying to solve? – Or is it an opportunity?
- 6. 2 Know your Users • Who are you designing for? – categorize your users • Think about – demographics (age, exp., sex, etc.) – technographics (platforms and skills) – psychographics (behaviors &attitudes) • Create personas.
- 7. 2 How to create a persona? 1. Gather background info – demo- techno- psycho- graphics – referent site information 2. Interview your users 3. Compile and organize research to isolate key target markets 4. Write fiction:
- 8. 3 Interview your users • Or survey them (if need be) – Understand their motivations – Understand their behaviors – Understand their frustrations – Learn their "stories" from them. – Use group techniques with them • Focus group sessions • Mood sessions • Card sort session.
- 9. Example Persona Name Key Feature Descriptive Information Scenario Trigger
- 10. Example Persona Name & Key Feature Quote, from Research Concerns Descriptive Information Objectives & Motivation Behaviors
- 11. 4 Capture your user stories • What do your users want to do on your site? • How will they go about doing those things • Tell complete user stories • Tell as many as you need to tell.
- 12. 4 How to create user stories? • Group exercise: have users put stories on cards • Make personas the voice of the story • Be sure to include "so thats" As a <role>, I want <function>, so that <value> • I.N.V.E.S.T Independent, Negotiable, Valuable, Estimable, Small, Testable.
- 13. 4 How do you create User Stories? • Card • Conversation • Confirmation 13
- 14. 14 http://www.mind-mapping.org/blog/2010/09/edistorm-for-brainstorming/ http://www.edistorm.com/
- 15. 15 From http://www.agile-ux.com/2012/03/01/user-story-checklist-be-ready-be-effective/
- 16. 4 Some User Story Resources • http://www.agile-ux.com/tag/user-stories/ • How to write meaningful user stories http://www.subcide.com/articles/how-to-write-meaningful-user- stories/ Nice first introduction to user stories. • How to Create User Stories http://techportal.ibuildings.com/2011/07/19/how-to-create-user- stories/ Another similar introduction written more for agile coders. • The User Experience (UX) of User Stories (part 1) http://www.andersramsay.com/2011/07/16/the-ux-of-user-stories- part-1 Expands on ideas above • User Story Example http://www.allaboutagile.com/user-story-example/ Capturing more info on backs of cards • Better User Stories http://mindtheproduct.com/2012/02/better-user-stories-come-hell-or- high-waterfall/ This post discusses process a bit, focusing on tips and tricks for getting better results from your interviews with users. 16
- 17. 5 Research referent sites • Look at referent sites • Look at competitor sites • Look at sites for ideas – Look for best practices – Look for recurring patterns – Look to see how they addressed similar user stories • Reverse engineer their user stories and personas. 17
- 18. 5 Research wisdom • Test the users you want, not the users you have • Users give you conflicting feedback • Validate the problem you are solving actually exists • Verify your mental models • Prototype early • Plan through version two (or three). 18 http://uxmag.com/articles/five-ux-research-pitfalls
- 19. 6 Develop a Content Strategy • Explore content issues early in the process. – card sorting • Do the users want to see the information grouped by subject, process, business group, or information type? • How similar are the needs of the different user groups? • How different are their needs? • How many potential main categories are there? (typically relates to navigation) • What should those groups be called? 19
- 20. 6 Card Sorting resources Some card sorting resources: Great Primer on the details of card sorting http://www.usability.gov/methods/design_site/cardsort.html This one lists several online card sorting products http://www.measuringux.com/CardSorting/ More resources with rich detail http://sixrevisions.com/usabilityaccessibility/card-sorting/ http://www.boxesandarrows.com/view/card_sorting_a_definitive_guide 20
- 21. Conduct a content audit & 7 determine content strategy • Use audit to understand content properties and relationships. • Understand cognitive mapping of users • Understand how content relates to user stories or user communities. 21
- 22. 7 How to conduct a content audit ? • If you already have a site or content: – Inventory content page • Is all of this content still relevant? What business, customer, or employee need does it support? • What new content must be created? What is driving those needs? • What drove decisions about file types and/or variations in format that exist? Do these decisions still hold? – Look at site traffic by content type/item – Use this to provoke useful discussion with stakeholders. 22
- 23. 7 Results of a good content audit ? • Acute awareness of site priorities • Increased understanding of business or operational constraints • Surfacing of a common language • A accurate sense of scale for the project. 23
- 24. 7 How to conduct a content audit ? • If your context is new: – Build process flow diagrams to ID data and workflow of systems users • Document input and output content – Refer to your user stories • Look at what data they need to complete their user stories successfully – Look at referent sites and deconstruct their content. 24
- 25. 8 Create a Site Map • Consider vertical, horizontal, or sequential layouts • Design site map offline 25
- 26. 8 CMS's don't generate separate pages! • OK, so this is a trick question • We do need to think through our menuing scheme • We do need to logically cluster categories/sub-categories • We do need to deal with any "special" pages outside main content • We do need to think through our "tag" scheme • And we want to think through module/widget/block assignments 26 Nice sitemap primer: http://viget.com/inspire/ux-101-the-site-map
- 27. 8 Site Map with template information 27 http://www.advomatic.com/blogs/julie-blitzer/why-non-profits-need-user-experience-design-ux
- 28. 9 Build a Wire Frame • On paper, line drawings, black and white; or try a tool like mockflow.com • Conceptual, void of design artifacts • Note we haven’t built anything yet! 28
- 29. 29 http://speckyboy.com/2011/05/29/20-effective-examples-of-web-and-mobile-wireframe-sketches/
- 30. 9 How to create a Wire Frame • Use your previous research to inform this model • Understand relative importance of information • Group items by user story, by content type, or by relative importance • Use accepted design patterns. 30
- 31. Heat Map 31
- 32. Heat Map 32
- 33. 10 Research design patterns • Read best practice design patterns for site design constructs you are building • Select, modify if necessary, and apply these patterns. – http://www.smashingmagazine.com/2009/ 06/15/40-helpful-resources-on-user- interface-design-patterns/ – http://uxmovement.com/resources/4-best- design-pattern-libraries/ – http://www.briankenyon.com/content/ui- ux-design-pattern-repositories 33
- 34. 11 Design Pattern Books • My favorite pattern references: • Van Duyne, Landay, Hong: The Design of Sites (on Safari) • Schummer, Lukosch: Patterns for Computer-Mediated Interaction • Vora: Web Application Design Patterns (on Books24x7) 34
- 35. 12 Test early concepts on users • In real world, this is key • Validate your analysis • Then validate your logical design • Test against legacy system (if possible) • Test with real users (if possible) • Now you are ready to start building 35
- 36. Daniel Mittleman DePaul University CDM danny@cdm.depaul.edu Office: 312.362.6103 Skype: dmittleman That was fun 36
Notas do Editor
- Daniel Mittleman, Ph.D.Associate ProfessorCollege of Computing and Digital MediaDePaul University243 S. Wabash AveChicago IL 60604312.362.6103Skype: dmittlemandanny@cdm.depaul.eduwww.cdmblogs.net/work30
- Even the biggest and best books, for example: Bob Boiko, Content Management Bible, 2nded, spends just 12 of 1,060 pages on requirements gathering. And his approach is more of a traditional software systems development life cycle (granted he was writing about a decade ago) than current UX thinking.The texts do not prepare you to approach the problem the way modern UX professionals approach it for non-CMS site design.Some of the large firms that do CMS employ such professionals. This talk is for the smaller development firm, the CMS administrator, or the individual consultant who wants to pick up some of these practices, tools, and skills to compete with the big guys.
- This talk focuses on what we, at DePaul CDM, are teaching our graduate Human Computer Interface students about user experience planning and analyis in 2012. I am taking those materials and applying them to the web CMS realm. My own work is mostly in Joomla--so that is where my experience may lie--but you will notice this whole hour we be looking at the project from a point before the particular CMS is specified. All of this work is CMS agnostic.More elegant than anything I will say today, read this comic book:http://uxdesign.smashingmagazine.com/2012/04/23/mental-model-diagrams-cartoon/
- My work stems from the world view that systems analysis is "problem seeking". What we are trying to do at this stage is define the problem we are going to later solve. The logical design phase, which occurs largely after this phase is complete (though in most modern agile methods there is an circular overlap), is when the solution to our defined problem gets explored. You can't solve a problem until you define it!So, in spite of what the slide says, the focus is really on problem definition.And since we are working in a CMS realm, our problem probably has something to do with the curation and delivery of content. Therefore, we need to understand both that content and the consumers (and perhaps producers) of that content.And all of this is explored with a focus on how all of these users (creators, curators, and consumers) are going to experience their interaction with the content.
- I generally break the objective question into two parts: What is the business problem or opportunity we are addressing? This question is at a level above looking at the technology--and the system in question should not be mentioned in the statement of this problem. There is a business (using that term loosely) issue we are being asked to deal with, and we need to understand that business issue. We need clarity; we need agreement among the project owners that this is the business issue; and we may require agreement among key stakeholders (depending upon organizational context.)Once we know what the business issue is, then we can look at the systems goals: what are we trying to accomplish with our information system to address the business goal? Stated another way: what are the technical objectives of the project?As the slide says, the more specific and complete we can establish shared understanding for these two layers of project goal, the more likely we are to deliver a useful and complete solution.
- One we know the problem statement, we are ready to dive in and begin to understand the users. Perhaps the right place to begin is not here, but on my step five: doing research. But for now lets just dive in and think about the users. This slide surfaces three core dimensions to explore.The outcome of our user research process will be the creation of personas.
- Understanding Personas, the comic book (really). You have to read this:http://thinkvitamin.com/design/how-to-understand-your-users-with-personas/Personas are aggregations of our research presented in the form of fictional characters. Each character summarizes the research about a particular subset of systems user. Personas are not averages, rather they are specific representations that provide a vivid picture of what a user in a particular target is like.To acquire the information to create personas we may (depending on budget, time, and other resources): survey users, interview users, observe users, focus group users, and conduct secondary demographic research.The process of developing personas should be a team effort among the full development team. It can be both a fun and informative exercise to use a workshop to create these characters. Then the proto- personas should be presented to representative users for feedback. The live users will be able to validate whether you got the personas right; and this session will likely produce additional in depth information useful to the process.
- In gathering data about users, we are interested not only in demographic information, but what they think and emote while engaging with the system in question. The emotive dimensions will be vital toward deeply understanding what the actual experience of using the site will be like.
- This example is from http://uxsuccess.com/2009/12/01/agile-personas-and-context-scenario/ but if you google "persona examples" and look at images, you will find many more useful and different examples out there. I believe that "Betty" is a persona working at Symantec and the system being designed is an internal social networking system--probably on top of an enterprise CMS platform.
- These two examples are from http://asinthecity.com/2011/05/13/explaining-personas-used-in-ux-design-%E2%80%93-part-2/. I recommend this, and especially part 1 of this article, as a primer about persona creation.
- From personas we move on to develop user stories. User stories are short narratives describing how one user (ideally one of the personas just created) will use functions of the system to achieve one unitary goal. In many ways these stories resemble use cases, a similar tool used in systems design. The difference is that we are going to focus on narrative (rather than flow charts) to tell the story; we are going to make a persona our protagonist actor in the story; and we are going to make sure we have three parts to it: the role the persona is playing; the function(s) the persona will engage; and the goal the persona is trying to attain.A full systems could have dozens to hundreds (perhaps more) user stories.User stories not only help us develop systems requirements and specifications up front, but if well written, they serve as a way to test the system after it is written. We can revisit each user story with the finished system to make sure the system permits successful completion of the story as it was originally envisioned.
- Again, user story creation will be a group exercise. And, to the extent possible, we want to engage end users to be involved in this process. After all, they know their stories the best. So we will want to lead work sessions where we structure and support end users as the write their own stories in the voice of the personas.How do we know whether we have a well written story? INVEST: Is it: Independent (from other stories), Negotiable (not a core function of the system e.g. login), Valuable (on mission), Estimable (do we know the size), Small (unitary, not combined), Testable (can we test for success)See:http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-investhttp://www.agile-ux.com/tag/user-stories/http://www.agileforall.com/2009/05/14/new-to-agile-invest-in-good-user-stories/
- http://xprogramming.com/articles/expcardconversationconfirmation/CardUser stories are written on cards. The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. ConversationThe requirement itself is communicated from customer to analysts through conversation: anexchange of thoughts, opinions, and feelings. ConfirmationNo matter how much discussion or how much documentation we produce, we can’t be as certain as we need to be about what is to be done. The third C in the user story’s key aspects adds confirmation that we sorely need. This component is the acceptance test.At the beginning of the iteration, the customer communicates to the analystswhat she wants, by telling them how she will confirm that they’ve done what is needed. She defines the acceptance tests that will be used to show that the story has been implemented correctly.http://www.jamieclouting.co.uk/2012/01/user-stories-card-conversation-confirmation/
- If you are working virtually, there are now some great tools to support user story creation and development. the screen on this slide is from edistorm.comThey use a yellow sticky metaphor that permits not only the basic "card" information on the front, but more complete "conversation" and "confirmation" information embedded within.They make one stickyboard available for free, so you can try this out without risking any cash. And they are reasonably priced if you dive deep into it.Another product I like a lot is meetingsphere.com. This tool has less of an intuitive interface, but the group process structures are much more sophisticated. You can use MeetingSphere not only for user stories, but for most any step of the UX life cycle that requires user participation. This product comes with a one month free trial, and is also reasonably priced.If you approach the principals at either firm, don't hesitate to drop my name. (I get no cash from either, just merit badges.)
- Fromhttp://www.agile-ux.com/2012/03/01/user-story-checklist-be-ready-be-effective/This is a more complete user story template, if you prefer working with this level of structure.
- 0. How to write meaningful user storieshttp://www.subcide.com/articles/how-to-write-meaningful-user-stories/ Nice first introduction to user stories. At the end he talks about “INVEST” but doesn’t explain it. The next article below does explain it. 1. How to Create User Storieshttp://techportal.ibuildings.com/2011/07/19/how-to-create-user-stories/ Another similar introduction. He references XP (extreme programming). You can gloss over this without losing any meaning. 2. The User Experience (UX) of User Stories (part 1)http://www.andersramsay.com/2011/07/16/the-ux-of-user-stories-part-1 This is a nice place to jump to from above. This guy is clear and expressive about capturing user stories on a card. We will use Edistorm for our cards. He makes reference to the concept of “Personas”. Personas are fictional characters created to represent the users. Personas are nice in that the character can be much richer than an abstract user. His discussion of what to put onto a card and how to make it useful and complete is very important. He discusses story maps—that is where we are going with this when we have all our cards in Edistorm. He has a part 2 to this post, but I think that takes us to a place we don’t need to go right now. 3. User Story Examplehttp://www.allaboutagile.com/user-story-example/ This is a short example of a user story card highlighting how successful and failure outcomes can be spelled out on the back of the card. 4. Better User Storieshttp://mindtheproduct.com/2012/02/better-user-stories-come-hell-or-high-waterfall/ This post discusses process a bit, focusing on tips and tricks for getting better results from your interviews with users.
- I have been alluding to research all along. Let's focus on it here.There are many reasons to be looking at referent sites. There is little excuse for not doing so.A great argument is made here for doing research:http://idyeah.com/blog/2012/04/you-cannot-think-like-thy-users/
- The points on this slide come from http://uxmag.com/articles/five-ux-research-pitfalls.I find this to be good wisdom.Here is a great long blog post on the benefits of UX researchhttp://uxdesign.smashingmagazine.com/2012/01/26/ux-research-plan-stakeholders-love/
- Nice content strategy reference:http://www.uxmatters.com/mt/archives/2009/08/content-analysis-a-practical-approach.php
- Inventory content page by page capturing it and its meta-information (who owns, views, changes it; what it is used for)The key point here is that the audit itself is not as useful as the discussion the results will provoke with your user representatives. That is going to be the real win from this process.
- http://uxmag.com/articles/from-content-audit-to-design-insight
- There are a wide variety of tools you can use for this. Most any graphic tool from PowerPoint on will handle a site map. Pros might use a tool such as Axure as it will share data with their wireframe view and provides a wide variety of high end features (out of my price range so my experience with it is limited.)
- So a good wireframe is much more than a simple tree diagram. A useful wireframe will address all of the relevant issues surfaced on this slide.It may also designate which portions of the site are in phase A, B, and C of the build out. It may also designate workflow issues (editing rights of various user roles). It may also designate content or coding requirements. It may also designate security/access features by page (such as SSL or restricted access).
- You might start here for more reading on the subject:http://www.1stwebdesigner.com/design/beginners-guide-to-wireframes-tools/
- There are several good wireframing tools online, but many pros prefer to draw them by hand.Here is a list of good tools:http://www.onextrapixel.com/2011/03/28/creating-web-design-wireframes-tools-resources-and-best-practices/In addition, Axure.com is a well regarded high end professional tool. And balsamiq.com is a great simple tool that provides cartoon-like mockups.And also here for reference:http://www.noupe.com/design/35-excellent-wireframing-resources.html
- Some notes on eye tracking to generate heat mapshttp://uxmag.com/articles/eye-tracking-the-best-way-to-test-rich-app-usabilityhttp://www.uxbooth.com/blog/usability-testing-dont-guess-test/Image from: http://blog.caplin.com/2011/06/03/the-psychology-of-ux-part-1/
- From http://uxdesign.smashingmagazine.com/2009/09/24/10-useful-usability-findings-and-guidelines/