Research and Process

Narrowing the Scope

In exploring the space of social event planning, we gathered information on social events in general, on how people currently plan social events, and on the tools currently available to help plan social events. We performed literature reviews on event planning, analyzed potential competitor products, and outlined possible opportunities of use and integration with our clients many applications. During this foundational research, we began conducting informal interviews, asking people about the most recent social event they planned as well as asking them about their typical planning process and what they find difficult or irritating about planning social events. We were able to take the results of these interviews and initial research and narrow our focus considerably.

Casual Event Planning

We focused on casual social event planning and had a great sense of how people planned these events and what our system needed to be able to do, on a fundamental level, in order to support this type of planning. We now needed more in-depth user data on how people plan casual social events in order to model more accurately the workflow, culture, and sequence of the planning process. To gather this data, we chose to conduct diary studies to get richer, more detailed data that was not as retrospective as the data we had collected earlier. The studies lasted one week, and we had participants log any instances of social event planning or social events within that week. We followed the diary studies with interviews of the participants. The results of this study, combined with all of our earlier research, allowed us to model casual social event planning.

Unmet Needs

We began the summer semester constructing scenarios illustrating unmet needs that we identified in our earlier research. We wanted feedback on what was most essential for inclusion in our system. We also outlined the essential components needed within a casual event planning interface and began designing the specific interactions and features of each. We incorporated this work in our system and interface designs later in the summer because we still needed to refine the high-level interactions of our system.

Key Opportunities

With the unmet needs in mind, we created a timeline of event planning and an estimation of modality-usage at each step along the timeline. With these two models, we extracted five Key Opportunities for improvement given current event-planning methods:

• How might we help groups make decisions about event specifics?
• How might we get event details to people when they're not at their computer?
• How might we help people know when their friends are available?
• How might we get fast feedback/response during event proposal and negotiation?
• How might we better convey the event decisions?

Concept Validation

After having identified opportunities for our system based on breakdowns in our timeline model, we now needed to gauge users' perception of the relevance and desire for solutions based on these opportunities. We created fifteen scenarios based on the five Key Opportunities and then created storyboards illustrating the scenarios. The storyboards contained only high-level interactions with the system – no literal depictions of user interfaces – in order to focus the attention of the study on users' needs in planning social events and on the concepts of possible solutions to facilitate those needs. After assessing the worth to the user of each concept and proposed solution, we functionally dropped consideration of all concepts which did not test well with participants. Also, many valuable questions for further research and consideration came up during our concept validations, and we explored and probed on these new concerns in future designs and user studies.

Wireframes

After having consolidated the findings from our concept validation user studies and after having constructed the information architecture for our proposed solution, we developed general wireframe designs for the interface of our system. We also developed two scenarios which illustrated the use of the system given our concepts and opportunities. The scenarios were based on typical and realistic casual event planning workflows that we observed and modeled in our earlier research. In contrast to our previous user study where we presented the highest level of use of the system and presented no actual interface designs, here we wanted to elicit feedback on the highest level of the interface designs. After consolidating the feedback from this study, we were able to move forward with answers to our high-level interface design questions and to begin to define and fine-tune the specific interactions of the individual components within our system. We selected among our system interactions those which had the most positive feedback, and we iterated on our wireframe design, creating the first unified version of our within-Gmail system interface. We then began to further define the interactions of the individual components in order to make an interactive paper prototype of our within-Gmail system to test with users.

Paper Prototypes

Now that we had a solidified wireframe design of our system integrated into Gmail, we needed to define the interactions with the system at finer level, designing the specific behavior and features of each individual component. We began to construct paper prototypes of our current within-Gmail (or other email client) design in order to get this data by allowing participants to explore the system and to get system feedback from their actions within the interface. The data from these studies was richer still due to the fact that participants could now use our system to plan events in their own unique ways, enabling us to truly see how flexible the design of our system allowed the planning workflow to be. To best capture the natural and unique planning work-flows of our participants and to best evaluate the flexibility of our system, a key foundational design element of the design, we allowed for and encouraged a great deal of variability within the tasks we gave users to accomplish. Overall, we certainly did get richer user data from our participants with these studies, and we were able to iterate on several components within the Gmail-integrated interface as well as getting useful feedback on our third-party email system design. We used our current findings to improve our wireframe designs of the system.

Flash Prototype

Our user studies up to this point had revolved around demonstrated, hypothetical, or simulated use of the design of our system. We developed a working Flash prototype of our high-fidelity interface design and system functionality to observe participants actually using our casual social event planning application. This provided us with the richest user data yet of our design and allowed us to greatly improve and validate the interactions within our interface and the workflow of the overall system. Using a think-aloud user-research method similar to our previous studies, the data we could collect now was much more realistic and focused due to the reduced need for a suspension of belief for participants and the lack of tedious setting-up compared to our earlier user studies. We conducted two rounds of think-aloud user studies with our Flash prototype. We consolidated of participants' feedback during these rounds, iterating on all design elements that were confusing to participants or found to be difficult to use. Given more time and resources, we certainly would continue conducting more think-aloud user studies, further refining our system design with additional iterations based on participant feedback and focusing on newly added functionality in our final prototype version. The final version of the Fiesta system design and prototype are, however, quite robust in their user-centered construction and validation, and we feel that future iterations would consist of minor adjustments and fine-tuning.