When a digital product’s core functionality involves the display of content, the effectiveness of designs can’t be evaluated until such content exists. Prototyping is an effective means of validating designs, but unless prototypes include rich content, they will remain limited in their effectiveness.

I’ve begun to think of this kind of prototype as a “content prototype.” I draw a distinction between, say, a motion prototype (which may be as simple as an animation in Keynote demonstrating the movement of a few display elements) here because it allows users to search, filter, retrieve or read content. I also distinguish between product design approaches that flow content into static designs, such as those facilitated by the awesome Sketch Data Populator. While it’s important to make sure that your designs can accommodate the kinds of content they’re designed to display, doing so, at a template level, is often a case of making sure that you’ve designed elements that can accept strings of a certain length, or assets of a certain aspect ratio. Content prototypes are less about validating designs at the node level than allowing the design team to validate interactions that rely on sets of content. Does the search functionality return good results? Do those filters help to refine results effectively? Are there even enough content elements to necessitate search and filter functionality? These are the kinds of questions you can start answering when you prototype with live content.

To get started, you’ll need a set of content and a means of getting that set into your app. Both of these elements can be deceptively tricky. The set of content has to be both of good enough quality to serve as sample content in the prototype, and in the right format. (Often, web crawling can help here.) The measures for content quality can vary, of course, but in prototypes, soft attributes like voice and tone tend to matter less than the presence of usable metadata. Another element of a set of content’s suitability for prototyping is its size: if there’s not enough content items, the set won’t be able to help evaluate the effectiveness of search and filter functionality.

Creating a production ready content library is painstaking work. To apply the same level of rigor to content intended for prototyping is often untenable. However, one can assemble a set of content suitable for testing using intelligent modifications of existing content.

Generally, you should aim to have your content in a serialized format that your app can ingest. (I’m assuming here you don’t have a CMS yet; if you do, feel free to load your content in, and serve it from there.) While this might be accomplished by putting it into a CSV, XML or JSON file, a great approach is to use Google Sheets to hold your content. Google Sheets can be accessed via an API, which will allow you to get the sheet’s content encoded as JSON, ready for you to manipulate in you prototype. The advantage of this approach is that when and if your content needs to change, you can make those changes in the Google Sheet, rather than the JSON or XML or whatever serialized format you choose. To make the process of getting your content out of Google Sheets easier, I highly recommend Tabletop.js, which simplifies the process of querying Google Sheets. In just a few lines of JavaScript, you end up with an object in your script that contains all the content from your spreadsheet.

Once you’ve got your content accessible in JavaScript, the next step is up to you. If you’re designing filters or searches, it’s easy to fake those using vanilla JavaScript or whatever libraries you’re comfortable with. However, the exercise of getting your content together may have an unintended effect: it may make the design team reconsider the feature altogether. If the planned feature is some kind of a content feed or a search and filtering experience, and the set of content doesn’t seem to demand such a design approach, reconsider that design approach. You probably don’t need it.