Since there are already countless prosthetic redesigns we decided to use this project to instead rethink the process by which a patient interacts with their prosthetist and technician. Prosthetics need to be custom made to best fit their end user, but the current techniques for arriving at an end solution rely heavily on trial-and-error and anecdotal research. We sought to instead envision an end-to-end platform that used connected services to inform generative design studies. The ADAPT™ Prosthetic Platform solves the problem of poor socket-fit using Industry 4.0 techniques to collect patient data, monitor comfort, and generate new, custom designs as needed.The ADAPT Smart Sock measures key pressure points between the residual limb and socket lining. An array of force sensitive resistors are sewn into the spandex sock and their readings are taken on a microprocessor embedded in the prosthetic shin. This data is sent wirelessly to the ADAPT Patient Portal and can be used to monitor patient health and inform prosthetic design. A prosthetic technician can use the Patient Portal to generate new socket and foot concepts based on a patient’s particular needs and lifestyle. By applying generative design and finite-element-analysis to the data collected, the Patient Portal can automatically simulate hundreds of design studies to arrive at a solution that is truly unique to the end user.Generative design is a process by which hundreds or thousands of new form studies and design concepts are developed as genetic variations of eachother through mutation and crossovers. A design criteria is used to refine the concepts down in increasingly favorable generations until arriving at an optimal solution. Because these studies are done digitally the entire ideation phase of a design can happen in minutes.For the purposes of our proof-of-concept we used Dynamo Studio's visual programming language Primer to create logic-driven parametric conceptual designs. Each parametric property of the template foot, including the Keel Height, Heel Distance, Spring Height, Midfoot Arc Height, Midfoot Arc Weight, and multipliers of each, is then seeded with random data to generate a wide sampling of first generation options. As can be seen in our attached images, many of these first generation feet are so primitive they did not even result in actual 3D geometry. These options are refined through user selection of preferential results, the inputs of which are then randomized and used to seed the subsequent generations.Once an acceptable level of refinement has been reached (in our case usable geometry began to emerge around the fourth generation and was determined acceptable by the sixth generation) the resulting models can be exported to FEA simulation software to be analyzed against the data collected from the Smart Socket. For the purposes of this demonstration the downward force from the residual limb, as measure in the Smart Socket, was chosen as the simulation input. In practice, a prosthetics doctor– called a prosthetist– might choose to use simulation inputs specific to a patient's lifestyle. For a ballet dancer, for instance, a combination of angular velocity, rotational inertia, and angular momentum forces might be used to simulate a pirouette or other special case. We envision prosthetists could work with patients to create several specialized prosthetics designed specifically to their lifestyle or specific activities.The design of our proof-of-concept foot was informed by our generative design process using a combination of actual patient data and simulation data. In this case the keel and lower are uniquely joined together at the midfoot and the heel is heavily reinforced. In practice this is an “open design” since the results would vary for each patient.
I conducted user interviews throughout development and decided to launch into a 30 day closed beta in order to closely monitor user data and bug reports. I used Mixpanel to measure user activity, survey users, and A/B test push notifications. I used Apptentive and UXCam to record additional user data, including complete screen-recordings of user sessions.
The decision to drop users into a provider-catalog rather than a product-specific or discovery menu was informed by our early user studies. We found that customers had a certain level of allegiance to their chosen dispensaries, and that the brand was often the most more important factor when browsing product. This insight actually wound up informing a lot of how we structured the business and even our revenue models.We chose to add discovery and product menus as optional features for users who might prefer to browse this way.In addition to product design, I led our sales and company operations and was able to borrow learnings from these areas of the business to design a more sales-ready product. Through selling, I found that customer dispensaries wanted the opportunity to differentiate from their competitors.
I used Flinto to create several clickable prototypes for early user testing. Though high-fidelity, visuals were not as much a focus at this stage as user flow and functionality.
After a series of iterations and user interviews with both our paying customers and their users I felt comfortable greenlighting a v1.0 of the app so we could begin development.
designing with data
designing with data
At this time I was obsessed with Paul Graham's incredibly helpful series of essays on building a startup. One of my biggest takeaways from Paul's essays was that you are what you measure. We took a considerable amount of engineering hours to build out Mixpanel and Apptentive integrations to measure user behaviors and collect in-app feedback from users. This was an important part of the design process post-launch.
Our first onboarding flow required users to input the necessary text fields from their medical marijuana card. We notice that we were losing users at this step and set out to solve this problem. Our first move was to determine how many users downloading the application were qualifying medical marijuana card holders. Once we confirmed that there were qualifying users dropping off we A/B tested a new verification flow that eliminated the need to input text items. While the conversion rate did not change significantly we saw a 3.7 hour reduction in the time users spent completing this step.
I worked very closely with our developer to guide the implementation of my designs and make the build-out as easy as possible for him. I implemented my own design freeze for our v1 product to prevent unnecessary back-and-forth. I redlined everything and maintained a brand and style guide throughout.