Zello iOS Navigation

Posted in
    Visual & User Interface Design

    Zello iOS Navigation

    Exploring & testing new interaction models in existing contexts

    Despite starting as Zello's first designer, there were plenty of existing decisions to assess and build upon. Some of those decisions—in this case, the iOS app's drawer navigation—proved both limiting to new work and technologically foundational to the project as a whole, creating a need for ongoing revision towards a solution.

    • Outcome

      Design done, and implementation underway.

    • Company

      Zello

    • Period
      2016-
    • Skills

      Product Design, User Research

    • Tools
      • icons/sketch Created with Sketch. Sketch
      • icons/origami Created with Sketch. Origami
      • googleFormIcon Open Broadcasting Software
    An overview of Zello iOS's then-hierarchy.

    Problem

    Preparing for my interview with Zello, I tested both their iOS and Android apps. I was asked for my own thoughts regarding the apps, and I offered these among other points:

    1. The drawer navigation on iOS may heavily, negatively impact content discovery.
    2. The burying of previously received messages likely negatively impacts salience, retention, and engagement.
    3. Switching between synchronous processes like talking and asynchronous processes “discovering” — finding friends, finding relevant radio channels, etc — likely prevents engagement in one or the other, so that post-funnel users who retained by engaging conversation do so to the exclusion of finding new friends, having a low k-factor.

    Then, within my first year, we added a text-messaging feature, accessible only from the visibly buried History screen, compounding these problems.

    Our hidden and twisting navigation negatively impacts user engagement, retention, and content discovery.

    Process

    I reviewed work with John — each applying a spot treatment on an individual screen — building on AFN’s brand colors while cutting costly bitmaps from the app. We briefly explored alternative and optimized navigational paths, but ultimately decided to only readdress those if later proven necessary.

    Round 1

    These screen layouts were standard enough to describe color and type choices that would generalize throughout the app.

    Round 2

    I comped out the distinct screens and pursued a visual treatment from Round 1. Following this review, I isolated and sliced assets for the iOS and Android engineers to start building out the screens.

    Round 3

      • System Blue
      • UIColor.systemBlue
      • Brand Blue
        Medium
      • rgb(62, 150, 199)
      • Brand Blue
        Dark
      • rgb(56, 124, 174)
      • Brand Green
        Medium
      • rgb(064, 199, 56)
      • Brand Green
        Dark
      • rgb(38, 173, 30)
      • Slate
        Light
      • rgb(153, 184, 204)
      • Slate
        Dark
      • rgb(64, 102, 128)
      • System Red
      • UIColor.systemRed
      • System Blue
      • UIColor.systemBlue
      • Brand Blue
        Medium
      • rgb(62, 150, 199)
      • Brand Blue
        Dark
      • rgb(56, 124, 174)
      • Brand Green
        Medium
      • rgb(064, 199, 56)
      • Brand Green
        Dark
      • rgb(38, 173, 30)
      • Slate
        Light
      • rgb(153, 184, 204)
      • Slate
        Dark
      • rgb(64, 102, 128)
      • System Red
      • UIColor.systemRed
      • System Blue
      • UIColor.systemBlue

    John had received feedback from his AFN colleagues, and we took a single additional round to reintroduce a variant on AFN’s green, after which I handed off newly-exported assets, visual specs, and palette.

    Icon/Volunteer Icon/Donate Icon/Connect Icon/Learn
    Icon/mediaLink Icon/vid Icon/doc Icon/chat

    Problems

    The project’s timeline did not allow for revisions to data structure. The app was technically limited to wrapping Austin Free Net’s content library, and likewise, we were unable to structure it to respond to specific user problems.

    Future

    We planned to analyze the number and frequency of hits that given articles received, so as to better surface relevant material. We also found following early interviews that donor and client parties were largely mutually exclusive, and so I planned to restructure the app around a singular user journey, where clients are profiled through a series of interviews, personally relevant content is surfaced, and users can further search the library through direct string searches and natural language, describing the problem they’re looking to address.