When designing complex user flows it is important to constantly iterate and elicit feedback from stakeholders and actual users. For this example my team and I were challenged with improving an interaction that wasn’t as intuitive as it could be.
Users are either unable or having a difficult time changing and adding locations to their weather app. In addition setting push notifications (alerts) for that location is confusing and leading to the wrong outcome.
On the surface the current design has all the required features and some users are even able to accomplish the desired interactions easily. However most comments and feedback from a majority of users indicated that having 2 actions (set location and set alerts) coupled with a cell that might be confused as having 3 actions resulted in a lot of experimentation for users along with non desirable outcomes.
Secondly after a new city is selected from the search bar, that city is not automatically selected. Unfortunately due to the SDK being used we were limited to the amount of flexibility on both design and usability.
Involving developers early on proved essential. We came up with a user flow that look into account the technology and SDK this would be implemented on. The flow served as a the framework to make sure the imporoved user experience would be technically possible.
After removing the previous SDK and going with another solution we had full flexibility to design an experience that simply works.
As with most complex projects my team and I usually start sketching layouts and flows on paper or whiteboard. This allows for quick ideation without any emotional commitment to a design that might have taken a long time to work on. This is a great way to get feedback early and make changes before getting into screen design.
A new user flow was designed that drastically simplified the process of adding a location. Alert settings on and off switch as well as the ability to choose which alerts was still incorporated into the single action. A caption that indicated if an alert was selected for that city was added. Lastly arrows were added to the city name on the main landing page to indicate that there are multiple locations set in the app.
After an intial round of testing with users and feedback from stakeholders it became apparent that incorporating alerts within the direct flow was still not very clear. In this iteration the ability to customize alerts was removed completely from the location flow and instead the user is given an option to turn alerts on and off using a standard iOS action sheet. A bottom drawer was added that allowed for alert customization for all locations instead of specific cities. This eliminated any confusion and added only a single point of interaction when a city is tapped on.
Taking cues from the new and simplified iOS design, the team wanted to keep a similar flow while maintaining android material design UI and iteractions native to the platform. The key difference aside from the interface design is that users are not taken to an overlay with options to set location, turn on or off notifications or remove the city. Instead a simple tap will open up those options like an accordion.
Secondly the FAB (Floating Action Button), the bottom circular button on the bottom right of the screen technically goes against google’s guidelines as it is intended to be the primary action of the screen. It this design howerver the primary action is the search bar. Managing notification is secondary.
Finally the end result removed the headers between certain cities and grouped them all together into one list. No diveders between them. The Floating Action Button was also removed and instead replaced with a textual call to action that insterted a new screen through a traditional push animation.