Through user flow analyses and customer interviews, we uncovered pain points for one of Lighthouse’s key messaging features: Two-Way Texting. After a series of iterations, we improved the feature by allowing users to create and edit SMS templates, saving dental practices time and effort when communicating with patients.
This project lasted around 2 months, in close collaboration with a Product Manager, Visual Designer, and a team of 4 engineers.
Two-Way Texting was created as a company hackathon project. It was concepted, designed and built in 3 days, and when it was released to all Lighthouse clients, was hugely successful. It became one the most heavily used features, and our clients relied on it to quickly and easily communicate with patients. It also provided patients with a convenient way to cancel, schedule or reschedule an appointment, or simply let the office know they’re running late to the appointment.
As usage of Two-Way Texting ballooned, so did its use cases. The original design was meant to support office-to-patient text messaging, and provide the office with details on the patient they’re messaging, like their next appointment date or a link to the patient’s record.
I joined the Lighthouse team after the first release of Two-Way Texting. We noticed interesting usage patterns that hadn’t been designed for - for example, users were opening several Two-Way Texting windows in sequence and sending individual messages to patients, all within the span of a few minutes. We thought there was potential in those patterns - Two-Way Texting hadn’t been iterated on for over a year, and it seemed like clients were finding workarounds to complete certain tasks.
And so we set off to interview clients and better understand the thinking and behaviors behind these usage patterns.
We set up interviews with a random sample of our customers, hoping to get a diverse perspective on how they were using Two-Way Texting. These were conversations with open-ended questions at first, as we aimed to understand when, why and how they were using this feature. We learned a few key facts about their usage of Two-Way Texting:
These findings helped answer the “Why?” of the usage patterns we had observed initially. We discussed these with the team and felt that there were two potential directions to take these:
Increase the scope of our current “preset messages”
Provide a “mass text” functionality
We validated the potential of each by conducting additional customer interviews. The need for “mass text” functionality could be fulfilled by finding a better home for two messaging features that were buried within the Calendar page, so we saved that project for later and focused on optimizing our current preset message offering. Our existing library of preset messages covered 6 common messaging use cases:
Appointment Delay: notify a patient when the dentist or hygienist was running behind
Arrive Early: ask a patient to arrive early to their appointment to fill out paperwork
Call Us: ask a patient to call the dental practice
Confirm Appointment: ask a patient to confirm their appointment
Emergency Cancellation: notify a patient their appointment was cancelled due to an emergency
insurance Details: ask a patient to bring their insurance card or other paperwork with them
What we learned through our customer interviews was that dental practices had very specific needs beyond these default templates. These might cover a large swath of our customer population, but a pediatric dentistry and orthodontic dentistry have unique, specific needs not covered by the default list. Additionally, practices want to personalize these defaults with the practice’s phone number or the office manager’s name.
Creating and editing SMS templates was a new paradigm for Lighthouse, so we set off to quickly validate different approaches. I built 3 different prototypes to gather qualitative feedback from customers and decide on the workflow that best fit their needs:
The first prototype presented the new feature within the existing UI of the Two-Way Texting modal, allowing users to do everything in one place
The second prototype leveraged the existing “Communication” section where users were managing other templates (e.g. emails)
The third prototype was a drastic departure from the current mental model - it presented texting through a persistent messaging window
We conducted about 15 tests with users, and we ended up converging on the first version of the prototype for a few reasons:
While the other two prototypes tested well in terms of usability, the first version proved to be better with regards to “findability” - users knew to look for SMS-related features there.
Users thought it was “logical” to include SMS templates within the “Communication” section, but only after they were nudged to look for those features there. They still checked the Two-Way Texting modal first.
The idea of a persistent window was appealing and could allow users to better multi-task, but that outcome was out of scope and the process to edit or create a template proved to be the least effective.
Ultimately, in order to test the effect of introducing a new feature, it was also better to keep all other variables constant - something the 2nd and 3rd prototype wouldn’t allow us to do. With a general direction in mind, we aligned on a workflow for creating a new preset message within the existing Two-Way Texting modal:
I worked closely with our Visual Designer to explore different ways to create and edit preset messages within the modal. This included editing within the existing modal, breaking out the list of messages from a dropdown to a list, separating contact details and preset messages into different tabs, and creating a separate “view” for creating/editing so they could focus on that task.
We ended up redesigning more aspects of the Two-Way Texting modal to address previous UX debt that we had identified, and to modernize the aesthetic of the messaging experience. It was low-hanging fruit, and we wanted to leverage engineering efforts while they were already working to update the modal. We also found that streamlining their actions within one unchanging modal provided the greatest usability, and allowed customers to reference contextual information, such as the patient’s contact information, their next appointment date, or the message history with that patient.
Usage of the new creating & editing features for Two-Way Texting has grown at a healthy pace since we rolled out the updated interface. Customers are also very happy with the updated design. This was the first time in many months (maybe a year!) the Two-Way Texting interface had been optimized since it was introduced as a hackathon project, so even things like contrast and readability were improved with our redesign.
Don’t forget metrics. While we did get overwhelmingly positive qualitative feedback from customers through user tests and CS channels, we didn’t properly set out with a metric that we wanted to move. Without that, we can’t fully understand the new features’ effect on behavior, and determine how it impacts the business.
Start small. My first gut was to try and radically re-imagine the entire messaging experience within Lighthouse, and that quickly got out of control. Even though there might be merit to those ideas, we wanted to make sure that we stayed focus on the pain points we uncovered through research, and quickly get something in the hands of our customers to we could learn, adjust, and iterate rapidly.
The little details DO matter. Yes, as designers we’re most likely very aware of this, often obsessing over pixels and interactions. But working on a small feature like this helped elevate the value of these small details to the larger team. For example, they wouldn’t have considered improving the contrast of the text bubbles if our Visual Designer hadn’t suggested it. Take the time to find opportunities where these small changes can have a big impact.