goodbye specs hello prototypes
DESCRIPTION
As a developer, architect and now Product Manager, I've spent most of my career trying to turn software ideas into reality. For many years, I worked on teams that adhered to the Way of the Functional Spec, an ancient practice whereby a product leader spends countless hours producing a document that uses text to describe the future state of software, only to see that document become useless by the time the first line of code is written. Over the years, I've experimented with all of the agile and Product Management techniques designed to help drive down uncertainty in software and foster clear, high-fidelity collaboration between product leaders, designers and engineers. Some have been useful, others not. About two years ago, a few product teams at my current company began toying with the idea of replacing our existing spec work with prototyping. Instead of working with text-based docs, a PM would work with an Interaction Design to create an interactive piece of software that conveys the vision for a product or feature. This was one of the best decisions we ever made. High-fidelity prototyping is now a critical component of our product workflow, and we've become addicted to using these assets for collaborating with customers and internal teams alike. In this session, I'll will share how one software company abandoned functional specs and PRDs for the green pastures of prototyping. Using a case study format, I'll share challenges we overcame, victories we experienced and tips for embedding a full-on Prototyping workflow in any software organization.TRANSCRIPT
3 BIG IDEAS
V i s u a l s o f t w a r e c a n n o t b e p r o p e r l y e x p r e s s e d
w i t h t e x t
1
P r o t o t y p i n g i s a n e x c e l l e n t t o o l f o r c o m m u n i c a t i o n
a n d v a l i d a t i o n
2
P r o t o t y p i n g w o r k s b e s t w h e n d r i v e n b y g r e a t d e s i g n e r s , P M s a n d c o m p l i m e n t e d b y
g r e a t t o o l s .
3
OBLIGATORY YMMV SLIDE!
I am not a designer
6
ANOTHER OBLIGATORY YMMV
I am a product manager
7
TEXT
(Or, how to waste immeasurable amounts of time not building software)
A BRIEF HISTORY OF SPECS
THE EARLY AGE OF SPECS
10
“Ο γραπτός λόγος είναι το πιο οπτική όλων των µέσων, και πρέπει να είναι όλα αυτά που η ανθρωπότητα χρειάζεται για να δηµιουργήσετε όµορφα κτίρια, κατασκευή θαύµατα και να σχεδιάσετε το επόµενο iPhone, το οποίο άκουσα θα έρθει σε 3 ένδοξη µεγέθη.”
- Specificitus, On Text, 136 BC
THE EARLY AGE OF SPECS
10
THE EARLY AGE OF SPECS
11
“The written word is the most visual of allmediums, and should be all that mankindrequires in order to create beautiful buildings,construct wonders and to design the nextiPhone, which I heard will come in 3 glorioussizes.”
- Specificitus, On Text, 136 BC
THE EARLY AGE OF SPECS
11
“Προσπαθώντας να αντιπροσωπεύουν οπτικά δηµιουργίες χρησιµοποιώντας µόνο τη γλώσσα µας µπορεί να αποδώσει µόνο ρηχά αντίγραφα του τι οραµατιζόµαστε στο µυαλό µας. Είναι µόνο µέσω της χρήσης των εικόνων µαζί µε τα λόγια µας που µπορούµε να δηµιουργήσουµε το ένδοξο αριστουργήµατα! Με αυτό το ευγενές εργαλείο στο χέρι σίγουρα οι δρόµοι θα τρέχει κόκκινο και βρύσες µας ξεχειλίζουν από ούζο, όταν χρησιµοποιούµε αυτά τα σχέδια να πατάξει την µιγάς Spartan από τη γη!”
- Prototypus, What More Than Words, 135 BC
A DIFFERENCE OF OPINION
12
A DIFFERENCE OF OPINION
13
“Attempting to represent visual creations using only ourlanguage can only yield shallow copies of what weenvision in our minds. It is only through the use ofpictures along with our words that we can createglorious masterpieces! With this noble tool in handsurely the streets will run red and our fountainsoverflow with ouzo when we use these designs tosmite the mongrel Spartan from the earth!”
- Prototypus, What More Than Words, 135 BC
A DIFFERENCE OF OPINION
13
TEXT VS. PICTURES
14
TEXT VS. PICTURES
14
SPECS IN THE MODEN ERA
15
THE SPEC, AKA…
Functional Spec
Technical Spec
Product Requirements Doc (PRD)
16
STRENGTHS OF SPECS
Exhaustive
Detailed
Good at being verbose and also wrong
17
WEAKESSES OF SPECS
Impossible to capture everything in advance
Hard to iterate
Rarely used during development
Often out of date
A true sign of a "waterfall" mentality
18
19
19
Also… specs are terrible for capturing customer feedback.
Like, just the worst.
The. worst.
I’m not even kidding y’all, they are terrible.
You want proof, do you?
Immediate weight loss
Promotes cardiovascular health
Said to cure epilepsy
An affective treatment for metabolic syndrome (high blood pressure, high blood sugar, etc.)
I HAVE JUST THE PRODUCT FOR YOU!
25
Immediate weight loss
Promotes cardiovascular health
Said to cure epilepsy
An affective treatment for metabolic syndrome (high blood pressure, high blood sugar, etc.)
I HAVE JUST THE PRODUCT FOR YOU!
25
Immediate weight loss
Promotes cardiovascular health
Said to cure epilepsy
An affective treatment for metabolic syndrome (high blood pressure, high blood sugar, etc.)
I HAVE JUST THE PRODUCT FOR YOU!
25
HOW WE FAILED WITH SPECS AT TELERIK
Attempting to build a spec for everything killed velocity
Too easy to specify the “how,” which is NOT the domain of PM & UX
We had nothing of value to show to customers
26
Specs aren’t all bad…
… they help engineering build the thing right.
The spec, even when done well, can’t tell you if you’re building the
right thing…
How do we evolve the spec into something useful for modern,
design-focused teams?
(Or, how to be the Alec Baldwin to the Functional Spec’s Billy Baldwin)
A BRIEF HISTORY OF PROTOTYPES
BLUEPRINTS
32
MODELS
33
CONCEPT CARS
34
35
THE HARDWARE PROTOTYPE (AKA I DON’T HAVE A KICKSTARTER
ADDICTION NO REALLY I DON’T)
36
THE PPT AND PSD TWO-STEP
PROTOTYPING IS IMPORTANT
37
PROTOTYPING IS IMPORTANT
37
PROTOTYPING APPROACHES
Paper Prototype
Wireframe/Mockup
Pseudo-demo app
High-Fidelity Prototype
38
PAPER PROTOTYPE
39
WIREFRAMES/MOCKUPS
40
DEMO APPS
41
HIGH-FIDELITY PROTOTYPES
42
HIGH-FIDELITY PROTOTYPES
1. Functional demos
2. Represent the real product to be delivered (even if loosely)
3. Can be manipulated by end-users
43
1. Visual
2.Functional
3.Collaborative
4.Dual-Purpose
BENEFITS OF THE PROTOTYPE
44
45
RISKS OF PROTOTYPING
Time-consuming
Creates a built-in bias
Not a replacement for user stories and other key details.
46
ARCHITECTURE AND SOFTWARE
47
PM & UXIdeation and Design
PM TeamIteration and refinement
Feature
CustomerValidation and
Feedback
PM, UX & Engineering
Construction & Iteration
EngineeringClarification and
Estimation
HOW WE PROTOTYPE AT TELERIK
48
ARTICULATING CUSTOMER PROBLEM
STORIES
CHUNKING THE WORKCAPTURING THE
“HIDDEN DETAILS”
REQUIREMENTS MOCKUPS
WHERE WE STILL HAVE WORK TO DO
49
GET SOME TOOLS
FIND A PM &
DESIGNER
DO SOME RESEARCH PROTOTYPE
GETTING STARTED WITH PROTOTYPING
50
VALIDATEITERATEBUILD!
GOOGLE PARSE LOCALYTICS
ANALYTICS
ENGAGEMENT STICKINESS CHURN
INTERCOM SURVEY MONKEY
METRICS CUSTOMER ENGAGEMENT
USER RESEARCH TOOLS
51
PROTOTYPING TOOLS
Axure
Balsamiq
Bootstrap
UXPin
52
DON’T FORGET MOBILE!
1.InVision
2.proto.io
3.Justinmind
53
BEYOND THE PROTOTYPE
WHAT A PROTOTYPE CAN'T TELL YOU...
If the product or feature will help you meet your goals.
If you’re solving a real customer problem
Everything engineering needs to know to actually build this thing.
55
GOALS AND INITIATIVES
56
SOLVING REAL PROBLEMS
57
DECOMPOSING THE WORK
58
How prototyping fits into the big picture at Telerik
THE PRODUCT FUNNEL
60
Inputs- Strategy- Metrics- Markets- Customers
Work- Ideas- Features- Headroom
CustomersMarkets
Strategy
Backlog
Story + Prototype = Estimate
Roadmap
Valu
e / E
ffort
R1 R2 R3 R4
Work & Inputs - Aha!, Google Analytics, Qualtrics, Intercom Backlog - Aha!, UXPin & InVision Roadmaps - Aha!
THE BOTTOM LINE
1. Prototyping is just a tool in the toolbox.
2. Don't expect it to do everything, but do adopt it, because it excels at many things.
61