Designing Under the Agile fog of war

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


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


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


Wireframes

Prototypes

User TestingMockups


User Testing

Review

Validation

Personas

User Flows


Wireframes

Prototypes

User TestingMockups


User Testing

Review

Validation

2 Week Sprint

Personas

User Flows


Wireframes

Prototypes

User TestingMockups


User Testing

Review

Validation

Personas

User Flows


Wireframes

Prototypes

User TestingMockups


User Testing

Review

Validation

Personas

User Flows


Wireframes

Prototypes

User TestingMockups


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


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


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


Wireframes

Prototypes

User Testing

Mockups


User Testing

Review

Validation

Design Process

User Flows


Wireframes

Prototypes

Mockups


User Flows


Wireframes

Prototypes

Mockups


User Flows


Wireframes

Prototypes

Mockups


Fidelity

User Flows


Wireframes

Prototypes

Mockups


User Flows


Wireframes

Prototypes

Mockups


User Flows


Wireframes

Prototypes

Mockups

Implementation (HTML & CSS) High Fidelity

Medium Fidelity

Low Fidelity

User Flows


Wireframes

Prototypes

Mockups


Medium Fidelity

Low Fidelity

User Flows


Wireframes

Prototypes

Mockups


Medium Fidelity

Low Fidelity

Scope

User Flows


Wireframes

Prototypes

Mockups


Medium Fidelity

Low Fidelity

Scope

User Flows


Wireframes

Prototypes

Mockups


Medium Fidelity

Low Fidelity

Scope

User Flows


Wireframes

Prototypes

Mockups


Medium Fidelity

Low Fidelity

Scope

User Flows


Wireframes

Prototypes

Mockups


Medium Fidelity

Low Fidelity

Scope

User Flows


Wireframes

Prototypes

Mockups


Medium Fidelity

Low Fidelity

Scope

User Flows


Wireframes

Prototypes

Mockups


Low Fidelity

Scope

High Fidelity

Medium Fidelity

User Flows


Wireframes

Prototypes

Mockups


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


Wireframes

Prototypes

User TestingMockups


User Testing

Review

Validation

Personas

User Flows


Wireframes

Prototypes

User Testing

Mockups


User Testing

Review

Review

Personas

User Flows


Wireframes

Prototypes

User Testing

Mockups


User Testing

Review

Review

Personas

User Flows


Wireframes

Prototypes

User Testing

Mockups


User Testing

Review

Review

UX

Personas

User Flows


Wireframes

Prototypes

User Testing

Mockups


User Testing

Review

Review

UI

UX

High Fidelity

Medium Fidelity

Low FidelityPersonas

User Flows


Wireframes

Prototypes

User Testing

Mockups


User Testing

Review

Review

UI

UX

Personas

User Flows


Wireframes

Prototypes

User Testing

Mockups


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


UI

UX UX

UI


UI

UX UX

UI


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


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

http://gettingreal.37signals.com

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


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

http://lynda.com

http://www.slideshare.net/kristenjohansen/nobullsht-personas

User Flows


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)


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.



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

http://www.sequelpro.com

Title Text

Information Architecture Legend Adaptive.jsCustomer

Touchpoint (Email)


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


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


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


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


Clearing the Fog

Cost Of Change

Agile is great for constantly delivering value and rapidly iterating

Development Process

Design Process


Clearing the Fog

Cost Of Change

A good design process is hard to fit into small and iterative sprints

Development Process

Design Process


Clearing the Fog

Cost Of Change

Strict Agile methodologies inherently create a short sighted ‘Fog of War’

Development Process

Design Process


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


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?