
"One of the first steps the Searchlight team took this semester was to conduct background research on areas tangential to Pittsburgh Voyagerís mission. A pitfall that HCI warns against is jumping straight to technology, creating an overly narrow focus toward the problem space. As such, our team chose background research topics that covered diverse topics related to education, tours in general, and IT applications such as GIS. This included a visit to the Carnegie Science Center (in the picture), whose goal of teaching children science within a fun but relevant context, is comparable to that of Pittsburgh Voyager. The purpose of this research was to keep an open mind as we explored possible ways to enhance the Voyager experience.
Part of our initial research focused on analyzing the data repository that Pittsburgh Voyager is currently using to store the information obtained by students on its trips. This database is accessible via the Internet through their website, and was evaluated by the standard usability rules of thumb, as they apply to the web. Individual evaluations were consolidated, and a report given to our client about possible issues with and positive aspects of the database. Although our chosen solution does not use the results of our database Heuristic Evaluations, they do represent a significant area that can be enhanced, and did inspire one of the initial solution scenarios we presented to our clients.

After understanding in theory the general supporting concepts of the service which Voyager is providing, our next logical step was to understand how these concepts worked in the field. We aimed to understand not only the processes Voyager uses to spark the interest of students in science, but also to understand the system, the organization and the people who support this endeavor.
Retrospective Contextual Inquiries were performed with individuals from the Voyager full-time educational staff, where we interviewed them on past experiences. Also, Post Observation Inquiries were performed with the instructors on the Voyager boats, after observing full day voyages with students.
Due to the nature of Voyagerís activities, two types of models were key for our analysis. The flow models helped us establish the process of creating and sharing data between the full-time educational staff, the part-time instructors working on the boats and the students. The physical models made clear the physical limitations and environmental challenges that our design would have to overcome to be an effective solution to the problems identified.
Before getting into design and development, we deemed it necessary to compare our conceptual solution to similar products available in the market that might partially fulfill the needs we were focused on meeting. Presentation applications and other graphic display packages were evaluated. This analysis gave us tools not only to imagine possible ways to implement our concept, but also through our analysis we discovered the strengths and limitations our product could face as a real-life solution. Additionally, this second part of the analysis gave way to a discussion about the most viable and useful tools for the team to use in order to create our product

Our team went through several days of brainstorming, where a number of directions were explored, wild ideas were encouraged, but the source was always the findings from our research. Details on our brainstorming process can be found in the Design & Evaluation section.

From our brainstorming sessions came six developed concepts, each of which we portrayed in a scenario. Through scenarios, we used images and words to paint a potential experience for our clients. They gave our concepts context, without being restricting them by implementation details. Scenarios were a useful tool to open a space where to discuss the conceptual basics of our solution with the client. Details of our scenarios can be found in the Design & Evaluation section.
Once we felt we had a true understanding of our stakeholders ñ the students and the instructors ñ we created personas to help guide our design. These personas represented the needs, characteristics and roles played by these groups, and helped us keep them at the forefront of our minds while designing for them.

Before creating our solution, we first did user tests to establish basic concepts we would carry forward in the solution. Our solution was created in incremental prototypes (paper, Director and Java), each of which was tested, and then the feedback used to shape the next prototype. The user tests were all performed with Voyager instructors, and involved them thinking aloud as they performed tasks, giving us insight into their thinking on the tasks and the interface. Instructors also participated in design sessions with us. Details of all of our user tests and design iterations can be found in the Design & Evaluation section.
We performed KLM analysis on java prototypes to get an idea of how fast an instructor (who would be an ìexpert userî of our system) could perform common tasks. This helped us quantify the relative gains of different implementations, and helped us improve the efficiency of our application.
| Methods Applied (Quick Glossary) |
|
|
Heuristic Evaluation Heuristic evaluation involves having a product examined independently by multiple evaluators who understand the product's goals and have good knowledge of established usability guidelines. These evaluators develop a list of items that they must address, creating a structured format for the evaluation. Contextual Inquiry The contextual inquiry is a specific type of interview for gathering field data from users. It is usually done by one interviewer speaking to one interviewee (person being interviewed) at a time. The aim is to gather as much data as possible from the interviews for later analysis. Contextual Design Contextual design is a customer-centered process that supports finding out how people work, so the optimal redesign of work practice can be discovered. It includes techniques that manage the interpersonal direction of designing in cross-functional teams and keep designers focused on the data collected. Scenarios Scenarios specify how users carry out their tasks in a specified context. They provide examples of usage as an input to design, and provide a basis for subsequent usability testing. They are user- and task-oriented use cases. Personas A Persona is a short document which contains one or more representations of target users based on user research data. Usability Testing Usability testing is a method by which users of a product are asked to perform certain tasks in an effort to measure the product's ease-of-use, task time, and the user's perception of the experience. Keystroke Level Modeling GOMS stands for Goals, Operators, Methods, and Selection rules, an approach to human computer interaction observation developed by Stuart Card, Thomas P. Moran & Allen Newell. GOMS is essentially a reduction of a user's interaction with a computer to its elementary actions. Using these elementary actions as a framework, called the Keystroke-Level Model (KLM), an interface can be studied. Different GOMS variations allow for different aspects of an interface to be accurately studied and predicted. |