Cover Dashboard.jpg

Pando Admin Dashboard

Case study of the project of the Pando app admin dashboard and how we integrated into the web-app.

Dashboard intro.jpg
 
 

Intro

At the beginning of 2020 summer, an exciting project appeared in our radar. We had to build the first Pando admin dashboard and integrate it with the existing web-app in order to apply for an appealing tender. The end goal of this dashboard was to measure, monitor, and manage users, teams and overall communication of a hospital with a more immediate or shorter time scale.

Project Kick-off

Building an operational dashboard always starts with a list of questions from the people that will be using it. If someone is actively exploring and analyzing data, they will have a question in mind that they want to answer. Our job was to anticipate these questions and provide intuitive, user-friendly ways to find the answers in a dataset.

There isn’t a unique recipe for cooking and there isn’t a common process for building products and we broke some rules of our design process for this project for good reasons.

We started the project with a quick MVE (Minimum Viable Experience) of user and teams data table that we already had and meanwhile, this gave us time to make some research and find the relevant questions for this dashboard. These questions then would create our feature list since the features of our data-driven feature will serve to aid the user in finding answers to the questions.

This initial “discovery” phase was crucial to ensure the best data visualization product possible and instead of waiting for research results, we built something quickly to please some stakeholders and to get more time on the research. We could call it a “diversion”, that means fun in Spanish and that’s why you will always find people taking selfies on diversion road signs.

 
 
 
Dashboard MVE.jpg
 
 
 

Design aspects

Something really useful I learned is as soon as you share your ideas with the team, better they become. So once we got a feature list with all the questions that determined what was the most important data to use in the dashboard, we started talking about the wireframes and rough mockups to find the best way to tackle it. In this case, we decided to have the Material Library and its guidelines as our reference for engineers and designers. This helped us later for consistency, extra features, responsive versions and of course, to built it faster.

Cognitive psychology proves that the human brain can’t process a vast scope of the information at the same time. This made minimalism our very best option and that’s why we decided to reduce the number of tasks, cards and relevant data per screens.

We kept in mind that and we made some adjustments like turning all buttons into label buttons to improve usability or adding empty states and loading states for reducing friction during the search. All these light changes turned into a user-friendly and accessible dashboard.

 
 
Dashboard grid.png
Dashboard loading.jpg
Dashboard empty.jpg
 
 

Time to measure

The summer has gone and the last or first part of the project depends on how you look at it, has started. Metrics, events and feedback about the dashboard should be added in order to measure our success and what it’s important for all of us: to keep iterating through the right path.

Looking forward to listen to the Service Manager's feedback about using this dashboard in real-time and very impatient to know which questions will appear on this second stage to keep developing this tool.

 
 
 
Dashboard responsive.jpg