Brandwatch
Helping users share insights more effectively
Company
Brandwatch
Year
2022
Discipline
End to end product development
Platform
Web app, desktop & mobile
Timeline
6 months
My Role
Product Designer
THE TEAM
Product Manager
Product Designer (Me)
Engineers x 5
Product Marketing
WHAT I OWNED
Research Plan
Customer interviews x 6
Problem Definition & Synthesis
Ideation Workshop
Wireframes
Hi-Fidelity Design w/Design System
Usability Testing
Final Designs & Handover
THE PROBLEM
Brandwatch analysts spend their week finding things nobody else in the business can see. Then they spend hours rebuilding those findings in PowerPoint, because the people who need them don't have a Brandwatch login.
THE SOLUTION
A dashboard sharing journey that allowed Brandwatch users to share insights with people who don’t have an account. This allowed them to view insights on a range of devices.
A sharing flow within the Brandwatch web-app (desktop).
A desktop and mobile responsive dashboard.
Link management section allowing users to edit and delete existing links.
THE CONTEXT
Consumer Research is Brandwatch's flagship social listening product. Its users are analysts and researchers. Their audience is everyone else: clients, execs, marketing teams, none of whom have a seat and most of whom would never learn the tool.
I joined the reporting squad as the only designer, alongside a PM and five engineers. The brief was as open as a brief gets: improve reporting.
DISCOVERY: UNDERSTANDING REPORTING
The PM and I ran interviews to understand how users worked with dashboards and where it hurt. We came back with far more feedback than one squad could act on in six months.
Rather than average it into something that half solved everything, I split the feedback by use case, sharing, exporting, visualising, so we could see which one carried the most weight. Exporting and sharing won by a distance.
WHAT WE FOUND
Dashboard export was PowerPoint only. They wanted a web view.
They wanted to send a dashboard to someone without making them log in.
They wanted live data, not a snapshot that was already out of date by the time it landed.
They wanted their client's brand colours on the charts.
They wanted a rich text editor for notes instead of writing Markdown.
Synthesis: Three themes came out of the research
Customisation
Allow users to tell a story through with reports by making them more appealing and relatable for the business/client in terms of branding
Convenience
Users want to reduce the amount of time spent manipulating the data and want ready-to-use assets when exporting
Flexibility
Users want more options when they export into different formats
Which gave us the problem worth solving. Analysts were losing hours in Excel and PowerPoint reformatting insights for stakeholders who were never going to log in.
THE MOMENT IT CLICKED
Halfway through, a request surfaced in Productboard: let users share a dashboard by URL. This wasn't owned by our squad so it was a serendipitous twist. We had heard that;
Churn Feedback: labeled as a significant limitation of the product
System Similarity: A similar, highly successful feature in Vizia (another Brandwatch product)
Competitor Features: Feature offered by major competitors
That's when the PM and I knew we had it. The research told us what users needed and why. The request told us what it was worth to the business. Both pointed at the same build.
It also changed how I think about research. A backlog of product requests is user research. Someone has already done the work of telling you what's broken, they just filed it somewhere else.
GETTING TO A SOLUTION
Ideation Workshop
I ran an ideation workshop with the whole squad, engineers included, against one question: how might we let analysts share a dashboard with someone who doesn't have a login, in a way that's customisable, convenient and flexible.
Bringing engineers into that room early was the best decision I made on this project. They came at it from feasibility first, which killed two directions before either of us wasted a sprint on them.
Competitor Analysis
Alongside that I ran competitor analysis with product marketing, covering direct competitors and then Google and Miro, because sharing is a pattern people already know and I didn't want to invent a new one. Brandwatch had merged with Falcon that year and their platform already had dashboard sharing, so I pulled their flow apart to see what we could align with rather than build a second, slightly different version of the same thing inside the same company.
Feature Prioritisation
The PM and I then mapped the user journey in Miro and used it to cut the MVP.
Design
Step 1: Sketching and creating a mid-fidelity wireflow of the proposed flow
Step 2: Review in Miro with developers & product manager present.
Step 3: Move to hi-fidelity design once signed off. Using existing design system.
Testing
Two rounds of testing with internal and external users. Ten participants rated the prototypes 4.95 out of 5 for ease, and everyone completed the tasks without guidance.
That was reassuring, and not the useful part. Two findings changed what we built:
Preview
Users wouldn't send anything externally without seeing it first.
Link management
Users needed to be able to revoke a link. A live dashboard of client data reaching the wrong inbox was a liability That pushed link management from a phase two convenience into a security requirement, and it went into the MVP.
WHAT SHIPPED
A sharing flow inside the Consumer Research web app
A dashboard view that worked on desktop and mobile for recipients with no account
A link management section for editing and deleting existing links
WHAT I TOOK FROM THE PROJECT
Collaboration. First time being the only designer on a squad. I ran stakeholder interviews with the engineers before anything else so they knew how I worked and where I wanted them involved. It got me a much sharper read on what was technically feasible, and got them thinking about users earlier than they otherwise would have.
The right feedback, not all the feedback. The wider I opened the work up, the more opinions arrived from people without the squad's context on scope and constraints. Listening to all of it and actioning none of it is as bad as the reverse. Deciding which feedback to act on is part of the job.
Knowing when it's done. I ended up running a workshop with other product designers on this, because I still don't have a clean answer. Turns out nobody else does either.