Anúncio
Anúncio

Mais conteúdo relacionado

Apresentações para você(20)

Similar a Jason Moore - Interaction design in enterprise teams(20)

Anúncio
Anúncio

Jason Moore - Interaction design in enterprise teams

  1. Interaction Design for Enterprise Teams Jason Moore, UX Manager jason.moore@workiva.com
  2. Agenda I’d like to leave you with 3 ideas 1. What is Interaction Design (IxD)? 2. How IxD’s are structured to support Workiva’s success within our product teams 3. How product discovery plays a key role in our teams
  3. Idea #1 What is Interaction Design?
  4. What is Interaction Design? A design discipline dedicated to defining the behavior of artifacts, environments, and systems ...i.e. products The Interaction Design Group’s (IxDG) definition of IxD can be found at http://define.ixdg.org/
  5. If it were only that simple
  6. Our challenges continue to grow
  7. Idea #2 The day-in-day-out of UX life at Workiva
  8. What people think we do image used from http://jmoo.re/1HMEWj7
  9. What we don’t do
  10. What we actually do User Experience deals with: ● The interaction itself ● UI ≠ UX ● It includes UI but, is not bound by it ● Deals with all perceptions the user has while interacting with it
  11. We think of it like this Content “What People are looking for” Images used from: http://jmoo.re/ux-ui-diff UI “Tools to use the content” UX Consumption
  12. Problems we are solving today How do users retrieve and trust the integrity of financial data? How do we allow teams of 3 to 1000 to collaborate securely and effectively across desktop and mobile? How would our users most benefit from tracking their document lifecycle and the resources involved?
  13. Discovery ‘triads’ are at the core Image From: Jeff Patton. “User Story Mapping.”
  14. How did we get from here in 2009...
  15. ...to here in 2015?
  16. Idea #3 What role does Product Discovery play in Workiva teams?
  17. What is “Product Discovery”? Product Discovery is a set of tools and methods that allow you to evolve a product idea into an actionable delivery plan, within just a few days.
  18. Why is discovery important? Ever ask questions like, ● Does my product solve my customers problems? ● What works? ● What could be better? ● Where do we go from here?
  19. Stuff I said “I've never met an engineer who wanted to build something over and over for a user who has ZERO interest in using it.” - Jason
  20. Ever have feature discussions like this? Illustration by Luke Barrett
  21. What shared understanding looks like ...So, how do we arrive at this place? Illustration by Luke Barrett
  22. The Goal of Product Discovery Image From: Jeff Patton. “User Story Mapping.”
  23. Quick! To the UX Toolbelt ● Maps! (of all kinds) ● Customer Calls ● Sketching ● Prototypes ● Validation
  24. We love mapping problems (+solutions) ● Maps are a CORE component of our UX Toolbox. ● Visualizing information is infinitely more powerful.
  25. Our Compass http://jmoo.re/jp-story read it learn it love it ...and use it.
  26. When should I engage in discovery? Not often, only when you have a need to: ● Build an entirely new product ● Add new features to an existing product ● Innovate on existing features Ok...so, a lot.
  27. Empathy Maps Rather than sympathy (pity), empathy allows you to immerse yourself in a user’s environment
  28. How we plan for a customer Call
  29. If you make a habit of this, you’ll... Do not ever ask, “what do you want?” Image recreated from http://jmoo.re/3-better-questions What do you want? Feature 2Feature 1 Feature 3
  30. ...end up chasing features till you retire (or worse). Build solutions, not features
  31. What’s our alternative? 1. What are you trying to get done? Why? a. Getting background information about what a person is trying to do is critical to understanding your users.
  32. Example What are you trying to get done? Build a Fence Why? Image recreated from http://jmoo.re/3-better-questions So I can surround my front yard. Why?So that I can plant a garden. Why? So I can grow my own food. So that I can save money on groceries. USE CASE!Why?
  33. What’s our alternative? 1. What are you trying to get done? Why? a. Getting background information about what a person is trying to do is critical to understanding your users. 2. Can you show me how you currently do this? a. After understanding the scale of the ‘why’ and what they want to, step into their shoes and see how they do it.
  34. What’s our alternative? 1. What are you trying to get done? Why? a. Getting background information about what a person is trying to do is critical to understanding your users. 2. Can you show me how you currently do this? a. After understanding the scale of the ‘why’ and what they want to, step into their shoes and see how they do it. 3. Can you tell me what’s painful about this? a. If you jump to asking users about how they think something can be better from the start, you only get their opinion, not how they actually deal with their current problem.
  35. We try and remember that... When talking to our customers, ● Great discovery feels like a conversation, not an interrogation. ● We never assume that we know what a user means. Ask. ● Silence is our friend.
  36. Journey Maps
  37. Journey Maps ● Allows us to understand what the user is doing TODAY. ● It’s about mapping the process of observing, and describing all the experiences and emotions the our user has as they encounter a product. ● There will most-likely be gaps! ○ That’s why we’re here!
  38. Time to Pause! The tools mentioned previously are meant to help create shared understanding about who our user is and the pain around their current solution(s). Going through the motions without reaching the why’s is called “Discovery Theatre”.
  39. Do we know the user now? Let’s map a solution! “Story maps are really about discussion, conversations, breaking big ideas into granular detail..” - Jeff Patton
  40. What’s a Story? A story is a named item that we might build in our software ● It names what we might build ● It avoids saying how it would be built
  41. Why Stories? User stories act as the narrative with which you can have conversations in and around your triad (PM/UX/DEV) and team: Illustration by Luke Barrett
  42. How do we write stories? ● Keep the language simple ○ Express stories in a language most people can understand ● Build wide, then deep ○ Start with the big ideas and then backtrack. ○ Details should be discussed in other pertinent meetings, where they are useful.
  43. The life of story map
  44. How it breaks down Big Ideas (concepts) User's steps - smaller steps - UI details - technical details/steps MVP/Release level MVP/Release level
  45. Build better maps ● Build a physical map when possible...and let the rest of the team see it! ● Start with the ‘Walking Skeleton’ ○ build wide, then deep ● Focus on the MVP’s or MVR’s (Minimum Viable Release *) ● Add UI to the map to spark discussion ● Revisit the map constantly (during the project)
  46. Milemarker: Storymap Progress A good way to understand if our story map is on the right track is to sketch it out. ● Everyone on the team is invited to participate. Yes, Engineers too! ● We pick a vertical column of our map and timebox 5 minutes sessions to walk through it. ● Have each person share and discuss.
  47. Sketching ideas … is a good idea Rough sketch of user interface flow on a mobile app. Image by Fernando Guillen. Interaction Flow Single Screen
  48. Why do we prototype? To EXPLORE concepts for ourselves To VALIDATE concepts with users To COMMUNICATE concepts with stakeholders and teams
  49. How we select the right fidelity What is the FASTEST, cheapest way to explore validate communicate [ insert what you are prototyping ] ?
  50. Prototyping: One size does not fit all Low High live data, polished ui, html or axure wireframes and lo-fi ui. clickable interactions paper or balsamiq, high level flow
  51. After we validate our hypothesis Time to build ... aka define the MVP! “The minimum viable product is the smallest solution release that successfully achieves its desired outcomes.” ← solves our clients pain! Excerpt From: Jeff Patton. “User Story Mapping.” iBooks.
  52. This is NOT MVP Illustration by Henrik Kniberg This is a beautifully incorrect product plan for MVP. At every release the user gets something they can’t use, until the last release when they get something that they finally can.
  53. Bingo. MVP FTW Illustration by Henrik Kniberg If we build like this, our user gets something at every release that they can use!
  54. Define MVP Excerpt and Images From: Jeff Patton. “User Story Mapping.” “Focus on outcomes—what users need to do and see when the system comes out—and slice out releases that will get you those outcomes.”
  55. Wait, that’s a lot of maps... Q: How do I know which one to use and when?
  56. A: You won’t...right away. The key is to build habits around around each of these tools so that you can recognize what’s appropriate and when.
  57. It eventually becomes second nature photo: boltmade.com
  58. A sample week might look like… Be ready — the plan will change. Adapt with it.
  59. The way our interaction designers, product managers and engineers continue to build and iterate, is never ending. There is no finish line…There is no finish line… The way our interaction designers, product managers and engineers continue to build and iterate, is never ending.
  60. @mooreplusone Thank you! Feedback + Questions Welcome! Thank you! Feedback + Questions Welcome! @mooreplusone
Anúncio