Healthcare Dashboard Redesign

I know, I know, but before you start with "Ugh, another dashboard, again?", let me say that this is not something meant for the customers as final users, but for doctors instead.

Pretty cool, uh?
So give it a read, will ya?

Industry

Healthcare

Team

1 UX Designer, 2 UI Designers, 1 Design Lead

Role

UX Designer

Tools

Figma, Figjam

Timings

1 month (and another month for the UI finalization)

Target users

Doctors and opticians, Front-deskers, Store salesmen, Admins

Project Brief

ExxolirLusettica, a pioneering brand in the eyecare field, requested a complete redesign and enhancement for the platform VisionX, which enables doctors and opticians to manage their schedules and appointment with customers visit in the stores. Part of this stream required the total makeover of the dashboard, considered blank and 'not insightful' enough for the users.

The goal is to design a business intelligence dashboard, able to solve the issue of each employee inside of the practice of having to go to multiple systems or screens to understand what they need to do and how their business if performing today.

In order to do that, it is required to refresh the design of the current functionalities and provide integration proposals for new ones, based on how other competitors do and what the users may need during their daily job. The dashboard should provide useful insights and overviews for:

• Doctors and opticians who need an overview of their schedules and appointments
• Front-deskers who have to manage daily appointments
• Store salesmen who want to understand better the store revenues
• Admins who have necessity to administrate the other staff members.

MY ROLE IN THIS PROJECT

I played a leading role in defining and creating the dashboard’s User Experience, working directly with the project owner in ExxolirLusettica.

I handled the entire research and design phase to incorporate the requested features, as well as integrating additional functions that could be useful for enhancing the dashboard itself. I also made sure the dashboard was fully customizable, dealing with all the challenges that come with creating such an adaptable and flexible design.

Once this phase was over, I supported the UI Design team in finalizing the UI.

INITIAL STATE OF THE PROJECT, GOALS & KPI

This is how the dashboard looked like before the redesign process. Pretty plain, isn't it?

This project for VisionX was much more than a UI refresh. It was an opportunity to transform a complex ecosystem of tools into a cohesive, scalable, and user-centered platform—one that balances business ambitions with the real needs of Eye Care Professionals (ECPs). The goal wasn't simply redesigning an interface, but helping define what the future of connected eye care could look like.

But, in order to do that, we needed to understand the real users needs.
So, after a few live workshops with the stakeholders in the United States, the business gathered thoughts and ideas about which sections and functionalities this new dashboard should include. 
Here is the list, according to the client brief:

• A clean appointment section comprehensive of:
  • Today's appointments list
  • Appointments YoY – Day shifted
  • Appointments for the rest of the week that do not have all pre-requisites completed
  • quick links to resend documents or text/call patients to complete work
• Exams Section:
  • Current exams
• Order section:
  • Orders/invoices
  • Product pickups
  • Daily Revenue – YoY Day Shifted, by hour
  • Capture rate – YoY Day shifted, by hour

THE PROCESS

First of all, I spent a lot of time doing benchmark research to get a sense of current trends in healthcare platforms. Since this is a very specific field, in addition to researching competitors in the medical sector, I also explored more visually oriented platforms, such as Dribble, just to get an initial idea that I could later discuss with the UI team. 

A glimpse of the benchmark I did in the initial phase

Once the research was complete, I began the brainstorming phase to collect ideas and better understand which features might be useful, based on the roles of the various professional profiles targeted by this project. Some insights I had gathered during the benchmark research came in handy here, so I decided to note them down as “additional suggestions.”: even though these features  hadn’t been formally requested by the Business, I was quite confident I could initiate a discussion with the project stakeholders to explore whether it might be worth going beyond the basic MVP concept.

This could give you an idea of the considerations I was doing with the internal stakeholders to define the purpose of the dashboard

Once I received the go-ahead to look into the integration of these additional features for the proposal, I turned my attention to the actual design. Considering that this platform was already undergoing a UX/UI review by my team and others, and at the request of the project owner to speed up the process as much as possible, there was no initial phase consisting of actual wireframes. Instead, we started directly with the UI and the dashboard’s overall structure, and then figured out how to fit the various elements within the available space.

Unusual approach, indeed, but hey, that’s the life of a UX consultant, right?

A work-in-progress screen of the dashboard, during the creation process

After several back-and-forth exchanges of feedback with the project owner and other internal stakeholders, the VisionX dashboard design was officially confirmed and the team responsible for finalizing the UI was brought on board.

PAIN POINTS

One of the biggest challenges of this project was defining the grids and dimensions of the various widgets that make up the dashboard: these could change depending on the feature itself or on how important that feature might be to the user. They could also change depending on the presence or lack of other elements, in particular during the customization phase performed by users.

The first step was to identify the possible combinations of elements per row based on screen sizes, taking into account that the dashboard would primarily be viewed on desktops and very large monitors, and possibly on tablets as well.

The defined rules for widgets dimensions within the page, with different combinations

After that, I focused on figuring out how the individual widgets could be adapted, both in terms of the displayed information and the usefulness of having a section of a certain size.
To give a basic example, the Customer Satisfaction Rate chart was not intended for the M and L formats because it would not have changed the data representation in the slightest (it would have merely increased the element’s margins and white space).

The ratio behind the widgets dimensions

COMPROMISES AND REWORKS

During the design phase, there were some decision-making challenges that took a lot of time, especially regarding the functionality to create and edit custom dashboards.

For example, regarding the ability to add widgets as the user sees fit when customizing the dashboard, I was exploring two possible approaches based on a MacOS benchmark: one involved a modal that slides up from the bottom to display the elements you can add. The second, similar approach involved a modal that slides in from the right side (both examples of what I mean can be seen in the screenshot below).

Personal opinion: in this case, I thought the side modal option might be better than the other one. They're both functional, but users might have preferred this option because it provides a better preview of how the widget looks before adding it to the dashboard, compared to the bottom modal, which offers much less space for this preview.

The side modal version

The bottom modal version

However, during a discussion with other internal stakeholders, the decision became much more contentious: another designer was pushing for the version with the bottom modal “because the other option covers too much of the underlying dashboard”. The discussion dragged on for several days, but with the support of the project owner, I tried to explain why it might be the wrong decision for this context.

After all, when creating a new dashboard, the modal partially covering the page isn’t a big deal, since it’s practically still empty and needs to be built up. In fact, as I mentioned earlier, this version at least provides an initial overview of what can be added. On the other hand, to achieve the same result in the version with the bottom modal, you have to expand it, and that ends up covering practically everything below it. This was the main reason we were more inclined toward the second version, since the two approaches were otherwise very similar.

Ideally, we would have set up an A/B test to evaluate with real users whether there was a preference for one version over the other. Unfortunately, we were tight on schedule, so the project owner took responsibility for choosing the side modal, as well as for convincing the remaining stakeholders, who were still a bit reluctant.

Also due to time constraints, in addition to technological limitations, our request to include a feature for automatically generating dashboards via AI (based on the user’s role and interests) was technically rejected. Alas, we were unable to pursue this small dream for the MVP.

FINAL DESIGN

Doctors and Opticians default dashboard

Front-desk default dashboard

Billers default dashboard

TAKEOUTS & FINAL THOUGHTS

Thank you for passing by!
Let's connect ✨

© Giada Ercolani, 2026