You are viewing a javascript disabled version of the site. Please enable Javascript for this site to function properly.
Go to headerGo to navigationGo to searchGo to contentsGo to footer
In content section. Select this link to jump to navigation

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

To build a platform for (high, sustainable) use, we need to know what will thrill users. Finding the right concoction of technology, functionality and design to delight users takes a thousand decisions, pivots and changes. 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 paper, a distillation of a presentation I gave at NFAIS 2015, I will describe how we have done this, highlighting the partnerships, skills, tools and content that help us innovate.


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,1 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 – 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;

JSTOR Snap was developed using a “flash build” at a coffeehouse in Ann Arbor. (Colors are visible in the online version of the article;

3.Case study #2: Understanding Shakespeare

Understanding Shakespeare (see Fig. 2) – – 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;

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;


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.1.The team

The JSTOR Labs is a small and diverse team. Its three full-time members each bring a different expertise: one team member is the lead technologist, another leads the user experience and design efforts; the last represents the needs of the business.2 The small size allows the team to be agile – communication is quick and efficient. The diversity helps in creating innovative products: the best products combine technical, design and business innovations all toward a single goal (for example, helping users better understand Shakespeare’s plays). The barest expression of that goal is often called the Minimum Viable Product (MVP), and each JSTOR Labs prototype represents its goal’s MVP.

4.2.A space to innovate

Any team with the capacity to innovate also needs a space within which to do so. This takes two forms: technical and cultural. On the technical side, JSTOR has been working the past few years to build a new platform, one based on highly-scalable open source technologies, and which embraces componentization and continuous deployment. With this new platform, JSTOR has moved from one, burdensome release per month to releasing over a hundred times each week. Because developers and product managers get immediate user feedback on what they build, they are able to move much faster. It also limits the risks of large releases – with this technology, we can perform a/b tests, or release to a small portion of our users, allowing us to test new functionality and features in a safe environment. There are also low-tech ways to create a safe space to fail. Examples include labeling something as a Beta or a Labs project, or testing in-person or with self-identified beta testers.

On the cultural side, the space to innovate comes first from being able to embrace uncertainty. For example, during those first few days in the coffee shop when users were telling us they were uninterested in doing research on their phone, we were unsure whether our work would be valuable in any way. It is vital in those circumstances to avoid getting stuck or discouraged, but instead to keep learning and moving forward. Last, innovation does not necessarily take a great deal of time, but it does take focus. During each of these flash builds, the JSTOR Labs team has been 100% dedicated to the work at hand – no additional meetings or obligations, no multitasking.


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.

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


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.


1 You can see a video of the week here:

2 There are also two part time members, a visual designer and a project manager.

About the author

Alex Humphreys is Associate Vice President, JSTOR Labs at ITHAKA. The Labs team seeks out new opportunities, and refines and validates them through research and experimentation. Prior to working at ITHAKA, Alex worked at Oxford University Press (OUP), Inc. where he built an award-winning publishing platform for OUP’s subscription-based websites.