How to Build a Better Dashboard

Best Practices for Surgical Device Companies

A robotic surgical device can collect as much as a terabyte of data with each surgical procedure. Unfortunately, statistics show most of it never reaches the people who could use it to improve patient care.¹ More commonly, it sits in unstructured data lakes waiting to be translated into usable form.

Enter the surgical dashboard. Surgical device manufacturers are beginning in earnest to examine the reams of data collected during robot-assisted surgeries. Many are discovering that helping hospitals access the robot’s data is a critical value-add alongside device sales.

It can be a daunting task. Today’s robotic devices can generate 3-D models of joints, capture full procedural videos, provide smart mapping technology for surgical accuracy, and much more. How much data do surgeons really want to see in a dashboard? And, how can you be sure early enthusiasm evolves into long-term user commitment?

Start with these four best practices for dashboard development.

1. Pick the right data.

Business teams often assume that, as scientists, physicians would want the functionality to drill deep into data and to manipulate it in a broad range of ways. In practice, time constraints generally trump physicians’ scientific curiosity.

Hospitals also may find there are numerous professionals and departments who need to access to the data in entirely different ways. Physicians may task admins with pulling data for presentations. Researchers may study the data for population health initiatives. Executive leadership will likely pull metrics for administrative evaluation, and engineers will watch the data to maintain and service the device.

Step one of dashboard design is to survey representatives from all the user groups to understand what’s useful to them—and to filter out what’s not. Developers can’t design an effective application unless they fully understand what the users expect it to do.

2. Identify branding guidelines.

Save yourselves from a tremendous amount of rework by soliciting input upfront from the marketing department. Countless business teams have gone far down the development path before discovering they’ve misused a logo, omitted required taglines and co-branding, or used non-compliant iconography.

To marketing teams accustomed to creating PDFs and emails, these may seem like quick fixes. On a dashboard, however, some branding features are deeply embedded into the coding, and modifications may require a complete redesign.

On the other hand, be aware that what the marketing department sometimes think of as design components—buttons, links, and even colors—are actually technical elements that are critical to the user experience. Expert developers will help you navigate those challenges, perhaps tweaking a brand color slightly to improve text legibility, or managing logo placement to optimize its appearance across multiple screens.

Dashboard Spotlight: User Experience

3. Plan for mobile.

We’ve seen it play out time and again: Whenever teams assume their users will be exclusively desktop-based, it’s almost always wrong.

Short term, you’ll get to market faster with a desktop-only dashboard. However, you’ll lose ground when you inevitably discover that clients want the flexibility to pull up a video during an impromptu hallway conversation or generate a quick chart from home. It’s considerably more difficult and expensive to retrofit compatibility with mobile devices. At the very least, teams should future-proof their projects by building in the framework to support mobile expansion in a subsequent release.

One manufacturer’s story can serve as a cautionary tale. The company became a market leader when it launched the first dashboard in the industry, but unfortunately, a non-customer-facing technical leader made the decision to build a desktop-only application. A few years later, competitors launched their own dashboards with multi-device support. Now the market leader is playing catch-up.

4. Evaluate and iterate.

Pre-launch user interviews are critical to dashboard design, but they will only take you so far. The best user information comes in after launch, when you can view user data to learn how they’re actually interacting with the dashboard.

The results are often surprising. What physicians asked for may not ultimately be what they really wanted. Or, you may dig into an area of unexpected low engagement and discover a friction point that causes users to abandon a search.

The importance of continued evaluation cannot be overstated. As part of the development process, assign a person or team to be responsible for regular, scheduled review of user data and feedback. Go deep—if your team is tossing off quick traffic reports, you’re missing a significant opportunity.

Usage data then provides the starting point for user interviews. Why are certain pathways getting no engagement? You may uncover common error paths that prevent people from accessing certain sections of the dashboard. What value are the power video users getting from being able to export video segments? You may be able to inspire other physicians to find value in it, too.

Usage data then provides the starting point for user interviews. Why are certain pathways getting no engagement? You may uncover common error paths that prevent people from accessing certain sections of the dashboard. What value are the power video users getting from being able to export video segments? You may be able to inspire other physicians to find value in it, too.

What you learn from the scheduled reviews will inform future versions of the dashboard. Yes, iteration must be factored into the project from the outset. Web applications are never “done;” they’re constantly evolved to improve usability, keep up with trends, and accommodate upgraded technology. With continued investment, they deliver ongoing business value for both you and your customers.

---

Resources: 

• ¹ https://www.healthleadersmedia.com/finance/data-analytics-utilization-negligible-among-80-healthcare-orgs