The devil is in the details: shifting gears from developer to designer

For an entire quarter, I had the privilege (a curse to some) of focusing all my time on a single project. Romaine, a social platform/tool for selecting courses, had a simple goal: how do we harness the community nature of the question, “what class are you taking next quarter?”

My initial solution was laughably naive and simple. ‘Just link each course to Facebook!’ I thought to myself. We’d be done in no time. Ha, ha.

When it came down to actually building the project, my teammates Nicole, Mallory, Ashley and I found ourselves discussing the merits of increasing the space between an arrow and an unrelated feature; whether a user needed to see a ‘go’ button even if people are more likely to use the enter key instead; if more information was better than a minimalist look; among countless other details.

My first mistake was assuming that design meant making things look snazzy with some well-structured CSS. Figuring out how to translate a user’s tendencies and usage desires to components of functionality was a rabbit hole of roundabout conversations and only occasional successes that I hadn’t been ready for.

Fortunately, by the 11th hour, we had vetted responses to a survey we sent out to get a better feel for the purpose of Romaine and narrowed its use cases down to three:

At any one point during her college career, average Jane faces one of three situations while registering for classes.

  1. She knows exactly which classes to take next, because they’re core requirements for her degree.
  2. She knows what kind of classes to take next, because they’re non-core requirements for her degree.
  3. She has no idea what classes to be taking, because she either doesn’t care or can afford that flexibility.

In any of the scenarios, there stands one thing between Jane and that “register” button: retrieving the specific courses to register for. And to retrieve the courses, one must search for them. As it stands, CAESAR, the official course registration system at Northwestern, has a comprehensive but overly specific search system that requires users to know in advance at least which subject they want to look in. So we decided to design a better search process. For the following week and a half, The Search plagued our design-newbie minds.

We knew The Search had to address our primary goal of providing, first and foremost, a platform on which users can leverage the fact that they are considering courses that their friends are potentially taking as well. To figure out at which point and how much friends play a role in the course selection process, we blasted our existing social media platforms with the survey and got as many responses as we could without having to offer our firstborn child or lifetime supply of Chipotle burritos.

While the number of results we received was meager at best (24) and two schools were not represented, most  responders said their course selection process was to:

  1. Figure out requirements left to fulfill.
  2. Figure out which classes might meet those requirements.
  3. Vet their potential choices with friends.

At this point, we deemed it important to distinguish between two types of users -- Jane of Scenario 1, and Jane of Scenario 2 or 3. The former gets a kick out of knowing who’s in the class she knows she’s taking, or wants to take a specific section with her friends. The latter is open to influence, and wants to have a browsing capability that CAESAR’s current search engine does not allow for due to its specificity.

To properly address the latter, we spent hours discussing drop-down menus, fuzzy searching, filters and the like. We decided to implement a simple but exact search bar for our Jane who really just wants to get to the course she’ll be taking to see if her friends are in it, too. The other, indecisive Jane received a little more attention.

She might know she needs to fulfill a history requirement but this could fall under Gender Studies, History, Russian or any other number of subjects. She might also want to see courses that only fall under specific schools. Maybe she wants to see all 4,000+ stinking courses at once, because hey, options!

So maybe we should have every subject available as a toggle feature, and each subject will bring up information about all the courses that fall under that subject?

Our first wireframe. Oh lord, those squares.

The thought was that it’ll be like how Stumbleupon asks its users to check off all their different interests on sign up. But Stumbleupon doesn’t have more than 200 options, and we sure didn’t want the user to have to go through multiple pages of checking off the subjects they’re interested in.

In order to address both the vague nature of course selection and readability of the interface, we decided to keep the toggle feature but implement a two-search system instead, where the user would toggle first by the schools they’re interested in then the subjects offered under those schools.

Our second wireframe. With the search functionality split into two (for Jane of Scenario 1 and for Jane of Scenario 2 or 3), we instituted toggle at all levels of the “browse” search that could be turned on or off at any point to see the courses and/or subjects only under the clicked buttons.

