I recently updated my Mac Book to the latest and (allegedly) greatest OS, Mavericks. I have to say that my Mac Book is about two years old and I don’t believe I have ever upgraded the OS since day one. My philosophy is simple; it works so leave it alone. This philosophy is not shared by most OS providers and Apple seems to have decided that massive change is always good, even when it’s not.
With this new OS upgrade items that were old and familiar have now taken on a new and frustrating sensation. Something as simple as Safari no longer closes the Bookmarks tab when you launch a web page from it is at best frustrating but also very darn annoying. This is but one example of how time-in-motion has not been considered at all in the redesign of the OS or many of the programs running on the machine. A better example has to be the Apple program Grab.
For those of you not familiar with Grab, it allows you to quickly capture a window, screen or portion of a screen and then save the “grab” as an image for later use. I have used this app extensively for capturing screenshots of applications for training materials and presentations. The “new and improved” Grab automatically closes itself once you change focus to any other program. And no, it’s not going into the background, it’s closing, requiring you to reopen it each time a new screen shot is required. Annoying isn’t the word I was using this morning but most of those words I can’t write on this page without a visit from HR.
How does all this relate to mobility you may be asking? This kind of approach to upgrades is not limited to OS providers. If you use a similar approach to your mobile applications, whether they are customer or employee facing, the reaction will be swift, loud, and painful.
Here’s the advice I give to all customers: the only people who know how your application is being used are the ACTUAL users. You went through the effort to solicit user input for the initial app design and that typically leads to strong user adoption. Why would you then turn to internal people, outside influences, non-customers, etc. for guidance on the next phase? As an example, a customer added a new “mandatory feature” to an existing mobile app that caused revolt among the user population. When I asked what users had actually asked for the “feature” and what the written requirement was, the response was classic (and scary); “I saw a presentation at a trade show and some other company did this so I wanted it in our app…” Forget the fact that the other company was in a totally different industry and doing sales and not service, but that’s a minor detail.
The moral of the story is that no matter how smart your development team, product management, engineers, executives, and any other set of employees are, if they don’t ask the user community what they need they will get something they don’t want and worse, can’t use effectively. In that case nobody wins. Are you listening Apple?
