Mobile App Best Practice: Design and Build Multiple On Ramps and Off Ramps

Why aren’t more people using your app? It’s well designed, works as expected and is a critical part of your marketing and customer service strategy. The problem could be a lack of attention to how your users get back to your app after they have made the time investment to download, install and take a tour of what your app offers. To solve this problem, you need to think really hard about how your users will leave the app (and what they will bring with them) and then how they will get back in (and what they bring with them) – in other words the app’s “On Ramps” and “Off Ramps.”

Avoid the Walled Garden Design Trap and Weave Your App’s Flow Into Your User’s Current Habits and Preferences

Many mobile apps fall into the “walled garden” trap where the user flow starts only at the app’s main view (logon, home page etc.) and then forces the user to keep his data and content within the confines of the app. If users absolutely love what they see while exploring the app for the first time, they will come back to get more from your app and help you achieve the usage numbers for which you hoped. This works for large platform apps that have thousands/ millions of users and lots of new interesting content published everyday, but experience has shown that this same level of engagement does not happen for the vast majority of apps. There is just simply too much inertia and competition for users’ attention.

Fortunately, you can still design a useful app that can achieve your business objectives by leveraging what users already know and the platforms and tools they are accustomed to using. The key is to interweave your app into your users’ own content, relationships and processes that are stored and executed elsewhere. As app designers we find that the “on ramp” and “off ramp”concept is a clarifying principal to make this happen.

Mobile App On Ramps and Off Ramps

On ramps are essentially communication pathways that help a user open the app in context to what they are doing. Examples include websites, email, beacons and social networking sites.

Off ramps are ways (also communication pathways) to share content or move content from within the app to a more appropriate platform for the next round of work. Off ramp examples include email, web portals and pdf reports.

As you can see there are lots of technical options to make these ramps, which can be costly to design, build and maintain. So, the challenge is to carefully select which ones to use and then plan where these ramps will occur in the app’s flow. The key goals for each pathway is that they work, are easy to figure out and help you achieve the app’s engagement goals.

On Ramp Use Cases and Best Practices

Getting users into the app through your on ramp in context is key. Many users are already overloaded with app messages and especially dislike push notifications, uninvited “marketing” communications and other interruptions to their routine. On ramps that work will thus have to make up for this annoyance by delivering a valuable, easy to act upon message that is relevant based on a trigger. Of course, the content for the message is unique the app, but using the right combination of technical capabilities will make the message work better.

For example, we have found that texts get a better response compared to push notifications since they are more likely to be noticed and read. To make it relevant, you need a user-specific trigger (reminder, new info, time of day etc.), good content (obviously) and a deep link in the message that will open the app up to the exact right view. Done correctly, you have a user’s attention for critical moment to collect information, share an offer or establish a connection.

A newer kind of on ramp is a small network of cheap and easy to install beacons that simply broadcast a device ID. As long as your app is active in the background, it can come to the foreground or generate some other kind of notification that takes advantage of knowing the user’s location. Instead of a deep link like the earlier example, you can open the app directly to the appropriate view based on a push notification from your server.

Off Ramp Use Cases and Best Practices

Off ramps are often overlooked because of the design focus on getting users into the app and starting to engage with the content. However, off ramps are critical to help users stay engaged with your app during their normal routines and sharing your app with others who might also be interested in its value.

Examples of off ramp use cases are emails with content that can be shared with friends or colleagues. Pictures, scores, summaries and other useful bits of information should be sharable with non-app users.

Facebook Open Graph is also a good way to get information out of your app so others can discover it. The key design point here is to make sure that the links in the Facebook post lead to relevant content and a way to learn more about your app.

For more data intensive apps, data exporting and reports are ways to make the investment in using the app pay off for your user. A user works to enter data (whether by hand or through the phone’s sensors) and having that data available to other programs (excel etc.) where the data can be manipulated more efficiently is viewed as a positive.

In general, off the ramp’s destination needs to be easy to find so that the user can come back to them when needed. Storing links to the data on a web portal, sending those links in an email or putting the output in a central location like Dropbox are good ways to make sure that app’s output is accessible.

Finally, a good practice for deployment will also include measurement of which ramps are used and whether they work as expected all the time. A behavior tracking service like Localytics plus a script that tests the landing points regularly to make sure all is up and running will give you this insight.


Using “On Ramps” and “Off Ramps” to weave the app’s flow into your user’s already established habits and communication expectations will reduce the barriers to adoption and increase the likelihood the user will incorporate your app into her routine.

Making this happen is a matter of thinking about your user’s app interactions and what is happening just before and just after that interaction. Doing this as early in the design process will help you make better decisions about how to combine functionality, content and triggers in a way that is meaningful to users.

If you pull this off then you will not only have a useful app but an app whose users are voluntarily raising its profile.

Creative Uses for Bluetooth on Mobile Devices

BTLE - Beacon AND Receiver

