As a group project for an information visualization course we were tasked with developing an InfoVis and we could use any data set. I chose MLB stats because of its inherent statistical nature of the sport, as well as the challenges and limitations of current solutions of displaying immense amounts of baseball statistics.
We analyzed current solutions and user needs, to create our solution goals. With current solutions, when a user wants to understand a hitter's performance or value they often search through multiple pages of data tables. This becomes even more difficult when users want to answer more complex relational questions such as a player’s performance in context with the history of baseball, or the relationship between hitter and team performance. Our goal was to create a solution that simplifies this processes and allow the user to retrieve insights on a simple single-page interactive InfoVis.
The other two team members were M.S. Computer Science so I was responsible for the design and they led the development. I went through multiple iterations of design prototypes from paper to high-fidelity, incorporating feedback on each iteration.
I chose the topic of visualizing MLB statistics because baseball is one of the most statistics-laden sports because of its relatively additive nature (individual player contribution can be well separated), large sample size (500+ at-bats for a starting player during the season), and a long tradition of applying statistics, concepts and tools. As a result, baseball statistics are not only of interest for the analytic departments of professional teams, but also widely popular among the fans. The immense available data set consists of over 6000 plate appearances by hitters for each team per season dating back to 1901. This presents an interesting challenge of displaying all of this data in unique and usable ways to help users gain a better understanding of statistics and performance for players and teams, and this challenge excited me.
The purpose of the course project was to develop an InfoVis using D3, this meant there was little opportunity in our timeline for me to employ user research methods in order to better understand the problem and the users.
Another challenge was our group was supposed to be 4-6 members, but I could only recruit 2 other members so we had to do more work per person in order to satisfy the project requirements.
Both of my teammates were from China, one did his undergrad in the US and had a good understanding of baseball. The other, did not know anything about baseball so that presented a challenge.
|Type||Group Class Project|
|Class||CS 7450 Information Visualization|
|Tools Used||Balsamiq, Sketch, D3|
UX Research, UX Design, Front-end Dev, Video
Member 2M.S. CS
Finding data, D3 Programming, Front-end Dev
Member 2M.S. CS
D3 Programming, Data analyzing, Database
Many people love baseball because of its inherent statistical characteristics. However, most of the time the practice of statistical inquiries of the fans are still limited to looking a spreadsheets with tables of hundreds of values, and it takes efforts to figure out patterns or trends. Even in the best internet resources of interesting baseball analytics (Fangraphs, Hardball Times, 538, etc.) where visualizations are often included, the figures are often of simple forms such as scatter plots or bar charts. Existing solutions are rarely interactive, and often presented in views that are independent with each other.
Our project can be seen as an attempt at extending the conventional designs to convey richer information on a single view, while maintaining the information saliency of the simple designs which allow users to quickly figure out answers to interesting questions.
For this purpose, we choose to focus on the temporal dimension and to enable visual exploration of the history of MLB, highlighting individual player performance/development, team performance, and the relation between the two. Temporal patterns in these aspects are especially difficult to see with traditional methods, and even though finding historical data of an individual player is relatively easy, it is much harder to integrate the temporal storylines from different players from a team or the whole league.
The purpose of the course project was to develop an InfoVis using D3, this meant there was little opportunity in our timeline for me to employ user research methods in order to better understand the problem and the users. I did however take advantage of the early stages of the project to go through a mini “design sprint” and multiple stages of design prototypes, incorporating feedback on each iteration.
Unfortunately, because I did all of the design work, I decided to let my teammates take care of the development. In typical semester-long project fashion, development of the final app didn’t start until the last couple weeks of the semester. Fortunately, my teammates were great developers and turned around a functional web app in short time.
Unfortunately, I experienced the classic designer disappointment of handing off designs from a semester of hard work and having them all but ignored. The web app that they designed and developed works decently, and includes some of my design and research. However, the user experience is painfully disappointing to me.
I often like to say, “If you need an onboarding tutorial to explain a user how to use your app, it means your UX sucks.” The inclusion of an onboarding screen in our app is a great example of this.
Although the final solution was incredibly disappointing to me, I took away some important lessons. I learned the importance of good communication between designers and developers. Despite me communicating my research and design decisions, the developers ignored them. I’m not sure what the issue was, but maybe I didn’t communicate the justifications for the design decisions effectively enough to motivate the developers to incorporate them.
However, I also learned that as the designer, I could have benefitted from more communication with my team. Although what the developers designed and built wasn’t what we designed, they made some design decisions that I thought were great and I would have loved to incorporate them in the design process.
I'd really like to take a step back and do another design iteration. Then develop a web app based on that and do some user testing to quantitively compare my solution to existing solutions. As a busy college student it'll be tough to find time to work do this on the side, but I think it will be fun and give me some closure on this project.