The Creation Of: How Well Do You Know Your Classmates?

Click here to view the project.

How Well Do You Know Your Classmates? is a data visualization/narrative that analyzes various aspects of the freshman Class of 2021 at Cornell. It is an attempt to learn more about matriculating Cornell students. What were the demographics? Were there correlations between variables, such as intended major and financial background, interest in Greek Life and socioeconomic background? Did students who got assigned to certain dorms tend to have similar lifestyle tendencies? We aimed to debunk or confirm some of the major stereotypes about freshmen.

The project reached over 16,000 Facebook users and garnered nearly 300 reactions. Despite the end product’s success, the creative process was not devoid of challenges and tensions. What was significant about this undertaking was that it served as a trial run for us to learn about making digital editorial projects, which would be important towards expanding our presence in the world of digital journalism and media. We all emerged from the process knowing more about team communication, efficient workflow, working across disciplines…knowledge that we would carry with us to our next project.


Throughout the semester, I would talk with editors of The Sun who expressed interest in publishing infographics and data visualizations. It was incredibly surprising — and encouraging — to see so many people who were excited about this initiative. So towards the end of the Spring 2017 semester, I organized a meeting with some Sun staffers to brainstorm topics that we could pursue.

Some of our initial ideas from brainstorming included analyzing each building’s water/energy consumption, looking at mental health data, breaking down financial aid at Cornell, and more. In order to decide on an idea to develop, we looked at how feasible it was to obtain the data we needed for a given project, how complex the project would be, and how much time we had to publish a project. We settled on making a data visualization about the incoming freshman class. Collecting information from Cornell students wouldn’t be too difficult; if we got our survey approved by the school and publicized it extensively on social media, we could get a decent sampling. Other models of this type of project existed, so creating our own would be a good place to start. Our projected publication date would be during the first two weeks of school. Although we were short on members, we were confident that we would be able to find some people willing to join the team by the time summer ended.

The Process

The challenge of doing this for the first time was that we were creating the process as we went. We had little idea how long the project would take to complete, so we overestimated how quickly we could get everything done. However, there were complications that no one had really thought about beforehand that slowed the process.

We started distributing our survey through various mediums over the summer. While the answers rolled in, we made a list of different types of graphs summarizing potential trends and basic demographics. We also tried, unsuccessfully, to implement a basic framework for the project website so we could get more done before school started. These efforts were hindered by various factors; people were slow to respond online, they were working at their internships, everyone was in different time zones. We soon concluded that trying to implement anything over the summer was less than ideal and axed efforts to do any of the creative work during that time.

We reconvened when we all returned to Cornell and delayed our original publication date, since the work we thought we’d be able to do during the summer wasn’t completed.

The dilemma that we had at the end of last semester persisted — we were short on developers. The remnants of our web team had dissolved last semester; most members had quit or graduated, and I was still in the process of recruiting and interviewing new candidates. We only had one developer on our team. Besides that, analyzing the data and making sure that it was accurately represented in our graphs was something none of us were completely confident doing and there was no time to learn.

We had to get help externally. I reached out to Cornell Data Science (CDS), a campus organization. I knew the Outreach/Event chair, who previously told me that they would be interested in collaborating for a project. I held an initial meeting with a few executive members and luckily, they were on board after I pitched the project idea. By this time, we had also recruited several developers to our web team, so they were put onto the project as well — we were no longer short-staffed.

With the team fully assembled and no time to waste, we started working on making the graphs that we planned on featuring on the piece. My new plan was to have CDS members implement the graphs we told them we wanted in one, maybe two iterations and send them to us. We would then design the site around the graphs so that there would be a cohesive narrative and theme. Our front-end developers would implement the user interface and our back-end developers would take care of deployment. Then we would publish.

This waterfall model approach would create complications for the project, which needed a lot of iteration. We believed that in order for us to come up with several potential designs and write the narrative, we needed the graphs. And those, as we initially failed to realize, were not going to be completed in one or two passes.

Some initial mockups that our UX designer made based on the first round of graphs

A later iteration of the user interface

CDS members analyzed the responses and experimented with various versions of the graphs we requested. What they presented to us was good, but some of the graphs we wanted were missing. I asked why and they explained that there either wasn’t enough data to reach a sound conclusion for a certain survey question or that the results were not intriguing enough and would match the public’s general expectation anyways (gender would generally be divided 50/50 between female and male with a smaller percentage for non-binary). I reinforced that the purpose of the data visualization would be to reveal essential demographics, even if they weren’t necessarily interesting. I requested minor adjustments to the existing graphs and also create the ones that we had requested. But because they were also going through their own club recruitment and individual organization projects, the turnaround was slow. Trying to get these changes done as fast as possible was difficult; I wasn’t working extensively with them in the same space like I did with Sun staffers, and I hesitated to be too gung-ho with them about getting the work done immediately, since they were volunteering their time and asked nothing in return. We had to be considerate of their timeline as well.

