Introduction to AL 444: Prototyping, Spring 2020 (Part 1)
This document is the first of two posts intended to serve as a complement to our introductory discussions in the course, AL 444: Prototyping, a user-experience design course conducted at MSU in the Spring Semester of 2020.
It could be out of either ignorance or laziness, or a combination of the two (or the wonderfully time-consuming presence of my infant daughter), that I was unable to find a series of accessible readings that addressed both some of the nuts-and-bolts questions around what a prototype is and what kinds of uses it might serve as well as the (often under-appreciated) politics of prototyping (and the choices one must make when engaging in the prototyping process).
I will, instead, take some time to work through these things drawing on the bodies of literature with which I’m most familiar as well as on my own experience as a practitioner of interaction design, and, more broadly, as an artist/designer who develops interactive installations that seek to engage visitors in specific ways around issues of agency and subjectivity in a computationally-mediated world. What will follow (in this post and the following one) is not necessarily intended to be read as a scholarly document, but rather a component of a broader discussion that I hope to begin in the first days of our class and expand on throughout the semester.
What is a prototype for?
The basic idea of a prototype is that it’s something from which the designer learns about the thing they are trying to design. This seems pretty obvious, but it’s an important thing to consider when you start thinking about all the different ways you can prototype whatever it is you’re working on (are you going to use electronics? A paper prototype? A storyboard/narrative scenario?). Understanding the purpose of a prototype—your design teaching you something about itself—leads a good designer to prototype with intent. When you appreciate the role of the prototype in the design process, the medium/form that a prototype takes aligns with what you’re trying to learn about the thing you’re designing.
For/form
One way to think about this is the continuum of fidelity in the prototyping process. Low-fidelity prototypes (e.g., some “paper prototypes” in interaction design settings) are intended to help designers and users think through major issues of hierarchy and flow, and as the questions they are trying to answer get more detailed, the fidelity of the prototypes increases. You don’t need to know whether a button should be purple or blue in order to answer what should happen after a user selects it. Likewise, making storyboards and/or a video (without seeing any interface details, or maybe without seeing any interface at all) to demonstrate to stakeholders the context and use of a product can be much more helpful (and much less expensive) than programming a functional prototype if you are unsure of how exactly the product will work and how the user will engage with it. In other words, the fidelity of the prototype should align with where you are in the design process, and you should aim for no more detail/fidelity than is essential in order to get what you want out of it.
For and with whom?
The “what aspects of my design do I want my prototype to teach me about?” question should also be reflected in the people with whom you choose to do your prototyping. There are lots of things to think about when it comes to the ways our prototyping practices have exclusionary dimensions. The ways designers exclude/include, “user-test,” or even begin to identify so-called “problems” in the first place, goes so far beyond the scope of “prototyping,” and gets at the core of so much of what’s wrong with design today that it’s impossible to give adequate guidance/advice in this space (or in a single semester) regarding the relationship between prototyping and people. That is to say, however, that beginning by thinking about your colleagues, users, collaborators, stakeholders, or laborers in the electronics factory that produces the sensors you use, as people or as citizens is important.
Whether you “test” a prototype, how you go about doing so, and with whom, should reflect what you are seeking to learn about your design. You’ll want to think in advance about how to obtain consent from folks with whom you’ll be working, and you will need to cultivate an awareness and proactive approach around the multiple facets of inclusion. “For” whom are you designing and why? And why are you designing something “for” someone in the first place? Whose “needs” are you fulfilling? [1]
Scale and components
To prototype a product or service with intention is one thing. And, to an extent, when prototyping something relatively simple, such as a self-contained mobile application that relies only on an individual user’s input, the prototyping process seems relatively straightforward. But as the scale of the design concepts expand and the more complex and multifaceted they become, decisions about what to prototype and when also become more challenging. Think about medical devices, multi-user-type mobile applications (think driver vs. rider in Uber or Lyft), museum interactives, or multi-channel experiences of university student services. The scale of the design and the interconnectedness of its components, in many ways, determines aspects of the prototyping process. So not only do you have to consider the fidelity of a prototype, who you are working with to build and test/evaluate the prototype, but you also have to start thinking about precisely which aspects of the experience/product/service you want to prototype and when in the design process does it make sense to do so? (e.g., are you worried about user flow/journey, form factor, or sensor functionality?)
As the scale of the design “problem” increases, developing comprehensive prototypes that address more than small slices of the problem becomes impossible. A constellation of artifacts (e.g., a narrative scenario video that demonstrates the context and use of the entire service combined with a proof-of-concept for the sensor technology) often becomes useful for designers to get an understanding of how the thing they’re designing is actually going to work. This is especially important today, since most design problems (and their proposed “solutions”) are systems-oriented in nature. To think, to design, and to prototype in systems requires, maybe a different way of designing altogether (and/or a different political economic system, but let’s leave this alone for the moment…). [2]
Notes
[1] There is vast scholarship on the problems of neoliberal/individualist paternalism in design practice (even in “participatory design”) and of “inclusion” (I’ll also put this in scare quotes because of its co-opting by institutions to further neoliberal agendas) in design spaces, ranging from race to gender identity to (dis)ability. Some of my favorite scholars include: Elizabeth Guffey, Sara Hendren, Sasha Costanza-Chock, Ahmed Ansari, Arturo Escobar. There are tons more — these folks are a great place to start, though. These issues also intersect with critiques of Human-Centered Design and the lack of (or very selective/racist/colonialist) human-centeredness with which it is often practiced.
[2] One of the most articulate advocates for these alternative ways of designing has been Cameron Tonkinwise (as well as his colleagues and peers from when he was at the Transition Design Program at CMU).
