Requirement documents [...] are typically written documents[s] describing the technical and functional requirements of a system. [They] tend to be more focused on written description and less on visual illustration–they are more tell and less show. The lack of visual simulation often leads to misinterpretation of a requirement. Screen shots can be included to help reduce this misinterpretation, but static screens only go so far.¹

In terms of collaboration between graphic designers, programmers, project managers, and the other various actors in creating a product, a requirement document falls short (Todd Zaki Warfel makes the continued claim that so too do wireframes). The insufficiency stems from the limitations of representation and designed purpose. The requirement document is produced to enumerate concerns rather than answer them, and does so in an unobtrusive qua indefinite manner. A prototype, on the other hand, fills in the gaps that the requirement documents (and wireframes) fail to capture by demarcating the boundaries explicitly.

To some extent, the requirement document is purposefully vague. As Seymour Chatman explains with regards to movies and novels,² the ability of a written text to remain vague and a visual text to demand specificity results from the inherent modes of signification. A written signifier exhibits a one-to-many relationship–the written statement “Helen of Troy is the most beautiful woman ever” allows people fill in the qualities satisfy this claim. A visual signifier (especially that of a movie or prototype) exhibits a one-to-few or one-to-one relationship–the image of a woman playing Helen of Troy fixes qualities of beauty, thereby resulting in judgment of whether she is, in fact, the most beautiful woman. For the requirement document and prototype, the transmutable relationship benefits designers, who can interpret and generate new expectations.

While Zaki Warfel makes the requirement document’s imprecision out to be a bad thing, for my purposes it is wonderful. The Sheep’s Clothing workshop aims to inspire industrial designers to think outside the typical modes of representation. To create a completely new functional and aesthetic housing for a sensor, one must not be presented with a blueprint that limits confusion, but instead encourages multiple interpretation. Overdetermined documents would only result in similar (i.e. non-inventive) housings. Moreover, industrial designers have been trained to read such documents, added to the worth of such a loose representational mode.³

In the first hour of the workshop, the industrial designers will be presented with a short (15-30 minute) video/presentation about the client–urban and covert mushroom growers/foragers. The next 30-45 minutes will be spend looking at a requirement document that outlines both the technical components of the EasyBloom and the practical concerns of covert farming. Before each participant/group heads out to explore the city, a detailed slug (a physical requirement document) of the internal components will be given out to provide some sense of scale, potential, and material connection.

1. Zaki Warfel, Todd. Prototyping. (Brooklyn: Rosenfeld Media, 2007.), 5-6.; emphasis added [↩]
2. Seymour Chatman. “What Novels Can Do That Films Can’t (And Vice Versa).” Critical Inquiry, Vol. 7, No. 1, On Narrative (Autumn, 1980), 121-140. [↩]
3. two example document templates: a software requirement document and a functional requirement document [↩]