Solving A User Problem

The following aims to give you some insight into how I typically approach user problems. This piece focuses on a specific area that I worked on in recent times...

Background

Dentists and their assistants have demanding schedules, particularly in public hospital environments with ever growing waiting lists. Software can never treat a patient - only a dentist can. Therefore, having as much time possible with the patient and as little time recording information is what dentists and dental assistants need.

This piece looks at some of the problems faced within a specialty area of dentistry. I designed this particular product from scratch.

Please Note Some of the information has been obfuscated for NDA purposes. In an effort to make it more understandable to a wider audience, I've avoided using dental terminology as much as possible.

The Problem

Background: SpecialtyX is branch of dentistry concerned with the prevention, diagnosis and treatment of diseases of the supporting and surrounding tissues of the teeth.

When a patient has their first appointment, the dentist inspects the mouth and calls out what is wrong with each tooth. In most cases, the dental assistant then records this information on a desktop screen that is usually located behind where the dentist and patient are interacting.

dental environment

As the dentist calls out what's wrong with each tooth ("Numeric" and "Amber" are fictional names)..

The assistant records this information. Sometimes there are 10's of findings and time is precious!

Let me outline some of the specific problems associated with this scenario. I'll then provide some detail into the role I played in solving such issues.

  • Time pressure and volume of info: A large amount of information must get recorded as swiftly as possible in a high pressure environment.
  • Ergonomic difficulties: The person recording the information often has their back to the dentist. This makes communication between the dentist and dental assistant more difficult.
  • Administrative burden: Ultimately, less time is spent on patient needs due to the burden of admin.

The above issues were highlighted to me by the product manager and we set about finding a solution to such issues.

The Process

(A) Frame the issue and have an intended outcome

This is the most important part. What intended outcome will this product or feature have on the end user? Will it make their job quicker to do? Enable them to do it better? Having a predefined outcome creates a focus and shared vision for the success of the product and/or feature. Our intended outcome was enabling a quick and clear method of inputting data across both tablet and desktop devices.

First of all, I identified the why (user motivation/s), the who (which user types) and the when (scenarios) associated with with this particular product.

  • Why: Electronic recording of patient information is critical. However, dentists in public environments must get through a lot of appointments per day. More time with patients and less time with software is their goal.
  • Who: Dental assistants and sometimes dentists.
  • When: There are several scenarios. This article looks at 1 - the first appointment.

Usually this part would get done on a whiteboard and would form the framework in which I'd draw out some potential options, both to ensure that core business requirements are met, but also to get other people's perspectives on what might work. I believe that everyone has a bit of design within them without knowing it. That's why I'd sometimes ask a BA, tester or front ender to draw out their thoughts on something. This can be great for both coming up with a great solution and engaging those around you in the design process.

dental environment

Area for framing the problems, scenario/s and requirements.

Ideation (scribble) area.

User types. I like to keep these in view as a constant reminder to all stakeholders on who we are designing for.

(B) Sketch and prototype

I then independently sketched out and paper protoyped the various scenarios where required. I usually do this in areas of a product that are highly interative and require "custom design" (i.e. a design that isn't just made up of reusable UI components like standard buttons, lists etc.). Currently I use a combo of Sketch/Invision to prototype out in high fidelity. Other times I have used code (HTML/CSS3/Bootstrap etc.) when it has made sense to do so.

sketches and high fidelity

This is a paper sketch of a "keypad" that the dental assistant would use in order to enter scores on a tablet device.

Final high fidelity version.

(C) Test on actual users

A colleague and I had earlier established a user testing plan for the application. In agreement with the product manager, we prioritised areas of the system to test and then built out test case prototypes for 4-6 actual users to go through. We usually ask for permission to record the sessions so that we're confident in obtaining all the feedback we need.

Early stage testing on SpecialtyX confirmed that we were on the wrong track. What we thought was a clearer and more digestible way of inputting and viewing information was off. Given our limited face to face time that we get with users, I used the sessions for more than just testing but also for other research purposes. During the latter user tests, I started to sketch out potential alternatives to the design we had presented them with.

before and after user testing

Same info, different layout. Early stage user testing, particularly on products with very specific user types is vital to the success of any product's design.

Upon return from our onsite testing sessions, we identified trends and prioritised next steps. SpecialtyX wasn't the only area of the application we had been testing, but was the one which had brought about the most constructive criticism. I therefore adjusted the initial prototype based on our findings and retested it alongside the original to a mix of some of the same users and new ones who were available to participate. Users were then sent a follow up questionnaire which asked them to outline which version worked better. To no great surprise, users went with the second version by a count of 6 to 1.

The Solution

  • A "dynamic keypad" was designed that allowed the user to quickly target and update any tooth and associated measurement.
  • Only commonly used measurements are on display by default. This enables the dentist and assistant to get a full view of all 4 quadrants of a patient's mouth regardless of whether they view the information on a desktop or tablet device.
  • Clearer and quicker input of information as a result of displaying the right information, at the right time - even on a tablet device - access to such resulting in ergonomic gains.

Testing didn't end there. We retested the developed version, further tackling any UX related issues encountered. A digital product's design never ends and I'm sure we'll make it even better over time.

A Sample of The Solution

Here's what it looks like on a tablet (portrait).

What Users Have Been Saying In Relation To My Work

“Very quick and efficient. Easy to use. Excellent software.”

- Afsana Sajid, Dental Nurse

“I have just started using the new Salud Dental EPR in my hospital and it’s a pleasure to find it is intuitive and well-designed. It is easy to navigate and you can quickly see the important clinical details that is so important to ensure good patient care."

- Alastair Speirs, Consultant in Restorative Dentistry

“Easy to use and follow even on the first attempt."

- Vishal Aggarwal, Professor of Oral Medicine