From Complaints to Awards
A makeover put BART back on track
by Michael Hurwicz
April 2002
In the late '90s, a lot of people who rode the train in San Francisco and the East Bay area were getting lost. Not on the trains, but on the Web site for the San Francisco Bay Area Rapid Transit (BART) District. BART was receiving complaints, questions, and suggestions about its Web site (www.bart.gov) and was prepared to make some changes.
BART runs automated electric trains on 95 miles of track, and serves over 3 million people in one of the most Internet-connected areas in the country. According to a poll conducted by a local advocacy group, the Bay Area Council, 72 percent of Bay Area residents use the Internet, compared to a national average of about 59 percent.
"Our customer base includes a lot of savvy Internet users," notes BART Webmaster Timothy Moore. "They come to our site expecting something comparable to Amazon.com or Yahoo. We need to meet those expectations to achieve the business goals of the site."
Site Issues
BART wanted to redesign its Web site, and its main goal was to improve the site's usability, giving people easier access to train schedules, fares, station locations, track work, future plans—whatever people might need to know to ride the train. As a government agency, BART also has legal accessibility requirements for public information under the Americans with Disabilities Act (ADA). Finally, the agency wanted to make schedules available on wireless devices.
"The version of the site that we were running had been built in early 1998, before we had significant numbers of Web customers," says Moore. "It reflected how we saw ourselves from the inside, not how our customers [saw] us."
However, traffic skyrocketed in the late '90s, growing 100 percent per year until, by 2000, and the site was getting more traffic than it could handle. Customers had access problems during peak periods when thousands of users tried to plan BART trips simultaneously.
One 1998 PC on Windows NT 4.0 struggled to keep up. The PC was running Microsoft Internet Information Server (IIS), and a Microsoft SQL Server database to hold scheduling information and other data for the site. A 1998 version of Allaire's ColdFusion (now owned by Macromedia), generated HTML pages based on the data in the database.
The number of pages that needed to be updated regularly was growing with the site. Except for two sections of the site—job postings, and agendas and minutes for the board of directors—all content was emailed to Moore, who put it into templates and published it (sometimes working with a contractor). This one task was eating away about half of his time.
For pages relating to job postings and board agendas and minutes, people in appropriate departments submitted content via ColdFusion, which generated the pages. This decentralized approach was clearly more efficient than funneling everything through Moore, and the process needed to be implemented for other pages. However, the aging version of ColdFusion could barely handle its current load. The site needed an efficient content management system (CMS) in short order.
Planning
Thus began a research and strategic planning initiative to decide how best to address the problems. About 25 stakeholders were involved within BART. These were mostly content managers, with one or two people from each of several different business units—including public relations, the district secretary's office, human resources, several planning groups, and marketing (the department ultimately responsible for the Web site).
Planning for the back end and the user-facing aspects of the site proceeded simultaneously. One element of the research involved finding out what customers wanted. BART prioritized thousands of email suggestions, looked at log trends to find out what customers were and weren't using on the current site, conducted focus groups, and asked for people's reactions to various user interfaces. All of this information eventually informed decisions about the design and site organization.
Formalizing and quantifying this research was important, because each internal stakeholder naturally believed that his or her area of concern should have priority on the home page. Clearly some compromises were necessary. Decisions had to accommodate the site's customer-focused mission.
