Adobe analytics mobile app
Liberating numbers from a web application. This project tackled both a web interface and a mobile interface.
Role - Lead designer
Type - zero to one
For - Adobe
PROJECT SUMMARY
The context.
A mobile app version of Analytics was a popular user request on our forums, the industry run slack channel for Analysts, and during conversations our team was having with customers.
The problem.
Which pieces of the web experience would be best suited for a mobile experience? And which would provide the best utility for our unique non-analyst user base?
The opportunity.
Many of the people that needed the numbers from Adobe Analytics (to make business decisions) actually didn’t know how to use the complex web application. Instead they relied on others for to retrieve that information for them. If we could somehow liberate the numbers from our web application we would gain a loyal user base of non-analysts.
The hurdles.
Every project has baggage, things that need to be overcome in order to release the final product. This project was no different.
Analytics was built web first😭
The engineering team had never worked with a designer
There was a rough proof of concept, but this had been made with no user research
First — research
The Audit
We needed to figure out which features & functionality belonged in a mobile app, and which only had a place on the web app. This info really helped inform the script for our initial discovery calls with users.
Next — team alignment
A summary of the overall research/design process, along with the names of the new items created specifically for the mobile app would help us communicate using a shared vocabulary. This was critical since the app was a net new offering there wasn’t any precedence.
An end to end user flow outlining the steps that needed to be taken in both the web and mobile experiences to get a project on the mobile app.
Analysts needed a way to share numbers with non-analysts. People like Executives, directors and marketers. These “consumers” of the numbers the analysts were producing needed the app to be simple to navigate, access and consume. There also needed to be a way to provide context for the numbers specific to each business.
What we learned
Now iterate. Release. Listen. And of course iterate some more. Release again.
A lot changed from the initial proof of concept, to the version that acutally ended up in the app store. As the cross functional team trusted design more, I was able to make larger changes to the proof of concept engineering had put together at the beginning. The date range selector and the detail screen showing the line chart were redesigned with simplicity, and ease of (first) use in mind.
Finally — the final versions
The end.
Result —
There was previously no mobile experience of Analytics, and now there’s an optimized mobile experience. 10 months of continuous development and design iteration saw the app released in beta to a select group of customers. 2 months after the beta was released, the Adobe Analytics app was released officially and available in the app store.
What worked —
Following a more agile process. Ensuring that we were defining the set of features and functionalities our customers needed was what determined the scope of the beta release. We didn’t skimp on visual polish or user delight. Rather we prioritized the work that would deliver the most value to our user base. Nothing was added “just because it might be cool”.
Hindsight is 20/20 —
Getting the whole team speaking the same language is key. No matter how great the agile process is, if the team is confused nothing can happen quickly. Having one person from each of the cross functional attend any user research/feedback sessions greatly reduced the amount of time we spent debating the pros and cons of each potential solution.