Precision Stone Treatment Simulator

Overview

A training tool that helps both urology residents and professionals to create data-driven strategies for treating kidney stone diseases.

This case study will only reflect a few aspects of my design process because this project is under NDA. Images you see are the ones I've got approval from the client directly.

My Role

I worked on the first phase of the project as a UX Design intern at Focus21. I had the opportunity to take the ownership of this project. I designed the end-to-end experiences of major platform features, interaction and product interface, and presented these to the client. I worked alongside the stakeholders, an engineering team, and a chief experience officer.

The Goal

The goal of this project was to develop a simulation service from a “static model and algorithm-based service” to a “dynamic machine-learning based service” with the aim of accelerating the training time and educating urologists and technologists.

Process

  1. Conducted generative research to understand the problem space
  2. Created a task flow to have a big picture before wireframing
  3. Sketched with pen and paper for low fidelity wireframes
  4. Designed interfaces with multi-paged forms and guiding elements
  5. Iterated designs by having feedback loop of presentations
  6. Finally, design assets, high fidelity wireframes, prototypes and mockups were developed using Sketch and InVision

Platform Flow Design

Image of sketch

Initial form sketches

Image of task flow

Task flow ideation

At first, I thought having one screen without scroll would be the best because the user would be able to interact with the input fields and see the result right away on the side. However, after presenting the demo to the client, I realized that this concept presented some issues:

  1. The information got too crowded with multiple form elements
  2. Additional requirements were found during the design phase
  3. There were more form fields than initially identified
  4. TIn the technical point of view, the dropdown fields proposed unexpected behaviour

Therefore, I decided to break forms into different pages, reducing cognitive overload, and grouped fields into some related categories for simplified layouts. This created a seamless flow for the simulator.

Balancing the Skill Levels

Image of a table

Example of a table usage

Originally, I made the table with manual input because when I talked with technicians, they were used to manual typing. However, this made me to omit the educational portion of the platform. Users had various skill levels and this should be balanced. To support this, I thought of having a tutorial onboarding but it could be frustrating for the experts so I took a part of the tutorial idea and created input fields combined with dropdown options which were based on the previous treatment data. This way, if unsure what to enter, users can refer to and choose from those options. If not, users can perform as they are used to.

Image of tooltip

Example of a tooltip usage

Not all users need an explanation, but that does not mean it should be excluded.

To make the information more succinct, I created tooltips to give people the opportunity to gain more detailed information, but would be subtle enough to all content to flow naturally.

Collaboration & Styleguide Creation

Our teams worked collaboratively with client to avoid miscommunication during the process, and to deliver the product on time. We conducted weekly meetings and communicated more frequently on an online platform. To minimize conflict between the software and engineering teams, I created a developer-friendly style guide for the simulator, and walked the team through the mockup several times. Whenever technical issues did come up, they were resolved by working with the developers more collaboratively to come up with proper design solutions that would satisfy the client.

Image of styleguide

Sample of styleguide

Challenges

Unfamiliarity with medical terms

Prior to the project deliverable, I made a point to familiarize myself with the different medical terms involved in the kidney stone treatment process. It was crucial to do this so that communication with the client would be smoother, and so that the project would be fully understood.

Uncertainty of features

One of the main pain points during the project was the frequent feature creep. To resolve it, I took on a more agile process to wireframe and rapid prototype different versions of the project to gain more understanding of what the client wanted. This was imperative in finalizing features, and due to this adaptability and ingenuity, the design was able to be delivered on time.


Solution

Simulation solution image

A simulator that resembles the workflow of a real-work environment with several guiding elements.

Results

The simulator platform was created and delivered on Novemeber 2017. Currently, it is used by over 200 residents and professionals in the U.S.

Reflection and Learnings

Ask the right questions

I was onboarded with this project that had begun a few months before I started my internship. Researching and defining stages were already heading to the end so I was overwhelmed with the amount of information. However, I strived and achieved to learn quickly and ask the right questions when I needed additional context. During this defining period, I made notes and excel files of all the elements for the simulator to run. This allowed me to enhance my productivity and worked as supporting materials for the software engineering team as well.

Design with a purpose

With projects within the medical field, there are various, intricate features that are all important. Complex features can make convoluted interfaces, however by undergoing multiple iterations with purpose, I strategically positioned elements to successfully create intuitive interactions.

Taking the ownership

Being able to take initiative and full responsibility of the project’s design feulled my passion and enhanced the productivity of my work. At Focus21, we had weekly design walkthroughs and client meetings. By taking ownership of the project, I was confident and proud of presenting the final deliverables. Throughout these sessions I recieved valuable feedback that improved the final outcomes.

User research

The technicians were used to following certain paths or actions. Due to the repetitive nature of the tasks, a habit is formed, making any kind of interference confusing for the user. Therefore, to design a new function, one needs to consider the repeated actions or habit to avoid unnatural interactions.

Thank you for reading my case study!

View More

Design.local