To be able to scale the utility of the dashboard and ease the pressure on the sales team the dashboard had to be majorly redesigned.
Interviews
We interviewed all our different customers. We found that Vungle had three main types of users who used our dashboard very differently.
1) Developers used our dashboard to monetize their app by serving mobile video ads. The dashboard helped developers integrate our technology into their app and then track revenue.
2) Advertisers used our dashboard to upload campaigns and creative assets, target users and then monitor conversion rates.
3) Internal sales employees, dashboard power users, who managed large publisher and advertiser accounts.
Personas
We created personas for our different types of clients and documented all their touch points with Vungle. They helped us map out when their experience was positive with Vungle and when it wasn’t and which clients actually used our dashboard.
1) Developers and advertisers never used the same tools on the dashboard unless they were both a developer & advertiser or an admin user. Additionally if they both have the same tools side by side made it very confusing to access the information or execute a specific task.
2) Developers would drop off or need to contact support when onboarding and integrating our technology.
3) Large advertisers needed a way to create multiple campaigns for a single product or application to test out different mobile ads in different countries and different audiences.
4) Clients were looking for more visual data and reporting features.
5) Technical glitches – buttons/links would not work and pages would load very slowly.The list of problems were long. Due to technical and time constraints we decided to tackle these issues first as they were the most important for our users and business goals.
1) Different account tiers for our advertisers/developers
Based on user feedback we decided to create a separate developer and advertiser view on the dashboard. If you are both you can switch views but all your data and tools would remain separate to avoid any confusion.
Account tiers were also introduced on the advertiser side so that large advertisers could create many campaigns under their different brands/ applications.
2) Graphs that visualised campaign success metrics
The only way to access data on the current dashboard was to download a report. Our users wanted to see a quick snapshot of much revenue (developers) or how many users they were acquiring (advertisers) so I implemented a graph feature on the dashboard that included the most important metrics over a 30 day period.
We regularly met with customers both internal and external to show off our mockups and prototypes.
1) We realized we needed to add some necessary filter options so that advertisers were able to sort through their different campaigns.
2) I realized that our users like to compare data weekly and so I designed a feature that compared this weeks data with the previous week.
3) There was some confusion finding specific accounts and creatives so we added a global search feature.
Successes
1) Separating advertiser and publisher tools really helped our users execute their tasks more efficiently.
2) The graphs were a huge win and we got a lot of positive feedback across the board that they were easy to use and provided useful data.
Failures
The dashboard became very hard to navigate as we introduced an account hierarchy but not an intuitive way to get to different tiers in the dashboard. The biggest error was that you could navigate down a tier but not across which made it very difficult for our power users to get where they wanted to unless they could remember the exact name of the account/campaign/video asset and search for it.
The hamburger navigation which we inherited from the legacy design was ideal for the desktop view. It made it difficult to navigate from the developer view to the advertiser view and navigate to different sections within those views.
Fixing Navigation
I went back to the drawing board and laid out our entire dashboard and identified all the problem areas so that I could design a solution holistically and not just for specific feature.
1) A quick fix I shipped was a color change from the publisher view to advertiser view to clearly indicate where you are in the dashboard.
2) I introduced a sub nav system that allows you to navigate sideways/downstream and upstream between account tiers without confusing users.
Prototype the complete product
We just prototyped the updated parts of the dashboard but not the whole system. This would have helped surface navigation issues before the launch.
Use an iterative process to fix a legacy product
Often with limited resources it is difficult to redesign a complex product and implement it quickly. A more iterative process allows changes to be constantly shipped and also makes sure the design does not become obsolete if development takes a long time.
The quickest/cheapest way is not the best way
If more time had been spent asking our customers if we were building the right thing instead of asking if we would hit our launch date, we would have definitely helped build a better product.
