Human factors in parking enforcement

Those who attended the Human Factors and Ergonomics Society meeting in Chicago in October 1998 may remember the bright orange parking tickets on illegally parked cars. This article describes the human factors design process that led to a dramatically improved parking enforcement system.

The Problem

For a generation, Chicagoans had thumbed their noses at parking regulations. City and court recordkeeping was chaotic. With no credible enforcement, motorists parked in loading zones, and delivery vehicles doubled-parked. Stalled traffic prevented timely deliveries and brought down the wrath of the Environmental Protection Agency. Only about 10% of parking tickets were paid, and, over a decade, Chicago had accumulated 17 million unpaid tickets worth $420 million. In the mid-1980s, the Illinois legislature authorized municipalities to create a civil administrative adjudication system for parking tickets. Several Chicago mayors announced plans to implement a new system, but without success.

In 1989, Richard M. Daley was elected to fill out the term of Mayor Harold Washington, who had died in office. Daley was looking for high-visibility initiatives that could be accomplished before he ran again in February 1991. Parking was one of these initiatives. In November 1989, I was recruited from the prosecutor's office and given the responsibility for designing and implementing an effective program that would capture public attention. We had 10 months (before a September 1990 target date) to write a city ordinance, design a new system, write a Request for Proposals to bring in an outside technology vendor (the city's mainframe department could not handle the system we envisioned), negotiate a contract with the vendor, construct neighborhood service centers, install new equipment, design a new parking ticket and associated forms and notices, convert 17 million records, and educate city personnel, police, and the public about the new system.

The Result

The new system went live on schedule and within budget and worked smoothly from its inception. A parking ticket program that had been a joke and a scandal had metamorphosed into a technologically elegant, cost-effective system that was successful at controlling illegal parking, yet perceived as fair and easy to use. Within a year, the same-year ticket payment rate rose from 10% to 65% and annual revenue increased to $65 million, while the total annual cost to taxpayers decreased by about $5 million. The program was one of 25 finalists out of 1900 submissions for the 1991 Harvard University Kennedy School of Government/Ford Foundation Innovations in State and Local Government award and the 1992 Computerworld/Smithsonian award for innovative uses of technology. It was profiled in a Fortune magazine article as a public sector success story and cited by the Chicago Tribune in its endorsement of Mayor Daley for reelection in 1991.

The Design Process

My small staff of city employees followed a design strategy based on systems and human factors principles. A few principles were emphasized over and over, constantly reminding us to "think systems," build in feedback, and always consider what individual users would actually do with tickets, forms, and equipment.

Image-based systems design. We began by thinking "from scratch" about how a parking enforcement system should work, drawing flow diagrams to show information paths and Venn diagrams to see how components had to coincide in time or location. This level of abstraction helped us break free of mental constraints rooted in the old system, enabling us to avoid mere efficiency improvements.

For example, Venn diagrams helped us see that ticket adjudication required matching up not people and physical documents (such as tickets) but information: data entered by the ticket writer, the motorist's explanation, and various records from the database. This led us to replace paper and microfilm with an image-based solution that permitted on-line, paperless adjudication at neighborhood service centers and flexible procedures for paying tickets or contesting them in person or by mail.

Tickets were to be scanned and the images stored on optical disk. Motorists who requested an in-person hearing would be assigned a week-long window of opportunity to drop by any service center, where a hearing officer could simultaneously view the ticket image, the ticket history for the license plate, and the meter repair database in different windows on a Sun SPARC station. After reviewing the evidence and hearing the motorist's story, the hearing officer would key in "liable" or "not liable" for one of five statutory reasons. This automatically updated the database and generated a decision in plain English.

All mailed-in materials would be scanned, packaged as electronic file folders, and staged for decision. Any hearing officer not occupied with a hearing could log on to the queue and handle the oldest case requiring decision. These decisions were printed overnight at another location and mailed. This interweaving of in-person and mail-in hearings made it cost-effective to station hearing officers at neighborhood locations.

Parking ticket design. Once this basic image-based system design was in place, our attention turned (beginning in May 1990) to designing the parking ticket. This was the single item that touched all components of the system. Tickets had to be ordered, printed, shipped, and distributed.

