Paul Dawson - Walking the line: The Role of Product Development.

flux[x] @fluxxstudios @poleydee

Friday 9th November

Paul Dawson, Partner at Fluxx

Walking the line: The Role of Product Development

• Product development is, or at least should be, a user-centred discipline, but often has a strained relationship with the design teams that have to bring that product to life.

• • We’ll look in this session at what the role of Product Development is,

how more and more companies are thinking of their digital services as ‘product’, and the very thin line Product Development has to tread in the user-centred design process between empowering a design team, and potentially alienating them altogether.

This document and its content is Copyright ©2012 Paul Dawson and UCD UK Limited. No rights are claimed over third party images, all of which are used under ‘fair use’ and whose origin is acknowledged wherever possible.


Walking the line:The Role of Product

Development

Paul DawsonPartner, Experience & Innovation, Fluxx


The boring cred’s bit


A product & service innovation company

Setting Strategy & Vision Developing & validating products

Innovation practices & long term change


Ideal outcomes from this session?

Digital UX

Product design

Product development.

How to get better briefs that allow you to explore interesting opportunities and less dispute with the people who are ‘leading’ it

How to get closer to the product you had envisioned, and create greater harmony with the team tasked with making it great

“wtf ?”


There are two types of organisation in the world


Develop, design and sell prod-ucts


Behave like they are a product company

Don't behave like a product company



New Product Development (NPD)

Strategy Ideas and insight R&D Concepts Developed & Validated Concepts

(Desirability, Viability, Feasibility) Partnerships and organisation Design & Build Operate


The ‘Non Product’ Approach



ResearchBusiness Case

Investment decision




Opinions, guesswork

and speculation

The ‘Non Product’ Approach


Fortunately, most digital projects I’ve worked on start

here:


But then they go one of two ways:

Exciting, interesting, innovative.

Empowered, creative, inspired

Detailed, monotonous, not thinking for myself

Demotivated, dis-spirited, ‘done to’

What if…

Wireframes

An exploration of why What new opportunities there might be within itNew ideas, ‘blue sky’ thinking,…

Well, they seem to have made up their minds, we’ll just get on and be the wireframe monkeys shall we?


What if companies who know they are product

companies did not behave like product companies?


An imaginary new product

“A new range of luggage specifically for the family”

The budget is setThe board is all behind it


Stage 1: Research

When product companies don’t behave like product

companies


Stage 2: Envisioning

When product companies don’t behave like product

companies


We could pre-load them with things people need


We could do niche products for specialist audiences


Hey, what if the suitcase became a mode of transport?!

Hey, what if the suitcase actually became the holiday?


But then…

“Product Owner”

But suddenly…

The more radical thinking simply gets dropped as it can’t be validated

Ideas may be good, they might not. Nobody is in a position to judge before time starts running out.

“We’ve got a whole stack of basics to do first”


Agile approaches in non-product thinking companies…

Things we know we can do

Things we know our customers value

The unproven ideas domain


Stage 3:New ideas get pushed to the back and we focus in on the basics, having no time, resource or remit to

progress our half-formed ideas, no matter how brilliant they were…


but…

We have bright people, all eager to unleash their creative juices and we

lost them quite early on…


The Line


Empowered, creative, inspiring



Anything is possible

I have a very tight, prescriptive brief


We might have had the ‘right ideas’


but we haven’t been able to ‘make those ideas right’


Now design something magnificent

What we needed was an inspiring brief with real possibilities

“Design a suitcase that children and parents will love.

We know that hassled parents and kids will love a ride-on case. We can save tired parent arms and tired toddler legs and

make travel fun.”

Research & Insight:

A clear product proposition:


And that’s what product development is


Product Development is pure UCD

But it doesn’t design interfaces, and it’s not concerned with usability or

ergonomics

desirable feasible

viable


Product Development’s Goals

1. To flesh out and validate product and service propositions

Desirable: Customers will find value in itFeasible: We can make it workViable: It can be an economic success

2. Prove that this is the right thing to do, kill it early, or learn enough to turn it into the right thing to do

3. To arm a design and build team with all they need to get the product designed and built in the right way


But what many product development teams miss is…

That once they’ve ‘developed’ the idea into a product, the customer experience still has to be

designed

(because generally, they’re a bit crap at doing that bit!)


I’ve been on both sides

Digital UXProduct development.


“The CEO had a designer mock something up”

“We’ve had a product design

consultancy working on it”

“We’ve developed a new brand, and the branding agency have

done some mock-ups”

Words that strike terror…


“Here’s how it could look”

Movie UI Design by Jayse Hansen


Getting the wrong side of the line only leads to confl ict…

“Arrogant tossers, they just don’t get it!”

“Ha, they’re so wrong. This is a much better idea.”


Today’s Line








Setting out to raise the bar







“Mmmm. Nice concept, full of possibility.

Will be fun to see how we make it work.”


So two key questions:

How do you do this cost-effectively?

We already think we don’t have enough time for design – how do you make it worth investing in?

How do we ensure this process does not entirely alienate design and development teams?


Three answers

Focus on generating facts, not opinions; and be lean about it

Enable and equip your design & build team, don’t tell them what to do

Don’t be precious – about your ideas, or being right


Focus on generating facts, not opinions; and be lean about it


Flux[x] Labs





insight idea feasibility

design & development manufacture distribution


Hard to do, and a lot of risk

manufacture

design & development

feasibility

Idea

distribution

insight

Easy to do, and no risk

Starting to invest time & money


Hard to do, and a lot of risk

manufacture


feasibility

Idea

insight

Easy to do, and no risk

Starting to invest time & money



MVP = Minimum Viable Product

Q: What is the absolute minimum we can do to see if people actually value our

product?

