The Two Types of Labs Projects You'll Meet

At JSTOR Labs, our mission is to partner with the community to build experimental tools for research and teaching. As we’ve gone about that mission over the years, we’ve built a wide variety of tools, both in kind and in quality. Kind -- what exactly the tool does -- is vitally important, but today I want to talk about quality, by which I mean how well-developed an idea is.

Ideas, in our experience, don’t spring fully formed from our heads. There’s usually not one, big “Eureka!” moment, but instead a thousand little ones on the long path towards having an idea prove itself to be viable. By “viable,” I mean an idea that is desirable (even delightful) for users, technically feasible, and valuable for the organization. Over the years, we’ve seen many ideas travel this path and we structure our projects to take into consideration where on that path an idea is. While each project has its own unique qualities (Labs teams don’t favor cookie-cutters), generally we have two kinds of projects at JSTOR Labs: discovery projects and incubation projects.

Discovery projects are projects where we don’t know yet whether an idea is a good one. We often start our discovery projects without an “idea” at all -- instead, we’ll have just a territory that we want to explore. This might be a person, like “Shakespeare researchers,” or a technology, like “linked open data and entity extraction,” or some combination. The purpose of a discovery project is: to create and to find value in an idea. This takes exploration and iteration. It takes curiosity, humility, and a little perseverance. It takes showing half-finished ideas sketched in pencil to users and listening in their responses for clues to direct us. JSTOR Labs has been doing discovery projects since we started and over that time we’ve built up a suite of methods and tools (many inspired by the design thinking movement) to use. One of the most important tools on our discovery workbench is the prototype.

As I described in this blog post, there are endless varieties of prototype, but their purpose is to learn as much as possible about an idea while investing as little effort as possible. Most of these prototypes don’t get shared publicly -- these are the napkin sketches and clickable Sketch files that we show to one or two people in a user test and then immediately change based on their feedback. With enough iterations and feedback on a discovery project, usually we find a concept that’s formed enough that we think -- but still we may not know! -- that there’s value in it. When that happens, we share it with the world as a JSTOR Labs Prototype, a kind-of concept car used to help people imagine what might be possible. Sharing prototypes like Cultural History Baseball Cards or TopicGraph has helped to validate our hypotheses about the fundamental idea, while sometimes sparking new ideas and partnerships based on the feedback we receive.

Incubation projects are when we believe we have a good idea and our job is: to realize and scale the value within that idea. This ALSO takes exploration and iteration, but it looks a bit different than a discovery project. Because we are no longer primarily interested in learning, we’re willing to invest a little more to ensure that the design is scalable and sustainable. Because we’re interested in realizing the idea’s value, we’ll pay as much attention to how people find the tool as to how they use it. For example, in the early days of incubating Text Analyzer we tested a variety of different pathways to it, from the JSTOR homepage to Google SEO. Because these projects are still changing rapidly as we optimize them, and to encourage the community to share feedback on the idea, we indicate an incubation project with a beta label.

What do we mean when we say Prototype and Beta?

	Prototype	Beta
Indicated by
Project type	Discovery Project	Incubation Project
Location, usually	JSTOR Labs site	The main JSTOR user experience
Value	We believe there is value in an approach and we are seeking to validate and bolster that belief.	We are confident there is value in an approach and are seeking to realize that value.
Generalizability	The scope of the tool shows the concept, but perhaps only on a very specific use case or content set.	The tool should be relevant to multiple disciplines and content sets, or a wider variety of use cases.
Expectations & commitments	We’ll aim for the site to be fully-functional, but there may be a list of known issues. So long as the site is actively used, we will address issues that appear (e.g., the site goes down), but it may take a few days. We may decide to retire the project.	We aim to address any issues that arise. We commit to fixing any issues that arise as quickly as possible, within business hours. We fully intend to develop the tool until it is ready to remove the beta label.

An example may help to understand this. One of our first projects was Understanding Shakespeare. When we started that project, we only knew that we wanted to explore ways to connect Shakespeare’s plays with the literature about them. When we released the Understanding Shakespeare site, we felt we had found a new way to do research that used the primary text as a portal into the literature about it. We showcased that concept with just a few Shakespeare plays in a prototype. As it became clear that there was value in the approach, we created a few additional prototypes to understand that value, including exploring how the approach worked on texts other than Shakespeare’s plays. Once we felt we had a good handle on the concept and how generalizable and valuable it was, we started the incubation project that led to the JSTOR Understanding Series beta. Now, we are working to expand that tool and find ways to make it as useful to as many people as possible on the main JSTOR platform.