building your next great product by talking to users each step of the way

BUILDING YOUR NEXT GREAT PRODUCTBY TALKING TO USERS EACH STEP OF THE WAY

11 October 2016

Alex Humphreys, JSTOR Labs@abhumphreys

SSP Webinar 2016

JSTOR is a not-for-profit digital library of academic journals, books, and primary sources.

Ithaka S+R is a not-for-profit research and consulting service that helps academic, cultural, and publishing communities thrive in the digital environment.

Portico is a not-for-profit preservation service for digital publications, including electronic journals, books, and historical collections.

ITHAKA is a not-for-profit organization that helps the academic community use digital technologies to preserve the

scholarly record and to advance research and teaching in sustainable ways.

JSTOR Labs works with partner publishers, libraries and labs to create tools for researchers, teachers and students that are immediately useful – and a little bit magical.

THE TROUBLE WITH H2 & H3 INNOVATIONHorizon 1 Horizons 2 & 3

• Horizon 1 = core business

• Innovation usually seeks operational efficiencies

• You know the market, the product, etc.

• You can make reasonable predictions about both cost to develop and how market will react

• Horizons 2 & 3 = new products, new markets & new businesses

• “If you build it, they will come.”

• You don’t even know what “it” is

• Or who “they” are

Horizons framework: https://paul4innovating.com/2010/09/10/the-three-horizon-approach-to-innovation/

Q: If H2 and H3 are so uncertain, how do you find your way to a sustainable new product or business?

The Design Squiggle, by Damien Newman: http://cargocollective.com/central/The-Design-Squiggle/

A: Lots of short iterations + lots of user feedback = speeding up the learning cycle

Innovation isn’t one big “Eureka,”

it’s a thousand little ones.

HERE’S HOW JSTOR LABS DOES IT

1. Create the sandbox

2. Research

3. Design jam

4. Select an approach

5. Refine approach

6. Release & measure

1. CREATE THE SANDBOX

• Some combination of partner, target user and new technology/approach

• This is usually not the same as the “idea”

Case study: Understanding Shakespeare• Partnership with Folger Shakespeare Library• We were interested in finding ways to link their full text

plays with the scholarship on JSTOR

2. RESEARCH • User research & technical exploration

• Understand users’ context, language, etc.

• What does success look like for them? What stands in their way?

• Entire team joins user research

• What stands in the way of that success?

Case study: Understanding Shakespeare• User research:

- Skype interviews w/ 5-7 Shakespeare scholars• Technical exploration:

- linking based on citation (FAIL) - fuzzy-text matching of quotations (SUCCESS!)

Ok, honestly? This persona was from a different project but it gives an idea what kind of info we seek at this early stage.

3. DESIGN JAM • Informed by user research

• Diverse participants

• Brainstorm as many approaches as possible

• (8 sketches in 8 minutes) x 2

• Not constrained by feasibility

Case study: Understanding Shakespeare• Design jam held at Folger

Shakespeare Library on Day 1 of a week-long “flash build”

This agenda was from yet another project, but shows the kind of “serious fun” that leads to a good design jam.

4. SELECT AN APPROACH

• Create paper, low-fi or hi-fi prototypes of product concepts

• Test with target users to find most compelling concepts

Case study: Understanding Shakespeare• 3 user-tests conducted on Days 1 & 2 of flash-build

A paper prototype for Understanding Shakespeare. Create enough screens to test the “big concept.”

A low-fi prototype for Understanding Shakespeare. Used to test multiple approaches to the same idea.

5. REFINE APPROACH

• Refine approach with ongoing user testing

• Bring in live data, working infrastructure

• The prototype is created primarily as a learning tool

Case study: Understanding Shakespeare• 2 user-tests conducted each day on Days 3 and 4 of flash-build

6. RELEASE, MEASURE

• Release prototype

• Measure impact

• Document and share

Case study: Understanding Shakespeare• End of flash-build: working, designed prototype with

Macbeth• 1 month later: released ”MVP” – 6 plays• 12 months later: released all Shakespeare’s plays;

released API• 18 months later: tested approach on a different text

(Understanding the U.S. Constitution app)• Currently: exploring expansion to an entire Classics

Library

labs.jstor.org/shakespeare

WHAT WE LEARN, WHEN

User Input!

Who are they?

What can we do that will help them?

How should weimplement it?

How’d we do?

1. Create the sandbox

2. Research

3. Design jam

4. Select an approach

5. Refine approach

6. Release & measure

THANK YOU

Alex HumphreysDirector, JSTOR LabsITHAKA

http://labs.jstor.org@abhumphreysalex.humphreys@ithaka.org

Further Reading• The Lean Startup, Eric Ries• Business Model Generation

& Value Proposition Design, Osterwalder et al.

• Marty Cagan’s Blog: svpg.com/articles

• Running Lean & Scaling Lean, Ash Maurya

• Sprint, Knapp, Zeratsky, & Kowitz

APPENDIX AOPEN IN CASE OF POOR INTERNET CONNECTION