Background
Supporting an enterprise mobile app brings in a whole new set of challenges.
Let me exemplify with a some of the key characteristics you'll meet:
Mobile devices
- Multiple operating system (iOS, Android, Window phone)
- Multiple different version of each operating system
- Large variation in form factors and screen size
Network
- Common with network issues caused by poor network coverage in areas or unstable wifi connections
Users and user experience
- Extreme variation in the mobile experience and maturity of your users
- Hard to resolve support incidents directly over the phone (no screensharing for example)
- User are using the app outside company offices and outside normal working hours
- Very high expectations on user experience (comparable to consumer grade)
- Varying precedence and experience with user interaction patterns for mobile
Front-end
- Increased degree of application logic being done in the front-end (offline usage is a common scenario)
- Javascript as an untyped and interpreted language
- Requires more experience to debug apps
Back-end
- Typically stateless due to scalability concerns
- User may not have latest version of the app, so back-end needs to support multiple front-end version
- In a multi-client SAP environment, customizing may vary from client to client
The sum of all the above underpins the complexity of supporting your app users. In many ways it's a whole different ball game to what we're used with traditional enterprise software solutions.
Understanding your users
In order to give good support, you need to understand how users react when they encounter an unexpected situation preventing them from completing a task. The best way of gaining this understanding and empathy for the user is to perform user testing on early prototypes, new features and existing functionality in production.
When doing user testing, you'll recruit representative users and observe as they are as asked to complete realistic task in your app. Make sure the recruited users cover varying degree of mobile experience, new hires vs seniors and with varying domain experience. These should not be people you ask just because you know them from before.
Performing user testing is a mature competence area within user experience area, and you can also use it for acquire quantifiable metrics. However, the basics can be quickly grasped and the benefits compared to cost in a mobile project can be staggering.
In order to spread this understanding, make sure everyone involved in implementing and maintaining your app join one or more user test as silent observers.
So how do users react when encounter an unexpected situation preventing them from completing a task?
Based on my experience and extremely non-scientific gut feeling, I would assign the following actions and likelihood:
(this assumes the actions in the app can also be completed through other less efficient methods such as a portal solution)
- Scan the screen for recognizable content or clues - likelihood ~100%
- Restart the app or phone - likelihood ~80%
- Try again tomorrow or later - likelihood ~70%
- Ask a colleague or friend - likelihood ~60%
- Complain to a colleague or friend - likelihood ~40%
- Lookup help documentation on intranet - likelihood ~25%
- Submit a support incident - likelihood ~10%
- Give up in the end unresolved- likelihood ~50%
The first takeaway here is that there is a "hidden iceberg" of situations where users of your app cannot complete the task they would like.
They're basically stuck, but the users are still unlikely to contact whatever support you have in place.
This is great news if you only care about support costs. Never has it been more simple to avoid helping your users. But how does this affect user adoption?
Unhappy users will spread their frustration within their personal network and make it less likely their co-workers will actively use the app both now and in the future.
And as your user adoption basically stands still or even reverses, you'll see the business case crumble as the app is in essence worthless without user adoption.
The main takeaway is that the success of your app depends on how well you support your user, so make the support functions as accessible as possible.
Providing app support
As an enterprise, you most likely have a mature support orgorganisation with a single point of contact and ITIL-based work processes and system support.
Use it and make sure to:
- Train support organisation in what to expect when supporting a mobile app
- Make them enthusiastic about the app
- Build up a common knowledge database with guides to common unexpected situations the users may face with the app that can be shared quickly
- Get your ITIL problem process up and running so the root cause for incidents can be found and resolved quickly
From the app you need to make it as easy as possible to reach this support organisation.
Support feature #1 – Calling your support desk from the app
From the help menu of your app you should provide highly visible option to call the support desk. When clicked this should automatically dial the correct number and put the user in contact with your support organisation from your mobile phone.
It's still hard to resolve such support calls directly over the phone as there is no screen sharing, however you sending a message that you are accessible and really are interested in aiding your users.
Support feature #2 – Send incidents directly from your app
The second feature I would recommend, is to allow the users to send a support incident directly from the app. This incident should be routed to your ITSM support system such as Solution Manager and be handled there.
What’s important here is to collect all the information you need to reproduce and then resolve the incident. Asking the user to provide this in written text is not an efficient way of doing this.It’s also error prone as it can sometimes be hard to remember the exact actions which was taken before an error occurred.
Therefore, we detect as much of this information automatically. Logged on user, operating system type and version, app version and screen resolution are all detected and included automatically in the incident.
In addition, we’ve implemented a standard logging practice and framework throughout the app. This log includes:
- How the user has navigated between various screens
- Exact timestamp which can be cross-referenced with any SAP logs
- Any uncaught javascript exception which may have occurred
(since javascript is an untyped and interpreted language there is no compile/activate phase and a single typo in an executed code branch is enough to throw an exception which the app may not handle) - Failed network request and other network related issues
The log itself is persisted in local storage, so even if the app crashes we’re able to retrieve details required to reproduce the incident.
Additional logging elements can be added through SAP transports if we have a reported error we’re unable to reproduce.
Proactive support
In addition to making your support organisation as accessible as possible, there are other actions you can do to help the user.
Onboarding help for apps is hotly discussed topic. Overlays which explain the interaction patterns are normally not recommended as explaining your interaction patterns do not make them more intuitive. However, a general introduction shown on the first use of the app which focuses on the benefits the user can achieve adds value.
Monitor dumps in ST22 and other error logs in SAP on a regular basis. Reach out to the users who have experienced the errors and let them know what you are doing to resolve the root causes. As most errors are never reported to the support organisation you need to be proactive in seeking out the hidden iceberg cases which are affecting your users on a daily basis.
Thanks for reading this blog and please add your own experiences on how to support mobile apps in the comment section below.
PS the screenshots in this blog are all sapui5-based with additional styling inspired by Google material design
- SAP Managed Tags:
1 Comment
