Ultra Competitive Sports Division

Intro

UCSD: an app that brings the audience together in every game. Our goal is to facilitate interest and get the crowd even more excited about the game.

The Prompt

Our team of four was tasked with creating a novel social computing experience that was both synchronous and co-located. In other words, not only would we have to create an experience that causes our users to interact with each other in a unique way, we were limited in our scope to creating a product that was to be used with others at the same time in the same location. Furthermore, this task was exacerbated by the fact that we only had 5 weeks to create a final version with two iterations of rapid prototypes.

Our Chosen Project Theme

Sporting Events

How might we create social connections between fans?

How might we create interactions that revolve around actions in the sporting event (i.e., a touchdown or strikeout)?

Needfinding and Research

In the initial stages of our project, we had to pick a field from several different contexts - education, sporting events, concerts / plays, town hall meetings, creative collaborations, gaming meetups, and corporate meetings - in order to focus our creation on a singular objective. We started off by exploring the space of sports games. We performed interviews from people of various sporting backgrounds, ranging from audience members to student athletes.

Observations and Interviews

In order to find a gap - a space in which our product could facilitate more interaction or smoother transition - our team conducted several interviews with sports audience members of various knowledge levels and observed sports games within our viable time period and area. Additionally, we also created observations both from watching a local, college-level baseball game and from watching clips of sports games online. We did this because we wanted to see the interactions that would naturally come about within the audience members during a real game. However, we also wanted to watch clips of sports games online to see the different interactions from a wider range of sports. Furthermore, we wanted to compare and contrast the types of interactions that comes about during higher legure sports games. As a result, we decided to limit our scope to creating an app to be used by audience members of a game in order to enhance their in-game experience.

Competitive Analysis

On top of scouring the internet to familiarize ourselves in sporting events, we also performed secondary research that composed of our competitive analysis and design space to see if there was an unfulfilled need within the scope of real-time, co-located apps to be used during sports games. Ultimately, we did choose to create an interactive application for sporting events as we felt that of the possible contexts, this area was of high, normally unexplored interest in social interaction and technology.

After doing this, we decided to divide the workload in our team based on preference and level of knowledge. We creates roles and made a development plan to help keep our team on track and our members accountable.

Aaron was tasked with being our Sports Researcher who would primarily do work with researching sport games and ultimately help to give our prototype some needed context.
Evelyn volunteered to be the Presentation Manager, someone who helped with quality control of all our prototypes and presentation.
June decided to be the User Research Expert who would focus on helping to create survey, interview, and prototype observation questions to gather user research.
Wayne was tasked with being the User Analysis expert who helped to lead the recruiting process of testing our prototypes, analyzing feedback from our prototypes, and leading prototype iteration discussions.

With this division in mind, we set on to rapid prototyping.

Prototype 1

While creating our prototype, we also had to consider the many constraints we had in designing our first iteration. Our most pressing was our small audience within testing of less than 20 people who all had, from what we could tell, minimal sports knowledge. As a result, we worked to ensure strongly-engaged participation with minimal incentive by providing entertainment without distraction on our question topics, adding clips to build background, and offering a small reward of candy as incentive.

Following, we debated several methods about which to go about making a low-fidelity prototype for testing. Given our limited resources and the fact that this was only our first prototype, we decided on utilizing Google Slides, Sheets, and Survey. The prototype would be mostly done through google slides where we would show clips of the game and ask trivia questions to audience members

After feedback from our class TAs, we pivoted and debated what other platform to facilitate interactions in as a piggyback prototype. One suggestion was using Facebook Live (see left image above) to encourage reactions from our audience. However, we ultimately decided to not utilize the platform for its lack of intuitive usability. Instead, we utilized Facebook Messenger which has a better chat integration and we could use reacts as a way to engage the audience

Feedback & Iterating (from Prototype 1 to 2)

After our first presentation, we discovered that our largest issue was the target audience and our available testing audience; a majority of our pool of testers had minimal interest in sports, which affected their knowledge on the topic. In addition, we also found that the audience was greatly confused and near resentful of the higher level questions, which had been created for a more knowledgeable audience. As it turns out, our estimate on their sports knowledge was even less than we had anticipated and, as a result, skewed our results.