Twelve thousand Chicago police officers carried ticket books and collectively wrote about three million tickets a year. Forty full-time parking enforcement aides wrote another million annually. The officer's copy of the ticket had to be collected, scanned and indexed for imaging, and keyed into the database. The motorist's copy had to survive rain and sun on the windshield and convey instructions for disputing or paying the ticket. The ticket envelopes sent back by motorists had to be sorted, opened, and processed and the payment posted. This ticket life cycle concept led us to a fast-track simultaneous design process.

We convened a group of about a dozen people representing users and the vendors for forms printing, scanning, automated envelope opening, and cashiering equipment. The Police Department initially asked that we provide the new design in time to issue a training bulletin, but I insisted that police officers participate and that the department assign beat officers - who actually wrote tickets - and parking aides to the project. The team also included a graphics designer, Sue Brodarick of the Huntley Brodarick Studio, Ltd. in Chicago, whose ideas on type size, font, and layout were key to reconciling user requirements and producing a readable ticket.

We met frequently around one large table to hash out the design. With all users present, the various constraints were understood by everyone, and we could work together to find a "best fit" solution. The statute required certain elements; scanning equipment required white space around the OCR number; and tolerances in envelope-slitting equipment determined the margins. The police had one nonnegotiable demand: The ticket book had to fit in an officer's rear pants pocket!

Any change suggested by one group had to fit the constraints and could be evaluated immediately from other viewpoints. One design layout looked attractive until the forms vendor explained that it required two passes through the printing press, doubling the cost.

Our collaborative approach also ensured acceptance by all parties. Police and customer service personnel alike saw that their concerns were valued and that their design ideas would help make their jobs easier. People were prepared to compromise when they saw how design decisions affected both cost and the burden on other parts of the system.

The more we talked, the more ideas spilled out. The beat officers explained that most tickets were for a handful of offenses, and they suggested check-off boxes. We ran a database sort and found that nine violations accounted for about 80% of the tickets. An early ticket mock-up (we used PageMaker on the Macintosh) was formatted with the check-off boxes on the left side and handwritten information (license number, location) on the right. Then we realized that most tickets are written by right-handed people standing in the street, not sitting at a conference table. The left-hand side of the ticket would be more firmly supported, so we reversed the design to put handwritten information on the left. This improved support allowed a more legible ticket with a cheaper grade of self-carbon paper.

Next, we thought about placing the ticket on the windshield. The writing was on white paper (for legibility), and we wanted the ticket placed face-down to protect the writing and display the bright orange (the mayor picked the color) reverse side. However, the chances of the police cooperating with such a directive were minimal. We needed a design solution. We ultimately used a small adhesive strip so that the only way to attach the ticket to the window or mirror was orange-side up. With the writing reasonably well protected, we could economize on the paper grade. The few cents saved per ticket add up when 4 million are issued yearly.

The basic ticket design was then modified for use with the handheld computers carried by the parking aides. For each new ticket, the ticket writer entered data or selected among alternatives that were presented sequentially in a small window on the computer. Again, we asked the aides how they worked and how their task might be simplified. We learned that their preference was to enter the license plate number first. Illinois was the default state. The current street name was the default until changed. For a different street, keying in the first three letters brought up a menu of Chicago street names from a stored directory. A pull-down menu of violations listed the high-frequency ones first. Keys had to be usable in wet weather and with gloves on.

Ticket instructions. With the ticket layout largely set, we drafted instructions to fit in the space available on the ticket and began user testing. We were particularly concerned about clarity because the legal rules and procedures were changing, and we feared that customer service phone lines and service centers would be swamped with angry or confused motorists. One test group was composed of five high school students, all new drivers. Other groups included city-employed secretaries and tradespeople. For each group, we presented a mock-up ticket with the instruction, "Suppose you found this ticket on your car windshield. What are your choices for dealing with it?" Every time we got a strange (to us) interpretation, we listened to the words the subject used, identified the ticket text that was the source of confusion, and redrafted the text. Over 10 days, we made revisions in the ticket mock-up and tested each iteration with a new batch of volunteers. When we ceased to elicit interpretations that we considered inappropriate, we stopped testing. Other forms and notices were designed using a similar but less elaborate process.

The result of this testing phase was essentially zero telephone calls from puzzled motorists. This too kept our costs down. Only about 7% of tickets were contested, and about three-fourths of these used the adjudicate-by-mail option, reducing traffic at the service centers and enabling the hearing officers to decide cases rapidly online.

The redesigned ticket is shown below.

Lessons Learned

