CS449 — Team HCI Course Reflection

Project Goal

This term as a part of Human Computer Interaction, CS449, at the University of Waterloo, every person joined a team to help design a mobile app addressing a different role in Improving the Culture of Waterloo at the University and Beyond.

Our group, consisting of Chris Yung, Richard Cai, Andrew Lee, Quinn Toyoda, and Arri Ye, was tasked with helping to improve coordinating amateur musicians, actors, dancers, and artists to create pop-up performances. We identified what our main goals would be and the primary value which our app should provide. While none of us had vast expertise in the area, we decided upon the value proposition of enabling performers to meet other performers and share their talents to a broader audience. We also established goals of making finding performance locations, meeting performers with similar talents, and coordinating practice all as pain-free as possible.

At a high level, our goal was to bring the community together via performances. One of our initial hypotheses was that local communities would come together and feel closer to each other if there were frequent performances in public areas (or popup performances) since they would interact with other community members more frequently.

By removing the barriers for performers to get together, find others and host performances, we aimed to achieve our goal.

Product anticipated users

Our team initially came up with 5 personas that would represent our target users.

The first persona we created was Bill, an undergraduate university student looking to expand his social circle. He also wanted to find friends who shared an interest in music. This person represents a casual user, who would mostly use our app to meet new people. He isn’t looking to play big performances but is trying to get back into music.

The second persona we made was Jessica, a fresh university graduate working in a new city. She dreams of making it big to the big stage and becoming a professional dancer. However, she is currently working to pay off her student debt, so she doesn’t have much time to search for people to practice and perform with. Jessica represents a more intensive user. She’s looking to cut down on the amount of time she needs to dedicate to looking for a group and will be using the app heavily as a result. She wants to form a dance group in order to practice and further her career.

The next persona we came up with was Sally, a coffee shop owner. She’s found her business has been slowing down recently and wants to find new ways to attract customers. She loves music but doesn’t play much herself. She represents a venue owner who would use our app to find people to perform at her coffee shop.

Another persona we created was Dave, a community engagement coordinator for the city. He loves to organize social gatherings and wants to create more performance events throughout the city. He represents an organizer, who would use our app to link performers and venue owners.

The last persona we created was Stan, another recent college graduate. He isn’t much of a performer but loves to go to pop-up events and watch live performances. Stan represents a user that uses our app to discover new performances in his community.

Using the feedback we received from interviews and our buddy team, we decided to narrow our focus onto three specific personas: Bill, the casual user looking to meet people, Jessica, the intensive user looking to form performance groups, and Dave, the community organizer looking to create popup events in his city. We found that these three users would benefit the most from what we wanted our app to accomplish. The two users we removed were Sally, the venue owner, and Stan, the casual onlooker. We decided that venue owners wouldn’t need to be so involved in the process, since they’re mostly just listing their locations for availability. As well, while we had initially envisioned something similar to Instagram’s discover section for the general public such as Stan to use, we decided that it would be better to focus on connecting performers.

Below is an example persona we created for Bill Anderson — a university student trying to get back into music and wants to meet new people.

Empathy map for Bill Anderson:

Think & Feel:

  • Cares about approval
  • Scared that people don’t like him
  • Feels uncomfortable with new people


  • Friends are really nice, but rarely have deep conversation
  • Classmates are somewhat quiet and he keeps to himself

Say & Do:

  • Generally walks alone with headphones in
  • Dresses in standard jeans and t-shirt
  • Generally polite, but on the quiet side. Only speaks if spoken to


  • Sees the lovely Waterloo campus
  • Enjoys going for walks and working at coffee shops
  • Will study on campus between lectures


  • Wants more, close friends
  • Measures success by happiness and self-improvement


  • Fears rejection
  • Fears people only pretending to like him
  • Has stage fright

User Interviews