Prototype 2

We started off by going back to our original goal: creating an app to be used during a sports game which would enable social interaction within the audience and further engage users in the game. Then, we analyzed each component of the prototype and asked ourselves, “How does this encourage social interaction?” Firstly, we decided to curate easier questions for our audience, as we had seen from our previous prototype that they had less basketball knowledge than our usergroup, sports fans in an arena. Furthermore, we decided to add a component of hint-giving to help our users and added gifs to make the gameplay more fun and engaging.

Another idea was to utilize Facebook Events instead of a Facebook Group Chat. This was done for 2 major reasons. The first is that we had an added constraint of prototyping for 100 people rather than 20. Because we were now prototyping with a classroom setting, it would be hard to friend and add every classmate to the group chat. The second major reason was that we theorized that having a commenting feature would lead to more social interactions between our users. For example, they could leave hints or commentary on our app as well as the game itself

More Feedback from Prototype 2

Sketches and Wireframing

The wireframes were reflective on our intended functionality of our initial prototype. We started off by creating sketches of some of the features we wanted to implement.

Afterwards, we had a meeting in which we chose the screens we wanted to include in our app. Before doing this, we all had slightly different ideas about the the way each person would interact with the app. As a result, we had a conversation in which we talked about each of the screens we created, one by one. We compared each version of the screen and had an open conversation in which we discussed why a screen would or would not work for our app. Ultimately, this helped us do two things. The first is that it allowed us, as a team, to be on the same page with how we wanted our app to look and function. The second is that it caused us to have to justify our design decisions and reflect on why we should or should not included a feature.

The next step in our process was to create high-fidelity wireframes so that both we and our audience could have a better grasp of how the app would function.

Results, Reformation, & Our Final Prototype

From our prototyping session we found a few key insights. The first was that our audience really enjoyed the integration of gifs with our prototype; they found the questions to be more entertaining. Another was that there was a decent amount of in-prototype socialization as a good amount of users commented. One thing we struggled with during our first prototype was having audience members interact with each other, so it was good to see that there was this change. Conversely, we found that Facebook events may not be the best platform as there were many technical issues getting to the site. Perhaps, creating an actual app or website would prevent this issue from recurring.

Future Work

Upon further analysis of our results and comparison with legitimate sports games, the success of our product is dubious considering the disparity of forced participation in our testing setting and the fast pace that preludes all decisions. Although certain aspects - trivia questions, for instance - seemed to appeal to the stronger sports fans within our testing pool, the other aspects appealed to more novice sports fans - such as the reactions to plays. This difference in opinion suggests either that our application can appeal to audiences of varying sports knowledge levels or that it may appeal to neither.

As a result, our confidence in the viability of our prototype cannot be confirmed without further research in a more realistic setting, preferably with a large audience of various sports knowledges and prior practice with the fast pace of the sports game in conjunction with our application. Furthermore, more testing would have to be done to see if the change in the purpose of our app have would have a difference in the interactions and feedback we receive from our testers. Additionally, we would like to test the integration of a customizable avatar as well as a point system to see the effect these things would have on the engagement of users.

If this goes well, the next step would be to create an actual app. This app could then be tested to get more realistic interactions from our testers. We would have a better sense of how exactly the app would be used and which features we should or should not integrate. Doing this would also mitigate any of the technical issues we had in both prototyping sessions from getting users onto the prototype itself as the process would be more straightforward.

Reflection

Overall, it’s been an extremely fast-paced five weeks. We’ve gone through the whole double diamond process of design and constantly refined and iterated on our prototype. We’ve learned how to work and communicate effectively as a team. We’ve learned how to divide labor and interpret prototype feedback. Honestly, we’ve learned a lot. Nevertheless, the most important thing we’ve learned is that sometimes things don’t go as planned and that’s all right. Neither of the prototyping sessions had the results we were aiming for. We also had issues with timing for both sessions. Despite this, the experience taught us a great deal about how to design effectively and that the path to success is not always a linear one.

That concludes our project! Thank for taking the time and consideration to skim or read through our work!