The Chicago parking ticket project was unusual in having a human factors/ergonomics professional in charge, responsible not only for design considerations but for the business decisions involving costs and timing. There are, however, some lessons to be drawn for using a human factors approach in other business contexts.

Focus on the business application. The emphasis on user-oriented, up-front design was explicitly described as a way to reduce future business risks and costs by ensuring that all components of the system worked together smoothly. It was never suggested as an end in itself or as something that had to be done to "meet human factors requirements."

For example, the ticket design strategy and the contractor's interests were aligned (the contractor had initially planned to print a ticket with the required elements placed anywhere they fit). The firm was compensated on the basis of a fixed price per ticket and was responsible for database maintenance, the customer service hotline, sending notices, and cashiering. The account was most profitable if every motorist paid the ticket immediately. Next best was a motorist who followed the instructions about disputing the ticket and did not phone customer service or require follow-up notices. Customer testing of ticket instructions minimized these future costs.

People become allies when their interests are advanced. This underscores the necessity of thinking carefully about the business incentives implicit in the business contracts used in any large project.

Use language the business world understands. Good design usually takes more up-front investment. The business world understands the concept of investment, and the human factors contribution should be phrased in those terms. Time and money spent on design will result in larger future gains in market share, profitability, and productivity. If the benefits aren't there, the design process cannot be justified.

In business, it is considered highly desirable to be customer-focused. The human factors approach can make this goal operational. User involvement encourages buy-in (as we found with the police). Test-marketing (not "usability testing") is a time-honored way of assessing how the market will react to something. Determining how people will perceive information or use a product is within this mainstream idea.

Finally, good design makes for a win-win situation. When all the internal and external users can work smoothly within the system, costs are minimized, profits are maximized, and errors and accidents are reduced.

Be conscious of the real business choices to be made. Wickens (1998) made this point in arguing that emphasizing Type I errors and rejecting the null hypothesis can blind investigators to the importance of Type II errors, and they can miss an alternative that is an improvement over the status quo. The real-world choice is not between the experimental condition and nothing but between the experimental condition and whatever the organization is doing right now. A parking ticket of some design will be issued. The only question is whether a new design will be an improvement over the old. A new design is better if the resulting gain in business productivity is worth the time and cost of developing and implementing the design.

Use simultaneous engineering. In a traditional design process, design and implementation choices are made successively and by groups that may not be communicating with one another (e.g., an architect designs a building and then a contractor has to figure out how to build it; an industrial designer plans a dashboard layout, engineers produce the manufacturing specifications, and assembly line workers cope with difficulties in handling components). The result can be very costly (and delayed and error-prone) if designs that cannot be implemented have to be redone or if people downstream in the process have to work around a design constraint that could easily have been changed had anyone realized its importance.

In contrast, simultaneous, or concurrent, engineering uses a design team that incorporates representatives from every stage of the product life cycle - from manufacturing to shipping to customer usage to repair. As we found with the ticket design, bad or expensive choices can be avoided, and the whole process is speedier because of the immediate feedback it allows.

There is a natural relationship between human factors/ergonomics and simultaneous engineering because it focuses attention on the question of what humans are actually going to do (move it, clean it, use it, read it) with the product at each stage of the life cycle. Although this is still a relatively new approach in business, it is nevertheless a recognized technique that can be cited by human factors professionals. Those business people who advocate this approach will be natural allies.

Rough and ready user testing. As Donald Norman argued in his address at the 1998 HFES meeting in Chicago, human factors/ergonomics professionals who want to make an impact must be willing to perform experiments that are only as good as needed. We were always very conscious of time and budget constraints. For both the general systems design and the ticket design, we were striving not for perfection but for the best design we could produce while staying within budget and meeting the implementation timetable.

For the ticket instructions, our objective was to enable motorists to form a mental model of the ticket system that was congruent with the new statutory scheme. With the right mental model, motorists could make intelligent decisions among their options and pose only those questions that were relevant under the new legal framework. Because the new system replaced an old one, we had to make similarities and differences clear. We had a pretty good idea of Chicagoans' mental model of the old ticket scheme: Ignore the ticket and probably nothing would happen, go to court and sit through the court call, after which the judge would dismiss the ticket, find somebody to "fix" it.

