�ݺ�ߣ

Editor's Notes

• #2: Thanks for coming out, everyone! I’m ____ and tonight I’ll be sharing with you all about how our product development team is making UX design work in an agile world. After that, OPEN UP FOR QUESTIONS TO THE WHOLE TEAM…
• #3: So, a little bit about our team. We’re working on a new SaaS product called Engage, which is a tool for progressive, member-based non-profits. Our entire team is in Atlanta, but Daxko has additional teams for other products in Birmingham, Alabama. We have some of the team members here with us. I’ll let them introduce themselves.
• #4: Traditional UX is in the calm waters at the TOP of the waterfall. Traditional discovery/design phases are hard to estimate, hard to follow. In waterfall, UX design is seen as an INPUT TO development - “ Uxers ” aren ’ t involved in shepherding the design through the full process - We communicate primarily through reams and reams of documentation
• #5: That’s impossible! No design survives execution By documenting everything, trad UX ends up in CYA mode (click, state change, edge case) And designers are rarely allowed to continue with the project after they deliver their design docs - talk to BAs, big design up front, pitch it over the wall into a black hole -If lucky, MAYBE someone will ask follow up questions. (not TOO many…state of analysis paralysis, with 5,000 versions of “final” wireframes. RESULT = longer cycle time and inferior product -Who here is familiar with this process? -It’s probably very similar to how you work now, huh?
• #6: Agile UX is IN the whitewater. It ’s part of building and delivering a product. It ’s continuous, from idea through delivery and support.
• #7: Here’s an example of something we do that’s different from waterfall—EDJIT. Last-minute requirement after sprint started. Pulled it into the sprint, had to quickly model. -this kind of thinking is not limited to the designer on our team. -If you can hold a marker, you can help figure out the answer. That simple! We communicate to the level that’s needed, on case-by-case basis.
• #8: Something else that’s different is our constant collaboration. No black holes here. Everyone’s working toward meeting the same deadline. This is our sprint board. Keep everyone’s status highly visible. Everyone should be in the loop, by design.
• #9: So, how can teams move towards a more agile approach to UX research & design? Focus on the same agile principles for software dev.
• #10: Let’s start with focusing on…
• #11: Primary allegiance has to be to the project team -this works well for our team—dedicated to project When you start to divide team members amongst many teams = problems - constant collaboration is critical to staying above water & moving forward -more teams you’re on, the less focused you are per project Designer needs to have same skin in game as rest of the team -on our team, we wear many hats; cross-functional -devs create & run automated tests, QA in the code; designers & Product mgrs in FED; whatever the team needs to keep ball rolling Design is part of what team commits to each sprint
• #12: Designer facilitates team doing design rather than doing ALL the design We involve team in design activities as often as possible -Design studio method -Dev/UX pairing **NO GATEKEEPERS On the flip side, an Agile designer should also pitch in to help other disciplines. -I’ve started brainstorming test ideas with our tester for each story. -UX is closer to users through more research & customer communication so can help identify typical user scenarios and edge cases.
• #13: We also focus on…
• #14: Measure success based on “delivery of VALUE” to customers, by the IMPACT. Product in customers hands = OUTCOME Design document handed off to developers = OUTPUT Focus on achieving outcomes. As an interaction designer here, work through ideas on paper, whiteboards, mockups, prototypes , and sometimes even in the browser. -No standard deliverable format….“deliverables” must communicate ideas. DON’T MAINTAIN SPECS. Dev/UX pairing = AWESOME! -no long revision/review cycles -Getting a piece of working software in the customer’s hands is more valuable than spending a month on documenting all the ins & outs of its design. PIC: keeping ourselves accountable—rotating dashboard of our successful builds, user research, and so on.
• #15: There’s a number of ways you could interpret this one… From a user experience standpoint, it could go like this:
• #16: Scenes represent what happens wh en you don’t communicate, collaborate -You & the customer spell out in fine print what everyone thinks the customer wants. -”The business” hands down requirements. -Crickets.... Then you have a release. -Customer ends up not getting what he needed. Focus on collaborating with the customer throughout your dev process (vs. trying to define EVERYthing up front & then being out of the loop thereafter). Iterate based on what you learn throughout the whole process—as you learn more about your customers’ needs, and they learn more about what you can provide them, the result will be a better product in the long run.
• #17: Example of collaboration: annual customer conference, design studio around a certain area of our product. This area wasn’t something even really outlined in any contract or product description. We knew we could be doing more, even if our customers didn’t see that far ahead yet. Got them together, brainstormed ideas. We tapped into a range of different concepts that would fulfill a customer need—even though they’d never before even have dreamed these ideas were possible.
• #18: Finally, Agile UX values responding to change
• #19: Don ’t just respond to change... seek out reasons to change. Seek to invalidate what you think you know, not to prop it up. If it ’s right, it’ll endure. (If it’s wrong, you don’t want it to endure.) In waterfall, change is bad. Change requests, all the process & documentation behind them… All the additional changes are a headache b/c system’s not set up to handle change. Agile is. Our product roadmap flexes. We don’t necessarily know what we’ll be working on a month or two from now. We might have a feature in our heads that, after some user research, jumps to the bottom of our list. We know things aren’t always set in stone.
• #20: We don’t have a formal process for how or when we do this, but I can tell you how we’ve done before: -we had a design, and a look & feel, for our pilot product -we got feedback from users -we iterated on the user stories & their priority -we created a prototype of our next iteration And we’re still iterating on some of the design even now. DON’T LET YOUR PROTOTYPE BE THE “SPECS!” -this is all about communication; use it when it makes sense as a guide (conversation with users, team mates, leadership, etc.)
• #21: Get your work in front of customers on a regular basis. -In some phases of project, we had 3-4 usability tests each week to make sure we ’d thoroughly vetted our design. BUILD THIS INTO YOUR PROJECT/TEAM CULTURE. -frequency & formality varies according to project’s needs; could end up on the wrong track—FAST! And remember you don ’t have to “get it right.” Look for actionable insights. -A wise product manager once told me that the output of usability testing (findings documentation) changes when you’re on an agile team. - I was used to a ton of documentation about what happened during user research. - In Agile, you need to know & communicate the action items from the insights you gleaned - 30-minute conversation vs. 50-page report
• #22: Ok, so now that you’ve heard a lot about how we do things, we’re going to open up the panel for questions. Please keep in mind that we don’t even pretend to have all the answers , so we’re more than happy to talk about our challenges, as well.