Why Offline First is as much about User Experience as Robustness

More often than not the ability to work offline is the reason using a solution like the one we have built at MobileCaddy is considered for Enterprise Mobile Apps.

This is really because no matter how good your app is as we can see from this previous post — if the app stops, so does the business that it supports. And of course this is not acceptable.

This alone should be enough to convince us all that our enterprise apps should always follow the MORE(s) Design specification with Offline First being a fundamental requirement.

However for many Salesforce.com customers that do not have experience of deploying and managing these apps there is another often ignored upside to Offline First. A reason that will have just as much impact on delivering the organisation aspirations.

Business Value & User Experience

If we can start with the knowledge that our app is going to be robust then we can move on to considering the two most important drivers for the digital organisation to mobilise their business processes.

Business Value

Defining the business value to be created and delivered via a mobile strategy, and therefore the supporting mobile apps, will initially be focused on all the upsides (and rightly so).

Things like worker efficiency, access to data & processes on the move, data integrity and new capabilities that become possible such as photos, signatures etc.

Linking these to agreed business outcomes that will be supported or enhanced by this new or improved mobile app is key. It means as we design, deliver and monitor the app we can measure against these.

What is also very important at this stage is to start to not just think about these as processes but how the user of the device will actually interact and use the app to actually deliver this business value.

User Experience

On the assumption that the Business Values have been defined we now get to the device, the app and the end user. This is where the rubber meets the road, where process meets design and design meets the user.

This is a very new area for most organisations and is where the most well intentioned, totally robust app can fail. There are many items to consider but to give you a flavour of some obvious and not so obvious:

1. Design Time— Well duh! But to state the obvious, time and resources must be allowed to give the app the best chance of success. The number of times the go-ahead is given with the expectancy that the build stage will come after a quick workshop is not going to cut it.
2. Speed — We need to consider how fast a process is from the End Users perspective.
3. Micro moments — our mobile users are not like us sitting at a screen all day — they need to be able to pull out the mobile/tablet and start (or finish) whatever is needed at that time.
4. Simplicity (most likely hiding complexity) — Making an interface simple is not the easiest thing to do. And it is even harder if the ‘designer’ does not actually use these types of devices for critical business tasks.
5. Flow — if we think about how the users ‘flows’ through the processes we are going to mobilise we can start to think about splitting these up into smaller / more accessible / more friendly pieces.
6. Interrupted Flow — it is highly likely our users will be using the app during their actual work. This means stop/start and moving from one thing to another is very common.
7. State — Due to to the Interrupted Flow we need to think carefully about retaining state. What we mean here is that if interrupted it is easy and intuitive for the user to pick up from where they left off (even if the app has been ‘back grounded’).
8. Data Risk — Our design must carefully consider when we are saving data (to the device storage). Because of interruption and battery loss or OS shut down of back grounded apps WE must protect the data through the design.
9. Feedback/Analytics — Many assumptions will be made especially within the first version of our app. To quickly gain an understanding via analytics plus genuine contextualised feedback from our mobile users will make sure we in a strong position to right any wrongs.

The speed of an app underpins a great user experience

For the purpose of this post I want to focus in on speed and why an Offline First architecture brings up more than robustness of the app.

With an Offline First approach we are not constantly querying or writing to the cloud ie the Salesforce.com platform. We query or read a local data store (which is encrypted by default). This significantly speeds up things like screen transitions, presentation of data and processing of logic. This is all completed on the device.

The result is not only does the transaction always work (ie it will not fail if we do not have a connection or strong enough connection) but also that from the users perspective it is quick. In most cases by a factor of 5 or more.

It means when we open the app we are ready to work. When we tap back and forth I see the result almost instantly. It means the app gets out of my way as quickly as possible.

For us (and I am generalising here) where we work on laptops and desktops for most of our day we do not see this as a must have — if a browser window or app is slow to open we just switch windows or apps and get on with something else (albeit still a little frustrated).

However for most mobile workers the app is something they dip in and out of from the physical world and therefore a slow running app quickly becomes a barrier to adoption. If the mobile worker is interacting with our customer, worse still, it becomes embarrassing resulting in lost customers or lost opportunities.

Define an App to deliver Business Value. Design an App for great User Experience

We’re working hard at MobileCaddy to make great design much more accessible. Embedding great UX in the whole app design, build and feedback loop.

If you would like to know more about how we can help you create not only a fully robust app but an app that really delivers in terms of value please email me directly at ceo@mobilecaddy.net.