Scenario
The MIT men's varsity volleyball team has a big game coming up against Harvard. We have statistics regarding each team and these allow the MIT coaches to develop some strategies. However, previously unobserved tendencies are likely to arise during the match. Assistant coaches need to efficiently record what is going on during the game and analyze this data so that the coach can make important tactical decisions. They will use SETistics, which will allow them to effectively maintain and visualize gameplay data. This is an extremely valuable resource as the coaches decide what strategic shifts they should make during the game in order to maximize chances of winning. After the match is over, the recorded statistics may be used to develop tactics for future play.
Design Sketches
One possibility for stat recording is to build a command line tool. Once users know how it works, they can be extremely fast at inputting data. As shown in the picture, there are commands to start recording for a new game, to add the information about a shot, and to view the highest scoring players. In a real version, there would also be commands to undo and to view aggregate stats over many games.
This interface is designed mainly for a tablet. There is a diagram of the court that includes the players that are currently in the match or on bench. Their position on the court indicates from where they hit their last shot. When a new shot is made, the user can drag the appropriate player to the hitting location, double tap to select that player, draw a line indicating the direction of the shot, input more information about the shot, and submit. A table that keeps track of top players is dynamically maintained. Additionally, as the game progresses, a heat map will be drawn on the court to indicate the locations at which shots are frequently made. It was only drawn on one side for clarity.
This interface is designed for a small screen. There is not enough space to keep a large court with each player's position, so a small court is kept instead. When a player makes a shot, that player can be selected from the scroll menus for each time and information can be input about the shot.
This interface is focused on improving efficiency by being able to record the information about one shot with a simple swipe. In the drawing, player 7 made a block touch that went out of bounds.
This interface seeks to provide as much context as possible for each recorded shot. The screen is taken up by a live video of the match. Whenever a shot is made, the recorder can tap on the location of the shot, input some more data about it, and submit it.
This interface tries to improve efficiency by allowing the recorder to input data through voice commands. On the screen, the best guess about what the voice command said will appear, and the user can make edits to it before submitting just in case the application did not correctly interpret what was said.
This interface attempts to take advantage of drawing as a potential input tool. Whenever a shot is made, the corresponding player can be selected from the numbered boxes, the direction of the shot can be drawn on the court, and more information about the shot, such as what type of shot it was, can be drawn into the drawing boxes. When a substitution is to be made, the user can long press on a player to reveal a pop up menu of players that could replace the outgoing player.
This interface focuses on allowing the user to efficiently input shot data while receiving visual feedback about what has been done. In the sketch, an ace is being input, as can be seen on the diagram at the top, and the menu at the bottom allows for selection of the player who made the shot. After this is done, more data about the shot, such as how much power went into it, can be input.
This interface focuses on a fusion between a command line approach and a drawing approach. Information about shots can be input into the text field at the bottom and their direction can be drawn onto the onscreen court. After shots are input into the system, they go into one of the rows on the right side of the screen. If an error was made, the user can cancel that entry and redo it. Furthermore, a video of the game is being kept, as shown in the top left corner of the screen. This allows for each shot that is input to be mapped to a portion of the video, which allows users to better contextualize the recorded statistics.
Storyboard Designs 
The game is underway and the next serve goes to MIT’s number 50. As soon as the ball leaves his hands, the recorder is already halfway done recording the hit, entering the command representing the unsuccessful serve out of the court’s bounds on Harvard’s end. As soon as he begins typing, the controller interprets his instruction, updating the display of the translated command into its real-time visualization next to the command prompt. Finishing his command, he presses enter to add the translated statistic to the command stack and starts preparing for the next serve. An issue has come up, however: in the process of inserting commands the user didn’t realize that Harvard’s server was the player responsible for serving the previous out of bounds case. Thanks to the slightly delayed display of the game (as recorded via the user’s external camera) the user notices the discrepancy and presses the F4 key to edit the corresponding value in the command stack. As soon as he hits enter, focus returns back to the command prompt, allowing him continue tying efficiently and record the stats.
- Learnability: While this design excels in its efficiency, it lacks in its learnability. The learning curve for understanding and recalling each of the commands is high, requiring the user to have an extensive knowledge about volleyball and a strong familiarity with the interface and its commands. To address this, an Information section is to be included, providing a tutorial on how to use the interface and documentation of the commands and their parameters.
- Efficiency: In designing these interfaces it is crucial that they be efficient given the pace of the game. This design has the potential to be one of the most efficient and is based on current implementations. As a command interface, this design focuses on cutting the time it takes to record a play, abbreviating statistics such as “kill” or “block” with one or two letter representations.
- Safety: Given the amount of statistics being recorded at such a high pace, the possibility of the user making mistakes is unavoidable. This design attempts to apply preventative safety measures by displaying the translation of the command in real time to the right of the command line (circled images displaying a visual representation of what has been typed). In the instance that a mistake is made despite this the user has one of two options: they can press a function key/double click on a cell to edit it with minimal loss of efficiency, or they can click on the cell to mark it as incorrect. In the instance that the user misses a necessary stat, they can use video footage as a reference to what recently occurred.
MIT's player 1 just hit a powerful crosscourt spike and Harvard's player 98 was totally helpless. The stat recorder selects player 1 to indicate that a shot by that player will be entered. Then, the recorder can draw the ball's trajectory on the onscreen court and make other drawings on the pad in the top right corner to indicate, that this shot was a spike hit with considerable power that landed on the ground before any of Harvard's players could get their hands on it. As these data points are entered, icons appear in the top left corner to indicate the features of the shot that is currently being input. If a mistake is made while drawing, the recorder can easily clear out either the current drawing or one of the already processed icons. At the end of this point, the Harvard coach decides to take out player 98 from the game because he is performing poorly. Long-pressing on his square brings up a menu where the recorder can select the player that will be replacing player 98 on the court.
- Learnability: This interface was designed with efficiency as the primary consideration, so a few sacrifices had to be made in terms of learnability. It is pretty intuitive to press the current player and draw the trajectory on the onscreen volleyball court, but it will be difficult for users to remember the different types of drawings that they can make to input data about shots. In order to address this issue, users will be able to configure the system to change the default drawings if they feel that something else feels more natural for them. Also, it is not immediately obvious that a player must be long-pressed to input information about a substitution, and it is likely that this method will change in future iterations of the design.
- Efficiency: It is of paramount importance that this interface is efficient due to the fast pace of volleyball games. This design has the potential to be one of the most efficient because it only takes a few button presses and quick drawings to record a shot. These drawings are to be made extremely simple so that a recorder can input them in as little time as possible.
- Safety: Since the recorder will be inputting data at such a rapid pace, it is highly likely that errors will be made. If a wrong player is ever selected, the user can simply select another player. If the recorder makes a mistake while drawing, he can either clear the drawing or clear the icon that appeared in response to the drawing, depending on whether the system had already processed the drawing. As this design currently stands, however, there is no way to undo a statistic once it has already been submitted. One possible way of fixing this is to display the most recently entered shots and allow the recorder to edit any of them if a mistake was made.