12.10.18 Final Critique & Presentations

To conclude the semester, students presented their projects at the NEMIC.
Each group presented their solution deck and the projects were evaluated by a panel.

Presentations included a summary of user insights, final concept, and supporting prototype.

10.29.18 Working Class - Studio time

Students worked on refining problem statements, identifying user group/conditions, and additional supporting context for example ergonomic/usability issues.

10.11.18 Observation Insights

Students worked on evaluating and ranking observational insights using post it notes, push pins and sharpies and then sorting them into areas based on 1) benefit to user, 2) impact to healthcare and 3) value opportunity.


10.1.2018 Design Thinking and Design Research

Elizabeth Roche, Director of Research and Strategy at Ximedica, gave a talk about empathy, Design thinking and core qualitative research methods. The second part of the class consisted of student presentations of what they have noticed so far in their clinical spaces and avenues for future investigation.

9.24.18 Healthcare Innovation

This week students learned about healthcare innovation and the state of the industry. Featured speaker was Aidan Petrie!


9.17.18 Visual Thinking and Storytelling

This week students were exposed to rapid visualization and ideation techniques with a workshop facilitated by industrial designer Michael Park from Ximedica. Specialty track research is under way and students are starting to venture out into various clinical spaces at Rhode Island Hospital, The Miriam Hospital, and Hasbro Children’s Hospital!

9.10.18 Immersion and Introductions

The first class of the semester kicked off with a foray into the world of industrial design by Ximedica designer Tom Lutzow! Students worked in groups to understand patient primary care experiences before, during, and after a medical encounter. From there, they were able to mindmap and create a series of solutions from opportunity areas identified by the group. We look forward to seeing what students uncover as they begin to conduct research within their specialty tracks in Emergency Medicine, Neonatal Intensive Care, Surgery, and Dermatology!

Prototyping Part 4

By Aaron Heskes

Sometimes you’ll fail, and that’s alright. Today I’m bringing you yet another prototype from a project that we’ve touched on earlier in this series. If you remember the “wearable” cad models from part 2, you’ll be familiar with this object. This prototype turned out to be ineffective because it didn’t replicate the effect of the concept.


Once you’ve looked at a system, identified a problem and committed to a concept, wherein a concept is a changed system intended to solve the problem, you must test that concept. This is done more easily in certain situations, such as in interface design, where user testers can evaluate the experience via paper models. In more nuanced environments however, it becomes much harder to replicate the situation experienced by the user. Even more pressing is the issue of successfully replicating how the implementation of the concept changes the experience for that user. Your goal is to be able to evaluate how the changes proposed by your concept affect the user’s behavior.

Let’s define what implementing your concept means. First, I’ll provide some more background on the project we’re looking at today.

This wearable concept was intended for doctor’s waiting rooms. From our survey results we determined a need for a system that could provide more accurate ‘live’ data to patients about how long the wait would be until their appointments. Gathering data on average appointment durations and wait times in relation to the reason for the visits, time of day and number of people in the clinic was viewed as a valid method of providing useful feedback to patients and nurses at the time.

The output on the patient’s side of things via the wristband would be a soft estimate of the time until they’d be called into the exam room so that they could use their wait time more effectively. This is admittedly like the buzzing discs that the hostess at chili’s gives out. Because each patient would wear a wristband to benefit from the feedback it gives them, they would simultaneously feed metrics on the efficiency of the clinic for the hospital to evaluate.

Looking back on this clumsy attempt at a prototype, we can see that by replicating the lights and buzzing functions of the conceptual wristband, we weren’t offering the users the real value in that buzzer: The actual time estimate. A much better way to test this concept would be to control patient influx on a certain day and tell each person in the waiting room exactly when they’ll be due to come in to the exam room. This would have allowed us to observe the effect of that information in the clinic without the headache of producing testing equipment.

Prototyping Part 3

By Aaron Heskes

Buck models are integral to developing ideas as they allow users to experience the scale, weight, ergonomic potential, and feature set of a device in a use case scenario. Here we have a few examples from a project wherein the goal was to design a portable insulin solution for type-1 diabetics.

