The vast majority of funding and resource focus related to a system’s implementation is on what users consider the 'back-end' - which is, to a user, everything that is not the interface they stare at. Substantial time and money is poured into infrastructure, database design, platform implementation / customization / configuration, and integrating the new system with other systems for example. But frequently too little time and energy is spent designing, implementing, testing, and refining the most critical part of the system: the interface users use. I refer to this gap as the chasm of the last mile that many otherwise great systems fall into.
If you look at a systems investment across both implementation dollars and time, you frequently find that the user interface receives less than 3% of the funding and effort. Compare this level of focus and investment with the percentage of system time users spend with the interface: 100% (or nearly). Users don't care how elegant the back-end database is architected and normalized. They don't care how well the code is documented. They don't care how well authentication is handled. What they typically do care about above everything else is how easy and intuitive the system is to use. If you want to implement truly great, successful systems, you have to bridge the last mile chasm. Here are at least three basic requirements necessary to do so:
- Budget and plan for user interface (UI) design and development activities. Much of this activity can and should occur across the SDLC, from requirements gathering to testing and go-live. I frequently see plans for implementations that exceed $10M but don't possess a single activity line specific to the interface.
- Interview and employ one or more interface experts on the project. Ask for examples of their work and make sure it impresses you. Like many resource types, there's a lot of 'average' out there. Don't settle.
- Leverage mock-ups and wireframes in user sessions and testing across the lifecycle. Let UI wants and needs push the rest of the implementation team rather than the other way around.
Here are some examples of interface elements that I've seen wow users and close the chasm:
- Thinking through data to what it's used/going to be used for, and doing what you can to tie it together better. Example: A system NIST developed captured patent numbers - do what NIST did and make the patent number field on the form a hyperlink that opens the patent's full information from PTO in a new window. Easy. Obvious. How many fields in your systems have the same potential? Probably several.
- Pull external data into the same interface. Similar to the example above, dedicate a sidebar or part of a sidebar to show data relevant to the record being viewed. If the system has a company record/form for example, use a public RSS feed to populate the section with company news from the feed.
- Use improved or 3rd party enhanced interface components. Don’t settle for a standard table when you can include one that allows sorting or filtering on the table’s columns. Need to add a file? Don’t use (only) a browse button when you can include a drag and drop space in the application.
- Hiding less used data. A simple but effective trick is to use any one of a variety of techniques to hide rarely used fields on a form under a clickable title, so that even if there are dozens of fields on a single form, only the relevant/most relevant are initially shown.
- Make the home/main menu screen relevant and helpful. Show queues of pending actions required or object status aging for example to facilitate access and processing as well as provide insight into the information the system stores (I’ve seen this done very elegantly as a simple tree view that even let the user pick which queues they wanted to see.)
- Gamify the system in subtle ways. One organization added simple badges to their system which are automatically displayed on a user’s home screen when they exceed certain processing levels (in this case, it was based on request aging and closeout rates…)
- Asking for feedback directly within the application. Add a permanent button to the header or footer that automatically directs the user to a web form (or in-system pop-up form) that captures feedback, desires, bugs, etc. and make sure that information gets to any change control/roadmap functions.
These are just a few of hundreds of ways to build truly great interfaces that drive significant user satisfaction. The best software architect I have ever worked with, Ken Nehring, really got this concept and has built a number of systems across many industries that have acted as reference interfaces for dozens of additional systems. Be the one who builds the reference interface that others in your organization/customer base refer to as the standard to shoot for.
All of this is not to say that well architected and implemented infrastructure, platforms, and databases are not critical, they are vital. But all of that investment could be considered a complete waste when hidden behind a poorly designed UI – falling into the chasm just before the user can experience it. Plan for and leverage a UI expert, a good one, on your current and future implementations. Your users will thank you.