How to prototype to understand your clients

antti.tarvainen@leonidasoy.fi@tarvaina

harri.lammi@leonidasoy.fi@harri_lammi

1.

3.

2.

Understand the contextof your system.

Build prototypes to validate your understanding of the context and the design.

Talk in one slide

Different situations call for different kinds of prototypes.

“A prototype in seven days”PROTOSONNI

Demohttp://youtu.be/jVlYofasZnI

http://lausuntopalvelu.fi

https://github.com/leonidas/lausuntopalvelu-prototyyppibut look at it on your own risk — it really is throwaway code.

Case: Lausuntopalvelu

Schedule:

Team:Proxy product owner

2 IX/UI designers

2 software developers

Start shop 1 dayUnderstand the problemIterate with paper protos

Design & Development 5 days

Design user interfaceDevelop functionality

Demo 2 hours Deliver to the customer

Startshop Tips

DO have a schedule

DO let the client tell their story

DON’T try to come up with a solution before you understand the problem

DON’T delegate design responsibility to the client

Personas

Scenarios

Paper prototypes

Wireframes

Layouts

Context

Solution

We need to understand the context before we can implement the solution.

From context tothe solution

Personas

Scenarios

Paper prototypes

Wireframes

Layouts

From context tothe solution

Context

Solution

We use different tools to move from context towards solutions.

Personas

Scenarios

Paper prototypes

Wireframes

Layouts

From context tothe solution

Context

Solution

We verify our understanding at each level with the client and by comparing to the other levels.

PO CODE

Development Tips

DO have small tasks (< 2h)

DO commit and deploy all the time

DO have product owner test the prototype all the time

DON’T write anything extra

DON’T spend time in polishing

Internals in this casejQuery, Transparency, Spine, Undescore, ...

CoffeeScript

Node.js

MongoDB

Github

Linode

YouTube

Demo to the client

Lessons learned

• 7-day projects are exciting!

• Throw the code away.

• Throw the design away.

What is good software?

What is a good tool?

A tool is used in some context.

tool

context

tool

context

In the context different forces act upon the tool

tool

Tool is goodif it fits the context.

context

tool

Tool is badif it doesn’t fit the context.

context

Example.

when you arebored and needentertainment

just a fewminutes of time

you can stop wheneveryou want

you don’twant to learn

anything difficult

alwayswith you

etc. etc.

Example.

Example. when you arebored and needentertainment

just a fewminutes of time

you can stop wheneveryou want

you don’twant to learn

anything difficult

alwayswith you

etc. etc.

Example. when you arebored and needentertainment

just a fewminutes of time

you can stop wheneveryou want

you want to learn something useful

alwayswith you

etc. etc.

Example. when you arebored and needentertainmentsocial

situationyou can stop

wheneveryou want

you want to learn something useful

alwayswith you

etc. etc.

So to create a good toolyou need two things.

context

1. Understand the context where the tool will be used.

? ?

?

context

2. Design a tool that fits the context.

tool

tool

context

You cannot tell from an abstract idea,if it will fit the context.

tool

context

As you make the idea more concrete,you will see its problems more clearly.

tool

context

This gives you an idea how to improve it.

tool

context

And so on.

tool

Continue iteratinguntil you find a design that

fits the context well enough.

context

specification design implem

entation testing maintenance

Traditional waterfall lacks iteration

Probably resulting in a bad tool.

tool

context

specification design implem

entation testing maintenance

Agile methods, e.g. Scrum,introduce iteration to fix that problem.

But a few things are unclear

1. How do you find the context?

2. How does the context result in a backlog?

user needs

User needs are the mostfundamental part of the context.

user needs

architecture

user interface

requirements

data model

feature list

What is the most logical next step?Why?

?

user interface

User interface is, because itcan be tested against user needs.

user needs

architecture

requirements

data model

feature list

You cannot tell from e.g. data modelalone if it will match the user needs.

user interface

architecture

requirements

data model

feature list

user needs

This is our process.

The right side of the processis traditional agile, e.g. Scrum.

Before starting Scrum weinvestigate the context and look

for solutions by prototyping.

We find out the context of the systemby interviewing potential users.

context

?

??

?

We describe the contextby writing scenarios.

context

?

tool

context

We create prototypesbased on the scenarios.

?

We test the prototypesusing simulation and user testing.

tool

context

?

When the user interaction of the most common scenarios is clear, we put

them to the product backlog.

A use case may consist of one or more features.

We take new features to production basedon the rhythm of the project.

Preferrably as soon as they are ready.

There are multiple kinds of prototypes.

Paper prototyping is fastest.

A fancier prototype adds precisionbut not necessarily accuracy.

We use mostly paper prototypesand functional prototypes.

The length of a paper prototypefeedback loop is minutes.

The length of a functional prototypefeedback loop is days.

Paper prototype is good forfinding out and validating

the use cases and the design.

A functional prototype is good for communicating the vision of the product,

selling it and validating the market.

1.

3.

2.

Understand the contextof your system.

Build prototypes to validate your understanding of the context and the design.

Different situations call for different kinds of prototypes.

Talk in one slide