This early foam core mockup offered the basic functionality of a feature which records food consumption and appropriate insulin intake. As in: “How much did I eat at breakfast and when did I last shoot insulin?”

Screen Shot 2017-09-10 at 6.43.49 PM.png
Screen Shot 2017-09-10 at 6.43.40 PM.png

Early mockups like these test out methods of recording and presenting important information to users. Considerations included the clarity of the graphic icons and the order of operations for shooting insulin.

Once you’ve defined how one interacts with the device, it’s time to consider packaging. Specifically, for medical devices, it’s important to accommodate the standardized elements that must fit into the device. This defines the initial scale. This metal bar was turned on the lathe so that users could handle the device in its intended real world scale. It has functional knobs on the side so that users can evaluate the ease of use.

Screen Shot 2017-09-10 at 6.44.17 PM.png
Screen Shot 2017-09-10 at 6.44.56 PM.png

Finally, a high-fidelity buck model can be made with the changes informed by the earlier models. This one was modeled in the computer and 3d printed. At this stage, the buck model has the physical functionality of the real thing. The first knob is a time-of-injection setting and the second knob dials a dose of insulin, extending the button appropriately. These 3 types of buck models will serve you well, especially in terms of getting serious user feedback.

Screen Shot 2017-09-10 at 6.46.09 PM.png
Screen Shot 2017-09-10 at 6.45.25 PM.png

Prototyping Part 2

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.

Prototyping Part 1

By Aaron Heskes

Prototyping isn’t only done in the final stages of development of a product. In fact, prototyping becomes relevant very early on as a way of testing conclusions which in turn shapes the direction of conceptual development.

A prototype replicates a use case scenario. By allowing users to interact with an experimental situation, it allows designers to evaluate how those changes affect task completion.

Everything we’ve talked about so far gives us the background knowledge to start posing meaningful questions. By creating personas, we can develop empathy for the users of the product. Personas neatly assemble information about the users which may have an external effect on how they use the product or service. The key to discovering the reasons why people don’t interact effectively with a product lies in developing that sense of empathy for individual restrictions and needs. If you attended the gown workshop, you’ll understand that although all gowns serve that same purpose, every model had constraints that required the function of each gown to serve their personal physicality.

The degree to which a prototype can replicate the change in how a product can be used however goes well beyond physical constraints. Another aspect to consider is how one’s background affects their understanding of what a gown is, how it should be put on and where they feel comfortable wearing that garment.

System mapping graphically can allow us to picture the logistics of how a product interacts with a group of users. It answers the question, “what does everyone have to do (individually) to accomplish the greater goal?”, and for that matter “How do each individual’s goals relate to the greater goal?”.

Using what we know about a system/service/product, we can begin to ideate. The best place to begin ideating is at an area of friction and discomfort. Consider the points of contact between people. Think about what information must be exchanged in those interactions. What is each user expected to know, and what might be unfamiliar to a first-time user?

What is the purpose of each step the user is expected to go through? If certain existing aspects seem awkward, think about why more direct methods haven’t been put in place already.

How you replicate change to test for results varies by the nature of the entity you’re changing. For example, a team working on a software based application might hand draw the layout of a new interface and ask someone to complete a task by treating the paper like the surface of a tablet. As the subject interacts with the paper interface, the operators go through the pages accordingly to replicate the experience of navigating the app.

This method of testing is popular as a quick, low fidelity solution. It’s called the “Wizard of Oz Method” because the operators manually respond to the user’s input, giving the illusion that it’s a working product.


Low fidelity mockups are great because they can answer questions early on concerning what might be a good or bad change. They are also easy to change because they take such little time to produce. Although nicer mockups present a more realistic vision to the test user, team members might become attached to weak ideas early on if they spend too much time developing that idea before having any feedback that proves the validity of the change. There’s always time for nice mockups later.

At this point, it doesn’t matter how pretty your prototype looks. Think about what the problem is that you’re solving for. How do you expect the changes you make to affect the use case, and how are you replicating that change and testing for results?

Drafting Surveys: Problem Generation Part 3

By Aaron Heskes