Two weeks had passed. I would often be the middleman for communication between our two organizations — there were few opportunities for everyone to sit in the same room and work together. Because of this, not everyone fully understood each other’s pain-points. I would deliver news about progress but also the bad parts — we couldn’t use that graph because not enough people had answered that question, CDS wasn’t able to finish this weekend because they had recruitment and their own meetings. I had several conversations with team members who were frustrated by the frequent pushing back of the deadline — it affected the remaining schedule and everyone was starting to get busy with classes. People started to wonder if the project would ever get published and if it would still be relevant by that time. Although I did my best to reassure everyone that we were definitely going to finish and that we all wanted the same success for this project, I started to feel worn out. The enthusiastic team dynamic we had at the was unraveling.

I called for an urgent meeting, gathering everyone in one room. Things changed when everyone was there in person — it was easier to understand rationales for later deadlines for work, and everyone was able to get caught up in the full story. Teammates were pitching their ideas in person and everything flowed much more easily. With the renewed energy, we started working with fervor. Soon enough, we had the designs, the graphs, and finally the final site. We published it, receiving positive responses from our readers.

Reflection and Takeaways

I organized a postmortem because I wanted us all to reflect on the process of making this project, so we could improve ourselves the next time we decided to do another digital editorial project. Some questions we considered:

What worked?
What didn’t work so well?
What were some of the pain points that people were experiencing?

Here were some of the most problematic parts of the workflow that we addressed in the postmortem and how we plan to remedy them:


Not enough people on the team

At the beginning, it was unclear who would work on the more technical aspects of the project. Was it problematic to start without a finalized team roster? Perhaps, but I knew it was better to start as soon as possible, even if our plan wasn’t complete. If we had waited until we recruited all the right people into The Sun before we began working on the idea, it would have been too late to start or we might never have started.

Now that we’ve gone through this process and know more about what to expect, we established that a team had to have at least the minimum amount of people needed, with enough leeway to add members later if necessary. Members would join by fully accepting their responsibilities and promising to have the time commitment to take on those responsibilities.

Irregular Meetings/Broken Channels of Communication

Because I led the project and was working with every individual involved, I had a clear picture of what was in progress, completed, or behind schedule. I forgot that others in the team did not necessarily share this oversight. I also made some assumptions about how quickly we could complete certain tasks and how straightforward or nuanced those tasks would be, so I did not schedule regular project status reports and communicate that to the members who joined later. We would only meet periodically, and most of the time those meetings were sub-team meetings (design meeting, data science meeting) that I would facilitate. The project required more communication and face-to-face interaction between everyone, and as a result there were many points in time when members were confused about the status of the project and how close it was to completion.

We resolved to begin every project by making a schedule for weekly meetings (everyone in attendance). Sub-team leads would create their own schedule for individual meetings (as often as necessary) and share that with the overall project lead.

Logistics of working with outside organizations

Working with Cornell Data Science was essential towards the success of the project, but the fact that we were working with an outside organization also complicated certain parts of the process. Making sure that meeting times aligned was challenging. They had their own timeline that most of us were not familiar with. I also was not directly managing their members since they were not officially on The Sun. We were working with them, and they were volunteering to help us, so they were understandably busy with their own responsibilities.

Partnering with other organizations is good because our mission at The Sun is to give students on campus a voice. We could also get a lot more done because people outside of our organization could bring in more knowledge about something that we aren’t familiar with. However, in the future, we would try harder to recruit more people into our own organization who had specific skillsets as necessary.

Where was The Sun before This?

The idea of digital projects was not new. But I knew how much The Sun had struggled to create them based on past conversations that never amounted to anything more than a few initial brainstorming sessions. Our web department was not particularly strong, there was no existing workflow, and past editors had no time to solve such broad challenges on top of putting the physical paper together five times a week (we have since cut down to three days of print in order to focus on growing the digital side of the paper). There were so many components — programmers, designers, potential illustrators, editorial. How would we get everyone to work together effectively and who would delegate all the tasks? Who would figure out what those tasks would even be?

I remember chatting with my former Editor in Chief, trying to get some advice. I showed her some New York Times data visualizations I thought were cool. “Do you think we can do this too?” I asked her. “Probably not within the next few years.” she responded.

I understood her sentiment. The organization was facing many unwieldy issues, all complex and intertwined at their core. But one of the reasons I ran for Editor in Chief was because I wanted to revitalize The Sun’s push towards digital journalism. So I was determined to publish at least one digital project during my tenure.

What everyone agreed upon as one of the most rewarding takeaways about this project was collaborating and learning how their unique talents contributed towards the result; writing, editing, designing, programming, working with data, and so forth. Although there was compromise and the journey was not perfect, we still published a very well-received project.

Airing our grievances to each other about certain parts of the process could definitely be ego-busting, but we all gained a greater understanding of each other and challenges specific to our roles in the project. It made us more empathetic and gave us a sense of unity going forward; we all wanted our work to be successful and that would fuel us to resolve our issues as maturely as possible to keep the momentum going.

Like what you read? Give Sophia Deng a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.