Many developers find themselves creating the user interface for their applications without any training. Peter discusses how you can use Access’s features to deliver an excellent user interface.
For many years, the user interfaces (UIs) that I delivered with my applications were accidents: They were what fell out of the process of writing the code. Fortunately for me, the companies that I’d been working with had been delivering bad UIs to their employees for so long that our users had been pretty much beaten into submission. They accepted what we inflicted on them.
However, that state can’t go forever. I finally got the message that the UI matters when I delivered the largest project that my company had ever undertaken. Two days after implementation, we had to go back to the old system. The new system, by and large, did what it was supposed to do. It even had pretty good response time (less than two seconds on most screens). Unfortunately, our users reported that they’d need an extra two hours every day to get their work done because the system’s functions were laid out in such an awkward fashion.
We were lucky; we had built the system in a modular fashion and were able to re-implement the system with a new workflow in three months. Other systems that I’ve worked on would have taken considerably more than one or two months to rewrite. After that disaster, I decided to start paying more attention to UI design and stop counting on luck to get me through. I’d learned my lesson: Failing to get the user interface right on a system of any complexity can substantially increase the costs of delivering the system.
The value of the UI
Normally, a bad user interface won’t stop a project from being implemented. The usual situation is that users persevere in the face of the difficulties created by the UIs that are inflicted on them. In the IS department, developers usually regard the application’s UI as not being very important. Rather than improve the UI, developers are more likely to complain about how stupid the users are and how no one ever reads the user manual. If anything like usability testing is done and the users point out the problems with the system, the developers complain about the people who tested the system: “Well, sure, if you get the six stupidest people in the world to test the application.”
The projects that I worked on didn’t completely ignore the UI issue. Sometimes, in the development process, the users were presented with a paper document that described the workflow of the system and diagrams of what the final screens would look like. However, there was no way that any human being could translate that mass of paper into the reality of how the system would actually work. The point of presenting the user with the design package wasn’t to get a better UI, though. The real point was that once the user signed off on the design package, the user could then be blamed when the application didn’t work.
In the case of the previously described project (and I had taken over as project leader about three weeks before delivery), the closest we’d come to usability testing was training the users. Even then, we had brought the users in, trained them on one specific function, and sent them away. We never let them work with and assess the system as a whole.
UI design isn’t a “nice to have.” There are real costs associated with poor UI design. In general, maintenance costs for computer systems are estimated to be six times the cost of developing the system. Since these estimates are based on the assumption that most computer systems last six years, and the Y2K problem has shown that lots of systems last considerably longer than that, this 6:1 ratio of maintenance to development costs is probably too low. Within the maintenance costs, the current estimate for cost of “support” (answering questions about how the application works, supporting new users, fixing problems caused by misuse of the system) is about 20 percent of the maintenance costs. If you work out the math, it turns out that the support costs for a system over its life are greater than the cost of building the application.
A bad UI design increases your support costs. Systems with poor user interfaces have many characteristics in common: things take longer to get done, frequent errors are made, training is expensive and constantly required, and users can’t tell if errors have been made or if they’ve completed transactions successfully. Does this sound like any system that you know? On the other hand, an “Excellent User Interface” can substantially lower the costs of supporting your system by eliminating these common failures.
A user interface consists of a number of things: forms, the overall metaphor guiding the application design, documentation, online help, controls, and training, among other things. It’s everything that your users see and interact with. In this article, I’m going to concentrate on the workflow design and outline a process that leverages the features of Access to help ensure that you deliver better UIs. Not all of the steps in this process apply specifically to Access, but if you’re using Access to deliver your application, you can use Access to improve your chances of delivering an effective UI.
The holy grail here is the Excellent User Interface. I don’t know if it exists (in the next section, I’m going to suggest that it doesn’t), but I do think it has to be your constant goal.
Who does what, and when?
There are two facts that you should bear in mind when designing a user interface: You won’t actually use the application that you create, and you don’t perform the job that this application will be used for. The conclusion you should draw from these two facts is probably obvious to your users: Your opinion on the worth of the application’s UI is irrelevant. You don’t know what you’re talking about. Only the people who actually use your application to do the job that the application is supposed to support are entitled to an opinion.
To deliver a UI that your users will accept, you’ll have to involve your users in the UI design process. Your role is to offer good advice and the benefits of your experience to your users, but the result has to be something that your users like and not something that you talked them into.
The sticky point is that the typical application will have several groups of users. You’ll need to analyze your users and break them down into the different groups that make up the overall audience for your application. Different applications will have different criteria for defining groups, but these criteria should be used by all systems in defining your users:
- Type of interaction with your application (customers, clerks, managers, and so forth)
- Experience with computer applications
- Experience with applications like yours
- Turnover in users
- Frequency that a user interacts with the system
The list attempts to divide your users into groups using two overriding concerns. First, you want to divide them into groups who do different things with your system. Second, you want to divide them based on the amount of training that they’ll require both at implementation and on an ongoing basis. Jobs with high turnover, for instance, will require more ongoing training than jobs with low turnover. A system to be used by a group of users with little prior computer experience will require more initial training than a system to be used by a computer-literate group. Systems that the user interacts with infrequently will require more support than systems that the user interacts with frequently.
If this list generates too many groups to manage or includes users that you can’t involve in your project (for example, staff at competing companies), you might have to identify the key users that you can get on board and limit yourself to them. Make sure that you notify your management whenever there’s a significant user group that you don’t involve. Once you fail to get input from a group of users, you’ll almost certainly incur extra costs in supporting them. The typical situation, though, is that there are only two or three groups that you’ll have to work with, and they will be internal to your company.
Once you’ve identified your groups, you need to identify what they’ll use the system for and under what conditions they’ll be using the system. Do members of the managers group just review reports from your system prior to going into the monthly production meeting? Or do your managers have to bring up key numbers on demand in your fast-paced company? Are clerks supplying all the necessary data on the health inspection forms, or is their job to get the order in and move on to the next customer as fast as possible? Are your users sitting in an office behind a closed door or at a counter with noisy customers lined up for service?
By answering these questions, you’re starting a “user-centered” design process. Your goal is to deliver a UI that helps a particular set of users to do a particular set of tasks in a particular environment. Even after you’ve answered these questions and defined “where your users are doing what,” you’ll find that there are many UI solutions possible. You can be sure that, while there isn’t one UI that’s obviously superior to all the rest, some solutions are better than others.
“Better” in this situation means “accepted by the users.” Getting your users involved not only improves your chances of getting closer to the Excellent User Interface, it also gets your users to make an emotional commitment to the resulting design. If your users feel that the resulting interface is one that they designed and that reflects their wishes and desires, it’s far more likely that they’ll accept the interface. While it’s tempting to just design the interface and present it to the users, you won’t get the acceptance and commitment that’s possible by involving your users in the whole process. You might feel that the UI your users design doesn’t meet certain criteria that you hold near and dear — but remember that your opinion doesn’t matter. Unless you can convince your users that something you want to implement will offer them benefits that are important to them, your opinions aren’t relevant.
Scenario design
After getting users involved, you must work with them to define the typical scenarios for which they’ll use your system. A scenario is a set of tasks that are performed by a user. Once your users have told you what their scenarios are, you can determine which scenarios should have the greatest impact on your UI design.
Unless you’ve defined your user groups, you won’t be able to define the scenarios or assess their importance. A scenario performed frequently by one or two users might not be as important as a scenario performed less frequently by hundreds of users. A scenario performed by a user group that you can’t train (for example, looking up information at a kiosk in a public mall) is probably more important to your UI design than a scenario performed by users whom you can train. Scenarios performed by long-term employees are less important than scenarios performed by employees in jobs with high turnover.
The key here is that the UI interface should make the most important scenarios easy (and obvious) to do. It’s tempting to create a single form that allows the user to do everything. However, the resulting form will be over-functional. Users would have to navigate through over-functional forms to perform their standard scenarios. Instead of creating “do everything” forms, you want to define the vital scenarios and their variants. Variants on the typical scenario can often be handled by creating special forms that are brought up when they’re needed or by using an “Advanced” button that reveals a set of functions that aren’t always used.
Scenario design also allows you to avoid a common problem with Access systems: the one-table, one-form syndrome. Your users don’t think in terms of tables. For them, a sales invoice is a single object, not a combination of the Customer/CustomerAddress/OrderHeader/OrderDetails/Product tables. If your users are allowed to design their own forms to support their scenarios, they’ll prevent your application from falling into this trap. On the other hand, if you design the forms, you’ll be tempted to use your UI to demonstrate the beauty of your data design.
It’s at this point that Access can make a significant contribution to the UI design process — even if you’re not going to use Access to deliver the final product. Access is a tremendously flexible tool that can be used by everyone from end-users to high-end developers. As a result, it’s very easy to train your users in the fundamentals of Access form construction. Typically, a day of training will allow your users to define forms, add controls, and use the various toolbox wizards to add command buttons to perform standard tasks. Often your only role is to set up queries and provide some additional support as forms are bound to those queries. Your users can then be left alone to build the forms and lay out the workflow that reflects their wants and needs. Your participation becomes a consultive one: offering helpful advice, warning about common problems, supplying some technical Access support, and so on.
It’s important, though, that you don’t let your users start defining their forms until you’ve defined the common scenarios. If your users start designing forms too early in the process, they’ll be tempted to create forms that handle difficult but unusual situations or to create their own “do everything” forms.
Your development process doesn’t have to stop while the UI design proceeds. Now that Access supports class modules, you can proceed to create the business objects that your UI design will require. Class modules let you organize the functionality of your system into objects with high-level methods like CreateCustomer or IssueOrder. To a very large extent, these objects are independent of any particular UI and can be developed in parallel with the UI.
An overview
The process that I’ve described here involves four steps:
1. Involve your users.
2. Define the system’s scenarios.
3. Determine which scenarios are critical to the design.
4. Build the UI to support the scenarios.
This process isn’t without its own problems. There’s a real danger that you can define your groups and the conditions that they work under so tightly that you build an over-specified UI. In this situation, the UI is so closely tied to a particular situation that any change in the company’s processes makes the UI unusable. With scenario design, there’s a danger that scenarios are so narrowly defined that you end up generating too many UIs, one for each limited scenario.
Having said that, this process, backed with the power of Access, will let you deliver a UI that your users actually want and will help them do their jobs. It would be hard to get a better a description of the Excellent User Interface than that.
