Introduction 
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 develop a prototype to address the problem.
Duration 
September 2018 - December 2018
Approach 
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.
Project Team 
John Falcone // Danielle Colbert
Demery Gijsbers // Sara Ramaswamy
Jessica Vu
Role 
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 functional.
Tools 
Prototyping // Adobe Xd // Sketch // InVision
01 - Design Process
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...
Design Process
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...
1. Defined a problem statement.
2. Analyzed the competitive landscape.
3. Developed relevant personas, use cases, and scenarios.
4. Designed a solution framework using QOC assessment.
5. Created low-fidelity wireframes based on this QOC framework.
6. Created a paper prototype to experiment with interaction styles.
7. Conducted usability tests based on this interactive prototype.
8. Guided the design of our final prototype with the findings from this testing.
02 - Problem Statement Definition
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.
Problem Statement Definition
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 tool available that helps students discover 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?
At the University of Michigan, there is no tool available that helps students discover clubs or events based on their interests.
03 - Competitive Analysis
When identifying potential solutions that attempted to solve the same problem, we considered all possible approaches, including non-digital solutions. After discussion, we identified six unique solutions that would be considered relevant to our problem space.
Competitive Analysis
When identifying potential solutions that attempted to solve the same problem, we considered all possible approaches, including non-digital solutions. After discussion, we identified six unique solutions that would be considered relevant to our problem space.
UMich Events
UMich Events was quickly identified as our most direct competitor. The university-run website showcases upcoming events of organizations and clubs. Their search functionality is comprehensive as well - allowing users to search for events by keyword, organization, location, or event type.
Pros:
- Most complete UofM event-finding solution.
Cons:
- No ability to customize the experience.
- Is not updated often.
- Design isn’t appealing.
Maize Pages
Maize Pages is another university-hosted tool that allows for students to find information on clubs and events around campus. It is a 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.
Pros:
- Extensive database of orgs and events.
- RSVP integration is a big plus.
Cons:
- Experience is not well-designed.
- No event showcase or appealing UI.
- Experience based entirely on searches.
Michigan App
The Michigan App is an essential tool for Michigan students. Containing information on campus events, The MBus System, and the academic calendar, it has plenty of uses. It has a minimal experience to offer for events. It does not allow for the user to filter events or tailor their experience.
Pros:
- Most Michigan students have this app.
- Plenty of value-added services.
Cons:
- Event experience is limited.
- Does not support customization or filtering.
Facebook
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.
Pros:
- Many students use Facebook regularly.
- Students engage directly with organizers.
Cons:
- Information can get lost in the News Feed.
- Difficult to search for events on Facebook.
Flyers
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.
Pros:
- Exist in the physical world.
- No need for an app or website.
Cons:
- Difficult to make changes to event details.
- Limited audience vs. digital services.
Social Spread
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 effective, but limited by the reach of an event or organization’s social network.
Pros:
- Most effective at engaging new students.
- Cost is lowest of all methods.
Cons:
- No direct way to reach “new” users.
- Very limited by social network reach.
04 - Personas & Scenarios
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?
Personas & Scenarios
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.
Identifying the users that we were designing the app for
was key in understanding how to frame our solution.
Personas & Scenarios
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.
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.
Personas & Scenarios
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.
05 - QOC & Wireframes
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.
QOC & Wireframes
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.
By examining how the competitors handled different aspects of their solution, we were able to assess their approaches with design criteria that we defined.
QOC & Wireframes
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.
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.
QOC & Wireframes
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.
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.
These initial wireframes highlighted key strengths and drawbacks of each design option, many of which weren’t immediately obvious.
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.
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.
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.
06 - Paper Prototyping
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.
Paper Prototyping
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 wireframes we had created and test the interactions that we would use in the 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 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 did not understand why they had to move through the onboarding tasks.”
“When asked to locate the filters, two users were unsure about where to find them, indicating that the iconography we used 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.
07 - Digital Prototyping
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.
Digital Prototyping
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 high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.
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.
The first iteration was a high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.
Digital Prototyping
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 high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.
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.
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.
Digital Prototyping
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 high-fidelity version of what we had created with the Paper Prototype, digitized and formatted to function on an iPhone.
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.
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.
08 - Conclusion
Conclusion
Behind every great project is a great team.
This project was a great learning experience. Guiding 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 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.
ABOUT ME
Currently working at Oracle in Austin, Texas as a UX Designer. I use my background in UX and Product Design to help companies implement innovative technical solutions while demonstrating the power of cloud-based applications.
Currently working at Oracle in Austin, Texas as a Cloud Engineer. I use my background in UX and Product Design to help companies implement innovative technical solutions while demonstrating the power of cloud-based applications.
Currently working at Oracle in Austin, Texas as a Cloud Engineer. I use my background in UX and Product Design to help companies implement innovative technical solutions while demonstrating the power of cloud-based applications.
WHAT'S ON YOUR MIND?
WHAT'S ON YOUR MIND?
WHAT'S ON YOUR MIND?
You're here for a reason - if you're just looking around my portfolio, enjoy. If you're interested in working with me, feel free to reach out to me via email or Linkedin - I would be more than happy to talk about my experience with you.
I'm always open to hearing about current and future opportunities.
You're here for a reason - if you're just looking around my portfolio, enjoy. If you're interested in working with me, feel free to reach out to me via email or Linkedin - I would be more than happy to talk about my experience with you. I'm always open to hearing about current and future opportunities.
You're here for a reason - if you're just looking around my portfolio, enjoy. If you're interested in working with me, feel free to reach out to me via email or Linkedin - I would be more than happy to talk about my experience with you. I'm always open to hearing about current and future opportunities.
CONTACT ME
Location: Austin, Texas
Email: johngfalcone@gmail.com
Linkedin: linkedin.com/in/johngfalcone
Medium: medium.com/@johngfalcone
Location: Austin, Texas Email: johngfalcone@gmail.com Linkedin: linkedin.com/in/johngfalcone Medium: medium.com/@johngfalcone
Location: Austin, Texas Email: johngfalcone@gmail.com Linkedin: linkedin.com/in/johngfalcone Medium: medium.com/@johngfalcone
All rights reserved. Made with care and caffeine by John Falcone. © 2020
All rights reserved by John Falcone. © 2020
All rights reserved by John Falcone. © 2020