Millions of people are affected each year by the opioid epidemic, and we wanted to help fix it. One of the major issues is that doctors prescribe pain relief medication after surgery but don’t always know how patients are navigating their post-operative pain relief. In order to assist doctors with more knowledge of at-home pain relief and to help patients be more mindful and feel safer taking their medication, myself, Mackenna Lees, Ostin Kurniawan, and Scott Smith decided to tackle this massive issue.

Research

How can we support and improve mindful and data-informed post-operative pain management to maximize patient comfort while deterring medication abuse?

Literature Review - User Interviews - Competitive Analysis - Design Considerations

The goal of this milestone was to gain a greater understanding of the context of our problem. In designing a product, it’s essential to understand what the specific pain points are in the current system and utilize the gathered information to build a list of design considerations . 

We wanted to hear from real users, so we interviewed ages 20-75 about their experience on pain medication, and talked to a variety of doctors about the problem. This helped us understand what our product needed to focus on for the patient stakeholders - namely, that they took less of the medication than needed because they were afraid of getting addicted while doctors prescribed more just in case of need, so our product should focus on helping patients feel safer and more in control of their medication journey.

We also looked at literature about current medical devices to see what research was done around this topic already, and did a competitive analysis to see what else was out there. While solutions exist for in hospital pain management and long term medication adherence, there was little to nothing for short term pain relief. We used all this information to build our list of design considerations. As project manager, I was in charge of synthesizing the information and ensuring our research was accurate and useful.

Ideation

Now that we know what the users need, how do we make it?

Sketching - Drafting - Modeling - 3D printing

With our list of design considerations, we needed to figure out what we could build. This involved building a user flow, a pill dispenser, an interaction method, and the overall form factor. As a team, we all sketched a variety of shapes and forms we found interesting that could hold the product.

After discussion, our favorites were a cylindrical, cuboid, and ‘apple’ shaped one which we prototyped further. We knew we wanted the pills to come out of the machine, as opposed to the current system of self-regulated pill bottles. This meant we had to devise a dispensing mechanism.

We came up with a variety of ideas, from spirals to slots, and eventually found the simplest and most possible to be an upright wheel. The core of our device was a user flow that would determine how each person would utilize the machine. We simplified the National Pain Scale from 1-10 to a 1, 2, 3 rating level. Based on their pain level, they would be given an appropriate dose . User could override and ask for more medication after a lockout (the time when it was unsafe to take multiple doses)

Iteration

Does It work? What needs to be changed?

Prototyping - Iteration -

Once we had our initial sketches and ideas, it was time to iterate upon them. I did a lot of the initial 3D modeling and printing of the as we played with varying forms and figuring out what angles and shapes were best. We’d design a part in Fusion, using varying angles and sizes to fit the different pill shapes, print it out, and test it to make sure it would work. However, the dispensing mechanism was not consistent, and our users found the overall form, while easy to access, too dark, blocky, and unfriendly.

Once we had prototyped a device, we wanted to make sure that it was usable. We asked college students, middle aged, and retired and disabled individuals to interact with the screen prompts and device to understand how they felt about it and how easy interaction was for them. Using this information, we were able to change significant aspects of the design. For example, the original design was very boxy and seen as unfriendly, so we switched to a sleeker white device. We wanted physical buttons, but these confused people, so we switched to a touch screen.

The user flow underwent a variety of changes. The main goals of the interface was that it would be easy to use and extremely clear. Not only would a medical device have to be very easy to understand, people would be using this after surgery when potentially confused or in pain. The goal was to be friendly without swaying the user to make certain choices so they don’t feel ‘manipulated’ by the machine. We experimented with buttons for the pain levels: 0-3, verbal or faces. We initially planned for physical buttons, but user testing (which I took point on recruiting, leading, and analyzing) revealed that the interface was confusing and didn’t involve error recovery for the users. Since we switched from the buttons to a touch screen, we were able to make a more colorful interface that was very easy to use. The pain scale was changed into 6 levels all determined verbally with very simple language for easy reading. The back button was prominent for easy error recovery. The user testing was invaluable and allowed for us to make changes that created a better product.

Final Prototype

Final prototype - Presentation - Reflection

This process was both illuminating and a lot of fun. I relished the opportunity to use skills practically and this journey has been a learning experience. Being able to build a product from scratch was very challenging in a lot of ways. Even though I came in with a smattering of skills in a variety of fields, it was so valuable to develop each of those skills further with the help of my incredibly talented teammates. We started with conducting research, consolidating that into design considerations, building the prototype, testing it out, and finally creating a final prototype. Throughout that process, many things had to change. Our initial user flow didn’t work at all, the form factor was iterated upon many times, and we are left with a variety of dispensing mechanisms that didn’t work. However, we utilized all the information we gathered, through testing and talking to others, to build our final device that was extremely sleek and easy to use.

