The JSTOR Labs team has been using Flash Builds – high-intensity, short-burst, user-driven development efforts – in order to prototype new ideas and get to a user saying “Wow” in as little as a week. In this talk, I’ll describe how we’ve done this. I’ll use two case studies to illustrate the importance of getting user input throughout the process, highlighting what your users can tell you – and what they can’t.
Learning Lean: Using Flash Builds to Learn from Your Users
1. LEARNING LEAN:
USING FLASH BUILDS TO
LEARN FROM YOUR USERS
10 September 2015
Alex Humphreys, JSTOR Labs
@abhumphreys
PSP Seminar:
Knowing and Understanding the User
2. 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.
3. At JSTOR Labs, we have one goal: to shape the future of
research and teaching, one project at a time. Working
with partner publishers, libraries and labs, we aim to
create tools for researchers, teachers and students that
are immediately useful – and a little bit magical.
8. PARTNERSHIP W/ FOLGER
Folger Shakespeare Library
• Folger Digital Texts
• Shakespeare Quarterly
• Scholars and students
Objective:
demonstrate the value of Folger
Digital Texts to scholars and
students and demonstrate how
it can be cross-referenced with
Shakespeare Quarterly.
JSTOR
• The full archive run of SQ
• 2000+ other journals
• A newly-formed Labs team
Objective:
validate the value of using a
primary text as a portal into
secondary literature.
11. WHAT WE HAVE
• A small, diverse team
with technical, design and
business skills
• A space to innovate:
• Flexible technology that
allows for componentization
and continuous deployment
• A safe-space to fail
• Ability to focus
12. Prior to the Flash Build
1. User interviews
2. Create the data & infrastructure
During the Flash Build
3. Design jam
4. Paper prototypes
5. Low-fi prototypes
6. Working site
After the Flash Build
7. Polish & clean up
8. Release & measure
WHAT WE LEARN, WHEN
User Input!
Who are they?
What can we
do that will
help them?
How can we make
our implementation
even better?
How should we
implement it?
How’d we do?
20. THANK YOU
Alex Humphreys
Director, JSTOR Labs
ITHAKA
http://labs.jstor.org
@abhumphreys
alex.humphreys@ithaka.org
Further Reading
• The Lean Startup, Eric Ries
• Business Model Generation,
Osterwalder & Pigneur
• Marty Cagan’s Blog:
http://svpg.com/articles/
• UX for Lean Startups, Laura
Klein
What they can’t:
- here’s what I actually do (the details)
here’s what you should build and how it should look and behave.
What they can tell you:
- I love it! / I hate it! / the dreaded: it’s useful.
- here’s where I struggle
- what tools they use
- here are my goals
- Other people to talk to!