Story 11: Learning to LeadStory | Print | eMail | Related Media | Archives
The Exhibit Development Process
Written by Mike Spock
I began to believe—and still am convinced—there are only a finite number of really great exhibit and program ideas or topics that successfully marry the museum medium to great learning experiences. Conceiving and then exploiting those experiences is really hard. Figuring out what the experience will really be about (or not be about) is the most critical decision that the project leader and the museum managers have to make.
Exhibit development is not a natural extension of classroom teaching. Classroom teachers are not always good exhibit developers. Exhibits are an arms-length, impersonal medium. Teachers thrive on dialogues with people. In a museum exhibit there may be no one available to help when the visitor gets stuck. Exhibit developers know how to present exhibit content to an unpredictable—and often unaided—variety of end-users—from quiet, solo visitors to exuberant school groups. (And museums also have good reasons for stationing floor interpreters (not guards) or offering docent-led tours to facilitate family and student visits!)
At The Children's Museum we thought up a new category of team leader called a "developer." Not a "curator" or even a "designer," the developer's job was to think about compelling experience for someone. Curators were passionate about things, their subject matter and collections. Developers were passionate about creating meaningful experiences for their clients (kids, parents, teachers, etc.). In this dynamic the developer, not the curator, would be the final arbiter in leading their teams. Developers usually lasted in those jobs for many years.
Exhibit developers trained the floor staff to interpret the exhibits to visitors. Under the dual title "developer/curator," developers sometimes had responsibility for their own areas of expertise and collections. In addition to exhibits, developers worked on developing programs, kits and other teaching materials. Those program-and-materials developers were the true teachers.
Developers could easily become bogged down in the minutia of their field, or in building and maintaining relationships with their home community, or, they could loose track of their goals, schedule, or budget. Elaine Heumann Gurian eventually added a new member to the development team, the "exhibit broker," who was skilled at detecting problems among team members, content, and design and how to get around those issues. The broker's role was not to be a tiebreaker or to decide the way ahead, but instead to lay out the issues and different points of view so the developer could make the final decisions and move the team ahead.