agile ux in practice  

@meelijane

Amelia Schmidt

what does it mean to do ux in an Agile way?

ux is well suited to product development

User research to discover a problem that needs to be solved.
Document knowledge about the users it affects and other context.

Refine and define the problem. Define what it means to solve the problem. Define what it means to have a successful solution.

Research how to solve the problem. Analyse competitor solutions. Reframe.

Ideate and iterate. Bring together stakeholders and users to help think of solutions.

Prototype and test those solutions. Potentially build and launch MVPs.

Gather and document feedback. Potentially decide on a solution to build with stakeholders.

Flesh out the solution. Build higher fidelity designs if required. Scope out implementation.

Build the solution. Make sure you can measure success. Measure if it's working.

product: multiple features at any time

so sometimes those "products" are actually "features"

and they are planned with a "product roadmap"

roadmaps usually are made up of features (not goals or themes)

...and are created in order to manage stakeholder expectations

the ux process is based on not knowing the solution in advance  

ux might need to be a few steps ahead of the delivery team, researching and validating

in larger orgs, there are often multiple cross-functional teams working on features in tandem

User research to discover a problem that needs to be solved.
Document knowledge about the users it affects and other context.

Refine and define the problem. Define what it means to solve the problem. Define what it means to have a successful solution.

Research how to solve the problem. Analyse competitor solutions. Reframe.

Ideate and iterate. Bring together stakeholders and users to help think of solutions.

Prototype and test those solutions. Potentially build and launch MVPs.

Gather and document feedback. Potentially decide on a solution to build with stakeholders.

Flesh out the solution. Build higher fidelity designs if required. Scope out implementation.

Build the solution. Make sure you can measure success. Measure if it's working.

These bits might be done by UX while other people do other things

User research to discover a problem that needs to be solved.
Document knowledge about the users it affects and other context.

Refine and define the problem. Define what it means to solve the problem. Define what it means to have a successful solution.

Research how to solve the problem. Analyse competitor solutions. Reframe.

Ideate and iterate. Bring together stakeholders and users to help think of solutions.

Prototype and test those solutions. Potentially build and launch MVPs.

Gather and document feedback. Potentially decide on a solution to build with stakeholders.

Flesh out the solution. Build higher fidelity designs if required. Scope out implementation.

Build the solution. Make sure you can measure success. Measure if it's working.

These bits might be done by UX while other people do other things

not all agile ux is in a product development environment

agency: multiple client projects at any time

workflow and activities for ux can change depending on the project and requirements

floating

ux team

project

delivery team

project

delivery team

project

delivery team

ux agency or consultant

client who does delivery

client who does delivery

client who does delivery

client who does delivery

in an ideal world...

your team should be cross-functional

back-end developer

designer

QA

front-end developer

unfortunately, ux is still in a silo in many orgs  

ux

engineering

testing

sales

try: pairing

Hypothesis: building a new front page for the store will result in more people buying products

Let's validate the assumption that users don't like the current store homepage.

I'll join you for that research so I can build a better sense of  what is and isn't working for users

We found that the current homepage isn't working and why. Now we need to figure out

some ways to make it better.

Let's sketch together. I have some ideas about how to improve it that might be helpful.

Great. Now we can test some of these ideas. Can you get started on anything while I do some mockups and usability tests?

Sure. We need to make it possible to create new pages and it sounds like we need to build a way to support A/B testing

I think we have a couple of things we should build into production. I'll annotate the wireframes so you can get started.

Sure. Have you got enough to build while I do that?

Great. Hey, when you complete the new nav, can you let me know? We might put that in front of a few users to make sure the design pattern is working.

Make sure it's hooked up with these metrics so we can measure whether it's had any effect.

Of course. The way you've made it work on small screens isn't ideal, and there's an accessibility concern with this button...

your work should be timeboxed

"what can we get done in the next two weeks?"
vs
"let's do these ten tasks."

remember: agile means being flexible around scope

not just: cutting down costs and doing things faster

you can't have a strict roadmap and a strict idea of what you'll be building

timeboxing can also help you with scoping a piece of work

"let's do the version of this that can be done in a week"

you'll need to break your work down into small pieces

...without missing the "big picture"

what is the minimum viable product for each feature?

mvp: the minimum amount of work you can do so you can learn what you need

(repeat until...)

ask yourself: how can this big idea be broken down into smaller pieces that can be shipped iteratively?

test-driven design at clover.com.au

the goal:

we want to give users more financial advice before they sign up.

discover:

what is the scope of the advice we want to tackle?

validate:

do users actually want advice on these things?

to test:

should we give them small chunks of advice or a big report of advice?

discover:

what are the risks of either approach? how can we mitigate them?

ideate:
what are some ways that we can give this advice?

refine:
which ways do we want to try?

prototype:
let's test two of these ideas with users

build:
we'll build the ideas and make sure we can measure them

the case against agile ux

sometimes you miss out on the bigger picture by breaking things down

ux takes time. it doesn't always fit in a box. some ideas can't be shipped iteratively.

to do this properly we can't plan too far ahead.

designers are experts and you should trust their instincts

many companies have adopted agile in an attempt to bring costs down and move faster

"engineers are expensive"

well, ux is expensive too

agile puts pressure on ux to move too fast  

the case for agile ux

to do this properly we can't plan too far ahead.

it limits the amount of superhero opinion-based design

it protects us against opinion-based design in general

it forces us to validate frequently

it requires us to work outside of a silo and build empathy for our team

it builds a culture where ux isn't a "stage" but more an ongoing activity

agile is not only about bringing costs down. it's about bringing risk down.

agile teams should be comfortable with the give and take of cross-functional pairing

i.e. sometimes your devs won't be writing code.

but what they'll be doing will be just as important

questions for you

in this course you've been working on your individual project in a ux silo... 

now you've met with your client and you'll be working "with" them

how will you design this idea in a cross-functional team?

what will your role as ux designer look like when your idea starts being built?

have you designed the mvp?

questions?