Basic Design Scenario
I am working for a start-up developing a new real-time sports app for the Apple watch that shares automatically your score such as your number of shot hoop when you play basketball and let you simultaneously compete with other players without being at the same physical location. It also will contain features in-app to simplify contacting other players who are in the same neighborhood to schedule a spontaneous game. The company has six employees from which one are part of my design team. The financial resources are limited that also leads to high time pressure. The problem I am trying to solve is how the app can track a player’s score without the necessary interaction or input of the player.
Good method of prototyping: True Programming
Why? - Since the user is going to use the app on its apple watch and is not going to further interact with the app while playing basketball, we need to figure out how the app tracks and displays the correct score. The core functionality we are designing for is the capture of a shot hoop. The prototype has to work almost like the actual app that we are going to sell to our customers. Furthermore, it requires tests in-person at the basketball court, because we have to think through what the optimal way is to track the score, if possible, without any additional devices, flawless, and without having the user counting and typing the result into the app. True Programming can be very expensive for a start-up with limited financial resources, but we are collecting more investments by let the investors experience our first prototype.
Poor method of prototyping: Storyboarding
Why? – The storyboarding just helps us to understand how the user interacts with the app but does not provide any further information on how the app tracks the score. The core functionality such as ‘press start button to start a game’ or ‘find my location to connect me with other available players’ are conceptual pieces of a user’s understanding and have been taught in a very similar way by interacting with Google Maps. Moreover, these user interactions are not as important as the functionality between the app and the ball as well as the basketball hoop. Functionality is more important than the user understandings because we are going to use familiar user interfaces from other fitness apps.
Good method of evaluation: Heuristic Evaluation
Why? – The heuristic evaluation works best for our design because it requires real users who will test our prototype. Hereby, our goal is to come up with complications we have not thought of and that we need to solve to provide a joyful experience while using this app. It also should give us insights of the quality of the tracker, easy usability, and its proof of counting correctly. We are concerned with the direct usability evaluation.
Poor method of evaluation: Cognitive Walkthrough
Why? – The user’s task of shooting hoops is straightforward. The cognitive walkthrough would not serve the purpose of evaluation. The evaluation method has to provide knowledge about the truly thinking and acting of the user on the basketball court. We are certain that we will not discover user behavior we have not thought of with this method.