To gain a better understanding of our users, we interviewed them to help us in narrowing down our assumptions and verify that they were correct. We ended up interviewing 8 people, and the average age was about 22–24 years old. The focus around this youth/young adult range was in line with our assumptions that users around this age are tech-adopters and users of social apps such as ours. Our interviewees had equal representation from different gender groups and was very diverse, and we feel that they were a representative sample for our user base.

To conduct interviews, we first came up with question sets. We crafted a kind of general set of questions, to gradually introduce interviewees to our topic and to learn some common usage patterns such as how they consume entertainment. We also made additional question sets that were based on the different personas, depending on the interviewee and what they reveal. In creating the questions, we incorporated interview design techniques, such as following Michael Barry’s interview process model, in building some rapport through general technology conversation, and then getting into specifics (entertainment and persona questions) and having time for reflection at each step.

We also consciously made an effort to avoid including leading questions, acquiescence bias (being as neutral as possible), and other bad interview aspects. To conduct interviews, consent was collected before collecting answers. In interviews, we were very flexible in allowing interviewees to answer how they want, with minimal prompts to get rich discussion. The discussion and questions were adapted as the interviewees answered to explore deeper specifics for each interview, and feedback was collected afterwards to iterate and improve the questions. We incorporated a lot of walkthrough questions to really get a deep response and to allow interviewees to reveal any pain points, as well as give us insight into their sequences of tasks (as in the Sequence Work Model). We also used points from the work models to iterate on the questions further, such as asking and making note of artifacts (items users interact with to accomplish tasks) and paying attention to moments of hesitation/indecisiveness.

Some sample questions:

  • Can you walk me through your social media usage yesterday, and if you felt any noticeable frustrations?
  • What was the last artistic performance you remember? +Follow Up Questions for discussion

To analyze the interviews, we collected the user behaviours into an affinity diagram which we added to as we iterated on our project and got more interviews completed. We also created some work models based on the results we collected, to formalize how users complete tasks.

Some overall themes that we found were in the widespread use of technology, the desire to accomplish hobbies, the need for entertainment, and planning/organization difficulties, as was revealed from the Affinity Diagram. Modern technology-users consume a lot of social media and entertainment, hence our app is logical in addressing these needs while using modern technology (mobile) and making it easy to plan and organize. Combining this with the work models, we identified the main breakdowns in pop-up event creation/management:

  • Finding other people to perform with is difficult due to not having those connections and people are busy
  • Finding a good venue for performance is hard as well as coordinating location use
  • Users use many different apps and services to plan and communicate. Sometimes info is lost in this network as information exchange takes place across many artifacts.

To tackle these problems, we decided to focus on these problem areas for our topic. Of course many other necessary features for an actual release we discovered (colour customization, layout configuration, Dark Mode, etc.) but we focused on having features that would address these main work model breakdowns. To allow people to find others to perform with, our “Profile” feature allows users to add interests to match talents, and also coordinate schedules by indicating times they are busy. This is the kind of social interaction that our app would facilitate, as users can find others they want to perform with. To help coordinate location discovery and management, we focused on a “Event Creation/Management” feature that builds in location search and booking. The layout is very similar to Google Maps, a familiar service. Having familiar layout and functionality was indicated to be useful from our interviewees, in speeding up tasks. Finally, to address how users have to manage several different services to communicate, we also focused on a “Messaging” feature that would be a hub for all communication. It allows the sending/receiving of files and multimedia, and is purpose-built for pop-up event management. Having this central place for communication reduces the amount of time needed to sort and manage info through other services and mediums.

Initial design ideas

Our initial design ideas drew very heavily from our imagined personas, model diagrams, and the interviews which we had conducted up until this point. The first common trend amongst the data we collected was that it was hard to find other performers and find a group. This led to our conclusion that our app needed a feature to find other performers to create groups. Naturally, this led to another design requirement which was to have some form of messaging system. We recognized that there are many messaging platforms already, but felt that it was a feature which would be frequently used and we could automatically create chats associated with groups and performances.

We also wanted our app to allow each user to have a profile where they could state their interests, skill levels, and sample works. This would be help people find better suited people for their performances and also would allow our team to more smartly recommend.

