• Created by Unknown User (abw333@mit.edu), last modified by Unknown User (mpolanco@mit.edu) on Mar 03, 2013 23:18

Project Home

Observations & Interviews

          Mr. W (Recorder)
  • given the medium in which stats are currently recorded (which requires drawing pictures to represent the direction of the volley) he suggested a tablet interface would be good for recording. He noted, however, that to encompass all the types of hits and errors that might occur within a volley might require more than what could fit on a single screen
  • the limiting factor in taking stats is the person's ability to pay attention/process to all the events occurring 
  • typically four people record (depending on the detail of stats desired). Creating a more efficient interface could reduce this number
  • it is crucial to have some statistics within the game. For in-game analytics during a high level game, having two people recording stats is minimal
  • typically the same people take stats
  • taking stats is dependent on the recorder's knowledge level 
  • storage and recall of information from previous games is hardly accessible
  • only "Box Score" is saved digitally. No other stats are entered
  • stats determine HOW a group won. A coach looks at this to determine how a group beat another, and what to have their team improve on and who to put into the 
    Mr. O (Player)
  • hitter tendencies are really important (where does each hitter hit)
  • may decide to move players around based on hitting tendencies
  • some players feel that the stats that are currently kept don't tell as complete of a story as the tape of a game
  • there are some stats that should be recorded but aren't
  • some players keep track of their stats in their head during the game!
  • lot of information exchange between coaches and the team, even between points
  • raw stats have little impact on choosing starting rotations
  • using paper doesn't slow down decision making at match time, but it's difficult to store stats and aggregate them over many games
  • would be great to have the opposing team's positional tendencies to find their defensive holes
    Mr. G (Recorder)
  • showed us examples of the sheets used to record statistics
  • a lot of time is dedicated to keeping track of where and how well each player hits each shot
  • also maintain basic stats such as attempts, errors, kills, blocks, passes, digs, etc.
    Mr. M (Coach)
  • "...none of the commercially available platforms seem to do everything I would want as a coach, so if you're open to input, I have tons and tons of things on the wishlist..."

User Classes

Recorder - keeps track of stats during a match
Coach - analyzes stats to create strategies both during and after a match
Player - gets his/her stats recorded and is directly affected by the decisions they lead to

Needs & Goals

          Recorder
  • efficiently keep track of various statistics during a match
  • record statistics that provide good context about what is going on
    Coach
  • analyze stats during a match to dynamically devise play strategies
  • maintain stats over multiple games to develop more long term plans
    Player
  • know what areas they could improve in
  • coordinate statistics with game footage
  • No labels

1 Comment

  1. Unknown User (jks@mit.edu)

    Overall: You have a well-defined problem and presented your needfinding really well in studio, but your write-up was not nearly thoughtful enough. In order to design a system, you need organized thoughts about what the user concretely has to do. Maybe you have these organized thoughts, but you didn't communicate them well in this write-up. For example, you learned that the recorder has to efficiently maintain lots of real-time stats like attempts, errors, kills, blocks, etc. You need to:

    1. Enumerate these stats
    2. Define each stat and understand how it's currently recorded
    3. Understand how the stat is used either in-game or over the course of multiple games by the players and/or by the coach
      We should talk about limiting the scope of your project, if it feels like there's too much to tackle.

    Specific comments:

    • Problem Statement: 
      • Way too concise. You need to describe the problem in more detail - discuss briefly why this is a problem in terms of user goals and obstacles. 
    • User Analysis:
      • Good division of user classes, but you haven't described their characteristics at all. Similar to the very brief problem statement, you need to be more thoughtful here. 
    • Needs/Goals Analysis:
      • Good high-level tasks, but you need to be more thoughtful here.
      • For example, there's a lot of mention about context here, something that isn't supported well by your interviews. Elaborate! 
    • Interviews/Observation:
      • Interviews need proofreading (e.g. last point for Mr. W) and more thoughtful explanation (only Box Score saved, no other stats entered? Do you mean automatically vs. what the stat taker has to do?)
      • You say second recorder showed you examples of sheets used for recording stats - pictures of these should be in your write-up!
      • Recorder interviews seem fruitful - half the problem is recording the stats. The other half of the problem is using the stats, which you seem to have learned very little about.
      • The coach interview is really week - did you actually interview him? You need to understand concrete examples of how stats are used by the coaches. 
    • Wiki Presentation:
      • Need to give more background on volleyball statistics. This could be part of the problem statement, it could also be a preamble leading up to the user interviews. I don't know what the exact definition of a hit, error or volley is.