An Iterative Look at Discovery's Analytics Dashboard
In general, the Clarity products helped with specific business goals and were used internally by different departments at Discovery. The Analytics Dashboard I worked on specifically tackled the means of aggregating significant data and displaying it in a digestible format.
Product Designer, UX Designer, UX Researcher
Discovery created content which required a certain means of tracking and aggregated analytics to derive information for monetization. I worked on these products as a solo designer. Discovery [Digital] specifically created web-based multimedia which included documentaries, web shows, and long/short-form written content.
The Analytics Dashboard
The Dashboard was an internal tool that brought all the statistical and analytic information into one hub. It was accessible to any department at Discovery Digital—its main purpose was to have specific sets of data readily available and easily digestible by anyone who required it internally (e.g. executives, product teams, social media managers). I worked directly with the VP of Product and consulted with Engineering.
After my time at Discovery, I took it upon myself to revisit the Dashboard and improve the product over the course of ~2 years (on and off) by critiquing my own design and reprioritizing UX design alongside product goals.
Its first iteration was a rough hodgepodge of the requested content. It lacked proper UX features but included all of the relevant data. This was the version that went into production in 2016.
These are the changes I made by critiquing my old work and applying UX strategies (after my time at Discovery) This is where I started adding dials or circle line charts to indicate progress towards a goal number:
Here’s the start of segmenting and organizing the page into digestible sections. Breaking down the UI into segments allows a method of navigation by section (rather than scrolling through an impossibly long page of data and charts) and segmenting proper information into their respective pages.
Going back, the first design is approximately 7,500 pixels long and with an average of 400-600 pixels per scroll wheel on a typical analog mouse (information here & here), it would take too long to get to a certain section and even more to scroll back up. So when the data and UI expands, the new dashboard would be flexible enough for an engineer to add on, and easy enough for a user to navigate and view applicable information.
I found a lot of help through Matthew Ström’s post about the best ways to present data, and data tables.
The last iteration of the Dashboard now includes a means of navigation on the left, a cohesive branding experience (with some artistic liberty), and a better display of data in a digestible format for those who need it.
These are the cleaned up the charts—to have a clear view of the current time frame vs past information.
In the end, this was a practice of taking solutions I’ve created and re-thinking it in context of the user. Problems like this can always be avoided by bringing UX early in the process, and always thinking in context while designing.
Discovery Product Team
Eric Mies (Product Manager)
Lehua Sparrow (Product Manager, VP of Product)
Ibu Madha (Front-end Engineer)
Jae Page (Front-end Engineer)
Robert Saurini (Back-end Engineer)
San Chung (Product Designer, UX Designer)