In retrospect, I wish we had enough time to user test and iterate upon the current prototype. Our one round of user testing was illuminating, and having a second round with the working prototype would have led to an even better final. I also wish we had gotten the dispensing mechanism working more consistently, possibly by getting the servo and testing it sooner. While I don’t regret the amount of time we spent on research, I think we should have built more in the ideation stage so we had more to test out and more time to test it.

Overall, I learned so much about building a product. From research and thinking about how to solve an issue from a human perspective, to improving my sketching, 3D design and printing skills, to designing and branding, to just figuring out what to name our team, this was an extremely thought-provoking problem that I count myself luck to have been able to tackle and work on with this incredible team.

https://www.hcde.washington.edu/capstone/2018/pca

Husky Robotics Team Redesigns

For the 2016-2017 Husky Robotics Season, I designed their Graphic User Interface (GUI). The previous GUI had been difficult to understand or use and the team wanted to have a better one for their next season. I also built and designed their new website. The old website was outdated, difficult to edit, hard to share, and didn't support all the functions the team needed. I agreed to design and build a new website for the team specifically for the 2017 team, but one that would be usable for years to come. 

GUI

Building a GUI 

To start with, I did some background research. In order to build the best GUI, I had to understand what the situation was and what would be needed on the final product. I began by asking the team leads and members a series of questions: What is the GUI for? What do you want the GUI to include and/or be like? What problems did you have with the previous GUI? I learned that the GUI is for the people who will be driving the robot remotely at competition, and that the main issue was that it was very hard to read, understand or use. I made a list of what needed to be included: 

Necessary: Three Cameras, Map with GPS, Emergency Stop 

Possible: Arm position visualization, Sensor readings, health readings of camera and sensors

In order to get a better idea of how to build the design, I looked up other activities that involve reading multiple sensors and cameras at once; flight simulators, other rover GUI's, and video game interface design.  I used this to come up with a series of design drafts in Adobe Illustrator. 
​
Once I had multiple drafts, I asked multiple team members to help evaluate the different drafts, and used their feedback to design a final prototype. Using that prototype as a framework, I worked with the software team to build a GUI using PyQT, that the team was able to use at competition.

During this process, we had to make various changes. For example, the emergency stop was supposed to be red, but was found to be too distracting, so we switched to purple. There were also significant technological challenges as we incorporated myriad ideas (the arm visualization) into the overall GUI. However, the final GUI was incredibly user friendly and worked wonderfully.

WEBSITE

Building The Husky Robotics Team Website

https://www.huskyrobotics.me/

Process:
Easy to Read/Looks Professional: 
        I chose simple colors and shades that are thematically appropriate and arranged letters in a large and clear sans-serif font. The logo is in black and white, so I used them as base colors throughout the website because it is easy to read, provides great contrast, and works with all other colors. Since the official color of the University of Washington is purple (and the team shirts are purple as well), I used shades of purple as an overlay for the page pictures as well as for subheadings and borders. The white lettering contrasted with the purple to be easy to read. 

Easy to Edit/Supports pictures and sponsor information: 
       The website is built on Squarespace, so anyone authorized by the team to edit the website can easily add pictures or change content. Squarespace functionality involves a variety of galleries that made arranging and showing the pictures much easier. The Sponsor Information is available in both the scrolling and on an individual page. 

Conveys Basic Team Information/Contact Information: 
       The website is one main page that the user can scroll down and gather a fairly accurate picture of the team, and more information can be found under the individual pages in the menu header. All information is written clearly and concisely. 

Mill With Jill

Summary

 As part of Dr. Beth Kolko’s DRG, I learned how to use a Bantam Tools Othermill. As part of a team, we learned how to do various projects on the mill, and developed, tested, and ran a protocol to teach others how to use Othermills. I later continued this program by running a Mill with Jill workshop at the UW Co-Motion Makerspace the next year.

Introduction

I had done some 3D printing, but I had never used a mill before. Fortunately, neither had anyone else, so we all set out on a mission to learn how. Using the website instructions, we played with the mills and made a variety of dog tags and rings. Once we had a general idea of how the machines worked, we completed observations of other workshops and took detailed notes to create our own instruction set. After each iteration, we’d run through the entire thing ourselves to make sure the work was clear.

Workshop

Using our carefully complied information, we ran multiple workshops to make sure our lesson plans would work for a variety of users, especially as an introduction for new users. The final workshop was a success! We introduced 5 people to the Othermill and had them all make coasters. They all rated our workshop highly and many expressed interest in continuing to use the materials to make new things!

Just for Fun

In between, I’ve done a variety of small projects to try new things and test my skills.

3D Printing

One of my hobbies is 3D printing. I first downloaded prints online to learn how the printer worked, and then tried to build my own. Although I wasn’t able to build my own 3D printer, I did teach myself modeling in Fusion 360 and used these skills both in my Capstone project, and to make these fun elephant pen and phone holders. I consider hardware to be my Design Superpower- I love building things people can feel and play with. I’d like to continue working on my prototyping skills by doing more 3D modeling and printing.