Editor’s note: This article won the ERP Focus 2013 ERP Writers Award for best ERP article of the year.
I take the opportunity to review enterprise mobile apps formally and informally on a regular basis. These reviews bring unintended lessons on the many ways to screw up an enterprise mobile app.
Unfortunately for those hard at work developing these apps, those mistakes can damage the market prospects of an app from the get-go. (Those who missed my prior piece on Judging enterprise mobile apps may want to skim that first as I will build on it rather than repeat it). Just like in the last piece, I hope a couple of these will surprise you and provide debate fodder.
Enterprise mobile apps mistakes
1. Going it alone rather than co-innovating. I fail to understand why a mobile apps developer would undertake a design process without a customer viewpoint in the midst of it. Rather than claim to be ‘customer driven,’ build something a customer actually wants. I recently spoke with an aspiring developer who understood some business processes well, but couldn’t authoratively speak to a customer pain point the proposed solution would solve. The next step in his case? Survey a core group of customers about the proposed functionality and fine tune the requirements from there, hopefully leading to a co-innovation relationship. Result: much higher degree of confidence not only developing the solution, but pitching it.
2. Developing for too many operating systems. With Blackberry falling off a precipice, development choices are a bit easier, but I’m still struck by how many mobile apps developers are concerned with cross-platform compatibility (iOs/Android/Windows) rather than nailing the user experience 100 percent on one platform. This goes back to knowing your initial customers and which devices are dominant in their shops. Sure, if you can get away with an HTML5 wrapper or hybrid approach, great, but be careful.
Once that ‘total user experience’ discipline is ingrained, adding new devices or offering a browser-based version is fair game – hopefully funded by early customers on your initial build. When you see 10 or 20 mobile apps stacked up against each other, you can almost always recognize which apps are hybrid and which ones are built just for that device.
Argue the point if you like, but take into account this notable detail from a piece on native, mobile, and hybrid apps. On the Banana Republic hybrid mobile app:
However, the Back button in the Android app ignores the fact that, unlike iPhones, Android devices come with a physical or virtual Back button. The tab bar at the bottom of the page works well in the iOS design, but is clunky and clearly non-native on Android.
Banana Republic can afford this kind of quirk, but when you’re trying to put a dent in the enterprise mobile universe, that kind of generica takes away from the personalized elegance you’re shooting for. During a recent debate on this topic, someone went for the checkmate on me by saying. ‘Well, the LinkedIn app is a hybrid app.’ My response? ‘I rest my case.’
3. Designing for too many form factors. Designing-for-device is not just about operating systems. Some apps are much better on tablets (such as those involving visualizations, or review of detailed contracts). Whereas alerts-based mobile apps (like workflow approvals) don’t really require the tablet to excel. Wasting early development rounds building for phone and tablet when one form factor is clearly superior for the app is a mistake.
4. Depth of knowledge shouldn’t require app complexity. Some folks have been kicking around an industry for a decade or two. From a mobile design perspective, that’s mostly a good thing: better industry know how = better app. But some apps get bogged down in that functionality. Simplicity remains the goal of the mobile experience. Bite size apps that capture one workflow are often best. When I hear someone say ‘end to end process’ when presenting their mobile apps, I cringe.
I want the designers to have end to end process knowledge, but I also hope they can chop that into bite size chunks – perhaps by building one app at a time until they have enough for a small suite of apps that can be purchased separately but managed in the same dashboard.
5. Don’t solve an industry, solve an industry problem. The best enterprise mobile developers are evangelists: they are bursting with ideas on how to re-imagine their industry with mobile/connected workers and new levels of customer interactivity. That’s a good thing, but these problems are best solved one at time. Take retail for example – there are a plethora of retail mobile use cases. A great retail mobile app would take on one of them. Managing item stock on a store-by-store basis, for example, or collaborative product configuration, or sales contract negotiation, or real-time coupon offers and redemptions. Each problem is hairy enough to have its own app.
5, If it doesn’t integrate with the system of record, it’s not an enterprise mobile app. That might be laying it on a little thick, but apps with better back end integration are likely to whip their competition. Whether you are talking purchase order approval or customer service exception handling, tying that workflow into the back end system is how mobile can extend the enterprise rather than adding to the chaos of disparate data stores.
This could be another case of focus ruling that day: start on integration with one or two leaders in a given market, be it Salesforce.com, Oracle, SAP, or even JD Edwards if that’s where your initial target customers are. I almost called this ‘back end integration’, but in some cases we are talking about customer-facing systems. For ‘systems of record.’ I’m including data warehouses – I’ve been also nifty integration scenarios with analytics software for the purposes of data visualization in front of customers and prospects.
6, Don’t just build a business case, build a business presentation. I’ve heard developers present their mobile solutions mumbling out of the corners of their mouths. Sometimes these business cases are very well thought, but when you can’t grasp what the presenter is saying you start to count it against them. One neat thing about modern hackathons is that many of them now require developers to get up in front of the audience (or jury) and sell them on their pitch or product.
That’s tough sledding and there are some moments best left on the cutting room floor, but it’s terrific practice for almost everyone on the team to give a shot at summarizing the business benefits and customer input that led to the app.
In the long run, there will be dedicated spokespeople to do the heavy lifting with new audiences, but everyone involved in developing mobile apps should learn to present them in a way that grabs attention – especially in sessions where there are thorny questions and ‘live without a net’ feedback.
Plenty of mistakes are still to be made, but in all honesty I am seeing less horrible enterprise mobile apps than I did a year ago. While I only see a minority I would call ‘brilliant,’ I’m seeing a much bigger amount of apps that are not just blandly functional.
The idea of rethinking and simplifying processes is catching on. All this talk about consumerization and low tolerance for bad UX seems to be having an impact also. Most importantly, I’m seeing the ‘industry light bulb’ go off with those who are experts in an industry and ready to implant that into a cool/useful app.
I like this industry app design trend a lot. It’s counter-intuitive for those who want to hit a mass market home run out of the gate, but building those horizontal mobile apps carries the risk of redundancy, not to mention a far greater chance the elephant in your vendor ecosystem will one-up you with a similar app. That’s a burn you don’t want to feel. Whereas if you carve out that narrow expertise and own it, folks eventually come knocking, with all kinds of offers. Or even better, they ping you – from within your app.