Mostly content with the implementation of The Search, we turned our attention to how to organize the search results next, which was much easier to figure out given how users normally expect their search results to appear.

By default, the results would be grouped by subject then ordered by course number. And since the social aspect is crucial, the friends who’ve selected the same courses the user would be looking at would immediately show up. There would then be the option to view more details for each course.

If my Facebook friends had also added these courses, I would see their profile pictures next to the course buttons.

The other option: toggle ALL the things! The user has the option to view as few or many subjects and classes at once.

In the end, we ended up designing a product that would fit our main goal while addressing some of our peers’ complaints about the usability of CAESAR. We did however learn that there was more demand for an application that would allow the users to see what their friends have taken in the past, not just what they will be taking, so they could seek advice.

My team and I did not address all the design challenges. Nor did we find the best possible solutions to the ones we did attempt to tackle. But between paper prototyping with index cards and arguing over the placement of an arrow, we learned that product design is an art form that tests developers’ proactive thought, judgment, and, of course, patience.

About the author

Suyeon Son

Undergraduate Fellow


Latest Posts

  • With the 25th CAR Conference upon us, let’s recall the first oneWhen the Web was young, data journalism pioneers gathered in Raleigh

    For a few days in October 1993, if you were interested in journalism and technology, Raleigh, North Carolina was the place you had to be. The first Computer-Assisted Reporting Conference offered by Investigative Reporters & Editors brought more than 400 journalists to Raleigh for 3½ days of panels, demos and hands-on lessons in how to use computers to find stories in data. That seminal event will be commemorated this week at the 25th CAR Conference, which...

    Continue Reading

  • Prototyping Augmented Reality

    Something that really frustrates me is that, while I’m excited about the potential AR has for storytelling, I don’t feel like I have really great AR experiences that I can point people to. We know that AR is great for taking a selfie with a Pikachu and it’s pretty good at measuring spaces (as long as your room is really well lit and your phone is fully charged) but beyond that, we’re really still figuring...

    Continue Reading

  • Capturing the Soundfield: Recording Ambisonics for VR

    When building experiences in virtual reality we’re confronted with the challenge of mimicking how sounds hit us in the real world from all directions. One useful tool for us to attempt this mimicry is called a soundfield microphone. We tested one of these microphones to explore how audio plays into building immersive experiences for virtual reality. Approaching ambisonics with the soundfield microphone has become popular in development for VR particularly for 360 videos. With it,...

    Continue Reading

  • Prototyping Spatial Audio for Movement Art

    One of Oscillations’ technical goals for this quarter’s Knight Lab Studio class was an exploration of spatial audio. Spatial audio is sound that exists in three dimensions. It is a perfect complement to 360 video, because sound sources can be localized to certain parts of the video. Oscillations is especially interested in using spatial audio to enhance the neuroscientific principles of audiovisual synchrony that they aim to emphasize in their productions. Existing work in spatial......

    Continue Reading

  • Oscillations Audience Engagement Research Findings

    During the Winter 2018 quarter, the Oscillations Knight Lab team was tasked in exploring the question: what constitutes an engaging live movement arts performance for audiences? Oscillations’ Chief Technology Officer, Ilya Fomin, told the team at quarter’s start that the startup aims to create performing arts experiences that are “better than reality.” In response, our team spent the quarter seeking to understand what is reality with qualitative research. Three members of the team interviewed more......

    Continue Reading

  • How to translate live-spoken human words into computer “truth”

    Our Knight Lab team spent three months in Winter 2018 exploring how to combine various technologies to capture, interpret, and fact check live broadcasts from television news stations, using Amazon’s Alexa personal assistant device as a low-friction way to initiate the process. The ultimate goal was to build an Alexa skill that could be its own form of live, automated fact-checking: cross-referencing a statement from a politician or otherwise newsworthy figure against previously fact-checked statements......

    Continue Reading

Storytelling Tools

We build easy-to-use tools that can help you tell better stories.

View More