5 Important Mobile UX Areas People Usually Forget

5 Important Mobile UX Areas People Usually Forget

At Salty Dog we help clients to define their app. Many clients know how they want their app to solve a particular problem but haven’t figured out how the app will look from the perspective of their customers.  There are some key UX areas they often forget that can have a huge affect on the user experience.

Here are some of the most easily overlooked UX areas:

Login and Registration

Login and registration are usually the first part of an app your user will see. Some commonly forgotten sub-use cases are: forgotten password, registering email, forgotten password but haven’t verified their email, or re-sending email verification.

Forgetting passwords can happen more frequently on mobile devices. It can get really annoying for a user to try a bunch of passwords, then have to go back to the main website to request a new one.  This is amplified if the registration requires email verification, and they are denied a new password because they haven’t completed this process.

The solution to these issues is to remember some of the more subtler use-cases. Here are the  use-cases for a complete login and registration experience.

  • As a user, I would like to register/create a new password-protected account, in case I don’t have one yet.
  • As a user, I would like to authenticate with the app, so that my information is protected.
  • As a user, when I start the app I would like to know if I haven’t validated my email address if I haven’t, so I know to look in my inbox or spam folder.
  • As a user, I would like to be able to resend the email verification in case the old one is expired or lost.
  • As a user, I would like to be able to set a new password via my validated email address in case I’ve forgotten my old one.
  • As a user, I would like to be able to log out of the device, in case I want to restrict access or log in as a different user.
  • As a server administrator or app owner, I want a way to log a user out, in case there is a good reason I want them to re-authenticate.
  • Application Updates

    Sometimes it is necessary to make changes to the way the app works and require users to update. For example, there might be a change to the way the server works that breaks any previous versions of the apps that haven’t updated, or there is a really important security fix.

    The solution for this is to provide a way to make sure the user updates the application, and then gracefully degrade functionality if they do not update. A simple flow outline might work like this:

    1.On app start, connect to the server supplying the version of the application.
    a. If the version does not need to be updated, then respond with an OK.
    b. If the app DOES need to be updated, then respond with a “needs update”.
    2.If the app received an “needs update” response from the server, then:
    a. Inform the user they need to update.
    b. Let the know that functionality of the app will be impaired if they do not.
    c. Give them an easy way to facilitate the update such as a button that takes them to the App Store or Market app to update.

    Important Notices

    It is really important to be able to send notifications/notices to the user. The purpose can be anything from letting them know about planned server maintenance, other companion applications, updates/upgrades to the functionality,  or bug fixes.

    What makes this so critical is because of how difficult it can be to communicate with the user. You need to communicate with them so you can set their expectations about app functions and changes. In the absence of information, the user may jump to negative conclusions that can result in bad reviews, or worse, uninstalling your app.

    The fix is relatively easy and accessible: add a way to send notifications to the user. There are many third party services that can do this. Some even allow targeted notifications to segments of your users.

    Alternatively, you can implement your own solution. The messages can be displayed using webview controls, allowing you to point the user to blog posts or release notes. The app just needs to be smart enough to know if the user has seen the notification before so they don’t get spammed with notifications.

    Network Problems

    Issues related to the network or connectivity are ignored a lot of times, and are only discovered in testing or when a user has issues with it. These fall in three basic categories:

    1.Server issues. The server might have an issue. The cloud provider may decide to reboot your server. Even though the network is functioning correctly, the server may not respond.

    2.Network issues. Sometimes there are outages either at the ISP/provider level or somewhere in the backbone.

    3.Device connectivity. It could simply be an issue with network connectivity from the device. The user is out of cell range, or service quality is low.

    4.Planned outages. The server might need to be upgraded, or the system restarted.

    There are two basic ways of dealing with this. First, design the app with lack of connectivity in mind. For example, if the app cannot reach the server then handle it gracefully. When the network is not reachable, you can give an indication in the app so the user has an idea of what is happening. I’ve seen some apps show an indicator in the title-bar.

    Second, leverage the Important Notices suggestion above. If you’re using a 3rd party notification service, then you can inform users that you’re aware of the outage and when they can expect it to be available again.

    Interacting With Someone Who Doesn’t Have the App (Yet)

    When designing social apps such as chat, it is easy to forget about the case when one person has the app and they wish to interact with someone else who doesn’t. This is important because it can provide a viral way of gaining more users.

    We’ve blogged about this in detail here and here.  The basic problem is how to interact with someone who doesn’t have the app yet. Once you solve the interaction problem, how you can turn that into a seamless onboarding process for a new user.

    The answer is to use something called deep-linking in conjunction with SMS messages and a bit of magic from the iOS web-view control and Android App Store broadcast message. This allows you to send an invite link to someone over SMS, which sends them to a landing page that includes links to the appropriate web-store to install the app. After they’ve installed the app cookies can be used on iOS or broadcast messages from the Google Play Store App, to let the newly installed app know there was an invite from someone else.

    This allows an invite to go to someone without the app, them to install the app, and then pick the invite up from where they left off as if they had the app installed in the first place.


    When making your mobile project it is important to remember what happens after the initial release and use. As the overall quality of apps has improved, sensitivity to clunky apps has increased. Failing to include these user stories is very likely to result in a user deleting your app.  These user stories should become a part of your larger release strategy to help you plan for ongoing updates, user engagement, and to ensure that you have the infrastructure in place to support users when they have a problem with the app.

    App Map

    App Map

    Not to be too much of a downer here, but you aren’t psychic.

    Since you are not psychic, you will have to communicate your app idea to others using words and pictures. You are going to need an App Map.

    Your App Map is a way for you to visualize the different features and how they connect.  It shows others what you want your app to do and why.

    There are a lot of different ways to plan your app: App Map is ours.

    Step 1: Problems and Solutions

    Too many apps are a solution without a problem or have a solution that doesn’t match the problem.  Having a clear vision of the why and what of your app prevents this.

    Get some stickies and/or some 3 x 5 note cards and painters tape.  This allows you to have a way of re-arranging ideas quickly.

    Get a nice big patch of empty wall or window that you can use as your workspace.  It helps if you have a space that isn’t on the same wall as doors that open to the outside or are in rooms that lots of people travel through.  You don’t want things flying off the walls and getting rearranged unintentionally.

    To begin, write on a large piece of paper the problem your app is trying to solve and tape that high on the wall.  Next to that write how your app will solve it.   Write big enough that you will be able to read it both from a distance and in a picture later.

    For example, if you were making a traffic navigation app, your problem might be: There are no navigation apps that show how to get to places using only even numbered streets.   Your solution would be: app will display directions between locations using only even numbered streets.

    Do you see what we did there?

    There is a clear problem statement. 

    The solution solves the problem.  

    The solution is directly related to the problem.

    Next, you are going to write out the main things that the app will do in a row. Below each of those things a lot of additional things need to happen.  For our pretend map app, which we’ve decided to call Even Streets, it might look like this:

      • Identify even numbered streets on a map
      • Give directions list
      • Show map of directions
      • Audio cues for directions
      • Show traffic jams and accident

    Below each of those things a lot of additional things need to happen.

    Identify even numbered streets on a map

      • Have a map
      • Highlight even numbered streets in green
      • Show all other streets as grey lines

    Give directions list

      • Show every turn on route
      • Show every street on route
      • Show distances traveled on each street
      • Show the name of each street
      • Be able to slide between list and map picture

    Show map of directions

      • show map with route highlighted in blue
      • Have arrows pointing in which direction the person should go
      • Map can be made larger or smaller by pinching screen
      • Be able to slide between list and map picture

    Audio cues for directions

      • A bell tone will sound when a person gets within 100 feet of a turn
      • A voice will read directions when a person gets 90 feet from a turn
      • Voice will state what next turn or direction is after a turn has been made
      • Voice will report if there is an accident or traffic jam
      • An alarm tone will sound when the app picks up the signal of a traffic jam or accident report
      • Voice will announce re routing when it occurs

    Show traffic jams and accidents

      • Traffic jams and accidents will be shown in red

    Re route when a wrong turn is taken

      • Show a new route when a wrong turn is taken to get back to even numbered streets as quickly as possible.
      • Show new route on both map and directions list.



      • How much map should be shown on the screen as a default map size?
      • What is the maximum and minimum map size?
      • Is it a male or female voice?
      • What kind of tone?
      • Can you select the tone type?
      • Can you silence the tone and keep the voice?
      • Can you silence the voice and keep the tone?
      • Can you mute both the voice and the tone?
      • What constitutes a traffic jam?
      • How much slower than traffic usually goes does it need to be for a jam?
      • Where are you getting the traffic and accident data from?

    See how this can get complicated?  How will each item work?  And then what?  Ask, “And then what?” until you’ve got no more what.

    Step 2:  User Stories

    Next, we are going to make “user stories.”  User stories are a way to explain in a single sentence the relevance and need for each feature.  If a feature is not relevant or needed, cut it.   This is really hard when there are things that are super cool but serve no purpose.  Even if you waaaaaant it, how much money are you willing to pay for something that doesn’t really do anything?

    To come up with the stories you are going to play a game of Let’s Pretend.  You are going to pretend to be:

      • An app User
      • A Developer
      • An Administrator/Business Owner

    You are going to create user stories for each role, with at least one user story on each feature.  You are going to come up with statements that follow this formula:

    As a ________, I want  ____________, so that I can ____________.

    As a User, I want the app to alert me with a tone prior to a turn so that I can be prepared to make it by being in the correct lane.

    As a Developer, I want to know the parameters for a traffic jam so that I can set them.

    As an Administrator… wait a minute, what if there isn’t anything on the map that an administrator would want? Maybe you should think about that. What would you want/need to know as the app Administrator?  What functions would help you measure and improve performance?  What do you need to be able to bill/make money off of the app?

    Step 3: Narrowing it Down to MVP

    Now that you’ve played this game of Let’s Pretend and gotten your user stories up, your App Map should look pretty full.  You’ve probably had to move and expand it a couple of times.

    Take enough pictures to clearly show each of the parts of the app so that you could clearly read what is written on each post it/card.

    What you’ve got on your wall is a fantasy.  It’s what you would do if you had unlimited funds to spend on getting your app made.  You aren’t going to get the fantasy.  Or, as one of our clients once said, “I feel like you’re telling me I’m not going to marry a supermodel.” Guess what, you’re not.  But that’s ok.

    Every single post-it/note card on that wall represents money.  Money gets wasted when features (that’s the stuff on the post its/note cards) turn out to not be the ones the app needs to be successful.

    How can you possibly know which ones will be successful?  You don’t.  You’re going to want to test it out a little bit at a time.  You’re going to start your app with the smallest possible piece of it that you can make.  The most bare bones skeleton of an app.

    What is the one thing that if your app doesn’t have this, it can’t exist?

    What is the feature that best solves that problem?

    Once you’ve identified the core functions-your first release- of the app, pull those to the far right or left of your wall.  Put a piece of tape between it and the rest of the feature sets.  Take a picture.  It is your Minimum Viable Product (MVP).

    Let’s say that by some miracle the first release of your app was profitable.  You would use the money you made in your initial release to fund a second round of features and improvements.  The money you made in your second release then will fund the third, and so on.  What would your first release be?   Group those portions of your App Map and take pictures of them.

    Really Do It

    There is no App Fairy.  Your app will not magically come together just because you clap your hands and believe.  The more you’ve thought your app through before you go to a developer, the clearer you can communicate that process, the better your chances are of actually getting the product you both want and need.

    This seems very simple, but like most simple things, it is crushingly hard.  Don’t give up, do it anyway.