One of the hardest parts about building software for people is the people. The last couple projects I have worked on have been user oriented data exploration tools (generally speaking, one was for a marketing group and the other was for an automotive firm). In both cases there were two overarching questions that had to be answered for every feature we implemented. The questions were what would a new feature do and how would a user use the new feature. In a version of form over function we discovered that a number of times how a user would use a feature to find data would influence how it needed to be implemented.
The difficultly with working on end user facing applications is that the coolest, best feature in the world isn’t worth very much if is not clear how to use it. On some level the importance of UX is obvious with consumer facing applications. It’s why interface changes to popular pieces of software such as Microsoft Windows and Microsoft Office cause so much commotion. The importance of UX in enterprise applications, however is also deserving of the same focus. At one point or another workers at large enterprises have likely had the (dis)pleasure of working with badly designed user interfaces for internal applications. It’s unfortunate that in the enterprise scenario UX is less important due a combination of tighter budgets, forced adoption, and short schedules.
Users can be asked to use a specific application in the enterprise scenario even if it is poorly designed and hard to use. The results of forced use of enterprise applications may be not ideal or as great as hoped. A project my company was brought in to help save was plagued by a buggy and slowly web UI. The project was an information portal for internal use, it looked nice, but the core workflows of the application didn’t match user expectations resulting in complaints and users choosing to ignore the (expensive) application in favor of older systems. In other more extreme cases where the new application is intended to replace an old workflow a poor user experience may result in little or no user adoption. A poorly designed UI may result in fewer time or accuracy savings than might have been otherwise anticipated even if internal users adopt an application.
The point is that getting user experience right is hard and it should be considered an important part of internal enterprise application development.
“How do we get it right?” you might say. The answer unfortunately lies somewhere between approaching business applications like consumer applications and hiring a UX/IA consultancy. It will involve:
- Asking the target users what they do to accomplish a business process and not assuming that individuals’ managers know the end to end workflows.
- Creating mocks that demonstrate what an application will do before actually building it
- Let the target audience use the application before it’s finished in order to give feedback on the design
- Listen to how existing processes work and don’t prescribe new ways of accomplishing goals (at least not without solid evidence)
After following the above bullets points and hiring a good consultancy your application will still likely get it wrong. Iterative development models are important because it takes time to apply the above ideas and figure out how to correctly interact with enterprise users and automate processes. Taking the time to get it right though may be the difference between your users feeling like they’re working on a teletype connected to a 60s era mainframe and users appreciating productivity enhancing internal applications build for the 21st century.