Another design idea we had came as a result of our personas of people who didn’t necessarily perform themselves, but would like to see pop-ups including pedestrians, business owners, and community organizers. In turn, we wanted a feature to allow these users to upload locations where they would want to see performances.

After deciding upon these initial design ideas our team created many different visions of how we should implement these through the use of “Crazy 8s”. For this activity we each picked one feature and in speed rounds of 30 seconds we drew a sketch of how the feature could potentially look in our product. As you may guess from the name, this was repeated 8 times. After completing all 8 iterations, we evaluated the others’ designs and selected our favourites for further prototyping.

Paper prototypes and evaluation

After deciding on our favourite design for each feature, we wanted to get our “app” in front of users to have them interact with it. In order to achieve this as fast and efficiently as possible, we used paper prototyping. For those unfamiliar, paper prototyping is a method of making the product out of paper and interactions are emulated by a person moving and replacing pieces of paper for menus, buttons, and screens — here’s a great example: https://www.youtube.com/watch?v=GrV2SZuRPv0

We created 3 main features for these paper prototypes. The first feature was general a homepage that included featured nearby events, your created events, a search bar, and a navigation bar at the bottom. It came as a result of our crazy 8’s activity and drew heavily from apps such as AirBnB for the layout and features.

Secondly, we implemented the flow to create a new pop-up event in paper form. This allowed users to select a name, category, and location as a basis before being able to invite other members and advertise.

The third feature we included in our paper prototypes was a way for people to discover pop-up performances happening around them. The key features of this were a map view similar to Google Maps, as well as having the ability to filter by location and type.

After creating our initial paper prototype we had many users, both classmates and friends, test the first iteration. During these tests, the benefits of paper prototyping became very clear. There were numerous times when we would immediately iterate by drawing a missing component onto our screen while people were testing or totally change a feature flow with ease. Further, the feedback received was often more focused on the general feature selection and sequence of actions opposed to minor visual details since nobody expected the paper drawings to be a masterpiece.

Design Iteration

One of the biggest takeaways from this course is how few people you need to actually do testing.

Why You Only Need to Test with 5 UsersJakob Nielsen

Through this, we realized you can do usability testing and obtain solid feedback on just 5 users. We decided to leverage this idea and created many iterations of our app and tested on a small set of users such as our classmates/roommates/friends. We iterated and got feedback on our app many times to get to our final iteration and received a lot of feedback on flows and UI elements.

After iterating through our project designs and going through the in-class activities including paper prototyping and creating user/flow models , we realized that our scope was too large and that the quality of our project was potentially taking a hit. Furthermore the users were overwhelmed with the number of features.Our main findings were that the home screen was too busy and unintuitive (and therefore hard to navigate through), the focus of the app needed to be shifted towards the organizers instead of the audience, the schedule needed to be more easily managed, the discoverability of events and performances needed to be smarter and more intuitive based on schedule and interests, and the profile creation and editing needed to be simplified and streamlined. Based on these findings, we created some new assumptions. We assume that our app is going to be more useful and more used by organizers, or people who want to put on performances, rather than people who want to find performances to attend. We’re also assuming that the profile that users create are going to be very important when they look for members to collaborate with. Lastly, we’re assuming that scheduling will play a huge role in most use cases, and that we should focus on this portion of the app the most. For users looking for performances, we realized people probably wouldn’t want to download the app to just find events when Google Maps and other apps already had features to find local events. For leaving feedback for events, we decided to allow leaving reviews and videos without having to register.

From testing feedback, our home screen and flows were way too complicated, we decided to consolidate the home page into a simple calendar view where you could view your upcoming events and also create events. Besides the home, we had 2 other key tabs, (profile management and discovery)

One of the biggest pain points we discovered from our interviews was how difficult it was to schedule practices — so we decided to create a feature where you manage your availabilities and when creating an event/practice, it takes everyone’s availability into consideration to suggest practice times. This would alleviate the biggest pain point for organizers.

