How to prototype to understand your clients antti.tarvainen@leonidasoy.fi @tarvaina harri.lammi@leonidasoy.fi @harri_lammi
Jun 26, 2015
How to prototype to understand your clients
[email protected]@tarvaina
[email protected]@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