http://en.wikipedia.org/wiki/File:Zappos_logo_color.jpg

http://en.wikipedia.org/wiki/File:Zappos_logo_color.jpg


distribution

Dim and distant past

insight

concept

feasibility


manufacture

Painful, but we got there…

Dragon’s Den

Give it to the press

Bankrupt factory

Dodgy catches

People bought it

Licensee liquidated



He believed because he had generated facts

The toughness of his journey was testament to the fact that his MVP could not be that minimal


Fortunately…

This now happens in days, or maybe weeks, but certainly not months.

The Lab’s job within a product development cycle is to generate

evidence-based learning, to help get the ideas right, and make good decisions

based on facts

labs

labs

Basic Insight

We found it really hard to fi nd a

whiteboard the size we want and think

that other people will have the same

problem.

labs

This leads to a value hypothesis that we can begin to test

“We think that people will value a premium service that makes and

installs whiteboards to a precise set of dimensions.”

labs

1. Make a site that calculates the cost and puts customers in touch with us.

2. Get a phone!

If people value this service as

much as we do.Volume of people searching for it on GoogleRequests for pricingPeople who buy

labs

The fi rst MVP(c.2 days)

labs

The 2nd MVP

labs

The Lab’s Learnings

This is a viable, small, local business.

It would be a good idea to make the whiteboards erasable!

It is possible in a week to prove out a digital & physical business in a lean way

labs

“The High Street Bank”

A real life case study

labs

Amongst others, we created

one experiment designed to

test something that had been

debated for ages at the bank

labs

It was a thorny subject.

It involved using customers’

personal data to do something

we thought they would like and

value.

labs

But would they accept it, or

would they go nuts and call the

Daily Mail?

We put it live in a few weeks in an MVP to

several thousand real customers who didn’t

know it was just an experiment.

labs

But before we did…

labs

It was usability tested

It panned!

Only 24% of people said they would do it

labs

How many ACTUALLY did it in

real life?

96% of people just jumped right on in!


“What people say they will do and what they actually do is often very different

and can be greatly affected by their level of awareness

of the task at hand”


Market Research (quant and qual)

Usability TestingPrototype Testing

A/B TestingMulti-variate testing

True ethnography

MVP/Lean

Market Intelligence and behavioural data

Unaware Aware

Product/ServiceMaturity Level

Idea/Concept

Partial/FullyDeveloped

Is the Useraware of the test?

The fluxx ‘Tested User’ Framework


A wide variety of opinions, ideas

and stories

Usability

Optimising where there are multiple

options

Proving an idea one way or the

other

History

Unaware Aware

Product/ServiceMaturity Level

Idea/Concept

Partial/FullyDeveloped

Is the Useraware of the test?

The fluxx ‘Tested User’ Framework

flux[x] @fluxxstudios @poleydeeflux[x] @fluxxstudios @poleydee

The outcome of which

is…Armed with facts, a product development

team can simply ‘tell’ they don’t ‘sell’

It’s hard to argue with, & people don’t want to

It’s equally obvious how to apply that data to influence the design later on


A key point here though is…

An MVP does not a design make

Which leads us to:

Enable and equip your design & build team; don’t tell them what to do


Briefing the team means focusing on the outcome

“Nice concept, full of possibility.

Will be fun to make it work.”


Briefing the team

Present the trail of evidence• A user-centred journey• Help the team understand

the insight on which the product was founded

• Don’t hide any facts• Show your wrong turns


What it should be like, not what it should look like

Briefing the team

Describe, don’t prescribe


Create useful assets. Things that wil l enable, not confi ne your design team

Draft PersonasIf you don’t know these, then the product you’ve developed isn’t worth the Omnigraffle it’s visualised on!

Product and Experience PrinciplesDistil your experience of the product development learnings into principles that will help guide the design and build team


What we don’t say:“Yeah, we already prototyped it”

Product development should never be testing a UI, or a brand VI

We ask questions like:• Is the content valuable to our audience?• Is the function that it performs valuable?• How easy or low cost does it have to be to become, in

order to become valuable?


Which has led us to a unique design principle:

Make it as bad as you can get away with(So long as you don’t get in the way of the core testing

objective)

“I’ve never been asked to make my work ‘more sh*t

before!”


How do you brief in how a product ‘feels’?

I’ll give you a briefing I’ve used many a time


Let me tell you why I love Virgin Atlantic




http://www.flickr.com/





http://www.flickr.com/










Which is easily summed up as:

Brilliant basics, magic touches

… and a number of other principles to which a user experience or product would have to

conform in order to be the one that we believe customers will love


Finally

Our brief must be full of possibility

“It’s clear to us that people want a degree of serendipity; for the finding of information to have a ‘fuzzy edge’ that allows them to stumble on something that they love, but weren’t expecting”



Creating a product design brief with possibility

Always guide, never prescribeSet principles, not guidelinesDesign experiments, not UISay how it feels, not what it does

In short: Let the design team design it…


Finally:Avoiding the ivory tower

Don’t be precious – about your ideas, or being right


Talk about the dead endsExperiments never fail or succeed, they merely have outcomes


Take input wherever you can

Regularly take time to gather intelligence, ideas and product thoughts from everywhere you can, and credit your sources


Be inclusive

Get the design and development team to develop the MVP

A RapidStart approach looks to get an experiment out in under two days


Product Development can be a state of mind, not a department

For complex products where there is a high degree of

uncertainty, it’s an upfront investment


For new features in existing products, it can become a

‘spike’ in the existing process

Product Development can be a state of mind, not a department


Playing to each other’s strengths


[email protected]

Phew…

Date post:	07-May-2015
Category:	Technology
Upload:	ucduk
View:	364 times
Download:	2 times

Paul Dawson - Walking the line: The Role of Product Development.

Technology