View
798
Download
1
Category
Tags:
Preview:
DESCRIPTION
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.
Citation preview
Designing Under the Agile Fog of War
James Bryant @jamesbryant86
Designer at Mobify
Product TeamProduct TeamProduct Team
Product team at Mobify builds tools that help our users create amazing
mobile web experiences.
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
Agile Software Development
Iterative and Incremental
We work in 2 week sprints
Ship code every sprint.
“Small diffs are better than big bangs” !
- John Boxall, CTO at Mobify
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
Design Process
Design Process
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User TestingMockups
Implementation (HTML & CSS)
User Testing
Review
Validation
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User TestingMockups
Implementation (HTML & CSS)
User Testing
Review
Validation
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User TestingMockups
Implementation (HTML & CSS)
User Testing
Review
Validation
2 Week Sprint
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User TestingMockups
Implementation (HTML & CSS)
User Testing
Review
Validation
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User TestingMockups
Implementation (HTML & CSS)
User Testing
Review
Validation
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User TestingMockups
Implementation (HTML & CSS)
User Testing
Review
Validation
Wireframes
MockupsImplementation (HTML & CSS)
ReviewLeads to
Compromises
Leads to Compromises
Wireframes
MockupsImplementation (HTML & CSS)
Review
When we don't have enough time to build a coherent vision for future features
we end up building this…
Title Text
Fitting the ideal design process into an agile development process is hard.
Fitting the ideal design process into an agile development process is hard.
Really hard.
Our Goal
Strike a balance between rapid iteration and building a modular and extensible product.
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
Fog of War
This is what working in 2 week sprints
can feel like
High Fidelity Low FidelityHigh Fidelity
The Fog of War is simply varying degrees of fidelity
The Fog of War is not a bad thing. !
If you know how to balance it you can use it to your advantage.
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
Our Approach
Scope long in low fidelity. Scope short in high fidelity.
What is the spectrum of fidelity?
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User Testing
Mockups
Implementation (HTML & CSS)
User Testing
Review
Validation
Design Process
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS)
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS)
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS)
Fidelity
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS)
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS)
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
Scope
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
Scope
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
Scope
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
Scope
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
Scope
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
Scope
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS)
Low Fidelity
Scope
High Fidelity
Medium Fidelity
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Implementation (HTML & CSS) High Fidelity
Medium Fidelity
Low Fidelity
Scope
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
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
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
Applying this to our Agile Development Process
Sprint
Sprint
Sprint
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User TestingMockups
Implementation (HTML & CSS)
User Testing
Review
Validation
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User Testing
Mockups
Implementation (HTML & CSS)
User Testing
Review
Review
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User Testing
Mockups
Implementation (HTML & CSS)
User Testing
Review
Review
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User Testing
Mockups
Implementation (HTML & CSS)
User Testing
Review
Review
UX
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User Testing
Mockups
Implementation (HTML & CSS)
User Testing
Review
Review
UI
UX
High Fidelity
Medium Fidelity
Low FidelityPersonas
User Flows
Information Architecture
Wireframes
Prototypes
User Testing
Mockups
Implementation (HTML & CSS)
User Testing
Review
Review
UI
UX
Personas
User Flows
Information Architecture
Wireframes
Prototypes
User Testing
Mockups
Implementation (HTML & CSS)
User Testing
Review
Review
UI
UX
UI
UX
There are many ways to implement this, depending on the structure of your team.
!
Here’s how we currently do it…
UI
UX UX
UI
1 Sprint Multiple Sprints 1 Sprint
UI
UX UX
UI
1 Sprint Multiple Sprints 1 Sprint
UI
UX UX
UI
1 Sprint Multiple Sprints 1 Sprint
UI
UX UX
UI
1 Sprint Multiple Sprints 1 Sprint
Fog
Low Fidelity
Fog
Low Fidelity
Fog
Low Fidelity
Medium Fidelity
Fog
Low Fidelity
Medium Fidelity
Fog
Low Fidelity
Medium Fidelity
High Fidelity
Fog
Risks
Working at low and medium fidelities can be risky
Easy to over simplify Overlook potential problems Spend too much time refining
Inversely, if you put too much time and effort into high fidelity, changes
become expensive to make
Ensuring that we are making the right decisions at the right fidelity is crucial
If you don’t you’ll end up increasing your cost of change which defeats
the purpose of working at a low fidelity
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
“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
Cost of Change
0
100
200
300
400
Personas User Flows Wireframes Prototypes Mockups Implementation
Cost of Change
Some of the methods we use to clear the fog and keep the
cost of change low
Personas
User Flows
Information Architecture
Wireframes
Prototypes
Mockups
Personas
Little thing that we do
Building Personas Based on Real Data
Confession: We’re still working on that
No Bullshit Personas !
by Kristen Johansen from lynda.com http://www.slideshare.net/kristenjohansen/nobullsht-personas
User Flows
Little thing that we do
Continuously Talk to Users
When it comes to users, we are a little spoilt at Mobify
Build user flows whilst talking to Users
Title Text
Developer Setup Legend Adaptive.jsCustomer
Touchpoint (Email)
Last edit: Monday, March 24 at 11:23
Preview BundlePush First
BundleInspect 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 instructionsDownload “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.
Go back and talk to Users again
Title Text
QA Setup Flow Legend Adaptive.jsCustomer
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 instructionsDownload “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
Then go back and talk to Users again
Seriously, you’ll learn something new each time.
Information Architecture
Little thing that we do
Look at the database
If you don’t know how, get a developer to help you.
Even better, get them to set you up with a GUI like Sequel Pro
www.sequelpro.com
Title Text
Information Architecture Legend Adaptive.jsCustomer
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 DocsTag Verified
Verification Status
Link to Manage Organization
Get Slug
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.
Wireframes
Little thing that we do
Real Data
Avoid the temptation to make wireframes aesthetically pleasing
Focus on real data/content, or at least as close to real as possible.
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.
Remember to keep the cost of change low
Prototyping
Little thing that we do
Use a tool that lets us wireframe and create clickable prototypes
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
There’s plenty of other similar tools, just find the one that’s best for your needs.
Mockups
Little thing that we do
Design within the context of the Browser
Whether we like it or not, the browser is a part of our UI
Helps you design your URLs
OK, we’re at slide number 100, lets wrap this up.
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
Agile is great for constantly delivering value and rapidly iterating
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
A good design process is hard to fit into small and iterative sprints
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
Strict Agile methodologies inherently create a short sighted ‘Fog of War’
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
We can strategically uncover those layers of fog with varying degrees of fidelity.
!
Scope long in low fidelity, Scope short in high fidelity.
Development Process
Design Process
The Agile Fog of War
Clearing the Fog
Cost Of Change
Be mindful of your cost of change when working at different levels of fidelity.
!
It can make or break the whole process.
Thanks for your time!
Questions?
Recommended