Designing Under the Agile fog of war

2,534 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
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,534
On SlideShare
0
From Embeds
0
Number of Embeds
64
Actions
Shares
0
Downloads
12
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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
  • 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?

    ×