Although our user testing process was informal, it was not arbitrary. We wanted participants who were roughly representative of our target population of Chicago drivers: over age 16, with a driver's license, and unfamiliar with our project and its goals. Our strategy of asking participants to explain the directions on the ticket was analogous to the puppeteer technique described by Savage and Pearsall (1998). Prompted explanation is a simple technique for getting people to verbalize as they navigate through a problem space. It was immediately obvious when our motorists were making assumptions that were incorrect, and we tinkered with the wording until the responses indicated a correct mental model. A few subjects said, "I don't care what the ticket says. I'm going to call the hotline." We figured there was some irreducible number of motorists who would be oblivious to instructions, and there was no point in worrying about it.

I don't have any data on the correct number of people to use for such informal testing, but the mental model approach provides some guidance. Within a community - in this cased, Chicago drivers - there is a commonality of background information about how the relevant universe works. Signs indicate where parking is permitted; municipal obligations generally have to be paid. We took this knowledge for granted and crafted instructions that would be understood in this context. We didn't have to explain the concept of a parking violation or why mailing cash was a poor idea.

This probably explains why we never had to backtrack to reinstate old language, because another participant found new wording more confusing. Words that painted a clearer picture for one person within the community were effective for others as well. For a more diverse community of potential users, it will take a larger, appropriately stratified sample to identify relevant mental models of the way the world works in order to draft useful instructions about how it has changed.

Our participants' mental model did diverge from the statutory scheme in one interesting respect, and we ultimately adopted their representation. The state statute provided two fundamental options: pay the ticket or dispute it. The "dispute it" option in turn had two branches: dispute by mail or in person:

This implicitly incorporates a two-stage decision process. Perhaps being a lawyer, my mental model matched the statute. Participants, however, saw the situation - and their choices - in a different way. They were simultaneously evaluating the pros and cons of three alternatives:

Pay the Ticket Dispute by Mail Dispute in Person

Although there were two legal alternatives, there were three behavioral options: (a) write a check and mail it; (b) write an explanation of nonliability, include supporting documents or photographs, and mail it; or (c) mail in a note requesting a hearing.

There might be an immediate visceral reaction upon seeing the ticket ("They got me." Or "I'm going to fight this!"), but the 10-day response period allowed time for conscious strategizing. The inconvenience of contesting the ticket had to be weighed against the odds of prevailing before the hearing officer. "The signs weren't posted, but I didn't have my Polaroid in the car so they probably won't believe me, so I'll just pay the $20." (An an amazing number of people do carry cameras!) Or, "I know the meter had expired, but meters are often broken, so I'll claim it was broken, and I might win. If not, then I'll pay."

We soon decided that the behavioral reality of three choices matched the operational reality of our system. Checks had to be credited and deposited, requests for hearing scheduled, and mail-in adjudication materials scanned. Having three check-off boxes next to the return address was consistent with the motorists' reality and enabled us to sort the mail before opening it.

By reconciling the mental models held by motorists and the Parking Bureau well before the system went into effect, we could tailor the public education campaign to emphasize points of difference between the old and new systems as well as make operational choices that would ease our workload.

Conclusions

This successful real-world example illustrates the tremendous contribution that human factors can make in designing a large and complex business system and helping to meet tight financial and time constraints. Besides improving the technical usability of individual components, the human-centered approach was also key to earning the support of political constituencies such as police and the general public. The project also demonstrates that basic human factors principles make intuitive sense and can be readily grasped and utilized by participants (police, contractors, business people) with no formal training in the discipline.

By Inge Fryklund

From ERGONOMICS IN DESIGN: THE MAGAZINE OF HUMAN FACTORS APPLICATIONS, Vol. 8, No. 2, Spring 2000. Copyright 2000 Human Factors and Ergonomics Society, P.O. Box 1369, Santa Monica, CA 90406-1369 USA; 310-394-1811, fax 394-2410, lois@hfes.org. This final production draft does not include tables and figures; contact Lois Smith at HFES for a copy of the full issue.

References
Henkoff, R. (1991, September 9). Some hope for troubled cities. Fortune, pp. 121-128.

Savage, P., & Pearsall, S. (1998). A case study in iterative design. Ergonomics in Design, 6(1), 18-25.

Wickens, C. (1998). Commonsense statistics. Ergonomics in Design, 6(4), 18-22.

Inge Fryklund received a Ph.D. in human factors psychology at the University of Michigan and a J.D. from the University of Chicago. She has been senior vice president for Internet Banking and Marketing at the Mid Town Bank in Chicago.