Research:
- Group sessions were held with each of the service line leaders and directors to determine the channels that need to be tracked and what items need to be included.
- Once the channels were narrowed down, I collected their thoughts from a series of questions, such as: Goals and priorities, what does success look like, how do you measure success, what decisions do you frequently need to make, and how will the dashboard help, how much time do you spend looking at data. These are just a small sample of the questions asked.
- There are many wonderful dashboard examples to be found on the web. I wanted to determine the best visual representative for each data point in each section.
- Meet with the front and back-end developers to discuss, in depth, what data we have access to and what calculations can be made from various combinations.
Results from research:
My team and I walked away from these sessions with a solid understanding of the channels each team needed and what data points will be required in order for them to make rock solid business decisions going forward. I then made my recommendations on the best solution to not just display data visually, but design the best solution helping drive decisions that deliver results on their individual goals.
LoFi Wireframes:
I started with pages of basic sketches of the layout, sections and data representation. These are my own notes along with ideas that come from the discovery phase and quick thoughts throughout the day. This is just a small sample.
Chart selection:
Chart selection can't be emphasized enough on a dashboard like this. I worked directly with the developers and leaders to capture the best chart for the data. Some of the considerations were, complexity of chart design vs. user's ease of use, desktop vs. mobile, clicks vs. rollovers, and so on.
Color selection:
Selecting colors to be displayed on the chart, for the most part, are decided by strict corporate branding guidelines. EY has a primary yellow with shades of grey that must be used to specific specification in all material. There’s also a handful of secondary colors that can be used when necessary for marketing, presentations and analytics. The colors I selected needed to reflect the theme of data being visualized, service lines and functional teams. It needed to be easy to understand and follow, from chart to chart.
HiFi Wireframes/Prototype:
This is where I simulated the final product. I felt it was important to show the user flow, e.g. what kind of information a box shows when something is clicked/mouse-over, and how colors, shapes and text changes. All of this was going to be in the final product, so it had to be planned, specified and designed – but above all, it has to be prototyped accurately.
Validation:
Here, the product’s simulation was tested with real users, communication leaders, and directors and stakeholders in order to gather feedback. Everything was documented to allow the final developers to build it exactly as it was approved. Keeping in mind, in Agile, deliverables should be early. We needed to divide the deliverable into smaller pieces, so that can be delivered earlier, and feedback loops can be shortened.
Building a successful dashboard:
In the end, a successful dashboard was launched with a clean, creative layout and an easy to navigate structure. We were able to successfully combine data points for multiple channels into a high responsive web application.
