Aviate is a smart Android launcher that automatically organizes your apps and surfaces information at the moment it's useful. Since Q3’15, I’ve led product design (as the only designer) alongside a team of developers, data analysts and product managers. I’m responsible for every step of the product design process.

Aviate's recent product strategy is laser-focused on growth. As a designer, I've partnered with PMs and engineers to brainstorm ways to achieve this. 

In particular, I've focused on the following design goals along with their corresponding business goals: 

  1. Make search better · increase search revenue
  2. Help find what you need faster · improve app opens
  3. Help people find great apps to download · introduce app install ads
  4. Bring Aviate to new markets · establish international partnerships

PRODUCT GOALS


Features

QUICK ACTIONS

Hack build of Quick Actions

In Q4, I joined others in my team to participate in a company-wide Hackday. That week, we met to brainstorm ideas and decided to pursue our own interpretation of Apple's 3D Force Touch on iOS. The feature would allow anyone to complete actions directly from their homescreen simply by swiping up on an app icon.

Within 24 hours, we designed and built an early prototype of Quick Actions for Yahoo Mail, Spotify, WeChat, Dialer and Google Maps. We won Best Overall Hack and Best in our category.

A few weeks later, we set out on launching it as a full-fledged feature.


PROCESS

For the hack, I quickly spec'd a simple list menu with a few variations on the indicator icon. The hack allowed us to quickly get feedback from colleagues about the feature, and although the concept was extremely well-received, the gesture felt unintuitive and the animation too slow. 

To determine the use cases we would support for v1, we also began by looking into the most frequently opened apps on Aviate and inferring on the most commonly used actions for each one. 

My first round of explorations was around varying levels of content— are quick actions simply navigational or can they provide more information such as previews and widgets?

  

For v1, we settled on showing only actions, as showing previews would show too much text and take longer to read, which we felt contradicted the principle of quick actions.

aquaSpecs.png

 

GESTURE

The next challenge was to nail down on the gesture and animation. Our goal was for quick actions to feel fast and easy to discover. Our options were:

  • Single tap: Replacing existing gesture to open apps
  • Double tap: Difficult to discover
  • Swipe-up: Unintuitive and conflicted with another swipe up action in the same area (opening People Space)
  • Long-press: Users already do this to rearrange apps, could we somehow combine these two actions in one gesture?

We tested these ideas by creating a Javascript prototype and I used After Effects to explore the timing of the indicator animation.

We also conducted two user studies and found that users were able to discover long-press the easiest, but were sometimes confused when prompted to rearrange apps since both actions were now combined. To solve this, we refined the timing and visual/vibration feedback to clarify both actions.

NEXT STEPS

Quick Actions launched a few months after the original hack was completed. In the near future, I'd love to further explore making actions contextually relevant to the user's location and app usage history. 


We found that only about 70% of new users actually reached the homescreen during onboarding. The current flow consists of 7+ screens and feels really long, so we brainstormed ways to shorten the process and make it feel more connected to the product itself. Additionally, we took this as an opportunity to explore app recommendations in onboarding.

 

HYPOTHESES

  1. In-context set up makes people feel more invested in the product
  2. Introducing app recommendations during onboarding feels more natural and less ad-like

 

PROCESS

To begin redesigning the onboarding flow, I conducted an audit of the existing screens to identity the essential elements.

ONBOARDING

 

Next, I created wireframes around two flow ideas:

  1. Choose everything— use empty states to show incompleteness and allow user to set up their apps from scratch 
  2. Defaults— show default-selected apps but allow user to add or remove them by dragging them in
 

We landed on a combination of both flows: selecting favorite apps by default instead of empty states, and allowing users to multi-select apps from a grid. In order to test the flow, I set up a user study using an early build and an Invision prototype

Our findings showed that participants understood the flow and felt it was intuitive, but the process of setting up collections was long-winded because they had to add them one by one. 

 

My next iteration allowed people to select multiple collections at a time. We also removed the step of choosing apps to place in each collection.

Another important aspect we wanted to test was introducing app recommendations. On the final flow, we introduced a screen with recommendations specifically tied to the collections selected before.

 

NEXT STEPS

This new onboarding flow is currently in bucket and we're hoping to get data in the next few weeks and make updates accordingly. Additional changes I'd like to make include wallpaper selection and further explorations on timing the "Set Default" screen.