Fitting experience design in the agile shaped box
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Fitting experience design in the agile shaped box

on

  • 305 views

Presentation with a proposed framework on how to create minimum delightful products using Agile by supporting the product owner to help order User Stories / Product Backlog Items. ...

Presentation with a proposed framework on how to create minimum delightful products using Agile by supporting the product owner to help order User Stories / Product Backlog Items.

Presented at the Avanade TechSummit14 at Microsoft.

Statistics

Views

Total Views
305
Views on SlideShare
267
Embed Views
38

Actions

Likes
1
Downloads
4
Comments
0

2 Embeds 38

https://twitter.com 31
https://www.linkedin.com 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • After having finished my Masters at the Industrial Design faculty of Delft, I decided to join the Royal Netherlands Navy to become a Maritime Operations Officer. A dream of a 16y old to make the world a better place, contribute something to the overall picture, and at the same time, impress the ladies with uniforms. <br /> <br /> After being involved in a work related accident, I wasn’t physically strong anymore to be deployed in active operations. I left the uniform but still wanted to make the world a better place, and decided to look around me. There are so many poorly designed products and services everywhere. There was no delight in these products, no happiness in using them.. But hey, they did they job I needed to do. <br /> <br /> While at the Navy, I observed one very clear truth: everything needs to follow a process, no step can be skipped as this would put in jeopardy our finely tuned machine. Being there, it made quite a lot of sense. Remembering my design training, it was also all about process. You cannot start designing something ‘out of the blue’. <br /> <br /> When I joined Avanade, a little more than 2 years ago, that dream of changing the world was still present. <br /> <br /> <br /> <br /> <br /> Iets over delightful software delightful als rode draad
  • In the beginning I realized that most of the things I, as a designer, did was to “make it pretty”. Basically coloring between the lines. There was no room for changing usability aspects as the code was all written down and the budget didn’t allow for any changes. <br /> <br /> As you may know, designers need a bit of freedom to be able to explore concepts, measure which concept will delight our users most, etc. No kidding, coloring between the lines is very difficult, as you always know it could have been so much better. <br /> <br /> However, when the project hits its release date.. We proudly say that… <br />
  • The users will love it. <br /> <br /> You can see how happy we are, something gets released, we did all the research about that problem needed fixing and our solution takes care of that. <br /> Our customer has paid us for our skills & knowledge and trusts us in the fact we will solve the problem they were facing. <br /> <br /> Plus…
  • We covered all the minimum requirements we set out at the beginning of the project! <br /> <br /> Yea.. Minimum required features mean that it is minimum. Remember these products that were built that were kinda working but super functional? <br /> <br /> Is it so minimum that it barely works or that you have to say to your users “this kinda works, you need to click here and there first before something will run”. Plus, you’re not sure whether these minima are the ones that truly delight the users. <br /> <br /> “Minimum Product is like visiting someone in the ICU… they’re alive, but not fun to spend time with. “ <br />
  • The PO owner did it! He is the king here. <br /> <br /> “The product owner owns the product backlog!” He/She should have prioritized better! (driven by hypothesis, silos, etc.) <br /> <br /> However… NL has a democratic monarchy… one can wonder how politics try to make his country as delightful as possible. That brings us to the next question.. <br /> <br />
  • How can you be sure that the King knows about each of his subordinates and represent their best while he has so many other things to care about and only relies on information of other people, the people preparing and executing the work. <br /> <br /> In agile, the only place where the king can do things is on the backlog. Only the King (or Queen) can do stuff there. We shouldn’t touch this as the PO really knows our end-users and is granted the permissions and trust to represent them. <br /> <br /> As you may be aware in Agile, the order to User Stories on a Backlog is key to the entire process… We can ask ourselves “Shouldn’t we not be assisting the PO in ordering the backlog items?” <br /> <br /> So,…now that the responsibility falls on both the PO and us… <br />
  • That is the real reason why I am standing in front of you all today. I want to show you a process how you can make products delightful, products that excite users, products that solve real problems which the users are sensitive to. <br /> <br /> I want to introduce you to the concept of “Minimum Delightful Product”. The minimum delightful product is an increment on the Minimal Viable Product. Let’s first define some ground first..
  • As you can see, delight is a much broader concept than ‘just’ something visual.
  • As you can see, its more than just a pretty ui… it’s about how the someone receives something. It is about emotions, understanding, perception and sensory information. <br /> <br /> It is really how people feel & experience things. <br /> <br /> A product that is truly delightful has three boxes it needs to tick. <br />
  • Gestalt (soul of ux experience – combination of functionality and ux) <br /> Design <br /> Quality <br />
  • Makes something feel complete <br /> One of the temptations with the MVP approach is to build a bridge that only goes halfway across a ravine and then to ship it so you can get iterative feedback. The feedback amounts to “this bridge sucks” even if a bridge across a ravine is a brilliant idea. <br /> Without the end-to-end experience, the product simply feels broken or nonsensical to the user or, in the case of the bridge, very dangerous. <br /> <br /> Minimum is Minimum <br /> Minimum are not ALL the features. <br /> You can’t achieve a great gestalt by simply accumulating the right features. <br /> It comes from the right elements working together so users stop thinking about the technology and simple achieve their goals. <br /> <br /> Iron triangle verhaal hier in breien. <br /> http://blog.standishgroup.com/news/ <br /> <br />
  • Visual design is the conveyor of the Gestalt. <br /> <br /> Things do not need to be visually impressive, it needs to be in balance. <br /> Google Search Box, Windows Phone 8, etc. <br /> <br />  there is direct need for highly detailed, hand-drawn paintings, etc.
  • Gestalt + Design often lead to a crappy product… as the code behind it, is just wrong. <br /> Quality, Speed, responsiveness etc. need to be good . <br /> <br /> Whatever it needs to do, it needs to do it well! <br /> <br /> Definition of done anyone? ;-) <br /> <br /> Iron triangle verhaal hier in breien.
  • We all know that not all PO’s are very experienced and knowledgeable about their end users. <br /> As Consultants, we need should be thinking of helping them out so that we can deliver a delightful product. <br /> <br /> What methodology would you use to make this happen then?
  • Agile. What a surprise! <br /> <br /> The agile framework is perfectly suited for delivering a minimum delightful experience.
  • Its more about the focus… being to focus on the users using the agile methodology. <br /> <br /> Being able to deliver something like this, in time, on budget can be quite challenging.
  • As you can see, what we imagined en envisioned is by far different from what was delivered. Was the functionality the same? Sure. Did it do what it had to do? Sure. <br /> <br /> However, the gap between idea or vision and reality is called the agile business gap. <br /> <br />
  • So you have this project… it has a start and end moment. The horizontal line represents the path towards a successful delivery. As the project progresses, regular feedback from our users help us to stay on track and deliver something delightful. As we deliver increments, feedback from our users helps to guide us to our goal. <br /> <br /> Note the distance between the horizontal lines and the orange stroke. This difference is the agile business gap.
  • This would be a real situation, again start and end dates, project path, etc. <br /> <br /> In this case, you can notice that feedback is delivered on working increments, however… there seem to be a total misalignment from what we make and what the end users want. You can ask yourself.. Is this because of poorly understood users? Is this because of poorly ordened user stories etc? At some point, usually near the end, a decision is made to drop a few features in order to satisfy minimum things and to preserve functionality. <br /> <br /> Feedback, or even usage insights, is a very important aspect of anything.. It brings you the possibility to see what the users do and (really) want
  • This would be a real situation, again start and end dates, project path, etc. <br /> <br /> In this case, you can notice that feedback is delivered on working increments, however… there seem to be a total misalignment from what we make and what the end users want. You can ask yourself.. Is this because of poorly understood users? Is this because of poorly ordened user stories etc? At some point, usually near the end, a decision is made to drop a few features in order to satisfy minimum things and to preserve functionality. <br /> <br /> Feedback, or even usage insights, is a very important aspect of anything.. It brings you the possibility to see what the users do and (really) want
  • Explain that the product <br />
  • Feedback and iterations are king <br />
  • Feedback and iterations are king <br />
  • Feedback and iterations are king <br />
  • Understand the people that are going to use your solution. <br /> Get clear understanding of the entire flow of the application. First click here, then here, then there.. Etc. <br /> <br /> 1-2 main personas <br /> Max 10. If too many, not clear enough. You cant cater for every possible edge-use case.
  • Understand the people that are going to use your solution. <br /> Get clear understanding of the entire flow of how your users would like their problems resolved. Check it with them! <br /> You need to know WHAT your users need to have done so you can help them doing so.
  • Understand the people that are going to use your solution. <br /> - Get clear understanding of the entire flow of the application. First click here, then here, then there.. Etc.
  • Sequentially build up the experience map. <br /> <br /> Try to get very broad user stories / epics broken down as soon as possible. Layer the user stories by importance (most used/least used).
  • Sequentially build up the experience map. <br /> <br /> In the end, move it to the UXI map
  • Understand the people that are going to use your solution. <br /> - Get clear understanding of the entire flow of the application. First click here, then here, then there.. Etc.
  • Focus on the problem to be solved <br /> Deal with highest value items first and work your way down.. <br /> <br /> If you have overlapping areas, knock these out first
  • Make  work in progress limit  Transparency aspect of agile <br /> Don’t focus on all user stories all at once. Walk the map and build them all from there. <br /> <br />
  • Feedback and iterations are king. <br /> <br /> Think of measuring UX metrics using tools as for example Application Insights, Usabila, etc. It is all about measuring (and trying to understand) the agile business gap. <br />
  • Its about people and you incorporate them and take them along a journey…
  • Yes, years of training and some sense of empathy. Ultimately it is very process driven, and missing a step, will make the design less effective. <br />
  • we make our users shine through our pixels and we are trained to do so. <br />
  • Start with one and convert all members to follow and keep updating the <br />