In problem generation part 2, we touched on surveys. Naturally, every response you read should be taken with a grain of salt as each person surveyed can only provide information based on their own priorities and experiences. This in turn is why surveys are valuable, as they flesh out the troubles, needs and desires a certain user role encounters. Each user role is defined by the reason an individual is engaging with a system in the first place. As we saw with the dreamcatcher exercise in part 2, every system is comprised of several co-dependent roles. Each role is filled by an individual who has an independent set of tasks and priorities to complete. As a result, feedback is best understood in the context of each user’s role.

The best responses come from specific questions tailored to the challenges and responsibilities that user takes on. It’s important to keep in mind why you’re surveying these people. Good questions prompt the survey taker to tell you about the experience, but as the question writer you can’t allow your own theories and opinions guide those responses. What are the steps they must go through to get the job done? What aspects of the task are most difficult for them?

Wording questions for specific yet unbiased answers can be difficult. A good rule of thumb is to try the questions out yourself. Is there more than one possible answer? How predictable are the responses? Instead of asking: “Do you think the sign in process is problematic?”, you may ask the survey taker to “Please tell me about how you sign in at this office…”

If the sign in process at this fictional office is obviously and hopelessly flawed, then skip the basic portion of the question. Think instead about why a better sign in process would be important to the patient, and gear your questions towards getting that information.

Take a look at the survey below. This Survey was conducted to evaluate the care environment in the Oncology Clinic at Miriam Hospital.

IMG_9259 copy.jpg

This survey is an example of an instance where a survey taker goes above and beyond. She gives a lot of detail about what a nurse does in the clinic. However, she also shows an awareness of how she handles those responsibilities when interacting with patients. This nurse describes her professional and therapeutic temperament as a coping mechanism for her patients. This adds a layer to the formal list of responsibilities a nurse has in that environment, and insinuates that the clinic might be an uncomfortable place for patients. This type of self- analytical response gives you, the evaluator, everything you need to understand her place in the equation, as well as a sense of her insights.

Not everyone will be so willing to give quality feedback. Naturally some people, like nurses, feel obligated to be thorough and competent. Others, namely the patients in the clinic, didn’t take well to filling out surveys typed up by some pesky RISD students.

The survey below is from one such patient. The curt answers don’t give us more than the facts.

IMG_9253 copy.jpg

To avoid useless survey results, remember to word your questions carefully. Due to patient privacy laws, I can’t recommend you record your interactions with people in the clinic, however take notes on what they’re saying. Most of the patients we surveyed were having chemo done, so they didn’t feel like writing. If you wish to take anything from my advice on the written survey methodology, remember to keep your interactions cordial, conversational and natural. Most importantly, keep your ears open and your mouth shut. If you can coax someone into a story or rant, you’ll learn a lot more about who they are and what they experience, than you might if you expected them to articulate the same insights on paper. Written surveys are flawed, but if you can make up for their shortcomings with some social finesse, you’ll be able to collect all the information you need from anyone.

System Mapping: Problem Generation Part 2

By Aaron Heskes

Secondary research is good. In fact, published research is scientific, comprehensive and reliable. However, the value of the design process is in its application to unique environments and unusual situations. Almost anyone might be willing to give their opinion on a product or service, but a designer can’t operate on opinions of what “should” be changed. User opinions are valuable if only as an indicator of the general proximity of a pain-point.

Within any product system, there are always weaker areas where an unusual burden is put on a group of users. This could be a passive end user such as a doctor who enters data into a health record, or non-user participants, like her patients, who must wait longer because she has difficulty entering the data efficiently.

In a case like this, our survey of the patients in the waiting room would probably return complaints of long wait times. The challenge at this point is to look for the causes of those wait times. Discovering the root problems by mapping out what each person is responsible for and who they interact with is the primary goal. I’ve already identified the root problem in this hypothetical situation, but if we were to attack a problem like this in reality, it would take much longer to even discover the data entry problem.

It’s important to emphasize the value in viewing a product system as an interconnected entity. Picture a dreamcatcher; It has a circular perimeter to hold its shape, and a web on the inside linking all areas of the perimeter. The circular perimeter is representative of a user’s workflow, broken down into each step which is necessary to use a system or product. We can arrange the user’s steps in a circle because the they always repeat themselves in the same order; they are cyclical. However, each step has a direct effect on the next consecutive step in the system and an indirect effect on the other steps.

