Cloud Services Dashboard

Dashboards are a powerful tool for helping people make sense of a large and complex set of data, especially when much of that data resides in systems that are maintained and produced by different teams for different purposes. With the right visualizations a dashboard can deliver unexpected and valuable insights that drive improved customer service and a competitive advantage.

Oracle tapped me to lead the transformation of a dashboard conceived as a way to help technical support engineers, managers, customer liaisons, and executives better deliver and monitor a portfolio of cloud services, and for customers to better understand the value of these services. This was particularly challenging, as data visualization design was still uncharted territory for me.

Guided by Abraham Lincoln's dictum to "spend six hours sharpening my ax...If I had eight hours to chop down a tree," I immersed myself in seminal works on the subject, notably Stephen Few's Information Dashboard Design: Displaying Data for At-a-Glance Monitoring.

Because of our team's workload and differing time zones, the other designers were unable to dedicate the same time to mastering the visual design of data. To overcome this challenge, I created foundational design templates in vector format that could be used and expanded upon by the rest of the team. The templates included dashboard chrome, a special dashboard grid, widget chrome, widget settings panels, filter and control examples, a color palette, and dozens of widgets with a rich mix of possible data visualizations. 

These templates permitted the team to produce designs for more than sixty widgets within ten days, exceeding all expectations. But this was only one hurdle.

Another element critical to the project's success was ensuring that the widgets we designed would be both technically feasible. We were already committed to using Oracle's own JET component library, but our designers were unfamiliar with these components and the complex configurations possible. Just as important, our developers would be unable to deliver the designs we had conceived unless those designs accurately matched up with those components, and all necessary configuration data was provided.

To this end, I created a widget spec sheet template in Confluence, so that each widget designed would have its own wiki page containing not only the visual design artifact, but also all configuration and meta data required by developers. The template also included information on the stakeholders, designer, users, and others involved in the creation and use of the specific widget. Our team produced a spec sheet for our still-growing library of widget designs, giving everyone a single place to find and manage everything about each widget, including status, related user stories, and more.

Despite these achievements, the most important element was ensuring that the widgets designed actually provided real value to the intended users. Given the variety of cloud services to be supported and the variety of roles people played, and the nature and workload of our team and the people we wanted to talk to, numerous in-depth discussions, ethnographic studies, and even surveys were not feasible. Instead, we based initial rounds of widget design on our own understanding of the services and users that we worked with routinely for other design work. In short, we proposed possible widgets in order to provoke critical, but valuable, feedback.

This approach produced the best results, supplemented by whatever one-on-one meetings, web conferences, phone calls, email exchanges, and chats we could arrange with stakeholders and users where visual designs could be used to promote discussion and iterative results.

A final contribution was my redesign of how users would manage their dashboards. Adding and removing widgets, managing multiple dashboards, and configuring widgets required real consideration. Our discussions with users informed us that the one or two possible filters originally envisioned — filters that would be placed in-line on the face of the widget — were insufficient for almost all use cases. Rather, a single widget might require as many as six or seven filters in order to be useful enough to enough users to justify its creation in the first place.

To address this and keep our widgets focused on the visual display of information, I designed a settings panel and the means to access it with ease. In addition, I created a wiki page that contained a master list of every filter type, along with its component type, initial state, initial data, possible data, and any other information developers would need. Each was also accompanied by a vector design, so the team could simply copy-and-paste into their own designs. The unique settings panel for each widget was included in the overall visual design artifact available on the widget spec sheet.

The work proved a success in many ways. Our team went from zero to sixty (widgets, that is) in just a few short weeks, accompanied by development specifications, standardized elements, and a process for the conception, design, iteration, approval, and development of each dashboard widget. The work also helped our team with a signification internal win that recognizes the value of the work. 

 

Proposed widget wireframes

Proposed widget wireframes

Widget management mockup

Widget spec sheet

Color palette 

Widget grid

Settings panel

Dashboard mockup