Craig Fryer and Professor Richard Helps, Information Technology
Designing and Implementing a web service for promoting genealogy and family history work requires a complex process of working with potential end users, designing a product that meets their needs, and testing it with the end users. I found that the greatest challenge to this process was including the end users in every step of the process. Developers tend to make assumptions regarding what is best for the users. These assumptions are often proven wrong when presented to the end user of the product. To circumvent this error, I used the following process.
It is important to properly select the appropriate end users of the web service. If the wrong end users are selected, the web service will be geared for the wrong audience. It can be difficult to select the appropriate end users, if the audience is widespread. When working with a web service as specific as the FamilyTreeMapper, I selected the end users from a pool of already existing researchers. To track down these users, demographic data was retrieved from the Family History Library in Salt Lake City. This data includes the characteristics of the users, such as age, gender, race, location of residency, experience in research, computer skills, religious affiliation, etc. To cater the web service to the appropriate end user, I selected users that matched this demographic data.
Once the appropriate end users were contacted, they were interviewed to gather additional information pertaining to the FamilyTreeMapper web service. I performed a series of interviews to gather this information.
In the first set of interviews, information was gathered in order to get a better understanding of the user. Various questions in these interviews included: What are your hobbies? What are your life goals? How much experience do you have with genealogy work? How many times per week do you perform genealogy research? What do you use your computer for besides Genealogy? How comfortable are you on computers? I used these questions to help gather data about the users to create a user profile. A user profile is a definition of the end user derived from merging the data collected from the user interviews. This profile makes it easy to have a clear, concise description of the end user without having to review the interview logs.
The second set of interviews was geared towards finding out the users’ wants. To gather this information, a dynamic conversation about the product and its benefits was required. In this stage, the users were asked what they would like to get out of the product. Follow-up questions were required to expand on the users’ responses. Various questions in this stage of interviews include: What kind of information would be most beneficial to you in your research? What kind of information would you want to know about geographical areas? What are your main goals in the genealogical research? How would you like this information presented to you? This data provided an initial insight into how the product would benefit the user, thus defining the initial design of the product.
With the information gathered in the first two stages of interviews, I can begin to design the user interface. The design of the interface relies on the tasks being performed and their frequency. I had to perform a task analysis with the users to identify these tasks.
In the third set of interviews, the users were asked about the tasks they performed and the frequency of these tasks. These interviews were the initial step towards gathering this data. Additional information was gathered through observation of the users. Users that are unable to identify tasks may provide information related to the overall process, which can be broken down into individual tasks.
An efficient method of gaining task-related information from the users is through storyboarding. Storyboarding is the process of using a comic-strip like document that shows the steps to complete a process. Each scene in the storyboard represents the individual steps in the task. This helps the users to divide the process into individual tasks.
After the task analysis was performed, I identified the most frequent tasks. The overall layout and design of the web service is based on these tasks. Tasks that are performed most frequent will be the easiest to access and perform. The layout will include these tasks first in priority, whether it is at the top of lists or using larger buttons. Less frequent tasks will be further down in priority and less convenient to access in the layout.
At this point, I could create prototypes of the end product to get user feedback of the design. By starting with low-fidelity prototypes, the layout can be easily changed without wasted efforts. The users then get a real sense of the end product, its functionality and design. I followed an iterative process to reach a higher-fidelity prototype. Starting out with a paper-prototype allows for easy but crude mock-ups of the design. This advances into a more complex, higher-fidelity or digital based prototypes. These digital prototypes include image files that represent the layout of the end product. The images are not functional, but merely represent the look or design of the product. After refining the design, I used software-based prototypes, such as HTML based prototypes, to add functionality to the prototype. I continued the prototyping process until a pseudo end product was created. It is important to focus on each stage of prototyping, whereas each stage serves a unique and independent purpose. I found that the further into the prototyping process, the more difficult it is to make changes to the end product.
Even after prototyping and gathering data from the users, many developers can mistake the users’ desires and insert their own biased desires. I used testing to highlight any discrepancy between the developer’s product and the users’ desires. User feedback from testing helped determine changes to functionality, usability, and usefulness that were needed in the product. This also helped determine if the product met its designated goals. When testing User Interfaces, especially when testing low-fidelity prototypes, it was important to put multiple versions of the prototype in front of the user. This accomplished two goals. First it eliminated the issue of the user saying that they like the interface just to be nice, even if they did not like it. The other way that this helped is by giving the user options. The user was able to pick and choose the functions that they liked from each version of the prototype.
The success of the project relied directly on the user’s satisfaction with the product. Adhering to the guidelines provided, studying the user and his needs through interviews, conducting tests with the user through prototypes, and listening to user feedback promoted a successful userbased product.