Design principles for non-analyst reporting
I designed and conducted a 1.5-day workshop with several group exercises that led the participants to develop the design principles and brainstorm on the definitions and best practices. The workshop was virtual by using a Miro board.
There are lots of reports or dashboards in different places provided by our products to our users to measure the outcome of the marketing activities. We also have a professional analytics tool for analysts to analyze deep data. Since I worked on the reporting topics and got to know the users better, it has become crystal clear to me that the existing reporting experience is not serving the users well. There needs to be a collective voice to reshape the experience.
Plus, we haven’t had anything tangible that would support our design decisions to communicate with stakeholder and align everyone working on the product. So, I led a task force of researchers and designers from multiple products to define the design principles for non-analyst reporting.
Preparation
Besides getting the Miro board ready for exercises, the most time-consuming part was to provide context and bring participants who are not familiar with the topics to the same page. I have worked with a researcher to run a study to understand the data needs from non-analyst users. But there were lots of insights from the past research studies that can be beneficial to this workshop. To make sure the findings would be well digest by the participants, I decided to use the raw data with no subjective interpretation. I went through 6 documentations of past research I had conducted or listened in to pull out all the relevant quotes. Then I categorized them to formulate needs in a general workflow.
Workshop
During the workshop, I as the facilitator guided 6 participants to brainstorm on top relevant keywords inspired by the user needs discovered from the non-analyst research revisit. And then vote on 5 top keywords that best describe the user experience we’d like to design for non-analyst reporting. Although we had some shared thoughts, it wasn’t an easy vote. We’d like to avoid design principle that sounds too obvious or general. But also make sure they convey the standard and actionable guidelines we’d like to see in the design in the future.
Then we did a mind-mapping exercise on the top 5 keywords to further define how this principle would enable users to do and how it would guide the design work. After another rounds of voting, we have the first draft of 5 design principles.
On the second day, we revisited the design principles and rewrite the formulation. After a night of sleep, participants seemed more excited and inspired. We decided to add “Trust” as a new principle, since it’s the very foundation before using any info. After several rounds of debating and revising, we finally landed on a good state of 6 design principles and ended the workshop with sharing best practices we had seen for each principle.
Design examples
To demonstrate how the principles can be used in the design, I led a team of 3 designers to create the design examples for the principles. It’s an internal validation to ensure the design principles are not just some well-written copies. The visualizations we have created are more of the design concept that works as teasers, hoping to inspire the team with more exciting design ideas that reflect those principles in the future.
Reflection
Context is never enough
I have prepared lots of user info from past research but didn’t expect participants to have questions about the users. So what do you mean by non-analyst users? Who are they? I added the ad-hoc exercise to align our understanding of non-analyst users. Non-analyst users can be anyone such as marketers, sales, operational people, leadership, etc.,) who need to view and use data to make decisions or tell the story to stakeholders in their daily work. They may not have any data analysis knowledge or know how to use data analysis tools.
Always plan extra time
Agenda is just a plan, workshop always run out of the time. We didn’t get to finish all the planned activities in the workshop. But I think the time was well spent on discussing and understanding everyone’s POV, which is the most valuable part of the workshop. I had no regrets in doing anything we had done. But I would add time buffer to each activity next time.
Don’t expect it to be perfect
We had achieved the goals of the workshop with the 6 design principles. It’s a compromised teamwork because of the time and other constraints we had to dealt with. I accept that they were not perfectly written because I know we are going to improve them with feedback from designers who are not in the workshop. The workshop version is a great starting point, and the most important thing is that we have something tangible to measure all the design work in the future.