With this picture in mind, we can take survey responses and connect surface level pain-points (or complaints) to deeper causes of dysfunction. This is in the service of avoiding premature solution generation. For instance, you may conclude from your patient surveys that the wait times are abnormally long. This is important information though it is not enough to start the solution generation phase with. If you were to try to solve the surface problem with such little information, the best solutions you could come up with would be limited to occupying the patients in the waiting room instead of shortening wait times or making appointment arrival times more accurate.

Let’s look at this dreamcatcher diagram. Again, its purpose is to help us visually lay out a complex system.

The first step in creating a dreamcatcher diagram is identifying the primary task. What is the main goal here? Within a doctor’s office, it might be to perform a complete physical on a patient.

Next, identify the primary user. From her point of view, list out all the steps she must go through to accomplish this primary task in a circle, from start to finish to start again.

Within each step, answer the following questions:

What is this user expected to do?

What does she need to know to complete this step?

Who else is involved?

Answering those questions will give you a good idea of how effective the current process is, and which steps present problems.

At all steps where the primary user interfaces with a machine or secondary person, the primary and secondary user share a step. These points of interaction in the process allow us to branch out to elaborate on the responsibilities of secondary users in accomplishing the primary user’s main goal.

To elaborate on a secondary user’s process, simply repeat the dreamcatcher diagram and fill in the steps.

Screen Shot 2017-08-23 at 3.04.23 PM.png

Personas: Problem Generation Part 1

By Aaron Heskes

Design is not a linear process. Rather, research, need-finding and incremental product development (via prototyping) all move cyclically to identify a set of problems. These activities all go hand in hand to close in on solutions incrementally.

As we look at the best starting place for the design process, I think it’s important to emphasize that all these processes are repeated several times in the iteration of a design thesis and later of a product.

Since people are always at the center of the problems we’re designing for, it’s best to start by understanding those individuals. A good understanding of who someone is can come through several different lenses, depending on which attributes and behaviors are relevant to the need or task.

For instance, the initial goal might be to make living with type 1 diabetes easier for teenagers. Although it’s a broad goal to start with, it allows the potential solution to take any form. This means that the solution will not be predetermined. If a team were looking specifically into insulin delivery, they might come up with a more specific goal, such as…

“to make the best insulin pen.”

Although this seems like a perfectly fine goal, we can improve it by making the parameters more specific and the scope broader. So, a better goal might be…

”to make the most intuitive insulin delivery system.”

This way, the method of insulin delivery is left open, while the goal of making that system easy for first time users to understand is very specific.

Although we’re labeling personas as a good starting point for the design process through understanding the users, the finished personas in themselves are the result of measurable research and time.

For many first-year undergraduate projects in the studio, Proto-personas suffice as decent guides for the direction of the project. Proto personas are based on secondary research from other people’s conclusions. They offer valid, though general, information on a demographic. Some studies may offer good information, but relying on these sources to develop users and use cases will never bring anything new to the table.

As we’ve begun to discuss how design relies on an understanding of the user’s habits and needs, it’s important to note that marketing teams also make use of these tools to determine the types of customers they are speaking to, and the message they want to send with their product.

What separates a marketing perspective and a design perspective is that a marketing team works backwards. They have a product that they’re trying to sell to a chosen audience. In a way they define the audience, not the product. Marketers may care about demographic information, buying motivations and customer behavior, but it’s not within their depth to care why a customer makes certain decisions.

By contrast, an understanding of these motivations is particularly the insight needed to develop a product thesis. Design personas do not necessarily separate people by age or social views, but rather by ability, means and any other factors that would cause them to have different priorities.

This begins to answer our main question: Where does this solution fit into the user’s life?


So, we know that understanding our user’s behavior and needs is the best way to design a relevant solution, but you’re probably wondering what the best way to collect primary information is to build those personas? That’s coming up next time as we delve into the gritty task of writing, administering and analyzing surveys!

max persona.png


Designing for Task Completion

