UX Research & Agile myths - Geek night Melbourne July 2014
•Als PPTX, PDF herunterladen•
1 gefällt mir•870 views
Presented at Melbourne Geek night in July 2014. Covers the importance of research as part of the design process. Includes 5 myths about conducting UX research in agile and tips on successful UX research.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
UX Research & Agile myths - Geek night Melbourne July 2014
- 1. UX research & agile 5 myths
- 2. “If I had asked people what they wanted, they would have said faster horses” -Henry Ford
- 6. • http://www.sonos.com/images/homepage/ v2/simple-section/content/expand.jpg Build better products
- 8. Evidence
- 9. “If we have data, let’s look at data. If all we have are opinions, let’s go with mine” -JimBarksdale
- 10. Myth 1 research is too slow
- 11. Myth 2 go to market & a/b test
- 12. Myth 3 must be primary research
- 14. Myth 4 only time for validation
- 15. Primary research • Foundation • Tactical formative • Tactical summative (validation)
- 17. Deliverables
- 18. “If I had asked people what they wanted, they would have said faster horses” -Henry Ford
- 19. THANKS
Hinweis der Redaktion
- used to suggest that if customers don’t know what they want there is no point in conducting research
- UX Research is often perceived as being time consuming, expensive & complex AND hard to do. If it’s hard to do in waterfall environments then it is virtually impossible to do in agile ones
- What qualifies me to speak about this? I have being doing this for the best part of 15 years. I run a company called NOMAT and we specialize in design research & strategy Help our clients, which include Parks and wildlife service Tassi, Big 4 holiday parks and Seek to improve their designs and design better products through a better understanding of their customers Qual and quant research, facilitate workshops and providing advice
- 3 reasons for doing research broadly and also in agile environments
- Basically through a better understanding of the people using your products, their needs and pain points, their context of use we are able to: 1 build products they want and that are useful 2 build products that they can use
- I have spent most of my career working with the likes of Telstra, ANZ and Coles large risk averse organisations when they build products it costs a lot of money They want to know that they are going to get a ROI on that investment If we follow a user centered design process like on this slide: Exploratory research up from then iterating and validating our designs we can ensure that the design is on the mark This fits nicely with the ethos of agile – collaboration with customers and reacting to change
- For mine at the core of UX is bringing evidence to the table
- Experience at Coles in a Steering Committee meeting wit the CTO With evidence from usability testing I was able to convince senior managers that a change was necessary. I’m sure every designing in this room has had an experience where a senior manager has SWOOPED in at the last minute and changed a design. I think this happened b/c they are ultimately responsible for the product not b/c they want to be designers. Our job is to bring evidence to convince stakeholders that our design is the right solution. We should be making senior managers lives easier by reducing the number of decisions they need to make.
- Can be but… Seen agencies where research is unnecessarily slow With the right techniques and systems in place it can be run quickly – BEING PRAGMATIC and making the best of the constraints of the situation Techniques such as online card sorts instead of in-person. By systems such as a panel of customers to speak to regularly or running usability testing every sprint. These things make it possible to run research quickly within Agile environments e.g. card sort – on the Tuesday….
- Can…. TWO reasons why not to 1. potential that we are wasting effort on getting something to market that won’t work – could have evaluated it with a paper prototype or wireframes 2. don’t give the why and rich insights available from qual research such as usability testing and contextual interviews Plus the understanding of the product gained from research helps tto build greater understanding (building a body of knowledge) Crucial in agile where the culture can encourage team members to lower their eyes and focus on the day to day issues
- Primary is is new research, carried out to answer specific issues or questions. Next slide
- Secondary research involves the summary, collation and/or synthesis of existing research rather than primary research. examples such as Forrester and NNG or even reviewing past research At Coles … they have a large market research department who do lots of research which is an amazing resource But a skilled researcher can take existing information and re-purpose it. to build an argument for a direction or design Which is time efficient and cost effective. And it is perfect for an agile environment
- What is validation? the act of validating; finding or testing the truth of something Techniques such as usability testing and tree testing
- define types Foundation – the big picture understanding of our customers e.g. REA where we would understand the process of looking for and buying a house Tactical formative – finding answers to the questions required to build something such as a new a registration form plan and take out of the streams use an agency however the downside is taking the research away from the tem Potentially chunk down into small parts and run over multiple weeks or even months – to deliver on the foundation and tactical formative research
- While we need to create deliverables efficiently in agile environments removing deliverables all together is a false economy going to accrue knowledge debt if we don’t Wall for visibility with quotes from real people THEN 1 one-pager 2 simple word doc
- 1 no evidence that the great business man henry ford ever said this 2 it actually provides some great insight ANY UX research worth their salt would not take customers at face value AND we shouldn’t be asking them what they want - it is poor research This quote speaks to efficient transport.