After many iterations, we added and removed many features, and finally focused our scope on just performers, our features focused on removing the bottlenecks for performers to get together, practice and host events.

High fidelity prototypes and evaluation

For the high fidelity prototype, our team decided to work with Adobe XD. We experimented between Adobe and InVision during class, and we found that Adobe was easier to work with and fit the needs of the project more. Our main goal for the high fidelity prototype was to confirm that the color scheme and design choices we chose for our app gave it a simplistic and approachable atmosphere. We also wanted to consolidate the three features we decided to create: profile creation and editing, event creation and editing, and messaging.

In terms of Jakob Nielsen’s heuristics, we decided to evaluate our app using heuristics 2 (match between system and real world), 3 (user control and freedom), 4 (consistency and standards), 7 (flexibility and efficiency of use), and 8 (aesthetic and minimalist design). We found these 5 heuristics to make the most sense given our design focus and app purpose. For heuristic 2, we had previously assumed that users would appreciate having UI elements familiar to them, (e.g. maps similar to Google Maps or communication similar to Facebook Messenger). While this assumption was true, from testing feedback, we realized that groupings in our events and messaging sections were inconsistent. For heuristic 3, based on feedback provided from testing, we found that we didn’t support enough options for location selection and the process for inviting people was convoluted. However, adding the ability to go back whenever the user wanted, and the ability to add and remove items was appreciated. For heuristic 4, we had received feedback that there were inconsistencies in icons and functionality in our app. We were able to fix this in our high-fidelity prototype and avoid confusion. We were also told that time selection for availability was not consistent and was confusing to use. For heuristic 7, we found that we wanted to make accessing and editing events and schedules as easy as possible. This followed the heuristic as our goal was to make the app flexible and easy to use. However, the main feedback we got for this heuristic was to make buttons bigger, as our prototype was hard to click in some areas. Lastly, in the early stages of design for our high fidelity prototype, we had decided on a simplistic, friendly theme that doesn’t overwhelm the user. This was based on previous feedback from our buddy team and follows the guideline of heuristic 8. We also got feedback on the high fidelity prototype testing that our app was indeed clear and easy to use.

Our team decided to create a cognitive walkthrough that went through each major portion of our app. The first walkthrough involved the profile creation and editing process. We asked the user to add an interest in rock music to their profile and edit their availability. The major feedback from this process was that the other add button and confirm button were confusing, and that the edit availability button was too small. The second walkthrough asked the user to create a new event, modify some details of the event, and to invite additional members to the event. The main feedback for this was that the color scheme was inconsistent and closing the location selector was unintuitive. The final walkthrough was to send a file to a dance group and to verify that it was sent successfully. Feedback for this process was mostly positive, though needing to confirm twice to send the file was brought up. Overall, feedback was mostly positive, and users thought our app was easy and intuitive to use. They also felt the app’s theme was friendly and simplistic, which was one of our main goals.

Based on our high-fidelity prototype evaluation, we found that we had received mostly positive feedback. The main concern of our testers was that there were inconsistencies through the app that made certain buttons and functionalities unintuitive. Some users also found buttons were hard to click. The main changes that we made were to enlarge said buttons, as well as make the related areas clickable as well. For example, instead of just having an edit availabilities button, we would also make the calendar clickable, which would take the user to the editing page. Another change that we made was to allow events to be deleted without having to edit the event. Overall, the design changes we made were small and mostly to address individual concerns. Our high-fidelity prototype was well received by our testers.

Final Artifacts


All-in-all, our team learned a great amount throughout this term. We began as five computer science students with little expertise with human-computer interaction and design, as well as negligible knowledge about the pop-up performance space. However, as the term progressed we were able to grow together by merging the content from class, the information retrieved from interviews, and the feedback obtained through testing to continually improve our product to the state it’s in today.

Regardless of whether or not we will be continuing on working specifically in HCI either in graduate school or industry, we obtained perspective, skills, and knowledge which will be invaluable when assessing any product or feature we may find ourselves working on in the future.