This was a unique project in that the ultimate product was the data being sent to the client. That data however was being generated by in-stadium scouts using the proposed collection software. So while the client did not care about the collection software per se, it did need to be designed to allow the scouts to deliver the data quickly and accurately. The project would require both feedback and testing of the collection software with scouts as well as feedback and testing of the data feed with the client.
What are the constraints?
- Unsanctioned operation
- Mobile web only
- Mobile network connectivity
- Limited testing conditions due to live nature
- Inexperienced scouts
- Single scout situations
- Unsynced & independent data feeds between 2 scouts (discovered later on)
What are the requirements?
The client provided an initial outline of necessary data points which we sorted into three types (Game State, Result, and Feed) and also prioritized from Tier A to D. More important data points would be prioritized in the UX/UI to ensure they were faster and more accurate. For context there were roughly 35 Game State, 20 Result, and 4 Feed data points in our initial list.
Data points were then divided between the two scouts with one responsible for the score, clock, and timeouts and the other responsible for the play-by-play action. These were referred to as the Clock Scout and the Game Scout from this point onwards.
How will the user move through the collection software?
Football unfolds in a very step-by-step fashion in terms of relevant data points (ie we are not concerned with Blown Blocks or non-targeted receivers). My thinking was to map out every possible path a game could take in the style of a choose-your-own-adventure book. Using FigJam, I mapped out these User Flows to determine which options would be necessary for the user to have at their disposal in a given situation. Showing only relevant options maximized the screen space to allow for better usability and reduced errors.