Lighthouse 360

 

Lighthouse is an automated patient communications system for dental practices. The product uses patient and appointment data to drive communications through email, text messaging, and postcards, and  has won numerous awards over the years for solving a crucial customer problem. 

Company: Lighthouse360 (Acquired by Yodle)
Role: User Researcher, Lead Interaction Designer

 

Key Issues

The application assumed that everything was important, thus lacking hierarchical structure for the user. This resulted in poor find-ability of information and cognitive dissonance between related features. 

The application assumed that everything was important, thus lacking hierarchical structure for the user. This resulted in poor find-ability of information and cognitive dissonance between related features. 

Out of Control Navigation
Without any direction, all the new features that were added into Lighthouse got its own page and place on the primary navigation. This resulted in a navigation with 15 main navigational elements, creating issues with screen real estate and user comprehension time. 

"Everything is Important"
Lighthouse 360 was an application that was a slave to many masters. After the acquisition, Yodle attempted to merge their Online Presence products with the automated messaging service of Lighthouse 360. The result was a bloated application with an unclear purpose.

No Primary User
The original Lighthouse was to be a hands off application that runs in the background. However, the reality is that soliciting contact information can be a tricky task in addition to the general flakiness common to  human nature. Our team dealt with dealing with the realities of a system that inevitably relies on human intervention as well as pushing the product further into different markets.

 

 


Re-discovering the Product Identity and Story

Understanding Our Users' Goals
Before we could we could re-orient the product into this story, we had to get a firmer understanding of our users and their goals. We shadowed dental offices and interviewed Yodle clients to create user stories under the jobs-to-be-done (JTBD) framework.

Aligning Our Product Position
I gathered a group of Product Marketing Managers and Product Managers to align the story of the product the sales team was pitching (and proving successful). The result was a fundamental conceptual shift of the product that was more focused and effective.

Yellow marks areas in which we didn't have a solid understanding of the user. 

Yellow marks areas in which we didn't have a solid understanding of the user. 


Re-architecting the Product

The product story and user goals drive the architecture.

With the story and user goals in mind, I led the effort in creating an affinity diagram and to align our user goals to current feature offerings. The result was a firm understanding of where our current features stand in relation to the new story and created a road map for future features. 


Testing the Story and Conceptual Model.

Now we needed to verify that our groupings resonated with the users. With buckets already defined, we went with a Treejack test, a modified version of a closed card sort designed to test navigational architecture within a navigation without the influence of the design. 

success_metrics.png

We tested two potential versions that resulted in a 62% and 87%  task completion rate, significantly more success over the current application (control) which tested at a 50% task completion rate. 


The Result

We designed a navigational structure that not only tested well with users, but also told an effect product story that proved effective in the sales lab.