⋅Understanding the User⋅
The first step started with understanding the user. In a kickoff stakeholder meeting, the heads of product gathered in a room with me and my product manager to create personas of the users who would be most interested in the shiny new tools we would be making. The target personas we created ended up mapping to three types of job titles:
- Audience Development/Marketing
- Yield Management
- Business Development/General Manager (GM)
In a whiteboarding session, we stepped into each persona's shoes to answer the following questions:
- What is this person's day-to-day like?
- What are their KPIs and key metrics?
- What are their pain points?
- Who does this person work with?
- If we could create a dream revenue dashboard for this person, what would be the first question they wanted answered?
- What other technologies and dashboards are these folks already using, especially on a daily basis?
Left: A page out of the product team's official persona document, written by our product marketing team. Right: I created a condensed Sketch version of the personas to place side-by-side in an artboard with design files for reference.
⋅Understanding the Problem We Were Solving For⋅
The day-to-day of audience development and yield management folks revealed a major pain point: every week, they pull piecemeal revenue metrics from multiple different dashboards and try to cobble them together, in an effort to understand where to allocate inventory or grow audiences. Our technology would be able to give not only big-picture revenue numbers, but also the exact amount of revenue for each detailed segment. Our reporting dashboard would give our users actionable data that could help them figure out where to direct inventory and audiences.
⋅Creating an Outline (Information Architecture)⋅
Once we had a better understanding of our target personas, the natural next step was to start gathering the information these users needed into a bare-bones text outline.
This text outline included the main questions we needed to answer, the key metrics that would answer their questions, and the definitions of each metric. The metric definitions were more for me to make sure I was on the same page with my PM and product heads.
Sketches: User flow and information architecture
This step also included gathering all of the revenue metrics and data that needed to be included in the reports: metrics like total revenue, RPM (revenue per mille), and pageviews, and filters like filter by device and filter by geography.
The outline made it pretty clear that our product would have a fairly simple user flow:
Overview Page ➝ Reporting Pages
⋅Wireframing and Low-Fidelity Prototypes⋅
My early wireframes experimented with ways to get from the overview to the reporting pages, and different ways to lay out the overview page.
Evolving wireframes of the Revenue Summary page
I created Axure prototypes to capture basic user flows. At this stage, my team and I discussed things like how navigation would work, where filters should appear and how they would work on a basic level, how referral traffic information would be grouped, and how tertiary-level pages - aka the document level, would be laid out.
⋅Hi-Fidelity Prototype + User Testing⋅
After we felt like we had a stable UX design nailed down, it was time for me to clean up the pages with color and visual design and put these hi-fidelity designs into a prototype that could be presented to users to test.
Revenue Report - Summary page
Paid Revenue Report
My fellow UX designer Mike Mathis was in charge of organizing the user testing schedule and plan. Within two weeks, we tested 3 internal Outbrain employees, and 9 external Outbrain clients. The Outbrain employees were tested either over Google Hangout or in the New York office. The external clients, who came from 3 major publishers, were tested on-site at their offices.
Some major user testing findings: users had trouble understanding dashboard vocabulary, such as "Outbrain Paid Revenue" and "Outbrain Organic Revenue." The design was also not clear enough for users to grasp that paid plus organic revenue equalled Total Revenue.
Sneak peak: A revised version of the Overview Summary page
Coming soon. Stay tuned :-)
Sagiv Gurevitch - Product Manager
Nic Paul - Head of Yield (Product Expert)
Cham Kim - Product Expert
Vlad Ioffe, Tal Magen, Amit Levinsky - Front-end Engineering
Mike Mathis - User Researcher
Savitha Pal, Ofer Perach - Color Palette, UX