Designing Under the Agile fog of war
•
3 gostaram•3,032 visualizações
Slides from my talk given at Style and Class at Hootsuite on Monday, 11th July 2014. This talk focuses on the struggles of maintaining a good design process whilst working in an Agile development environment. I explore the concept of the Agile Fog of War, which in essence is about the levels of fidelity we can work in to create a clear vision for our product's design. It's also critical to understand that working at these varying levels of fidelity that we keep our cost of change low to ensure we remain lean and agile with our decision making. I also throw in a couple of techniques that we use at Mobify (http://mobify.com) to ensure we keep making valuable decisions the whole way throughout our product design process.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a Designing Under the Agile fog of war
Semelhante a Designing Under the Agile fog of war (20)
Último
Último (20)
Designing Under the Agile fog of war
- 1. Designing Under the Agile Fog of War
- 4. Product TeamProduct TeamProduct Team
- 5. Product team at Mobify builds tools that help our users create amazing mobile web experiences.
- 6. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 7. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 10. We work in 2 week sprints
- 11. Ship code every sprint.
- 12. “Small diffs are better than big bangs” ! - John Boxall, CTO at Mobify
- 13. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 14. Design Process
- 15. Design Process Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
- 16. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
- 17. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
- 18. 2 Week Sprint Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
- 19. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
- 20. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
- 21. Wireframes Mockups Implementation (HTML & CSS) Review Leads to Compromises
- 22. Leads to Compromises Wireframes Mockups Implementation (HTML & CSS) Review
- 23. When we don't have enough time to build a coherent vision for future features
- 24. we end up building this…
- 25. Title Text
- 26. Fitting the ideal design process into an agile development process is hard.
- 27. Fitting the ideal design process into an agile development process is hard. Really hard.
- 28. Our Goal
- 29. Strike a balance between rapid iteration and building a modular and extensible product.
- 30. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 31. Fog of War
- 35. This is what working in 2 week sprints can feel like
- 37. High Fidelity Low FidelityHigh Fidelity
- 38. The Fog of War is simply varying degrees of fidelity
- 39. The Fog of War is not a bad thing. ! If you know how to balance it you can use it to your advantage.
- 40. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 41. Our Approach
- 42. Scope long in low fidelity. Scope short in high fidelity.
- 43. What is the spectrum of fidelity?
- 44. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation Design Process
- 47. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) Fidelity
- 50. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity
- 51. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity
- 52. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
- 53. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
- 54. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
- 55. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
- 56. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
- 57. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
- 58. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) Low Fidelity Scope High Fidelity Medium Fidelity
- 59. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
- 60. Scope Explore User Flows as much as humanly possible Develop Information Architecture for every known object Begin to define new features Smaller concern for technical implementation Low Fidelity
- 61. Scope Map Critical Paths and attempt to account for as many states as possible within those paths Accommodate entry points to features that you aren’t committing to developing just yet. Tighter collaboration with developers to address implementation Medium Fidelity
- 62. Scope Mockups designed to give front-end developers a precise expectations of what each page/state should look like Avoid scope creep. Functionality can be reduced to hit shipping targets. Features are shippable and usable Tight collaboration with developers to address implementation High Fidelity
- 63. Applying this to our Agile Development Process
- 64. Sprint
- 65. Sprint
- 66. Sprint Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
- 67. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review
- 68. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review
- 69. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review UX
- 70. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review UI UX
- 71. High Fidelity Medium Fidelity Low Fidelity Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review UI UX
- 72. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review UI UX
- 73. UI UX
- 74. There are many ways to implement this, depending on the structure of your team. ! Here’s how we currently do it…
- 75. UI UX UX UI 1 Sprint Multiple Sprints 1 Sprint
- 76. UI UX UX UI 1 Sprint Multiple Sprints 1 Sprint
- 77. UI UX UX UI 1 Sprint Multiple Sprints 1 Sprint
- 78. UI UX UX UI 1 Sprint Multiple Sprints 1 Sprint
- 79. Fog
- 80. Low Fidelity Fog
- 81. Low Fidelity Fog
- 84. Low Fidelity Medium Fidelity High Fidelity Fog
- 85. Risks
- 86. Working at low and medium fidelities can be risky Easy to over simplify Overlook potential problems Spend too much time refining
- 87. Inversely, if you put too much time and effort into high fidelity, changes become expensive to make
- 88. Ensuring that we are making the right decisions at the right fidelity is crucial
- 89. If you don’t you’ll end up increasing your cost of change which defeats the purpose of working at a low fidelity
- 90. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 91. “Change is your best friend. The more expensive it is to make a change, the less likely you'll make it. And if your competitors can change faster than you, you're at a huge disadvantage. If change gets too expensive, you're dead.” ! - 37 Signals, gettingreal.37signals.com 2009
- 92. Cost of Change
- 93. 0 100 200 300 400 Personas User Flows Wireframes Prototypes Mockups Implementation Cost of Change
- 94. Some of the methods we use to clear the fog and keep the cost of change low
- 96. Personas
- 97. Little thing that we do Building Personas Based on Real Data
- 98. Confession: We’re still working on that
- 99. No Bullshit Personas ! by Kristen Johansen from lynda.com http://www.slideshare.net/kristenjohansen/nobullsht-personas
- 100. User Flows
- 101. Little thing that we do Continuously Talk to Users
- 102. When it comes to users, we are a little spoilt at Mobify
- 104. Build user flows whilst talking to Users
- 105. Title Text Developer Setup Legend Adaptive.js Customer Touchpoint (Email) Last edit: Monday, March 24 at 11:23 Preview Bundle Push First Bundle Inspect Bundle Publish First Bundle Install Tag Verify TagDocs Verification Error Tag Installed? No Yes Successful Publish Tag Settings Setup Local Project Create Project Setup Documentation Get Slug/Init Command Generate Scaffold Slugs need to be exposed send to device open in new window Locally “View on localhost” useless Notification sent Via Email/Web Push Notification Publish in Progress Review Automated Testing Results Task Supporting Input/Action Task External to Cloud Develop Bundle Locally + Github URL Site Name Download Bundle 1 First Time Only Get Tools 1 npm install instructions Download “Client”, Grunt, Yeoman Download Adaptive.js Windows OS X Linux View Documentation Get API Key Developers are less likely to setup or even use cloud at all if they are working on a large team with Producers/QA. Smaller teams however would mean the developer is responsible for everything.
- 106. Go back and talk to Users again
- 107. Title Text QA Setup Flow Legend Adaptive.js Customer Touchpoint (Email) Last edit: Monday, March 24 at 11:23 Add other QA Members to Project Setup Local Project (via Github) Login via Console Pull Branch from Github Preview locally Push Bundle to Cloud Inspect Bundle Get URL for Device Preview Site URL Mobify Preview (Visible to Client) Bundle Location Domain Mobify This/All Tabs Authorize Install Tools 1 npm install instructions Download “Client”, Grunt, Yeoman Download Adaptive.js Windows OS X Linux View Documentation Get API Key Push Bundle QA usually has to setup permissions for their own team members. The tag will be installed for them but they will be making changes to the path. They will never be publishing during the setup of a project, that usually happens later in the QA process. They are more likely to send out a preview for the client. Review Automated Testing Results
- 108. Then go back and talk to Users again
- 109. Seriously, you’ll learn something new each time.
- 111. Little thing that we do Look at the database
- 112. If you don’t know how, get a developer to help you.
- 113. Even better, get them to set you up with a GUI like Sequel Pro www.sequelpro.com
- 114. Title Text Information Architecture Legend Adaptive.js Customer Touchpoint (Email) Last edit: Monday, March 24 at 11:23 Inspect Bundle open in new window Download Bundle Automated Test Results Download ToolsList Team Members Install Tag Verify Tag Verification Error Add (Push) Bundles Tag Installed? NoYes Configure Publish in Progress Bundles Analytics (Future) Team Publish Preview Delete List Bundles Invite Members Remove Member send to device Inspect Member URL Site Name Tag Proxy Modify Role Get API Key Delete Project Tag Manage Google Analytics (a.js) Set Device Support Manage Targets* Verify Tag Unpublish Notification sent Via Email/ Web Push Notification Link to Docs Link to Docs Tag Verified Verification Status Link to Manage Organization Get Slug
- 115. The more that your Information Architecture can be mapped to the data model the more likely it is that your users will understand your application.
- 116. Wireframes
- 117. Little thing that we do Real Data
- 119. Avoid the temptation to make wireframes aesthetically pleasing
- 122. Focus on real data/content, or at least as close to real as possible.
- 123. Focus on real data/content, or at least as close to real as possible. Every time you use Lorem Ipsum a content strategist somewhere drops dead. No Joke.
- 124. Remember to keep the cost of change low
- 125. Prototyping
- 126. Little thing that we do Use a tool that lets us wireframe and create clickable prototypes
- 127. Wireframes can easily be made to be interactive and clickable. Downside is it’s in PDF format, not on the web and hard to collaborate and annotate. We use Omnigraffle
- 128. There’s plenty of other similar tools, just find the one that’s best for your needs.
- 129. Mockups
- 130. Little thing that we do Design within the context of the Browser
- 132. Whether we like it or not, the browser is a part of our UI
- 133. Helps you design your URLs
- 134. OK, we’re at slide number 100, lets wrap this up.
- 135. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 136. Agile is great for constantly delivering value and rapidly iterating
- 137. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 138. A good design process is hard to fit into small and iterative sprints
- 139. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 140. Strict Agile methodologies inherently create a short sighted ‘Fog of War’
- 141. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 142. We can strategically uncover those layers of fog with varying degrees of fidelity. ! Scope long in low fidelity, Scope short in high fidelity.
- 143. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
- 144. Be mindful of your cost of change when working at different levels of fidelity. ! It can make or break the whole process.
- 145. Thanks for your time!
- 146. Questions?
Notas do Editor
- Now that you know a little about me and my team…
- Not surprising a lot of people are familiar with Agile?
- How incremental you might ask?
- Hard for designers to do
- This is a lot to do in 2 weeks!
- Don’t look ahead, build a slum
- A favela of features
- Really Hard!
- we should build towards a long term vision
- The Fog of War is a game mechanic
- Moving your units in unison at the same pace is a bad strategy
- Can’t see opponent. Strategically you can see terrain and resources.
- If you strictly stick to 2 weeks sprints you wont see far ahead
- Design too much future detail, outdated before development and you spread your team too thin. Also a bad strategy.
- Let looks at the output
- You want to avoid your high fidelity catching up with your low fidelity. This essentially means you have no vision into the future.
- Useable and user testable prototypes are what we consider a “shipped” feature in a UX sprint.
- The spectrum of fidelity
- Make sure you are taking any changes you’ve made at high fidelities and updating your lower fidelity assets.
- Simplify, Overlook, Too much time
- Not just money, but time and effort that could be spent on other things. This is not based on hard data, just past experience.
- Our most valuable users work in the same building, only steps away from us.
- Not necessarily 1:1, your IA should still simplify the complexities of your data model
- lower fidelity sets expectations that it’s work in progress, cost of change is lower. Worry about visual aesthetics later
- If your wireframes look so good you think you should post them to Dribbble then you are doing it wrong
- This one is specifically for web apps, but you can thane this approach and apply to other platforms
- Improves your ability to communicate clearly with developers what your intentions are and keeps your IA in good shape