UPA Meeting, 3/30/2010


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

UPA Meeting, 3/30/2010

  1. 1. UPA Meeting, 3/30/2010 Chris's Intro • UPA Conference is June 9th, the deadline to submit is April 9th. Remember you get a 15% discount with 6 or more attendees. The UPA is still looking for submissions and sponsors. • Upcoming Events: o 4/28/2010 Topic: Several talks, inc. Migrating Intranet to Sharepoint Speaker: Jen Hocko, TBA Location: The MathWorks, Natick, MA o 5/18/2010 Topic: "Squeezing 1,000 users into the usability lab, or how to conduct online user experience studies" Speakers: Bill Albert / Donna Tedesco Location: Fidelity o 6/9/2010 Topic: Boston UPA Mini-Conference Location: Bentley University o 7/21/2010 Topic: Tem Minute, Flash Talks Speakers: Beth Sherman/Colin Hynes Location: Staples o More info on events: http://www.upaboston.org/meetings/meetings_2010.shtml • Intuit hiring a Senior UX Researcher - www.intuitcareers.com • Online buddies hiring UI Engineer for android and other mobile (PHP, front end usability) - www.online- buddies.com • Deltek hiring usability engineer (Interaction Design / graphic design) - www.deltek.com • BDC at Umass Boston hiring Senior UX Director for healthcare startup • Watt-C (Wattsy?) looking for front-end Interaction Designer / Coder (html & css, usability) Alla Zollers @ Mad*Pow (Experience Design Firm) Link to Alla’s Slides: http://slidesha.re/8XL9nb Alla polls the audience for those working in Agile. She has been working in Agile for a few years, and as the popularity has increased, there is a lot of confusion in our field and in general, and negativity around Agile practices. Objectives 1. The Educational Bit – Background on Agile and What it is 2. The Practical Bit - How to work as ux practically in agile, 3. The Emotional Bit - Emotional / Philosophical part, address concerns Part 1: The Educational Bit - What does it mean to be agile? Not specific method, but a mindset, philosophy, principles – there is a difference between principles & practices - History = Evolved out of dev community in 90s, wanted to be treated by people, inspired by Toyota's lean thinking - Dev community wants – sustainable pace, self-organization, work as team cross-functionally, not know everything upfront, adapt & change course, realize business value quicker, high quality work, work in a way that makes sense today
  2. 2. - Agile’s Set of Values (source = agilemanifesto.org) o Individuals & interactions over processes and tools o Working software over comprehensive documentation o Customer collaboration over contract negotiation [Customer is defined as an internal stake- holder responsible for the overall vision of the product] o Responding to change over following a plan o Unwritten value of Agile – continuous improvement at the individual, team, org level (Alla suggested that you start with a standard Agile process, then adapt to team, organization, etc.) - Agile methods are process that support Agile philosophy (e.g. Extreme Programming (XP) and Scrum). Some key Agile practices: o Co-location / pairing - all sit in the same room, two developers (coders) working together on one computer (mentor, cross-pollination, team-building, trust, etc.) o Story creation - write features on note cards, i.e. "As someone who is hungry, I like to eat so that I'm no longer hungry." Should include user, feature, and end value add. Another example of this is “As a physician, I want to see my patient records so I can be up-to-date about their medical history when we meet next.” o Real customer involvement – Customers are not end users but internal stakeholders (ux, product, legal, sales, marketing, etc.) – have constant demos & constant involvement o Stand-up meetings - 5 min daily meetings, each person says what I did yesterday, do today, things standing in way (i.e. “I am waiting for Jim to send me those key elements, and I can’t do my work without them”) – if Jim is in stand-up, then he’ll do it right away, no waiting o Continuous testing – “testing” means QA as well as usability - is buggy, do people know how to use it - responsibility to change o Retrospectives - end of each sprint (which typically lasts 2-4 weeks), come together to say what went well, what didn't, then change based on this – adapt - Waterfall vs. Agile [slide 17] - in agile doing many things simultaneously, break it up so not developing it all at once (usually develop small sub-set of features, such as 1-15, then 16-30) - Value Propositions of Agile – Similar to the values developers wanted! o Higher productivity (not at first, but once hit rhythm) o Lower cost o Improved employee engagement & job satisfaction o Faster time to market o Higher quality, etc. o Main value prop = TEAM (in waterfall, there is US vs. THEM, but in Agile everyone works with the team) - There are challenges – Agile is not a silver bullet – it came out of dev and there was not a lot of thought about UX, requirements gathering is not defined, setting up agile is difficult, agile practices are pervasive (affects everyone, not as much individualization, some want to retain their titles), change to agile must come from top-down and bottom up, better at refining and not defining - Questions on Part 1: o What is scrum? Iterative and incremental framework, came out of rugby o When does real, real, real customer get involved? UX is responsible for talking to end-user, but “customers” in Agile are internal because they shape the vision – UX shapes the vision based on work with end-users o Story - where does it come from? “Customer” write the story - as a physician, i want to be able to access patient records to learn more about my patient. Developers go do it - generic, everyone has freedom to go about doing job. o Definition of customer - reason why Agile principles def customers as internal customers? Internal because customers are responsible for business value also added to the product, they need to prioritize what gets developed first, hold vision for entire product; end-users can only tell you what they want, not where the company wants to take the product (ux gets
  3. 3. requirements from end-user) o Example? Project Manager is product owner, Client is customer because prioritize the features; UX is customer because she comes up with scenarios for users (based on research, etc.). Important part is enough customers to keep developers moving (golden ratio is 2 customers per 3 developers, not including the product owner who has final say) Part 2: The Practical Bit (How do you do it?) - Instead of asking how fit ux into agile, ask how do you become more agile as ux - UX is customer role bc customers: o Evangelize entire vision of the product o Identify features and stories o Group features into small releases - Beginning of Agile process [slide 25] o Beginning, 1-2 weeks of discovery, begin prototyping stories o Iteration 0 [duration is 2-4 weeks] – developers begin to prepare for first iteration, prototype from UX (not necessarily a prototype, but instead of waving hands it's a concrete example) is started and iterated, start usability testing for the current prototype and discovery for Iteration - Objection - never enough time to conduct research up front; Answer = true, but assume that continue research throughout entire time working, constantly researching – just enough mindset - 'Just Enough' mindset means you do enough to continue, enough to get through that iteration, and not more. - Middle of project (i.e. Iteration 1) - developers develop what you designed in Iteration 0; since all sit together in room, dev ask you what you meant by things as they develop them; at the same time, you look to future, you design wireframes/prototype for I2, discovery research for I3 - Objection - if I break up design into pieces, hard to visualize the entire system. Answer = sketch the whole system, dive deep into certain pieces, sketch for I3, wireframe/prototype for I2, can create storyboards - Objection - Some designs are too complex for only one iteration. Answer = break them up into small, cycle-size pieces; e.g. If I wanted to design Photoshop so that I could select an object, move it, & change its’ color, I can break up into smaller chunks – focus on a toolbar to click and select an item first, then the second iteration would be to move it, then the next iteration would be to change color – always delineate into smaller pieces - Objection - Not enough time for formative usability & report. Answer = employ light-weigh techniques, progressively engage in defining test protocols - maybe not big lab study but you do remote testing, coffee shop, internal users at first then recruit valuable end-users - Objection - No more wireframes/mockups; Answer = use tools that help you produce good work (if you need a wireframe, do a wireframe), do enough, don't draw/wireframe something that you can discuss with developers instead - Summary - No surprises, camaraderie, learn a lot, work 9-5, hard, change practices from ux, but for better; almost weeds out team members that couldn't really cut it at the beginning anyway - Questions for Part 2: o What suggestions do you have to convince users/customers that Agile is worth doing or that Agile is working? Whip out a demo, or 2. Last iteration, then this iteration - see the change and usability increase. Also, invite them to usability session & give them a sticky note, write any usability issues you see – that’s your report right there. o How work on many projects at once? Cannot do that in agile o Is development writing actual code, or prototype? No, that's the code, constantly re-writing it but in small chunks. o Why iteration duration 2 weeks (if something takes 1 week, why not 1 week)? Maintaining a sustainable pace is important. Agree to do a certain number of stories in 2 weeks, specific rhythm to Agile, rhythm set by the agile - if change that around harder to estimate, breaks up
  4. 4. rhythm, etc. o Focus on mock-ups? Mockups are design, no other designs happening, o 7 people involved in Agile project? = 1 Product owner, 2 customers, 3 developers (seems to be a good rule of thumb) o Scrum & product backlog – what happens if something is reprioritized at the end of iteration? - Hopefully things not re-prioritize at end of cycle 1, working with product manager to know that this is coming, not surprise product manager should communicate that that is coming down. But if the backlog happens then you can pair with developer and design as you go – but not ideal. o How does copy fit it? Copy is customer, working with Interaction Designer, pair with them, design together, design around/with copy, be a sprint ahead with designers, dev a sprint behind design o Further out, minimizing fidelity, what is breakdown of work throughout sprint? Project dependent, 20% work within current sprint and questions, 50% look ahead within next two iterations (some time refining the entire vision of what you thought the system was) o Some confusion about roles, is designer a dev or customer? Designer is “customer”, although they are doing some of the work... can understand user researcher being a customer, but Interaction Design? Only diff between developer and customer is that customer can prioritize what developers should develop - worried about feeding the development machine? It is harder to dev than to design, so 2cus to 3 dev works out well Source - Adapting usability investigation for agile user centered design by Sy (2007) http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html Part 3: Resistance - Resistance - like status quo OR dislike agile process - do you feel resistance? o Someone thought "where's the designer?" in the manifesto, created by the development community, designers have to fill those gaps in - Questions in general o Who tracks the business value? Demos track progress, retrospective looks at business goals vs. what was developed o What if v. 1.0 of product, what do you have that is “releasable”? Still release to internal clients o How do agile if so busy? Have rep that goes to scrum and reports back to teams, but that’s really a resource issue o You mentioned some cheaper, quicker methodologies to use, such as coffee shop studies and remote studies. Any other methodologies to recommend? Start rough, then get more formal as iterations go along… Grab someone not on project internally to look at it, go to coffee shop/street give gift certificate, applications online (5sec test, pay fee, give you stats look, click), recruit some people, domain experts, board members, family and friends (networks - Facebook, twitter, LinkedIn), bring people in, formal - depends on fidelity (portability) - simple usability metrics come from any person even if not in end-user group, when fleshed out bring in formal people (Chris mentions setting up research for distance – recruiting 5-10 people each iteration, instead of big study up front) Link to Alla’s Slides: http://slidesha.re/8XL9nb