Table of Contents
In this session we will review the substance behind the hype over User Experience Design (UX Design), discuss the benefits of rapid iteration, and get some quick hands-on experience with some agile methods that help ensure a user-centered design. Exercises will be focused on team projects when possible. Possible methods include Personas, Scenario-Based Design, and User Tests.
This outline is meant to be both brief and approximate. I expect I may need to change plans on the fly and be flexible in how the class progresses
- 5 min - Brief Introductions:
- 15-30 second description of your group's project & where you are at in the design process.
- 15 min - Overview of User Experience (UX) Design
- Who cares about design? Answer: anybody who has ever used a bad design!
- Examples of bad design:
- Now we know what bad design looks like, how do we avoid doing it ourselves? That's what User Experience (UX) Design and related approaches are all about.
From UX Matters:
- User Experience
Comprehends all aspects of digital products and services that users experience directly—and perceive, learn, and use—including products’ form, behavior, and content, but also encompassing users’ broader brand experience and the response that experience evokes in them. Key factors contributing to the quality of users’ experience of products are learnability, usability, usefulness, and aesthetic appeal.
- User Experience (UX) Design
A holistic, multidisciplinary approach to the design of user interfaces for digital products, defining their form, behavior, and content. User experience design integrates interaction design, industrial design, information architecture, information design, visual interface design, user assistance design, and user-centered design, ensuring coherence and consistency across all of these design dimensions.
- Principles of UX design. There is no one singular approach to UX design. However, there are a number of principles that are present in most efforts to do UX design in one way or another. What follows is a partial list:
- Primary focus is on the users. Their needs/wants/desires are most important.
- UX emphasizes a holistic focus that includes the user's experience outside of their use of the particular thing being designed.
- UX is an empirical approach. When in doubt, build it (to some degree of fidelity), and test it out on (real) users.
- UX typically involves rapid iteration of design. Build something quick, test it, rebuild it better, test it, repeat until you get stability. Also known as Rapid Prototyping. The most popular specific method for doing it is Paper Prototyping.
- UX often emphasizes low fidelity (lo-fi) prototypes over high fidelity (hi-fi) prototypes, especially in early phases of the design process. The reasons: (a) lo-fi prototypes are quicker to build and can be iterated faster, (b) lo-fi prototypes typically look sketchy, which empowers users to give feedback because the design looks mutable, it doesn't look like a finished product.
- UX is the most general term for this kind of design at the moment, and also the trendiest term, however there are a lot of related terms. See the glossary for more related concepts.
20 min - Personas Exercise
A design method where designers construct user personas complete with names, pictures, personal information, and personality, in order to simulate the potential users of a particular design. The goal of the personas is to represent various characteristics of actual users in all their peculiarity and imperfection, and thus move away from conceptions of the "generic user" who wants to do anything the designers wish him/her to do. Final personas are best generated by creating many different user personas that together cover all the different characteristics of actual users (typically as discovered through ethnographic research), and then combining them to eliminate redundancy and overlap so that only core personas remain. These personas should be realistic in that they could be and feel like real people, but their characteristics should be as orthogonal as possible. Personas are used by testing interfaces against them. Instead of "the user clicks on this button and then reads this paragraph", it becomes "Mary is irritated by having to click too much and gives up on the interface".
- Find a group of 3-5 people to work with and pick a topic. Ideally this will work best with your group project for ILEAD U because you have already thought about it and made some progress on it, but should there not be enough group members present today for you to work on your project, you can either join somebody else's project, or pick another project as a group.
- You will probably be part of the same group and using the same project in both exercises.
- If you are having trouble finding a good project idea and you have decided not to use any of your ILEAD U projects, then here is a list of project ideas you can choose from. Or, come up with your own idea. Be sure to pick something you have experience with.
- Library OPAC - Who uses the OPAC? Patrons, of course, and there are different kinds of patrons. But also librarians.
- Library Programming - Either pick particular kinds of library programming, or think about it in more general terms, and then create personas that represent the different kinds of people who engage in it.
- Job Hunting Resources - Public libraries have long been a place where people go to work on resumes, cover letters, find job opportunities, etc. Create personas for people who use these services.
- Teaching Resources - I have heard many stories of school librarians feeling underutilized by teachers. Develop personas for both students and teachers to see how library services might be made more visible or valuable.
- The exercise of persona creation is all about understanding your users as people, and capturing their characteristics and quirks in a representation that takes the form of a made-up person. When we use the word "user", we automatically generalize across people, and end up with a conception that is bland and information poor. Personas instead strive to evoke our social intuitions as human beings by creating vibrant, memorable "people". The art of persona creation is to understand what aspects of your potential users are important to affecting how your design might evolve, and capturing those aspects in a memorable persona description.
- Within your groups, briefly discuss who your users are. Try to think about as many different kinds of users as possible, including people who play different roles (e.g., patron vs. librarian), people from different demographics (e.g., senior citizens, children, single mom, etc.), people who have different needs, people who have different levels of knowledge, etc. Take notes on your discussion.
- Once you have started to get a sense of the diversity of your potential users, write personas to cover all the different kinds of users you have identified. Make sure you give them all names, and do a quick image search (try Flickr Commons) to find appropriate pictures for your personas on the internet.
- It is unlikely that we'll have enough time today in class to write all the personas in sufficient depth, so focus your efforts on one or two to flesh out in more detail. If you find this exercise useful, you can always finish the other personas after class.
- The next step is to take the different personas you have created, and try to combine them, if it makes sense to do so. See if any users actually overlap, or if one user's characteristics are covered by those of two different personas, etc. Sometimes this involves editing or rewriting existing personas. We probably will not get to this in class.
- Now, as you continue your design process, you have personas you can "test" your designs on. How will Mary react if she were to use your GED training module? What would confuse her? What would frustrate her? What would she really love? Be honest when evaluating this. You persona should not be SuperMary who can use all software with ease! If you do this right, Mary will quickly seem like a real person whose reactions you can predict, as much as you can predict your friends' or co-workers' reactions to new software or programs.
- 20 min - User Test/Usability Test
- The purpose of user tests is to evaluate how usable and how effective a particular design is. Because at this point you likely have not built anything complete enough to warrant a user test, we will instead perform a user test on someone else's site. However, to make the experience as useful as possible, we will be focusing in on sites of groups who are doing projects similar to the ones you are doing in your groups, when possible.
- In your groups, for the project you are working on, do a quick web search and find a few projects that are doing something similar to yours. If it helps, think about this as trying to find your "competition", or your rivals, or your future collaborators. Don't worry too much about whether they are exactly the same or not—same ballpark is good enough.
- In (possibly smaller) groups of 2-3, conduct a user test with their website or other resources you are able to find of theirs. One person should be the "driver" or the "user". Their job is use the computer to navigate the site and see how usable it is. The driver/user should use the Think Aloud Protocol, which basically means they should narrate their thoughts and actions as they try to navigate the site. If they forget, someone else in the group should remind them. Everybody else in the group has the job of observer/recorder. Watch what the driver does, where they run into trouble, etc., and write it down. If you see something on the site that works particularly well, make a note of it. If their interface is terrible, take notes describing how and why. If your driver gets stuck or confused, take notes as to why. Etc.
- When observing your driver, pay attention to the following things:
- What do they do? What do want to do? How do the two match up?
- Pay particular attention to what happens when things go wrong, or don't happen the way you or your driver expected.
- Remember to look for what they don't do (but that you might have expected them to do)
- What was difficult for your driver? What was easy for your driver? What was confusing?
- There are a couple of ways you can set up your user tests. You can opt for more structured tests, where in advance of the user test you develop as a group 2-4 tasks which you think a user on the website you are evaluating should be able to accomplish. Then the job of the driver is to do their best to accomplish those tasks. Or you can take a more flexible approach, where the driver approaches the site as a potential user, and tries to use it in the ways they would "naturally" approach using the site. Which option you choose will, of course, depend on the kind of site you are evaluating.
- Once you finish conducting the user test, talk about the experience, and figure out, for your own project, what would you do differently? What would you do the same? What did you find particularly frustrating? Confusing? Unclear? Does your experience using someone else's site change your perspective on your current project in any way? Etc.