Listen to the Users

Learning Objectives

Allowing users to suggest improvements to the interface and processes
Building user participation into evaluation and testing
Capitalizing upon user input

User participation at all levels of a project is crucial to a successful outcome. Too often, the systems we use in our day-to-day activities are built from management’s vision, the consultant’s requirements and design, or the programmer’s implementation, with very little information from the users. As a result, projects can face unnecessary delays and setbacks because the people using the system have not been given the opportunity to provide insight on usability and functionality. User acceptance, often underestimated or overlooked, is gained from building their involvement into the system development and testing.

This presentation will bring together examples drawn from 30 years of experience in the industry on how the users, the real people using the systems, have improved the user interfaces, improved the processes and interaction with the system and graphic interface, and suggested new applications that have strengthened the overall output for the enterprise system.

A Venerable Tradition of Disregarding Users
When I first visited the offices of the company I now work for, I was surprised to see a meeting being organized with 15 technicians to discuss the progress and quality of the project. Wanting to know how often the operators met to discuss issues, I found out that such meetings were regular occurrences. Technicians were brought together at least once a month, if not more often, for anywhere from two to four hours. Having run and visited other offices, this was strange to me. I was under the opinion that technicians needed to be at their table or desk, inputting data, and not wasting valuable time sitting in meetings.

I admit it: I came from the tradition – the very common one – that asserted that management, consultants, and programmers built systems, and the users just used it. In fact, I have heard conversations between users and builders where the user’s suggestion was dismissed immediately, without consideration. One particular instance stands out; a technician approached a programmer/analyst about a data field that cleared every time a new object was entered. The project required a district number to be entered for each object, and that district number did not change too often in the daily conversion process. The programmer’s reply: “Well it works, doesn’t it? Just fill it in.” The technician’s request may have taken one hour for the programmer to implement, and it may have saved the operator five seconds on each object entry. However, when the technician has to enter that same number over and over again, the seconds will expand into hours. That was a time saving process lost for the entire organization.

There are two areas we need to keep in mind when designing a system. One is how efficiently the system will meet project requirements and the other is how effectively the users will use it. The efforts and processes that a user goes through to enter or revise an object can be quite different on different systems. It can be quite different on different data models on the same system. That’s why it is important to build user involvement into every project.

Seeing the Light
In the data conversion industry, many data models are based on attribute data that will be captured from a map or work order, with the rest of the attributes to be filled out at a different date from other sources, which will be hooked or joined to the object. I have seen data models that may have 50 attributes for an object defined, and yet there are only four or five that can be captured from the map or work order. Another four or five attributes are system maintained, and another ten attributes are filled by a hook from another data file. That leaves 30 attributes that, in all likelihood, will never be filled or maintained in the future.

Yet when the interface is built for one of these objects, the first two attributes that need to be entered by the user are near the top of the attribute menu, and the next one is ten rows down. The fourth and fifth attributes are located in rows 30 and 33. From a user’s view, the simplest approach is to have the five attributes that he or she needs to fill out in the first five rows. It is a waste of time and effort to click and drag down 30 rows before an attribute can be entered. However, the system worked as it was built; the users were using it; and data deliveries were being made. But unless the users are asked, it is all too easy to overlook how this awkward menu interface affected productivity.

Another area that the users have worked with the development staff to improve the process was to modify how a code list is designed for a particular attribute. On one particular project, the system had over 35 sizes defined as valid sizes in the database, starting at 0.25” and going up to 48”. Yet when the data sources were examined, five pipe sizes represented 95% of the pipes for the project. By re-ordering the code list to include these five sizes at the top instead of listing the sizes from smallest to largest, the process improved by ten seconds for entering pipe size. Ten seconds may not seem like a great deal of time, but if 150,000 pipe segments need to be entered, the amount of time saved is over 400 hours.