Fitting experience design in the agile shaped box Presentation Transcript

  • 1. FITTING XD IN THE AGILE SHAPED BOX: DELIGHTING OUR USERS.
  • 2. HI. MY NAME IS MICHIEL. XD DESIGNER AT AVANADE NL michiel.pruijssers@avanade.com | @michielpr
  • 3. HOW DID I END UP HERE?FORMER ROYAL NETHERLANDS NAVY OFFICER | INDUSTRIAL DESIGNER
  • 4. TALES OF A DESIGNER IN A DEV TEAM
  • 5. THE USERS “WILL” LOVE IT.
  • 6. WE COVERED THE MINIMUM REQUIREMENTS!
  • 7. THE PRODUCT OWNER IS KING!
  • 8. DOES THE KING KNOW HIS PEOPLE?
  • 9. HOW DO YOU MAKE DELIGHT?
  • 10. WHAT IS DELIGHT ANYWAY?
  • 11. DELIGHT REVEL ENJOY PLEASURE PLEASEENTHRALL TRANSPORT RAVISH ENCHANT ENRAPTURE DELECTATION JOY
  • 12. DELIGHT IS MORE THAN A PRETTY UI
  • 13. GESTALT DESIGN QUALITY+ +
  • 14. GESTALT DESIGN QUALITY+ +
  • 15. GESTALT DESIGN QUALITY+ +
  • 16. GESTALT DESIGN QUALITY+ +
  • 17. HOW DO YOU MAKE THIS HAPPEN?
  • 18. AGILE.
  • 19. AGILE FOCUS ON THE END USERS.
  • 20. DEAL WITH THE AGILE BUSINESS GAP.
  • 21. “THE IDEAL SITUATION”
  • 22. “A REAL SITUATION”
  • 23. “ANOTHER REAL SITUATION”
  • 24. THINK OF IT AS VIRTUAL DESIRE PATHS
  • 25. THEREFORE, OUR PRODUCTS NEED TO BE
  • 26. INCOMPLETE | IMPERMANENT | IMPERFECT Characteristics of our product
  • 27. INCOMPLETE | IMPERMANENT | IMPERFECT Characteristics of our product
  • 28. INCOMPLETE | IMPERMANENT | IMPERFECT Characteristics of our product
  • 29. 6 STEPS TO ACHIEVE DELIGHT
  • 30. STEP 1 DEFINE YOUR USERS.
  • 31. GET SOME GRIP ON THEM. STEP 2
  • 32. STEP 3 CREATE A MAP OF THE USER FLOW
  • 33. DEFINE & ORDER USER STORIES STEP 4
  • 34. most used Least used User Sequence #1 User Sequence #2 User Sequence #3 User Sequence #4 User Sequence #5
  • 35. A most used Least used User Sequence #1 User Sequence #2 User Sequence #3 User Sequence #4 User Sequence #5 B FC D E G
  • 36. A B C D E F G 1 2 Jean Renee UX Score Staffing & ResourcesDaniel Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y 9 8 5 Business Impact 5 3 4 5 2 3 5 290 27 32 40 46 120 25 Dev Estimate 3 2 5 10 3 6 4
  • 37. A B C D E F G 1 2 Jean Renee UX Score Staffing & ResourcesDaniel Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y 9 8 5 Business Impact 5 3 4 5 2 3 5 290 27 32 40 46 120 25 Dev Estimate 3 2 5 10 3 6 4
  • 38. REFINE BACKLOG AND REPEAT. STEP 6
  • 39. THINK | MAKE | CHECK WRAP UP
  • 40. THINK | MAKE | CHECK WRAP UP
  • 41. THINK | MAKE | CHECK WRAP UP
  • 42. UX IS MORE THAN PIXELS. Conclusion
  • 43. IT’S A HARD SKILL. Conclusion
  • 44. DESIGNERS FACILITATE, USE THEM. Conclusion
  • 45. TEAMS NEED TO GET EDUCATED. Conclusion