BTLE – Beacon AND Receiver

We’ve built a few iOS apps that use Bluetooth Low Energy to sense and also act as beacons that kick off other app services once a beacon is recognized. It’s a decent approach to sensing proximity that uses cheap hardware and iOS backgorund services.

Below is an example of how to setup an iOS device as a Bluetooth LE beacon (a peripheral), and have another iOS device (a central) scan for the beacon, and log a message whenever it comes within range. Since we’re using Bluetooth LE, you’ll need to use an iPhone 4S or newer, iPad third-generation or newer, or an iPad mini.

All code is written for iOS 6 or later, and relies on the CoreBluetooth framework.


Bluetooth Low Energy peripherals (like a Bluetooth beacon), all advertise which services they provide using UUIDs. You can create a new UUID for the beacon by running `uuidgen` in Terminal.

To start advertising the device as a peripheral using the generated UUID:

self.peripheralManager = [[CBPeripheralManager alloc] initWithDelegate:self queue:nil];


NSDictionary *advertising = @{ CBAdvertisementDataServiceUUIDsKey: @[ UUID ] };

[self.peripheralManager startAdvertising:advertising];

To stop advertising the device as a peripheral:

[self.peripheralManager stopAdvertising];


We want our app to act as a central (client) to our peripheral, even when it’s in the background. To have the app run in the background, we need to add “App communicates using CoreBluetooth” to the “Required background modes” array in our Info.plist file.

To start scanning for peripherals:

self.centralManager = [[CBCentralManager alloc] initWithDelegate:self queue:nil];
NSDictionary *options = @{ CBCentralManagerScanOptionAllowDuplicatesKey: @NO };
[self.centralManager scanForPeripheralsWithServices:@[ UUID ] options:options];

You will want to use the same UUID string as the peripheral you’re scanning for. `CBCentralManagerScanOptionAllowDuplicatesKey` is set to `@NO`, since we want to be notified every time the peripheral is discovered. When it’s set to `@YES`, we are only notified once per discovery of each peripheral.

In order to be notified when a peripheral (our beacon) is discovered, we need to implement this `CBCentralManagerDelegate` method:

- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary *)advertisementData RSSI:(NSNumber *)RSSI {
NSLog(@"Found peripheral");

We also need to implement the `centralManagerDidUpdateState:` delegate method to handle state changes. The `CBCentralManager` should only be used when its state is `CBCentralManagerStatePoweredOn`. The code will be fairly app-specific, so I won’t show it here.


This is a very basic example, where the beacon is only advertising its presence. It would be relatively easy to have the beacon also publish more information, such as a location ID, a URL, etc.

Where to Add Mobile to Your Portfolio?

Made this presentation to the North Shore Technology IT SIG a couple of weeks ago. Lots of good discussion with the group!

Please take a look and let me know your thoughts.

Video Overview: Four Drivers for Mobile Value

Here is a short (under 5 minutes) presentation from our workshop series on Mobile App Concept and Strategy development.

Please take a look and let us know your thoughts.


Developing for Mobile Devices

I had the pleasure of presenting at the North Shore Technology Council last week on Programming for Mobile Devices. I basically shared some of my thoughts on the mobile landscape, the tools we use to make our apps, and an example project. The audience was great and asked tons of good questions.

Click here for the slides.

You can read more about the North Shore Technology Council here.

MyHomeEnergyTips Pilot — Round 1 Results

We wrapped up a pilot test of MyEnergyTips a few weeks ago with a group of Massachusetts and California testers. The feedback was very positive on the approach and the interest was high in using the tool to make better choices.

There are a number of items we can do better on the usability front to make it easier for people to get started using MyEnergyTips. We are working on these areas now and should have a new release in about a month. For those interested, I am including the list of improvements we will deploy:

a. Simplifying the presentation of the amount saved (e.g., focusing on “life time to date” savings, fewer charts, more text based feedback).

b. Emphasizing sharing and posting results through Twitter and Facebook.

c. Simplifying the home audit process (removing any extra data input requirements, summary lightbulb count, etc.).

d. Clearer recommendations with positive feedback (message, sounds etc.) when you take a recommendation.

e. Adding comparables to put your efforts in perspective (e.g., you avoided producing 30 lbs. of CO2 which the equivalent to one tree’s use of CO2).

f. More information about the recommendations, importance of setting goals, what others are doing through links and popup views.

g. Progress bar during the set-up to show how far you have progressed and what is left to do.

h. More targeted alerts and reminders (now they are time based) that pop when there are lots of good recommendations.

These are all great ideas provided by the participants. The themes are all around making the app easier to fit into a busy routine. There are tradeoffs to made between information accuracy and usability and almost all the participants expressed more interest in the later and were willing to make tradeoffs in accuracy to reduce the amount of set-up work.

When we are finished with the redesign, I will post some screen shots and views to hopefully get more feedback on the new approach.