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

  • Introducing StorylineJS

    Today we're excited to release a new tool for storytellers.

    StorylineJS makes it easy to tell the story behind a dataset, without the need for programming or data visualization expertise. Just upload your data to Google Sheets, add two columns, and fill in the story on the rows you want to highlight. Set a few configuration options and you have an annotated chart, ready to embed on your website. (And did we mention, it looks great on phones?) As with all of our tools, simplicity...

    Continue Reading

  • Join us in October: NU hosts the Computation + Journalism 2017 symposium

    An exciting lineup of researchers, technologists and journalists will convene in October for Computation + Journalism Symposium 2017 at Northwestern University. Register now and book your hotel rooms for the event, which will take place on Friday, Oct. 13, and Saturday, Oct. 14 in Evanston, IL. Hotel room blocks near campus are filling up fast! Speakers will include: Ashwin Ram, who heads research and development for Amazon’s Alexa artificial intelligence (AI) agent, which powers the...

    Continue Reading

  • Bringing Historical Data to Census Reporter

    A Visualization and Research Review

    An Introduction Since Census Reporter’s launch in 2014, one of our most requested features has been the option to see historic census data. Journalists of all backgrounds have asked for a simplified way to get the long-term values they need from Census Reporter, whether it’s through our data section or directly from individual profile pages. Over the past few months I’ve been working to make that a reality. With invaluable feedback from many of you,......

    Continue Reading

  • How We Brought A Chatbot To Life

    Best Practice Guide

    A chatbot creates a unique user experience with many benefits. It gives the audience an opportunity to ask questions and get to know more about your organization. It allows you to collect valuable information from the audience. It can increase interaction time on your site. Bot prototype In the spring of 2017, our Knight Lab team examined the conversational user interface of Public Good Software’s chatbot, which is a chat-widget embedded within media partner sites.......

    Continue Reading

  • Stitching 360° Video

    For the time-being, footage filmed on most 360° cameras cannot be directly edited and uploaded for viewing immediately after capture. Different cameras have different methods of outputting footage, but usually each camera lens corresponds to a separate video file. These video files must be combined using “video stitching” software on a computer or phone before the video becomes one connected, viewable video. Garmin and other companies have recently demonstrated interest in creating cameras that stitch......

    Continue Reading

  • Publishing your 360° content

    Publishing can be confusing for aspiring 360° video storytellers. The lack of public information on platform viewership makes it nearly impossible to know where you can best reach your intended viewers, or even how much time and effort to devote to the creation of VR content. Numbers are hard to come by, but were more available in the beginning of 2016. At the time, most viewers encountered 360° video on Facebook. In February 2016, Facebook......

    Continue Reading

Storytelling Tools

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

View More