Ugly and Clunky Enterprise Apps

I read a couple of books about application user experiences and I am still amazed to see the user experience is still ignored today. Ease of use and user experience is at the bottom of the list in development practices while deadline and feature list tops the list. This approach results in lengthy, fruitless, never-ending meetings to discuss why “the excellent app” is not gaining traction among the users. Let’s see how enterprise application developers overcome such a result easily.
PS: If you did not read it yet, I strongly recommend the Alan Cooper’s classic “The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity”).
To begin with, the application has to fit in the current business environment, the business processes and has to be a solution to a certain business problem(s). .The application needs to have a focus, stick to it and improve upon it, rather than just being a technology showcase/programming wizardry. It also has to take the business into account, each business has its own way of doing things, own workflows and in some cases, their own equipment. The developers have to contact with the users from each department and have an overall understanding of the workflows, devices and the relevant applications. You cannot develop a container terminal operating application without understanding how operations work, the terminal operating system and the specialized tally devices used.
Your users are the ones who will use the application, so why not involve them from the beginning? The bottomline is you are programmer who is focused on solving particular problems and you are very comfortable with complex interfaces. But this is too much to ask from your users. Have two teams that are making the quality assurance of your application: the team that checks the technical points and the team of end-users that checks usability and experience. Remember, something technically elegant does not mean it will be accepted by the users. If it is not easy to use, you will be hitting the refresh button expecting to see one more download.

RELATED:   3 Steps to Cloud SLA: #1 Availability

Next, the application has to be pleasing to use: it is easy to use and it looks good. As I have touched in the last paragraph above, if the users are going three or more levels deep to accomplish a task without any clue or any guidance from the application your app is not in a good shape. Same thing goes for the interface. Application loading time, number of images, density of text, whitespace and the color palette should match today’s standards. Would you accept a 2000’s design standards in year 2016? Don’t do this yourself and match today’s standards in your interface. Your end user team will provide invaluable guidance to you on the use; how you need to present workflows, how to consider placement of certain elements, and the like. If you feel yourself stuck, as about their favorite apps and analyze them. This analysis will open a window to usability – the layout of their favorite apps can be a good point to start.
When you are working with the end users, don’t forget that they will use the application on many different form factors. Desktops with over 20” monitors, 15” laptops, 7-8-10” tablets, 5” Android, iOS, BlackBerry, Windows Mobile phones are just some form factors that I can count. In terms of platforms, we can safely say that the application that runs on the desktop/laptop computer can be fully featured and the mobile one can have a little less features and with a smaller technology footprint. You need to ensure that the application has to perform well and look pleasing in all of the form factors.

RELATED:   Top Five Cloud Use Scenarios

Different form factors also mean different use scenarios. In a desktop/laptop computer you can snap two windows on the screen and make data entry easier. Imagine doing that on a mobile device: it is pain to select text on screen, copy, switch to the other application and paste. Forget all if you mistakenly happen to touch a non-related area on the screen – and heavens forbid the back button. On mobile devices make sure that the usability is not that high compared to desktop/laptops. Therefore try to make the users’ lives as easy as possible. An example? Consider automated form fills. When the user begins to type the customer’s name on the screen, make the query in the background, return the results and present the user with choices that he/she can select with a tap. Don’t ask him/her to enter lengthy strings. And when he/she makes the choice, fill out the form with all the details.
If you followed my advice, during all these steps, you will have one technical and one end-user quality assurance team. And to work closely with them, developers need to make their error messages understandable. A “404 error” means “page not found” to many people but for your specific application it may mean “data inconsistency.” During the development phase make sure that the error messages are in plain English (and/or whatever language is spoken by the users) and they guide the user to a certain action. Following the example “Data inconsistency error – please notify your administrator by clicking on the ‘send error’ button.” does more than “404 error: data inconsistency.” In addition to guiding the user to an action, you also need to inform him/her about how to complete the task that he/she was performing.

RELATED:   Who Really Has Your Stored Data?

Having the error messages in plain language also bring us to the thorough testing issue. When you have the two teams (technical and end-user), you will have a lot of feedback. From the missing features to error messages from connectivity to usability, you will have a flood of information. You will be analyzing the information, prioritizing and fixing it. Never assume that rushing tests and taking away from quality assurance’s time will help you meet your deadlines. You will meet them, no doubt about it. But prepare yourself for the aftermath; to defend yourself against the high helpdesk calls, increased maintenance/fixing costs and ultimately less-than-desired usage levels, when asked by the executives.
Finally, in this Bring Your Own Device (BYOD) era, make sure that the application can be updated and wiped remotely. That is, the application could be updated in the field, could be tracked from the IT headquarters and if necessary, the data could be remotely wiped.
That’s my take on developing beautiful, easy to use, pleasing enterprise apps. What do you recommend for our IT fellows? Hit the comments below!
References