Thanks to the rise of lean thinking and increased capabilities brought by User Experience Design practitioners, the user experience of mobile software, particularly for consumers, has made great strides in the last few years. So why do companies sit on the experience sidelines when building mobile apps for their own employees?
You would imagine that apps being developed for the C-suite would be polished; at least, but industry insiders know that most of the associate-facing mobile apps inside of enterprises have poor usability characteristics – screen layouts that are so confusing as to require extensive training and interfaces that are slow to respond to clicks.
People seem to think that the “added expense” of great usability is only justified for consumer-facing apps. We often hear something along the lines of: “But for internal apps, why not just use a rapid app development framework like Kony or Sencha Touch?”
Here’s why that’s not a good idea.
- Usability means productivity. One of the reasons that you’re building an app in the first place is probably to enable productivity of some sort. If your employees are fumbling with the app, then it’s not likely to bring the rewards you were looking for.
- Extensibility is key. Once you hit the wall with most rapid HTML5 app development frameworks, large amounts of effort will be required to finish your project, and you’re likely to have to throw it out and start over for the second version.
- Collaborative interactions: A key trend in retail and service industries is a higher degree of transparency and a greater prevalence of “shoulder to shoulder” interactions between staff and customers. For example, a visit to Apple’s Genius Bar sees customers sitting beside Apple staff, working together to solve an issue with a device or to educate the customer on new and better ways of performing tasks with their technology. Powerful apps are a key enabler of these types of interactions, and their use is in full view of the customer, creating another important and influential brand touchpoint.
- Put your best foot forward. Retailers are starting to see the benefits of queue-busting mobile apps. For example, many restaurants increasingly rely on mobile devices as order pads. It’s obvious that this “employee equipment” could become a customer touchpoint. In one scenario, the device is on the table for consumers to operate in absence of the employee. If your customer-facing employees are embarrassed to show the app to consumers, there’s a whole raft of possibilities that disappear.
- Security and hotfixes. If you use the mainstream toolchain to build native apps for your devices, you’re likely to have an easier experience when your corporate users need to upgrade to the latest version of the operating system (OS) for security fixes. BYOD is hard enough without locking your workforce to an outdated version of the OS because your corporate apps aren’t compatible with the latest version.
In fact, designing for user experience in employee-facing applications requires a different approach than you might take for a consumer-facing mobile app. On a consumer app, you might prioritize the first-use experience slightly over the long-term use in order to get more people using your app.
In an employee-facing environment, first-use processes like registering for an account may not be issues at all given that you’re likely connecting the app back to your federated login service. It may make use of the same UX skills, but it doesn’t necessarily need the same approach.
Ask yourself: “Am I optimizing for the expert experience, or am I optimizing for casual users?”
One of the reasons that managers and enterprise architects push back on user experience or the use of native application development tools for internal apps is a perception around cost. They’ve witnessed the effort and expense going in to build a high-touch mobile app for consumers, and they’re worried that this will drive up the costs of their initiative. When thinking about total cost of ownership, ask yourself these questions:
- “Do you have control over the associate’s device?” You can mitigate the expense when doing native apps for consumers if you only target one platform. If you have standardized your workforce on iOS, for instance, it might make lots of sense for your internal mobile app dev teams to build native iOS apps and not bother with a “lowest common denominator” hybrid approach.
- “Is the device part of the task?” If all cashiers, for instance, are issued a specific device, it only makes sense to build an app that’s custom designed to take advantage of that device. JD Sports and Thoughtworks took a lean startup approach when integrating specific payment hardware with Apple iPod touch devices as part of a program to delight customers with a thoroughly modern in-store experience.
Even if you don’t have a uniform standard across your workforce, you can easily decide to support far fewer form factors with your associate-facing app while you might need to cast a wider net with your consumer-facing app. While many hybrid app toolkits seek to translate the same UI to several different target environments, this often creates subtle but deadly user experience issues that kill your project, creating huge cost overruns and schedule problems.
So, Does User Experience Matter?
Yes! Experience does matter, even for employee-facing apps. Technology is changing rapidly. While there are more and more frameworks on the market every day promising to accelerate your developers’ mobile productivity, it’s worth putting some thought into taking a structured approach in how you go about building apps for your digital enterprise.
I think you’ll find that usability matters just as much, though it might matter differently or require a different approach than the one you might take with a consumer mobile effort.
A version of this article first appeared on SandHill.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.