UI Design

It exasperates me that UI design is often overlooked; I've seen too many apps with poorly designed and implemented UIs. I'm not really talking about "shrink-wrapped" software as such, but in-house apps that are written to support businesses. In short, apps that are used day-in, day-out by people during the course of their jobs; apps that are there to help companies to make money, contact customers and maintain critical data.

A lot of devs see UI work as being not "real" programming; it's just laying controls out on forms, no logic involved or heavy duty coding. It's something to be shoved in at the end when there's nothing better to do; or, if a UI is required during development, it gets lumped together haphazardly to allow the dev to enter inputs while unit testing the "real" code; and so this is why most business people get inflicted with badly thought-out and buggy UIs. Ironically, the devs that see UIs as being an irrelevant and uninteresting part of the dev process are usually the ones that bleat the loudest when their shrink-wrapped software has a lousy UI.

In my opinion, the UI design is critical to the success of an application, for the following reasons:

• It's the interface with your users (duh!) - they can't see your code, and frankly couldn't give a monkey's what patterns you've implemented or what cool XP practises your dev team have used;
• A UI must support what the user needs to do - it sounds obvious, but too many apps are based on "best guess", i.e. the dev decides what the features are;
• A UI must be intuitive - too often apps are designed bottom-up, i.e. from the data layer upwards; UIs should not simply be based on database tables, but support a workflow; too many devs see the UI as being just a means to edit data - it's just insert, edit, read, delete, with the UI serving as a layer on top of the tables (for an example, cast your mind back to the last time you used or developed an MS Access application);
• A UI must control a user's actions while giving the illusion of flexibility; garbage in, garbage out, right? The UI allows the user to view and manipulate data, which sounds simple enough; but there's more to it than that; a UI that is too flexible allows bugs and issues to creep in;

I want to talk about that last point in more detail; what do I mean by too flexible? This covers those apps that don't provide adequate validation of input which leads to all sorts of bugs by itself, but it's more complex than that. Let me use an example:

You develop an app needs to display a series of rows of data to the user; you naturally display the data in a grid. You don't quite understand why the user needs the data, or what they're going to do with it once they get it; you know they need to view it, edit it, and so on, so that's what you give them. The data that the user wants to see is a problem, i.e. what "filters" they need so they can effectively do a search on the couple of database tables sitting behind all this, so you give them a completely "flexible" solution, allowing the user to perform any kind of search they want. You think you're giving them a wonderfully flexible app, and tilt your chair to celebrate.

Thing is, when the app goes live, suddenly the problems start. Your users have trouble finding the data they're looking for; it's only certain rows they need to see and edit. After a few similar support calls, you have the problem licked - the users know which filters they need to enter to allow the user to get what they want, kind of - there's still a heck of lot of extraneous rows, but you were thoughtful enough to allow them to sort the data, and included every single data table column in your grid, so they can fin what they want. Thank goodness you made the app flexible!

Then more problems start coming in thick and fast. The users report poor performance; it's just too slow, and the rollout looks threatened. The app won't scale, and your boss calls you into his office. Big problems; the users just don't want to use the app; everyone starts talking about buying bigger and more hardware, upgrading the database server, buying expensive caching solutions, without even stopping to consider the real root cause of the problem: the UI that lets the user bring back thousands and thousands of rows of data that they can't possibly read and don't actually want to see, and all those extra columns just add to the problem.

How could these kinds of problems be avoided? Analyse what the user wants, and what tasks they need to perform (use cases / user stories are ideal for this), and provide a mock-up of the UI. I personally produce use cases and UI mockups (using Visio) to help myself think through the problem and communicate potential solutions to the users; the diagrams change constantly (I see them as "throw-aways", just diagrams to help communicate my thoughts rather than serve as absolute blueprints). This means that the UI architecture is analysed and designed just as carefully as the backend architecture and logic; this means spending a lot of time over it, and not just leaving it to individual devs to come up with it ad hoc. In other words, I see the UI as one of the overlooked tasks of the system architect.

You can have the coolest, most efficient, most innovative code at the back end, but if the UI looks awful, doesn't support what the user needs to do, and has countless bugs, then your users are going to think your app is rubbish.