This project was created to provide messengers an easy activity to launch and cultivate so that they don’t have to rely on just speaking to people or having an activity already in mind. As such, we focused on designing a game that is feasible for college students to be capable of making in 14 weeks. We focused on the layout of the parts that aren’t the chat rooms–because standards for that layout are already well established–and how someone can still participate in the app even if they’re too low level to beat anyone else in a fight.
The selected competitors for the competitive analysis are: Discord, which is primarily used for people who already have an activity chosen/purchased; SnapChat as it’s a messaging app that has a score that increases by talking to people; and Pokemon Go, because it’s a mobile video game predicated on going outside and meeting people to battle. The method of figuring out our competitors was picking the first applications that came to mind, with the exception of SnapChat. That was determined because that was how the software engineering team thought to describe the minimum viable product: SnapChat, but you use the SnapScore to fight people. We would then use Google to determine different aspects of the products we didn’t know on hand, like whether or not SnapChat could be run on Linux. Our method of determining demographics started with us ourselves being users or former users of the apps and estimating based on our experiences of other users. We then adjusted for other factors, like the game being a dedicated feature.
Through Heuristic Evaluation we were able to score and identify key areas that our competitors both excel and struggle in. This was done in order to help guide what areas of our program we could focus in order to make it stand out more compared to similar competitors in the market. The heuristics that we used for the evaluation were: visibility of system status; match between the system & the real world; user control & freedom; consistency & standards; error prevention; recognition rather than recall; flexibility & efficiency of use; Aesthetic & minimalist design; Help Users Recognize, diagnose, and recover from errors; and help & documentation. The definition of each was based on this Article by NNGroup. Discord met our criteria, because it was the one we all had access to. Desktop and mobile versions of Discord were evaluated separately because the different layouts of the versions mean that the quality of the heuristics would vary. The final score was then based on an average of the two traits. Our time with the app once again contributed to grading, but actual experiments conducted for the evaluation were leaving the cursor of an icon on desktop and long pressing them on mobile to see if it would display a hint for it, opening the official help guide at Discord Support to inspect its documentation, and inspecting the layout of server customization. The unfriending and blocking of a team researcher was even conducted to test the user control and freedom.
With competitive analysis, we found that our competitors are free, but do have premium services. Discord and SnapChat excel in being messaging apps–with discord being more geared towards intuitive design and large scale communication and SnapChat having a bigger focus on photo sharing and temporary conversations–while Pokemon Go excels at being a sociable game. However, Pokemon Go lacks a chat function and SnapChat doesn’t have much in the way of games or any usage of its SnapScore. Discord has the capacity for games, but it’s all third party that has to be manually set up and consented to or requires purchasing Discord’s premium service, Nitro. All in all, we determined that our demographic would be teenagers with a predisposition towards video games.
Discord gave the user a plethora of customizations but most were locked behind Nitro or were rather too complex and had to be found through trial & error for their users. This allows us to better simplify our application and reduce the complexity since we want to give our users the comfort of personalization without forcing them to learn or remember shortcuts all the while enjoying the game. It curiously doesn't give any warnings for unfriending or blocking someone, an action that could only be reversed if the user unblocks, sends another friend request, and the secound party accepts it. There is significantly less user inferface navigation assitance on mobile than there is on desktop. Given the higher importance mobile usage and keeping a friend would have for Fight Me, we should put more security for unfriending someone and more support for mobile. For a final example Snapchat, has award based features for milestones and goals but aren’t fully implemented since the real focus is towards a more photo centric style of messaging. Thus we can use Snapchat’s evaluation to learn how we can improve from it and potentially make our application just as appealing if not more. Such as through a similar implementation of features to have more of a game orientation without third party dependencies and permissions to bring in more users through familiarity of other platforms.
Rather than trying to be the best messaging app or the best video game app, our focus should be a succinct and nonintrusive union of the two. Our methods led to the use of Personas & Scenarios to develop various “users” that would be interested in our application from our target demographic that was gleaned from our competitive analysis. With this in mind the Personas were modeled after a mixture of messaging app users and video game chat apps, in order to effectively provide accurate functionality from both. Thus the personas stemmed from a variety of backgrounds to ensure that we would have a healthy selection of potential users since we don’t have access to real users. So we created personas based on highschool students and college students with a small mix of average working class people. This helped flush out the Scenarios to identify the key features that users would be interacting with in our application. Thus we were able to help create real life examples and conceptualize the interactions between our users throughout the development process, slowly converting it from theory. In order to achieve this and better understand/visualize the features and functionality of our application, we used sketches and diagrams.
By using them, we were able to visualize the features and functionality of our application. Sketching out user stories helped us understand what kind of scenarios our users would encounter and how our application would serve a purpose in improving their situation, such as trying to make new friends at a new university. The diagrams of our application proved to be a great way to see how our application would look and perform from a user’s perspective. Having visuals for our concepts through hand-drawn diagrams showcased to us the strengths and weaknesses of our application, which helped us brainstorm on what we could do to improve the user experience of our application. Furthermore, we were able to learn how certain functionalities related to each other in the application and what kind of actions led to other actions in a logical flow, which also made it clear what kind of actions we had to adjust.
As we had no access to real users, we weren’t able to reliably gauge which age groups would actually take interest in this product. The creator of the idea not actually being on either the software engineering or usability engineering team was both a blessing and a curse, as we had to ascribe the need to fill independent of the original purpose, but it also gave us a lot more leeway to work with as the original vision could have gone beyond what is possible here. We had planned on using SnapChat for the heuristic evaluation, since it would have been the most similar application to our minimal viable product with its SnapScore, but we didn’t have access to it.