Really, really rapid prototyping: Flash builds and user-driven innovation at JSTOR Labs

1.Introduction

Organizations have oodles of ideas. The challenge for established organizations as well as for startups is knowing which of these ideas holds the greatest promise, and, for those that might hold promise, how best to realize them. At ITHAKA, a team, called JSTOR Labs, was formed in March 2014 with the express purpose of learning as much as possible as quickly and cheaply as possible about these ideas.

To do that, I will step through two sample projects the Labs team has completed, reviewing both the final product and the means to get there.

2.Case study #1: JSTOR Snap

In early December 2014, the JSTOR Labs team spent the week at a coffee shop in Ann Arbor, just off the campus from the University of Michigan. During that week we conducted a “flash build” (we also drank a great deal of coffee). The goal for the week was to create a mobile application for the JSTOR site, and to use feedback from potential users to inform its design. Hence, the location: nearly every patron was either a student or faculty member, many of whom were willing to provide feedback in exchange for a free cappuccino.

At the beginning of the week,11 we performed concept testing, in which we showed users paper prototypes of entirely different apps and used their feedback to choose which app had the most appeal. One of the things we heard routinely at this time was that, while some apps had more appeal than others, the fundamental idea of doing scholarly research on a smart phone was not especially appealing. Users repeatedly told us that they preferred larger screens for reading and discovering content. Regardless, we pressed on (since, in a worst case scenario, we would only have “lost” one week), deciding to build an application that would allow users to user their smart phone to take a picture of any page of text and return relevant research articles from JSTOR. Next, we refined how we would approach this idea – what set of screens, what would display on each screen, etc. – in a second series of paper prototypes. By the middle of the week we were building the application, and by the end of the week, users were giving us feedback on a designed, working prototype.

Users’ feedback at the end of the week was substantively different than what we heard at the start of the week. Whereas at the start, users were uniformly uninterested in doing research on a smartphone, once they could actually engage with the app on a phone and see what was possible, we heard much more interest. One user went so far as to tell us that researching like this could be even better than using his laptop and browser (see Fig. 1). While the final prototype – available by pointing a smartphone at http://labs.jstor.org/snap – still is more of a concept car than something you would want to drive across country, this change in sentiment is a great distance to travel in one short week.

Fig. 1.

JSTOR Snap was developed using a “flash build” at a coffeehouse in Ann Arbor. (Colors are visible in the online version of the article; http://dx.doi.org/10.3233/ISU-150763.)

3.Case study #2: Understanding Shakespeare

Understanding Shakespeare (see Fig. 2) – http://labs.jstor.org/shakespeare – is the product of a partnership between JSTOR and the Folger Shakespeare Library in Washington, DC. That partnership was an open, exploratory collaboration. We each brought the toys we had and we went to a sandbox to play together. In this case, the “toys” that Folger was able to bring were digital editions of Shakespeare’s plays, their role as publisher of Shakespeare Quarterly and, not least, access to scholars and students interested in researching Shakespeare. Meanwhile, JSTOR brought its digital archive, which included the full run of Shakespeare Quarterly and its new JSTOR Labs team.

In a flash build conducted at the Folger Library, the team again used user feedback as it designed and developed a site. In this case, they created an application that allowed users to click on any line of a play and see articles in JSTOR that quote it. The feedback the Labs team has received on this site has been tremendous: with virtually no marketing other than word-of-mouth, the site has become exceptionally well used, and is now frequently used in classes to help students research Shakespeare.

Fig. 2.

Understanding Shakespeare was the product of an open, exploratory collaboration with the Folger Shakespeare Library. (Colors are visible in the online version of the article; http://dx.doi.org/10.3233/ISU-150763.)

4.Analysis

There are a number of elements that contribute to JSTOR Labs’ ability to create these kinds of results. Let us take a look at three key elements in turn.

4.3.Users

Without users, none of this would be possible. All of us at JSTOR Labs have had the experience of spending tremendous time and effort building something that we were not sure users actually wanted, only to find out after everything that they did not want it. By showing work to real users early and often (see Fig. 3) – with the whole team present, so that everyone hears it – we can check those assumptions before we go too far. The more we test with users, the more our user-research skills and experience deepens, helping us to listen deeply both to what they are saying and what they are not saying.

Fig. 3.

Testing with users does not need to be expensive or fancy; sometimes a literal napkin sketch is all that is needed.

5.Conclusion

With these elements in place, the JSTOR Labs team has in a very short time been able to create innovative and impactful projects, all while learning relatively cheaply about possible strategic directions for JSTOR to go in. Innovation and delight are often not the product of single moments of inspiration, but instead of a thousand smaller decisions. Flash builds have been instrumental in helping the JSTOR Labs team get through those thousand decisions faster than they might have otherwise.