By Aaron Heskes

A prototype can be as simple as a change in how the task at hand is presented to the user, possibly altering the information given at a stage or changing the order of tasks. Remember, you’re testing how the change affects overall task completion.

There are several different types of prototypes which we’ll go over in this article, from tactile buck models to abstract concepts.

In prototyping part 1, we only went through a general outline of results based prototyping in small areas of existing systems. Today I’ve prepared some examples from my own work for you to judge.

Let’s start off with something a little different.

span storyboard.jpg

Not all prototypes are intended for evaluation by test users. Sometimes we can use storyboarding as a tool to work out how something would work logistically. These types of presentations are also great for presenting a hypothetical scenario to other stakeholders, like non- designers who are involved in the project. If you think about it, a storyboard is just a fancy adaptation of a flow chart, with a persona attached. You’re telling the story of a person who goes through a process that hasn’t been implemented before in its current setting, so the details that distinguish it are important.

I’ll argue that the act of drawing isn’t really prototyping. That fits more comfortably within the realm of ideation. Again, a prototype is created as a tool to visualize how a product system can be changed, and how those changes may affect the completion of the main goal. Some prototypes are created solely for understanding, like the storyboard above. Other models may be created to replicate the actual use case of the changed product, such as the paper interface discussed in Prototyping Part 1. Ideally, by observing the test user’s interactions with the simulated product, we can gain valuable information regarding how the changes are affecting task completion.

The following are a couple more examples from the same project as the storyboard above that serve the same purpose of aiding in understanding and visualization. These rendered 3d models present the appearance of the physical product. In part, they help set the abstract idea of the “wearable” in reality. Naturally, these visuals come later in the development of an idea as they are used to present the functionality of this wearable device within a presentation. By creating high fidelity visuals, you commit more time to the idea. Creating a more detailed visualization of the product demands a complete understanding of the product’s whole life. You must begin to answer questions about the product or system that you might not have thought of initially, such as how the wearable is charged, stored and packaged. How is it initially set up, and who is responsible for that? These considerations stem off from the initial storyboard which went through the use case from a patient’s perspective.

band render 4.png

A visual prototype should communicate how it fits into the story. If the prototype facilitates communication, what type of feedback does it offer to the immediate user. Furthermore, how is that presented so that it’s legible?

Screen Shot 2017-09-10 at 6.36.47 PM.png

A note on 3d modeling…

The first set of visuals for this wearable was created in rhino 5, which is a sculptural 3d program. Although measurements can be specified in the program, they cannot be changed later. This next set of visuals deals less with the functional demonstration, and more with the manufacturing potential of the product. By modeling the wearable in a parametric program (solid works in this case), we can go back at any time and edit the dimensions. This model deals with a different set of questions. How can this product be manufactured? How are the parts assembled, and how will they hold each other together?

The manufacturability of your model is almost irrelevant to your project’s conceptual strength, however both 3d models illustrate the purpose you should create high fidelity models for: aiding understanding.

By giving your concepts some visual polish, it makes other people take the concept more seriously. As more people understand the concept and can visualize using the product, you allow yourself to receive valuable criticism from a wider range of people.

The examples we’ve looked at today come much later in the design process, so next time we’ll circle back to simple user testing models that can be created and used before the concept is finalized.