CoEFFICIENT Metrics
Overhauling your every day Dashboards so that users can take ACTION.
01_Research
Nowadays, everyone has data.
I started this project by looking at the current state of the industry. In this case, since we were doing a lot of dashboards and data visualizations, I wanted to see how other individuals were tackling these problems.
Some of the companies I looked at, gathering screenshots, notes, etc.
Business Intelligence tools such as Tableau, Power BI, Looker, Salesforce
Consumer dashboarding tools such as Geckoboard, Databox, Google etc.
Any service I used that reported data to me such as fitness trackers, social networks, web analytics, etc
02_User Interviews
Once I had an idea of the current data landscape, and in our case we already had an established product we wanted to iterate on, I was able to arm myself with a better set of questions to see not only what was lacking in our current offerings, but questions that could help me uncover exactly how our users used our dashboards and what they were looking for in their data.
I knew we had at least 3 types of users.
Corporate Users - These users cared about performance and data at a National level. They also cared about how the software they were using/paying for was actually being adopted across the company
District and Field Managers - These users had a subset of stores or locations (ranging from 5-20) that they could be in charge of. Not only did they care how stores in their districts were performing, but they also cared how stores similar to theirs in other districts were doing.
Dealer Users - Technically not direct users of our platform, but we needed to keep these (potentially one day) users in mind as a lot of reports and screens that District and Field users might show them either in presentations, iPad, needed to be Dealer friendly. In other words, we needed to make sure they were only seeing their specific data and not anyone else’s.
03_Define the Problem
After user interviews it was easier to bucket the problems of each user into categories and themes, and also see where common problems occur.
Some of the biggest themes we heard:
Trusting the Data - Because data feeds are updated at different times or get delayed, it’s hard to tell what is fresh, especially if those same users are using other software that may rely on similar/same feeds and the data doesn’t match.
What next? - It’s great to have all this data, but once an issue is spotted, users want to take action on it immediately without a lot of barriers
Performance - Many of our district/field users aren’t on the high speed connections of our corporate users. Data load times, page performance, and mobile friendly designs are important.
04_Plan
Out with the old.
After our interviews it was clear the old dashboards were lacking in many ways especially those that hit on some of our themes:
There was no actionability, i.e “I see something wrong, what do I do next?”
There was no timestamps anywhere to show when the data was updated
Dashboards consisted of only 1 visualization so it was hard to represent different types of data (ex. your progress towards a goal)
Client brand colors were being used so it was hard to visually spot successes and opportunities
We took those key learning and a host of others into our design process.
05_Exploration
The more ideas the better.
I believe in exploring with whatever tools make sense. Personally, in this stage, it’s about generating as many ideas that help solve your key issues for each user and as a whole. Whiteboarding, sketches, low fidelity mockups, etc. whatever you need to use to express your ideas clearly.
You never know what idea or avenue you might explore that might connect with someone else. Don’t throw away any idea you may think may be too stupid or difficult. I often joke it’s nice to get the bad ones out of the way too.
Exploration on ways to make visualizations more actionable.
Lots of tools our users are accustomed with report data. The question becomes “What do I do when I see something I want to improve? Or something I want to praise? Monitor over time?
Wireframes
Numerous wireframe were created over the years to illustrate new ideas or refine current ones. We were constantly iterating and gathering feedback.
Prototypes
Often times I’d make prototypes to show how potential and new features would function in the real world especially in regards to mobile. I also could use these prototypes for usability feedback to validate designs before heading into development.
I’d use the webapp Codepen where I could load in our style sheets to give developers a boost in development or to see end expectations outside of flat design files.