Project for SI 482 - Interaction Design Studio focusing on Interaction Design, Iterative Prototyping, and User Testing
The Happenings App prototype was the culmination of a semester-long project for SI 487 - Interaction Design Studio. Over the course of the semester, we learned how to identify an opportunity area, assess possible solutions, and iteratively develop a prototype to address the problem.
In an effort to be as thorough as possibile during the design of this app, we adhered to an iterative step-by-step research and design process. This process included problem statement definition, competitive analysis, persona-based research, QOC assessment, paper prototyping, wireframing, usability testing, and interaction design.
Everyone participated in the ideation and problem definition phase, and once we began research the tasks were divided. I focused on defining the user personas and scenarios during the research phase. I worked on designing and constructing the paper prototypes. For the final prototype, I worked extensively on mapping the screens in InVision and making the prototype function interactively.
As mentionied in the introdution, the Happenings App prototype was the culmination of a semester-long project for SI 487 - Interaction Design Studio. Throughout the course of the project, we...
A problem statement.
The competitive landscape.
Relevant Personas and Scenarios.
A solution framework using a QOC (Questions, Options, Criteria) assessment methodology.
Low-fidelity wireframes based on this QOC framework.
A paper prototype to experiment with navigation and interaction styles.
Usability tests based on this interactive prototype.
The design of our high-fidelity prototype with feedback from the paper prototype
The first step taken for this project was the defining of the problem statement. Each group member came into the first meeting with a specific problem that they wanted to address, and the following problem in particular stood out: staying up-to-date with on-campus events.
At the University of Michigan, there is currently no all-in-one tool available that enables students to discover new organizations or events based on their interests.
Having clearly defined our problem, the next step was to look at the competitive landscape - who has attempted to solve this problem already?
When identifying potential solutions that attempted to solve the very same problem, we considered all possible approaches, including non-digital solutions. After thoughtful discussion, we identified six unique solutions that would be considered relevant to our problem space.
UMich Events (events.umich.edu) was quickly identified as our most direct competitor. The university-run website showcases upcoming events of both university organizations and independent clubs. Their search functionality is comprehensive as well - allowing users to search for events by keyword, organization, location, or event type.
+ Most complete UofM event-finding solution.
- No ability to customize the experience.
- Is not updated often.
- Design isn’t appealing.
Despite fluctuations in usership amongst the college-aged demographic, Facebook has remained a go-to for event promotion and discovery. Students will publicly share information about on-campus events and organizations in university Facebook Groups, which are effective at recruiting interested students.
+ Many students use Facebook regularly.
+ Students engage directly with organizers.
- Information can get lost in the News Feed.
- Difficult to search for events on Facebook.
Maize Pages is another university-hosted tool that allows for students to find information on clubs and events around campus. The website acts as a large, searchable database which allows user to filter by a keyword, date, theme, category, or event perks. Users can also RSVP for events directly through Maize Pages.
+ Extensive database of orgs and events.
+ RSVP integration is a big plus.
- Experience is not well-designed.
- No event showcase or appealing UI.
- Experience based entirely on searches.
Good old fashioned flyers are still a commonly-used means through which to advertise on-campus events, despite the world around them going digital. Flyers can capture students’ attention in locations that a phone or digital device simply cannot. Cost of production for flyers is considerably low when compared to that of an app or website.
+ Exist in the physical world.
+ No need for an app or website.
- Difficult to make changes to event details.
- Limited audience vs. digital services.
The Michigan App is an essential tool for Michigan students. Containing information on Events, The MBus System, and the academic calendar, it has plenty of uses. With regard to its Event-related capabilities, it has a minimal experience to offer. It showcases a handful of events, but does not allow for the user to filter or tailor their experience.
+ Most Michigan students have this app.
+ Plenty of value-added services.
- Event experience is limited.
- Does not support customization or filtering.
The influence that word of mouth has in encouraging students to attend a new event or organization is significant. Students are more likely to consider something new if they have a trusted connection inviting them. This organic spread of event information is quite effective, but also limited by the reach of an event or organization’s social network.
+ Most effective at engaging new students.
+ Cost is lowest of all methods.
- No direct way to reach “new” users.
- Very limited by social network reach.
Identifying the “types” of users that we were designing an app specifically for was key in understanding how to frame our solution. For example, we went into this step with a broad understanding of who we’d be designing for - “college students” - but needed further understanding about the subgroups of users that fall under this umbrella term. How would their needs vary by age? What about organizational interests?
Identifying the users that we were designing the app for was key in understanding how to frame our solution.
After long and thoughtful discussion about who exactly we’d be designing for, we created user personas based on these prospective users. For each persona, we defined needs, goals, and pain points. Based on these factors, we went even further and developed scenarios for each persona. These scenarios are example use cases, each of which addresses specific aspects of the persona’s personality and aspirations. Below are the personas and scenarios we created.
Together, these personas and scenarios work to form a crystal clear image of the users for which we would need to create a solution. The decisions that would be made over the rest of the design process would be informed by the varying needs of these personas.
For the next big step in the design process, our team used a QOC-based evaluation method to determine, in a broad sense, how we’d like our app to function. QOC (Questions, Options, Criteria) evaluation allowed us to integrate what we’d learned from the Competitive Analysis and outline some of the major elements of our app. By examining how the competitors handled different aspects of their solution design, we were able to weigh these approaches against criteria that we generated. This allowed for informed, holistic evaluation of the functionality options we were interested in implementing.
By examining how the competitors handled different aspects of their solution design, we were able to assess their approaches with design criteria that we defined.
Below are the QOC diagrams that we created to assist in our evaluation. Note that, for each question, multiple options were evaluated in conjunction with multiple factors. This is the main appeal of QOC evaluation - it allows for the different approaches to be evaluated in a directly comparative way.
From the QOC evaluation, our team developed rough, low fidelity wireframes based on the options evaluated in each. These wireframes allowed for our team to get a peek at how each option would likely look and function in an app-based solution, should we decide to move forward with it.
These initial wireframes highlighted key strengths and drawbacks of each design option, many of which weren’t immediately obvious.
Below are the wireframes we created for each QOC evaluation - note how each frame represents the implementation of a different option from the QOC evaluation.
The QOC & Wireframing step was critical in the design process because it allowed us to take the information we had gathered about competition and usership and begin the process of translating it into a comprehensive mobile app. This step was, I would argue, the most important and consequential part of the entire project - everything that our team worked to design following this was based on the key design and functionality decisions we made based on the QOC evaluations.
The development of the Paper Prototype was the means through which we took the rough wireframes and functionality ideas that we created with the QOC evaluation and came out with a paper prototype that effectively captured the big-picture interactions that we’d be implementing in our digital prototype. At this stage in the design process, we had some ideas defined.
The Paper Prototype allowed us to take the rough wireframes that we had created and design the major interactions that we would be implementing in our Digital Prototype.
We knew that our app was going to connect students to on-campus events, and we knew that we wanted this experience to be tailored to students’ individual interests. We knew that our app would allow students to search for events and organizations, and filter their search with a variety of criteria. We knew that we wanted to allow students to RSVP for events from within our app.
We developed the Paper Prototype in a way that would, as effectively as possible, meet all of these requirements. The Paper Prototype, which was based on our wireframes, made sure to in some way address each requirement. After days of meticulous planning and sketching, we completed the first version of the Paper Prototype, and recorded a demonstration of how it worked, which can be seen below.
We proceeded to take the first iteration of our paper prototype and conduct three independent user tests. We presented the prototype to the user and asked them to perform a handful of tasks, noting how they succeeded, how they struggled, and any comments or observations they made. Here are some excerpts from the user tests:
“Users jumped right to the navigation bar instead of clicking through the onboarding screens, and they did not understand why they had to move through the onboarding tasks.”
“When asked to locate the filters, two users were unclear where to find them, indicating that the iconography might be confusing.”
“Users expressed the desire for both an in-app calendar and an option to add an event to an existing online calendar.”
Following the user tests, we took these comments into account and developed a second version of the Paper Prototype. This second version directly addressed the user concerns and gave us the opportunity to make tweaks and changes that would improve the interaction experience. A recorded demonstration of the second version of the Paper Prototype can be viewed below.
Creating the Paper Prototypes allowed for us to achieve a clearer vision of what interactions we wanted to incorporate into our digital prototype. Through the user testing, we were able to identify key usability issues and address them early in the design process. These decisions and changes made during the creation of the Paper Prototype directly transitioned into the next step of the process, design of the Digital Prototype.
The design and creation of our high-fidelity Digital Prototype was the most comprehensive stage of this project. Throughout the weeks we spent designing, building, and iterating, we were able to refine details of the in-app experience, map out a collection of multi-step interactions, and experiment with visual design styles. It’s in this step of the design process that all of what we worked on in the prior stages came back and influenced the Digital Prototype.
The first iteration was a medium-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone screen.
The Digital Prototype had two major iterations. The first iteration was a medium-fidelity version of what we’d already created with the Paper Prototype, digitized and formatted to function on an iPhone screen. This iteration, while simplistic visually, set the foundation for the second and final iteration of the Digital Prototype. The first iteration mapped all of the interactions were were going to design as part of this project, including Onboarding, Events Navigation, and Searching. Below are selected screens from the first iteration of the Digital Prototype.
Following the completion of the first iteration, we took this prototype to our professor and our peers to get their thoughts on the user flow, interactions, and visual design. Feedback was largely positive, however, a handful of comments did translate into tangible changes in the second iteration of our app design.
Users helped identify bugs in our hotspot mapping, enabling us to clear up any “dead ends” in the user flows they ran into while using the prototype.
Users helped identify bugs in our hotspot mapping, enabling us to clear up any “dead ends” in the user flows they ran into while using the prototype. Users also made suggestions regarding the visual design - notably, users wanted relevant images to accompany the event information, and some users noted that the color palette was rather bland. Taking these comments into consideration, we reworked the design and created the second (and final) iteration of the digital prototype. Below are selected screens from the second iteration of the Digital Prototype, which highlight some of the changes made.
With the completion of our final iteration of the Digital Prototype, our work on the project was complete. Positive feedback from the SI 482 faculty confirmed that we’d succeeded in creating a solution for our problem statement, satisfying the requirements of the class.
Behind every great project is an even greater team.
This project was a great learning experience. Being able to guide an app’s development from a problem statement, through a collection of solution possibilities, into a functioning digital prototype was a rewarding experience. Seeing how we were able to identify design issues and make successful adjustments along the way solidified my belief that good design is the result of an iterative process. Doing all of this with a team of talented designers made the experience all the more enjoyable.
All rights reserved. © 2019 John Falcone.