The Vungle dashboard is a front facing desktop tool, used by 20,000 customers to create campaigns, add their applications, and make money with us.The dashboard had not been updated in 3 years and there were many user flow issues and technical limitations. 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.
I worked cross functionally across the company with a team of three designers, a product manager and 4 engineers to launch this project. I currently lead the UX team in further evolving the dashboard and releasing new features.
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.
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) Improve support documentation for developers
I sat down with around 10 mobile developers and watched them integrate our SDK using different platforms. Based on their feedback I realized the hardest part of integration was that developers would run into errors as they did not have the right/updated build environment before they started to integrate our SDK.We reorganized our support documents with a step by step table of contents so that new users would update their build environment before integrating our SDK.We also built a test app that developers could use to try our product before they integrated the SDK into their application, which the engineering team implemented.
3) Wireframes for graphs and visual data over time.
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. The screenshots below shows the V1 version that was implemented as well as the V2 version that will be implemented over the next few months.
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.
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.
3) Cleaning up SDK integration documents reduced the amount of support requests we were getting and we saw a rise in SDK downloads as users were more willing to download it and test it our with the app we provided.
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.
Finally, the look and feel was inherited and users felt it gave a cold/old feel to the dashboard.
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 am now working on removing hamburger and introducing a sub nav system that allows you to navigate sideways/downstream and upstream between account tiers without confusing users.
1) 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.
2) 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.
3) 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.
Now that the pressure of the launch is behind me – I have been actively integrating design process across the organization. I believe great products are built with tight collaboration across design, product and engineering teams something that was lacking in this project.
Having design in every step of the product process ensures we keep asking “are we building the right thing?” and “will our customer use this?” so that as a our products evolve we keep improving their user experience as well.