By Aaron Heskes


I want this phonograph, and I don’t even own any records. The Braun Phonosuper sk4 is a product of German postwar “geometric formalism.” Geometric formalism describes the school of design that governed the aesthetic and interfaces of Braun’s products for years under Dieter Rams’ direction. The straightforward layout of the controls and simple form language serve to bolster manufacturability and visual legibility.

A product’s visual and tactile details should tell a story about its use.

Rams’ phonograph looks simple, but his adherence to geometric simplicity and minimalism allows him to control what the product tells people about itself. Its simple and boxy structure might not speak to the music it produces, but rather to the environment it lives in. Consciously or not, everyone approaches a new gadget or appliance with the following questions. They might try to answer these questions mentally before trying it out, or as they go through the process of figuring it out.

What is your function?

What do each of your controls do?

In what order to I need to operate your controls to make you work?

Should I be gentle or particular with how I operate these controls?

We can look at a dinner party place setting the same way.... There are six utensils and four glasses to arrange for the diner. The order of these items on the table corresponds to the sequence of the courses, so that the diner only needs to take the outer most desired utensil during each course. Similarly, the champagne flute is the farthest to the right because it would be used for a toast at the beginning of the meal, and then cleared. Without this system, diners would not be able to use the proper silverware, making extra work for the help.

Within the world of electronic and mechanical products though, there is much more potential to make understanding from a two-way conversation. The designers can introduce details that give the user active feedback, such as an illuminating ON button when the button is depressed.

Passive feedback plays an equal or greater part, especially in a product that is as hands on as a phonograph or radio. Visually, the purposeful and minimal approach affords big opportunities to grab the user’s attention. Naturally, there may be a sparing use of color or visual mystique aside from the start point or end point of the interface.

Coming back to the place setting example, the same logic used there dictates how designers lead a user through any experience. The bright red button draws the eye in immediately. From there, even just by feel, the hand moves to the largest knobs. It doesn’t matter which the user chooses first (volume or tuning), because their functions become self-evident by simply adjusting them. The feel of the knobs punctuates this information, as the volume knob is smooth and linear, whereas the tuner is precise and notched.



Plastic Straws and Product Lifecycles

1 Comment

Plastic Straws and Product Lifecycles

By Aaron Heskes

Welcome to the design blog!

Here, we don't just talk about our world of consumer products and services, but also the thinking behind them. 

Every artifact has a specific purpose, and the initial presentation and packaging of it is usually essential to understanding how to use it properly. Unfortunately, it's often the simplest objects whose proper uses are neglected because people assume they already know how to use them.

Last week I was doing something I do a lot at my day job and this thought stopped me in my tracks. I was preparing a coke (actually it’s a pepsi, but no one would order it if they called it that). I don't have much to say about soda since I'm in no position to judge a sweet tooth, but I caught myself committing a minor hygiene violation.

I’m talking about straws here... plastic drinking straws with tidy paper wrappers to keep them clean.

These fancy straws are great for individual use because the crisp white packaging tells the end user, the soda drinker, where that straw has been. Its condition ensures that they’re the first one handling the straw.

This all falls apart in a restaurant setting.

I had to stop and think as I was preparing this “coke” because I realized that by tearing off most of the wrapping and leaving just an inch of sanitary wrap on the tip of the straw, I was defeating the purpose of the wrapper. Since tearing off most of the wrapper before serving it to a customer seems objectively illogical, I think an explanation is in order.

Restaurant staff do everything they can to make the patrons believe that they’re special and that the food/service/serving-ware is sanitary. While this is largely already true, sometimes working to uphold a perception of these values works against the end goals.

The paper wrapper communicates cleanliness so well that leaving a bit of it on the tip elevates the perception of cleanliness in the entire restaurant. This detail tells the patron that the server has considered their health.

Unfortunately, tearing off the wrapper forces the server to handle the straw more than if he had used an unwrapped straw.

All products have an intended life cycle, but few are interpreted properly at every step of the way. It’s important to understand whether or why people may misuse something as simple as a paper wrapper to design a complete process that actually accomplishes what it sets out to do instead of encouraging the problem.

1 Comment