Recommandé
Recommandé
Contenu connexe
Similaire à User Research for Agile Teams
Similaire à User Research for Agile Teams (20)
Dernier
Dernier (20)
User Research for Agile Teams
- 1. User Research for Agile Teams Lindsay Tabas | User Experience Design | @lindsayt
- 2. UX @ Group Commerce @lindsayt #agileuxnyc
- 3. What is user research? Anytime you interact with your current, future and past users is an opportunity to gain insights into how people use, misuse and abuse your product. @lindsayt #agileuxnyc
- 4. The user is always right …but they rarely know what they want* …and they hardly ever know what they need* * if you’re not asking the right questions @lindsayt #agileuxnyc
- 5. Getting to Meaningful Means Playing Games …and letting the users do all the work! Design Studio | Card Sorting | Contextual Inquiry | People Watching @lindsayt #agileuxnyc
- 6. Research When It Matters Nate Bolt (boltron on Flickr)
- 7. Research & Testing Cadence Create a backbone for performing regular usability testing and user research. @lindsayt
- 8. Be a User Therapist …and practice active listening. @lindsayt #agileuxnyc
- 9. You may hear things you don’t want to hear …but it will be better for your product. @lindsayt #agileuxnyc
- 10. Don’t Be That Person @lindsayt
- 11. Merci | Gracias |Thank You Lindsay Tabas @lindsayt ltabas@groupcommerce.com We’re Hiring! http://groupcommerce.com/about/careers/ @lindsayt
Notes de l'éditeur
- Introduce Myself + Introduce GC (White Label + Full Service, etc)
- I was brought on to bring a more user-centered design focus to GC. The picture here is the UCD process, which I find fits nicely into Agile. We involve our clients every step of the way – Analysis (User Research), Design (Design Studio), Evaluation (Usability Testing). Just short of making them build the software themselves, we have them working hard.
- Everytime I talk to a client, whether it be in passing at a Meetup, or in research or testing, I take little nuggets home with me. Maybe I better understand them as a person and their motivations, or I get an idea for a feature, this is all User Research.
- The way in which Product Managers + Business Analysts collect requirements is very different from the way User Researchers do. The user is definitely always right, but they don’t know what they want and what they need. While “What do they want?” and “What do they need?” are valid questions, people rarely answer those questions well. So we have to et at the answer in a different way.
- By playing games with them! I’m not going through all of these methods, but games trigger people to think about their own experiences and give them an opportunity to tell you stories that are relevant to what you want to learn about.Also, going to where these people work and seeing the context in which they work is important. Some of my users use my software everyday, all day. It’s their job to. Context is king.
- But in agile, when you’re moving quickly and have lots of projects, researching when it matters is important. The closer your research gets to when it matters to the user, the better data, in put and feedback you’ll get. This is why I like Diary Studies. I sent a two page sheet to a user that asks questions about what was successful and what was frustrating about using our software. They put it next to their desk and fill it out at their leisure. I sent it to one client thinking I would get 4 responses, and I got 20. The users fill it out when they give a shit, and I get to ready when I give a shit.
- P = PlanningR = ReleaseUT = User TestingUR = User Research
- Ask a Question, prompt an exercise, and then listen. Wait for the awkward silence because most likely they will fill it with a beautiful gem. Don’t just look for quotes to support your hypothesis, look for things that challenge it.Show Me? Explain to Me? What gave you that impression?
- Stubbornness is the worst trait of a researcher &/or designer. Remember, the user is always right. If they can’t figure out how to use the software, it’s my problem not theirs.
- Remember why we do this.