Fight Me was created with the main objective of allowing our users the ability to make new friends, and jump right into riveting and engaging gameplay all the while maintaining a form of communication through our application. Our previous sprint left us with a rich amount of information, how easy our interface is to navigate, which features were important, and which features to prioritize. The focus for this sprint is to be able to use user feedback to help further develop the application’s features compared to our first sprint where we created just the interface.
2 external evaluators (n=2) conducted cognitive walkthroughs using the wireframes we created. Pretending that they were one of the personas we created in phase I, the evaluators navigated the wireframes in order to accomplish the task outlined by the persona's accompanying scenario. The first picked Trevor Galloway as the persona and Trevor Relaxes With Electronic Chores as the scenario while the other picked the Joe Dane persona with the Ice Breaker With Doe Scenario. The first evaluator documented their walkthrough in Congestive Walkthrough while the other documented theirs in Cognitive Walkthrough.
In order to receive informal feedback, the software engineering team asked questions to an audience of 65 people (n=65) during a demonstration of the product. The questions that we provided were:
- Would you (The User) prefer to train one core player stat, or multiple?
- Would you (The User) like to be able to create a "Chat group" and compete against other groups?
- Would you prefer idle games, forums that contribute to stats, or both?
- Should we include profile pictures, or should users be solely represented by their avatar?
- What is an acceptable amount of gambling/gacha features?
The notes of the feedback were documented in Fight me demo feedback.
The Trevor evaluator was able to navigate from the home screen to the chats page to a chat room to the outcome of a fight without too much trouble. However, he struggled to figure out how to enter the battle, which means that the fight button at the top of the chat page is not discernable enough from a title widget. The fact that he thought that he could access the chats page through the VS button means that it can be used to keep track of chats that currently have a fight going on. This can help later on, because we are still not sure how the dashboard should truly be set up and what the fourth page in the navigation bar should be. The Doe evaluator similarly struggled with the navigation bar being unlabeled. He makes note that while the button to a chat room isn't labeled, there is enough of a standard with chatboxes that most people will understand clicking on the chatbox sends them to the chat room. However, he states the layout of the text field and the arrow at the bottom of the chat room are well placed enough to require no labeling. While he correctly surmises that the fight button is the way to access a fight, he does comment that it is potentially confusing. Once he is finished with a battle, he correctly chooses "Ok" to close the window, but he does not see a way to leave the chat room. This is simply a matter of us forgetting to include the back button when we transferred the wireframes to one page.
The first and second questions revealed that users would want multiple trainable scores and group chat functionality. The third question revealed that the games that are incorporated should be active rather than idle, because the focus of the entire application is maintaining conversations and connections. The last question showed that there is a potential to incorporate a shop or gambling features with avatars as the products.
Cognitive Walkthrough has allowed us to gain valuable insight on how clear our interface was for our personas to accomplish their goals using our application, such as chatting with friends. We were able to identify what vague or obscure features of our application needed to be made clearer, resulting in a simpler approach towards designing our interface so that users were able to clearly identify how to interact with our app. It is important that users are able to navigate our application even with a limited amount of aesthetics such as pictures and colors, so we made sure to reduce the number of unnecessary transitions. From our informal feedback, there was a lot of information regarding what features our application should be achieving. However, there was also a lot of contradictory information, so we had to pick one of the choices to commit to. Elias of the software engineering team specifically had the idea that there should be no negative reinforcement with messaging, since the intention of the app is to make connecting more fun. As such, rather than taking away points, more points are awarded when responding in a certain time frame.
The wireframes used did not fully capture the visual complexity or interactive elements of the app we had envisioned. This limitation led to some user confusion, as the wireframes lacked alignment with the envisioned app’s design and functionality. Adjusting or expanding the wireframes to better represent the actual app may help alleviate this issue in the future. Limitations arose in the cognitive walkthrough method, which depended heavily on the same wireframes. Given the app’s emphasis on visual interaction, users may not have effectively understood its intended functionality through this approach. Implementing scenarios that address key visual and interactive elements may enable users to better understand core features and provide more relevant feedback. Furthermore, the study included only two cognitive walkthroughs covering two scenarios, which we in turn had only one of per persona. Conducting additional walkthroughs with a broader range of scenarios would likely allow for a more thorough evaluation of the app’s usability. Finally, feedback collected from demo sessions revealed conflicting opinions among users regarding certain features and functionalities. While some users requested specific features, others expressed preference for alternatives, leading to inconsistent feedback. A larger and more segmented user base may help clarify feature preferences and inform design decisions based on specific user groups. In short, addressing these limitations in subsequent studies would enhance the accuracy and applicability of our findings and conclusions.