As a Strategist and UX Architect coming from a more design-centric background, I always placed so much weight on usability—no matter what I was building—that I never imagined Enterprise apps would be any harder to use than general consumer apps. I just assumed developers would strive to deliver a product that was as simple and intuitive as possible. I could never fathom a company building an application nobody could use. It was only when I started working for X—— that I realized just how wrong I was, and saw just how different the two worlds could be. After enduring several days of training, I came to the conclusion this company’s flagship billings application was unusable, at least by me. I panicked to think how I would even begin to go about improving it. And yet somehow the company had survived, even thrived, to the point they are now enabling commerce in 150 countries in 36 languages and 28 currencies.
But the problems remained:
- The company’s founders (software developers) designed and built the software.
The software was built in ’98 and had only been updated piecemeal without much rhyme or reason.
Not only was the application a literal hodgepodge of button and font styles, it contained a myriad of menus upon menus along with popup windows triggering popup windows such that no clear user-path was ever defined anywhere. To complicate matters further, the language was incomprehensible: terms meant to refer to the same thing varied from screen to screen. And worst of all, the developers had decided the best solution to achieving an application that could handle any eventuality was to insert long XML files directly into the application, literally requiring users to edit all the (slow-loading) files themselves, essentially coding their own application.
In short, it was a disaster. I wondered how anyone had ever managed to use it, let alone run their entire billings operation from it.
Let’s step back a bit. The overriding problem with having developers build your software is there’s a vast difference between solving a problem technically and designing a solution to that problem that is immediately usable. Getting an application to work technically presents one set of problems and building something that is as usable as possible presents another. The former implies building something that simply works while the latter involves so much more—primarily, the expectations and demands of our own psychology, and catering specifically to those expectations by maintaining a consistency with the digital language users already speak. As it turns out, it’s nearly impossible for anyone (developers and designers alike) to straddle both worlds simultaneously.
Even in the rare case of the ambidextrous unicorn who can pull off both architecture and development equally well, we’re still not talking about a best-case scenario. Because a) it’s always best to have several sets of eyes on a problem and b) there’s an inherent conflict of interest at play, because the easiest technical solution is usually not the most usable solution. So one way of thinking can often conflict with the other.
A decade or so ago, the marketplace mood was different. Engineers could build complicated software and no one seemed to mind. Perhaps this was because a) salesmen would present slick demos that showcased their software in the most flattering light and then leave you with an impressive list of features without demonstrating their actual implementation, and b) due to a more prevalent lack of technical know-how, folks back then tended to give kludgy software a pass. It was in a sense cool for software to be confusing. It seemed somehow appropriate that way. Obfuscation was mistaken for sophistication.
The novelty has since worn off.
These days, a company website provides potential customers a demo login so users can test drive the application themselves. There’s nowhere for the UI to hide. Additionally, there’s so much out there that we can now immediately compare any demo experience to any competitor products. So gone are the days when anybody think it innovative to let users do the heavy-lifting of editing long XML files as part of the UI.
This is where Propelics comes in. We understand that even the most utilitarian Enterprise application must not only be gorgeous to look at, it must be responsive and predictive, anticipating our every move and offering the user guidance every step of the way. In other words, it needs to be engaging, intuitive, and fun.
5 Considerations for Enterprise Mobile App User Experience
Thursday, March 20th at 1pm EDT / 10am PDT
Content Strategy Lead at Anexinet