Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Designing Under the Agile fog of war

2,752 views

Published on

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.

Published in: Design, Technology
  • DOWNLOAD FULL MOVIE, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... ,DOWNLOAD FULL. MOVIE 4K,FHD,HD,480P here { https://tinyurl.com/yybdfxwh }
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Designing Under the Agile fog of war

  1. 1. Designing Under the Agile Fog of War
  2. 2. James Bryant @jamesbryant86
  3. 3. Designer at Mobify
  4. 4. Product TeamProduct TeamProduct Team
  5. 5. Product team at Mobify builds tools that help our users create amazing mobile web experiences.
  6. 6. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  7. 7. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  8. 8. Agile Software Development
  9. 9. Iterative and Incremental
  10. 10. We work in 2 week sprints
  11. 11. Ship code every sprint.
  12. 12. “Small diffs are better than big bangs” ! - John Boxall, CTO at Mobify
  13. 13. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  14. 14. Design Process
  15. 15. Design Process Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
  16. 16. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
  17. 17. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
  18. 18. 2 Week Sprint Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
  19. 19. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
  20. 20. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
  21. 21. Wireframes Mockups Implementation (HTML & CSS) Review Leads to Compromises
  22. 22. Leads to Compromises Wireframes Mockups Implementation (HTML & CSS) Review
  23. 23. When we don't have enough time to build a coherent vision for future features
  24. 24. we end up building this…
  25. 25. Title Text
  26. 26. Fitting the ideal design process into an agile development process is hard.
  27. 27. Fitting the ideal design process into an agile development process is hard. Really hard.
  28. 28. Our Goal
  29. 29. Strike a balance between rapid iteration and building a modular and extensible product.
  30. 30. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  31. 31. Fog of War
  32. 32. This is what working in 2 week sprints can feel like
  33. 33. High Fidelity Low FidelityHigh Fidelity
  34. 34. The Fog of War is simply varying degrees of fidelity
  35. 35. The Fog of War is not a bad thing. ! If you know how to balance it you can use it to your advantage.
  36. 36. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  37. 37. Our Approach
  38. 38. Scope long in low fidelity. Scope short in high fidelity.
  39. 39. What is the spectrum of fidelity?
  40. 40. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation Design Process
  41. 41. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS)
  42. 42. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS)
  43. 43. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) Fidelity
  44. 44. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS)
  45. 45. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS)
  46. 46. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity
  47. 47. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity
  48. 48. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
  49. 49. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
  50. 50. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
  51. 51. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
  52. 52. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
  53. 53. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
  54. 54. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) Low Fidelity Scope High Fidelity Medium Fidelity
  55. 55. User Flows Information Architecture Wireframes Prototypes Mockups Implementation (HTML & CSS) High Fidelity Medium Fidelity Low Fidelity Scope
  56. 56. 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
  57. 57. 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
  58. 58. 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
  59. 59. Applying this to our Agile Development Process
  60. 60. Sprint
  61. 61. Sprint
  62. 62. Sprint Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Validation
  63. 63. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review
  64. 64. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review
  65. 65. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review UX
  66. 66. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review UI UX
  67. 67. 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
  68. 68. Personas User Flows Information Architecture Wireframes Prototypes User Testing Mockups Implementation (HTML & CSS) User Testing Review Review UI UX
  69. 69. UI UX
  70. 70. There are many ways to implement this, depending on the structure of your team. ! Here’s how we currently do it…
  71. 71. UI UX UX UI 1 Sprint Multiple Sprints 1 Sprint
  72. 72. UI UX UX UI 1 Sprint Multiple Sprints 1 Sprint
  73. 73. UI UX UX UI 1 Sprint Multiple Sprints 1 Sprint
  74. 74. UI UX UX UI 1 Sprint Multiple Sprints 1 Sprint
  75. 75. Fog
  76. 76. Low Fidelity Fog
  77. 77. Low Fidelity Fog
  78. 78. Low Fidelity Medium Fidelity Fog
  79. 79. Low Fidelity Medium Fidelity Fog
  80. 80. Low Fidelity Medium Fidelity High Fidelity Fog
  81. 81. Risks
  82. 82. Working at low and medium fidelities can be risky Easy to over simplify Overlook potential problems Spend too much time refining
  83. 83. Inversely, if you put too much time and effort into high fidelity, changes become expensive to make
  84. 84. Ensuring that we are making the right decisions at the right fidelity is crucial
  85. 85. If you don’t you’ll end up increasing your cost of change which defeats the purpose of working at a low fidelity
  86. 86. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  87. 87. “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
  88. 88. Cost of Change
  89. 89. 0 100 200 300 400 Personas User Flows Wireframes Prototypes Mockups Implementation Cost of Change
  90. 90. Some of the methods we use to clear the fog and keep the cost of change low
  91. 91. Personas User Flows Information Architecture Wireframes Prototypes Mockups
  92. 92. Personas
  93. 93. Little thing that we do Building Personas Based on Real Data
  94. 94. Confession: We’re still working on that
  95. 95. No Bullshit Personas ! by Kristen Johansen from lynda.com http://www.slideshare.net/kristenjohansen/nobullsht-personas
  96. 96. User Flows
  97. 97. Little thing that we do Continuously Talk to Users
  98. 98. When it comes to users, we are a little spoilt at Mobify
  99. 99. Build user flows whilst talking to Users
  100. 100. 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.
  101. 101. Go back and talk to Users again
  102. 102. 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
  103. 103. Then go back and talk to Users again
  104. 104. Seriously, you’ll learn something new each time.
  105. 105. Information Architecture
  106. 106. Little thing that we do Look at the database
  107. 107. If you don’t know how, get a developer to help you.
  108. 108. Even better, get them to set you up with a GUI like Sequel Pro www.sequelpro.com
  109. 109. 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
  110. 110. 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.
  111. 111. Wireframes
  112. 112. Little thing that we do Real Data
  113. 113. Avoid the temptation to make wireframes aesthetically pleasing
  114. 114. Focus on real data/content, or at least as close to real as possible.
  115. 115. 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.
  116. 116. Remember to keep the cost of change low
  117. 117. Prototyping
  118. 118. Little thing that we do Use a tool that lets us wireframe and create clickable prototypes
  119. 119. 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
  120. 120. There’s plenty of other similar tools, just find the one that’s best for your needs.
  121. 121. Mockups
  122. 122. Little thing that we do Design within the context of the Browser
  123. 123. Whether we like it or not, the browser is a part of our UI
  124. 124. Helps you design your URLs
  125. 125. OK, we’re at slide number 100, lets wrap this up.
  126. 126. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  127. 127. Agile is great for constantly delivering value and rapidly iterating
  128. 128. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  129. 129. A good design process is hard to fit into small and iterative sprints
  130. 130. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  131. 131. Strict Agile methodologies inherently create a short sighted ‘Fog of War’
  132. 132. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  133. 133. We can strategically uncover those layers of fog with varying degrees of fidelity. ! Scope long in low fidelity, Scope short in high fidelity.
  134. 134. Development Process Design Process The Agile Fog of War Clearing the Fog Cost Of Change
  135. 135. Be mindful of your cost of change when working at different levels of fidelity. ! It can make or break the whole process.
  136. 136. Thanks for your time!
  137. 137. Questions?

×