Overview
The Insights Dashboard in Live Aware compiles similar verbal data, allowing developers to easily triage feedback from users minutes after an interview, playtest, or build review. The feature includes a dashboard interface showing a short summary of each feedback group, a detailed view of feedback, and triage options.
Role
UX Designer
Year
2023
Project Length
6 weeks
Skills
UX Design, Iteration, Sketching, Presentation, Writing.
We regularly conducted discovery interviews with our current and prospective customers. At the time, we were interested in their playtest and player feedback workflows. Based on each interview, I created a flowchart of the customer’s workflow, noting tools and painpoints. I also highlighted how current Live Aware features could fit or replace other tools, as well as opportunities for Live Aware features that could solve painpoints.
Above: Example workflow. Identifying information is redacted.
Users told us that they would receive an overwhelming amount of data to analyze and triage. QA teams were finding it especially difficult, noting it would take them multiple days following a playtest to compile the data, inhibiting their feedback flow and limiting the frequency of playtests. With the evidence from the discovery interviews, this painpoint was identified for ideation and feature design for the upcoming sprint. I then conducted secondary discovery interviews with our customers to confirm how their workflows work and to get a better understanding of their tool usage and painpoints.
[Preface explaining design process with a flow?]
I created a proposal for the new feature, featuring user stories, limitations, and a brief competitive analysis. I also had a meeting with the design and engineering teams to gain a mutual understanding of the engineering limitations, most importantly with the technology we were using to analyze and compile data from transcripts. User stories were made with my own and the company’s design values in mind.
At the time, we called the feature the Event Insights Hub and each grouping of feedback was called an Insight. We later changed the name of the feature to the Insights Dashboard, which is what I will refer to it as.
After I completed the first draft of the proposal, I requested feedback from the design and engineering teams and they contributed ideas and critiques. I revised the proposal and once the whole team approved, I began sketching and ideation.
As a user, I want to...
Our customer’s workflows can vary widely, both between organizations and within organizations (or even within teams in organizations!) With every interview, we’d see a new workflow that could benefit from Live Aware, or see a way we could add an affordance to an existing feature to help them benefit. Keeping this in mind, I wanted to keep the constraints of insights as open as possible, so users could add as much or as little information as possible. I also wanted the format of the dashboard to be adjustable for user preferences. Given all these options, the challenge was going to be keeping all of these options and preferences easy to access, understand, and adjust.
I made some loose sketches of dashboard views to start, trying to understand how different arrangements affected the feeling of the feature. I was aiming for something clean, open, and nearly tangible, while still having some structure. I also wanted to match the visual design patterns we had already established in Live Aware, like modal and card-like elements.
As I continued ideating on affordances and started lo-fi wireframes, I met with the design team for design jams, where we would all share our work on various features and give our feedback. Design jams were also a good time for the Head of Product to reign in scope given his knowledge on the current engineering timelines. In the design jam, we deprioritized some format preference options to lighten the engineering load for the first implementation.
Once I completed the mid-fidelity wireframes, I prepared the design for hand-off and critique. I labeled each flow with a corresponding user story and with written steps for each flow. Details and notes were also included for clarification as needed.
In this iteration of the insights dashboard, there were four components: the summary, key insights, reports, and action items.
The initial proposal did not call for a summary, but I decided to include one at the top to give context to what the user would be looking at as they used the dashboard.
Below the summary, in the largest block, I featured key insights. Before this, we had created reports that included insights in document format. Taking notes out of the workflows our customers described to us, and my own experience doing UX research a few years prior, I tried to capture the feeling of thematic analysis. Presenting insights in this way made them much more digestible and enabled novel usage of these groupings. Users could take further actions, like triage, pinning, and deleting, upon hover.
A detailed view of key insights allowed for users to see all data that was compiled into an insight, and they could take further action on it. It also provided a more focused interface for looking through key insights and moving them to action items.
Reports lived below key insights, in a smaller container. Insights were sourced from here, so users could dig into full reports if they pleased.
Action items were in the right panel, serving as a triage tool. The panel was persistent and users could drag insights and reports from the dashboard into this panel to group evidence to then export, into programs like Jira, Notion, and Monday. The design presented here for action items was a basic version, as we decided to elaborate on this concept after I completed the design work for the rest of the Insight Dashboard.
AI and machine learning are very contentious topics in the games industry, so it was important to convey ethical usage and promote user choice in this feature. Including privacy settings was difficult to think through with the MLM engineer, and I had to emphasize the importance of privacy because this would be a bigger lift for him to implement. I made a detailed flow for these settings and thought of scenarios and implications that could arise from removing videos from analysis, turning off the feature, and reading videos to analysis. Results from these actions also needed to be clearly communicated to the user as it could be confusing when things move around and disappear.
Feedback from the team was very positive, but after further discussion we decided to shift the direction of the insight dashboard quite a bit. We decided on a heavier focus on key insights and removed reports from the dashboard as we already had a place to view reports on individual videos. The design also had to be adjusted to fit technical restraints that became apparent later in the process.
Given the feedback, I revised the design to focus on key insights. I refined the insight cards, featuring categorization and feedback type to provide more context at a glance.
[Reports lived below key insights, in a smaller container. Insights were sourced from here, so users could dig into full reports if they pleased.] INSERT NEW TEXT about removing reports and summary
[Reports lived below key insights, in a smaller container. Insights were sourced from here, so users could dig into full reports if they pleased.] INSERT NEW TEXT ABOUT new info included in cards to provide more context when entering each insight
The head of product and I went through my feature presentation and noted which userflows we wanted to include in the MLP (minimum “lovable” product), which would come a sprint or two later, and which would come with future updates. With our small engineering team, we needed to make these decisions so we could release the feature as soon as possible to show to customers and investors.
With design team approval, I passed the final feature design to the UI and MLM engineers for development and implementation. Over the next few sprints I collaborated closely with the MLM engineer to refine the format of insights and the data that was included. The UI engineer sent me proposed mockups for implementation, which I gave feedback on and confirmed to ship.
I continued work on the paired action items feature. I completed the design for that feature and it was planned for implementation, but once the insights dashboard was fully implemented we decided to prioritize other important features. With the triage features already included in the insights dashboard, users already found the feature fit well into their workflows and made their processes more efficient. Action items was delayed indefinitely and slated for a major revamp to focus on advanced triage and prioritization.
[The head of product and I went through my feature presentation and noted which userflows we wanted to include in the MLP (minimum “lovable” product), which would come a sprint or two later, and which would come with future updates. With our small engineering team, we needed to make these decisions so we could release the feature as soon as possible to show to customers and investors. ] add text
[The head of product and I went through my feature presentation and noted which userflows we wanted to include in the MLP (minimum “lovable” product), which would come a sprint or two later, and which would come with future updates. With our small engineering team, we needed to make these decisions so we could release the feature as soon as possible to show to customers and investors.] add text
We continued meeting with customers and checking in on how their usage of Live Aware and the Insights Dashboard affected their workflow. We received positive responses on the interface and the concept from users during our interviews.
Users had desires for:
Users also noted some issues on transcription accuracy and insight compilation when working with longer videos.
The feedback we gathered was considered thoroughly by the design team. We made decisions on what feedback would be prioritized and how we would take action on them, dividing it into three categories:
Updates were planned into the roadmap along with our other features.