Aventa Discovery Dialog
The Problem
GN ReSound hearing instruments are programmed via a desktop software platform titled Aventa. And, it can connect to this software via 2.4 Ghz technology. This is extremely convenient for patients who have trouble hearing because they do not have to remove the very devices enabling them to hear what their audiologist is saying. However, the largest problem we discovered through our research was the ability to both discover and connect to the devices. This wasn’t a technical problem at the time. It was a problem with the way the interface was engineered.
The connection flow for a new patient in Aventa looks something like this:
Boot the software —> boot the hearing instruments —> discover the hearing instruments —> select the desired instruments —> connect (via connection flow)
But, the problem wasn’t with a new patient – rather an existing patient. Until Aventa 3.9, if a patient had been previously fit with a device or set of hearing instruments, we automated the discovery process and moved the user right into the connection flow. The problem with this was the patient might have a non-functioning instrument needing repair or maybe they lost their hearing aids. Or, maybe they were upgrading their instruments to later models. This made it difficult for audiologists to loan a patient devices or to upgrade them. (As a side note: Automating actions for a user always runs the risk of wresting their control in completing their tasks.) In other words, the software would often conduct a 1-2 minute search for instruments that could not be discovered or weren’t present. This was the largest problem. But there were others.
Our research indicated, some audiologists were having difficulty understanding how to stop the software from searching for an instrument. We also found some audiologists had difficulty understanding the interaction of selecting an instrument and confirming their choice.
Project Details
Client GN ReSound
Date May 2015
Skills Interface Design, Interaction Design, Axure Prototyping
The Approach
It was clear the interface for discovering and selecting devices needed an overhaul. This process and the interface that supported it, needed to clearly indicate to the user what instruments had been discovered and what was being selected.
Additionally, the functionality of this process needed to be reengineered. Users needed to have the option of stopping the automation process for discovering previously fit devices when they wished to either replace or not use those devices. This required rethinking how audiologists discovered hearing instruments within this interface.
Our solution was twofold. First, we overhauled the discovery interface – making it clearer to the user what they were discovering and selecting during this phase of the connection. Second, we ensured our interface design supported the discovery of any instruments present and gave the user control over the selection (and sometimes replacement) process.
UX Work
I chose Axure in developing the design for this project for two reasons. First, it allowed me to iterate quickly and I didn’t need high fidelity wireframes (or comps) to sell functionality. Second, I knew I would need to show the interaction. Axure would allow me to do this more quickly than most other tools.
Wireframe Examples
User Flows
Static wireframes were not going to suffice for this project. Stakeholders and developers (who are also, technically, my stakeholders) needed to understand the flow and various user scenarios that would likely occur.
Prototypes & Videos
Even given wireframes and user flows, stakeholders often need to see the design in action. For this project, it was very important because timing was a key component of the design and very difficult to explain in human language. If a picture is worth a thousand words, a prototype can often be worth a million. So, I often record demo videos. The reason for recording videos – something I have written about before – is prototypes often seem to fail only when you are presenting them (i.e. the most inopportune times). But, the primary reason is because our stakeholders are all over the world at this point and you can simply email them a demo they can watch it over and over before providing feedback.
Functional Specifications
View the functional specifications for this feature, which will walk you through the wireframes and key components of the design.