There is a disconnect between IT buyers and IT vendors. Buyers assume that vendors will figure out what their IT system should precisely do. Vendors assume that buyers surely know their business and know exactly what their new IT system should do. Requirement analysts are deployed to gather requirements and write a specification which becomes the basis of a contract. A project is executed and the end result is taken to use. Users hate the system because it is clunky, does not meet their needs and is too complicated.
Why? The problem is systemic. Both the buyer and vendor assume that someone knows what the new system should do and how. In new product/service development requirements do not exist and cannot be gathered, they have to be developed collaboratively and iteratively. When automating an existing business no one knows with sufficient detail how that business works.
Agile software development proposes to fix the problem by iterative and incremental development where feedback from users using working software is used to guide the development effort. But working software is an expensive way of getting feedback when compared with role-play or paper design prototypes.
To solve the disconnect a new mindset and tools are needed. The mindset should be one of product and/or service design, where multiple stakeholders engage in a participatory design process centered around common, cheap, design artifacts.
This topic will include discussion about:
- the disconnect between business and software
- the nature of product and service development
- the role of feedback and learning
- participatory design and user-centered methods including service blueprints, role-play, prototyping and simulation and how they can be used to fix the disconnect
- advantages: better products, new ideas, engaged stakeholders, utilizing latent and tacit knowledge, increased empathy, cheaper more purposeful systems
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
The missing link between business need and software development: product design
1. The missing link between business need
and software development: product design
Ari Tanninen
Wildcard Conference 2013
Jūrmala, Latvia, Sept 13
“Bridging the gap between business and development, development and user, and buyer and vendor with
participatory product and service design”
2. Ari Tanninen
Product development consultant
15 years software product development, 8 years Agile/Lean
BEng, finishing MBA
ari.tanninen@gosei.fi
@aritanninen
3. Hello, who are you?
IT workers?
Business / management / designers / development?
Consulting / sub-contracting / internal development?
4. The problem
Disconnect between buyer and vendor
Consequences of disconnect
Fundamental issues
Proposed solutions
Design & feedback
Nature of design
Feedback in naive Waterfall
Feedback in naive Agile
An improved solution
Product/service design
Participatory design
Tools
Examples
Advantages
Products and services have form (or shape), and structure
Product design creates the form
IT systems make up the structure
6. Req.
spec.
Contract
Buyer Vendor
I need some IT!
Sure! Just write down
precisely what it should do.
Here’s a specialist to
help you out!
Analyst Dev team
Ummm...
Users
Tell me
everything!
We hate it!
Happiness is
to code!
Aaargh!Aargh!
Aaargh! Aaargh!
Aaargh!
System
Followed by... Change management process and more billing!
7. Surely my expensive vendor is best in
designing my IT system!
How could I possibly know
precisely what I need?
That’s why I pay consultants for!
Buyer Vendor
How could I possibly know what
my customer needs?
Or how their organization works?
And how their business ticks?
Surely my customer knows!
The disconnect
8. Example of disconnect
BuyerIT consultant
“How do you receive customer
orders? Phone, email? Actually,
which of your companies
receives these orders?”
“Do you expect us to know?
But you are the software
consultant!”
Image:Wikimedia Commons
Prototype factory built, need IT to orchestrate customer orders, production, deliveries and billing. Consultants
designing business processes that are to be automated in part by IT.
9. Consequences for users
• Complexity due to feature bloat
• Features missing
• System does not fit work
• System changed work and now needs changes
• Systems and service touchpoints work poorly together
• Fragmented user experience
10. Other consequences
• Systems never fit their intended use
• Expensive projects
• Failed projects
• Poor business
• Taxpayer losses
Buyers effectively
outsource ownership of
their products/services
11. Vendors assume buyers are aware and able to articulate their needs
Gathering requirements assumes they exist to be gathered
Fundamental issues
Buyers taught to believe in IT as fairy dust
The words we use guide our thinking: “requirements gathering”, “business process consultant”
15. Design
"Design is the successive application of constraints
until only a unique product is left."
-- Richard W. Pew
Take a need. Create solution. Try it. Take another need. Add to solution. Check that solution still fills all needs. Fix if
broken. Take the next need... Repeat until done.
16. Design problems / solutions
What users ask is not
what users need
Tacit and latent needs
Describing problems/solutions
without common language
Observation,
prototypes, simulation
Iterations, experiments
Design artifacts as boundary
objects
Cannot ask users, must iterate and experiment with artifacts
17. The key to design is creating new knowledge
Feedback and learning is essential
18. Feedback in Waterfall
Spec.
Real users
in context
System
Perceived needs
Biz processes
Workflows
Org structures
Domain knowledge
Assumpations!
Requirements gathering
years / months / weeks
Software development
years / months
Deployment
hours
Feedback
years / months
19. Feedback in Agile
Backlog.
Real users
in context
System
Perceived needs
Biz processes
Workflows
Org structures
Domain knowledge
Assumpations!
PO work
weeks / days / hours
Agile software development
weeks / days
Deployment
hours
Feedback
weeks
How to get faster feedback and even more iterations?
21. How about this?
Prototype
Perceived needs
Biz processes
Workflows
Org structures
Domain knowledge
Real users
Product/service design
weeks / days
Agile software development
weeks / days
Deployment
hours
Real users
in context
System
Real users
Feedback
immediate
Feedback
immediate
Why code & deploy, can’t we bring users into our office?
(the last feedback loop from users omitted for clarity)
22. Rough comparison
Max design
iterations
Cost of iteration
Waterfall 1 cost of project
Agile
project length /
length of iteration
cost of project /
number of iterations
Product / service
design & Agile
unlimited negligible
Writing functional software is an expensive way to get user feedback
23. Service design
User-centered design
Participatory design
Co-design
Design thinking
Co-creation
Prototyping
Personas
Scenarios
Wizard of Oz
Drama Role-play
Informance
Ethnography Bodystorming
Experience prototype
Mock-ups
Video
Moodboards
Customer journey
Service blueprints
A few keywords for you to google :)
24. Participatory design
• Collaborative design & development
• Buyers, vendors, stakeholders, users
• New concepts, products, services, business processes, user
interfaces, user experience...
• (feelings, smells…)
• Fast & cheap learning
25. Some tools
• Low/high-fidelity prototypes
• Role-play & drama
• Wizard of Oz
• Service blueprint
Simulation! Not
conceptual hand-waving
26. Examples
• UI & device paper prototypes
• Future library service (drama & Wizard of Oz)
• Talking sports watch (Wizard of Oz)
• Public-sector service (role-play, service blueprints)
• Cardboard hospital (1:1 prototype of environment)
• Urban planning: OurCity Meri-Rastila
27. User interfaces and devices
Image: flickr / Samuel Mann Image: flickr / benarent
Functional paper prototypes
Even detailed design possible by simulating with users by manual “animation”
28. Future library service
Concept, picture & video: Pirjo Kivistö, Marika Latvala, Mia Rahkonen,Terhi Kärpänen, Mikko Tenni / Laurea University of Applied Sciences
Functional future library: working lend/return machine, software, and verbal commands
Drama, Wizard of Oz
29. Talking sports watch
Concept and pictures: JuhoVesanto, Marjo Karjalainen, SamiVirtanen, IrinaYlikylä, Riikka Heloma / Laurea University of Applied Sciences
Prototype
User
Concept testing of a sports watch with a remote earphone verbally guiding the user to optimal exercise, like a
personal trainer
Test set-up: jogger, observer, and a talking sports watch prototype (real watch + person)
Wizard of Oz
33. Cardboard hospital
Juha Kronqvist, Heini Erving,Teemu Leinonen (2013): Cardboard hospital: Prototyping patient-centric environments and services. Nordes 2013.
http://designforhealthcare.blogspot.fi/p/spring-2012-cardboard-hospital.html
http://vimeo.com/46812965
http://www.slideshare.net/juhak/cardboard-hospital-prototyping-hospital-env
Cardboard hospital space at Aalto University where patients, staff, architects are co-creating ideas for the future
hospital for Tampere University Hospital in Finland
35. OURCity Meri-Rastila
http://meidankaupunki.wordpress.com
Images: flickr / MarianaSalgado
OURCity - sub-project of World Design Capital Helsinki 2012
Co-design of urban area, involving residents, children, city planners, and architecture students
Methods scale from individual user interfaces to cities
36. Advantages
• Fast feedback
• Validated learning
• Cheap
• Stakeholder buy-in & commitment
• Increased communication
bandwidth
• Evangelization
• Foster innovation & creativity
• Access tacit and latent knowledge
• User empowerment
• Empathy towards users - walk a
mile in their shoes
38. Service/prod design + Agile
Prototype
Perceived needs
Biz processes
Workflows
Org structures
Domain knowledge
Real users
Product/service design
weeks / days
Agile software development
weeks / days
Deployment
hours
Real users
in context
System
Real users
Feedback
immediate
Feedback
immediate
Last feedback loop omitted for clarity.
39. Key points
• Remember the disconnect
• Software design != product/
service design
• Design services and products
• Iterate early with real users - get
out of the building!
• Validate assumptions about needs
and design solutions
• Seek to shorten learning cycle
• Writing software is expensive
• Quick'n'dirty participatory design
- 20/80 rule