Enteract in use at the 2013 Spring Carnival.

Client
Carnegie Mellon Information Systems Department
Course
Junior Capstone Project, Spring 2013
Role
Design Lead
Description
Enteract is a responsive website which facilitated for the first time ever crowd participation at Carnegie Mellon's most famous and largest alumni event, Spring Carnival. Attendees interacted to select the student organization-built booth they deemed the most innovative to be the winner of a new people's choice award.

Background

This project presented our team with both great challenges and rewards. The project originally began as an audience polling system for gauging and grading participating in a university classroom setting as a free replacement for the costly iClicker system.

However, after the basic system was already in place, CMU’s Carnival Committee approached the department simply asking for an application to increase audience participation. Having embraced from the beginning an agile design methodology, the team was able to be flexible enough to seize the unique opportunity at hand to create the requested application. Overall, promoted by a high-visibility print and digital advertising campaign, Enteract attracted around 1,000 unique users over a three-day period and to this day is the only project in the course’s history to be deployed live and receive recognition on the university website’s front page

Carnival Implementation

Mapping the user experience of Enteract through scenarios with the user interface flow included.

In a total of only three weeks, we adapted our classroom polling system to be the first-ever interactive voting experience designed for Carnegie Mellon’s Spring Carnival. Due to the project’s success our team was asked to present, among other events, at the Meeting of the Minds, CMU’s undergraduate research symposium. In order to communicate the value of our product to stakeholders and improve the experience for next year, I mapped the user experience with insights gained from exit interviews.

The overall experience can be divided into two scenarios:

  1. On-Location Voting– A user’s initial touchpoint is a poster located at the physical grounds of the carnival and rates a booth directly after touring it.
  2. Retrospective Voting- A user’s initial touchpoint is an abstract recollection of an experience or a person talking about Enteract which leads to voting after one has viewed a booth. Voting takes place outside of the carnival grounds, such as when one is at dinner with friends.

Carnival Outcomes

Design Process

Enteract Product Development Process Diagram. My responsibilities as both UX and Visual Design Lead are outlined in yellow.

As both the team’s UX and Visual design lead, I took insights gathered from our team’s initial research and user testing to structure the interface and form both the interaction and visual design languages.

My decision to use an agile design process for this project, so as to work in parallel with the developers’ sprints, I was able synthesize and transfer our huge amount of research and pre-existing design framework from the classroom polling application idea to the modified implementation for Carnival that our stakeholders desired. In fact, it was our understanding of the target audience gained through the personas, that was the most helpful. While the setting changed from the classroom to an on-campus carnival, the people we were designing for stayed the same: Carnegie Mellon students (either current or past), professors, and administrators cover the majority of Spring Carnival attendees.

Explaining my role in further detail, my responsibilities can be put into the two categories highlighted on the process diagram above structuring the interface (interaction/ user experience design) and visual design:

Structuring the interface consisted of sketching initial concepts, creating low and high-fidelity wireframes, making the site map, and creating both paper and PowerPoint prototypes to be used during different user tests.

Visual design duties required researching, presenting to my team, and creating all original assets and screen layouts. Creating the visual language involved among many things choosing a color scheme and typographic conventions, which then summarized in the final style guide.

After interviewing multiple professors, students, and administrators we found there to be 3 user personas: Susie Student, Teacher’s Assistant Tim, and Professor Priya. There was additionally one customer persona, academic department head David.

 User Research & Personas

Our initial research consisted of interviewing professors and other academic administrators and surveying students in courses which used the iClicker system, which we had previously identified to be our main competitor through creating a comparison matrix within the competitive space of audience polling smartphone applications.

After aggregating and analyzing these hundreds of individual accounts, I determined there to be three main actors with different system needs. So as to facilitate greater understanding and empathy for the users’ needs among my teammates by personifying the system requirements and user stories, I created the personas shown at left.

We combined and created an initial prioritization of all the requirements gathered from our interviewees that had been translated to personas. From this diagram, I found that since the TA and Student requirements had a total overlap, we didn't need a separate TA persona. The decision from this point on was to design two distinct interfaces within our application, but keep both easily accessible to a user who needed to view both, such as a TA.

We combined and created an initial prioritization of all the requirements gathered from our interviewees that had been translated to personas. From this diagram, I found that since the TA and Student requirements had a total overlap, we didn’t need a separate TA persona. The decision from this point on was to design two distinct interfaces within our application, but keep both easily accessible to a user who needed to view both, such as a TA.

Gathering & Prioritizing Requirements

We then combined the key tasks and goals of each of our personas to derive the product requirements, use cases, and ultimately, key progress indicators. We then prioritized these requirements to determine our project timeline.

The second version of the Venn Diagram reveals key insights about prioritizing requirements. Those that are shared between the primary personas (Susie the student and Priya the professor) as well as those higher up on the diagram are those that should be implemented first.

The second version of the Venn Diagram reveals key insights about prioritizing requirements. Those that are shared between the primary personas (Susie the student and Priya the professor) as well as those higher up on the diagram are those that should be implemented first.

The second version of the Venn Diagram reveals key insights about prioritizing requirements. Those that are shared between the primary personas (Susie the student and Priya the professor) as well as those higher up on the diagram are those that should be implemented first.

Organizing requirements by persona in a Venn diagram also allowed us to determine 3 priority levels for the requirements. To create a shared group vocabulary and make sure we were on the same page we organized the requirements based on associated behavior type: A-level: Poll Class (professor asks questions to class and students answer), B-level: Assess Progress (professor assesses class' progress and students assess their individual process in a class), and Assess Product (a department head viewing the product information on our landing pages weighs the cost and benefit of adopting our product).

Organizing requirements by persona in a Venn diagram also allowed us to determine 3 priority levels for the requirements.

To create a shared group vocabulary and make sure we were on the same page we organized the requirements based on associated behavior type: A-level: Poll Class (professor asks questions to class and students answer), B-level: Assess Progress (professor assesses class’ progress and students assess their individual process in a class), and C-level: Assess Product (a department head viewing the product information on our landing pages weighs the cost and benefit of adopting our product).

IMG_0362

Initial user flow diagram illustrating through rough storyboards all possible flows & interactions a student could have with the application’s interface.

Sketching Concepts

IMG_0359

Detail of a student viewing more information about a class they are enrolled in (4a. Class Detail), and viewing a visualization summarizing their performance in this course (6. Summary).


IMG_0357

Detail of the possible flows a student could engage in upon signing in which included Viewing their Home Screen (2a.) and detailed information about a course.

IMG_0358

Detail of the screens a student would see when answering a question (5a.)


IMG_0355

Shown is the flow of student signing in and enroll in their course section (3b. – 3c.). After paper prototyping and more interviewing we decided to limit this functionality to professors being able to sync a class list from their laptop/desktop.

Sitemap Diagram

Internally used sitemap as a design reference to illustrate full application functionality. Dark blue screen is the initial login page, light blue the Home Screen, and Grey indicates further possible flows.

Internally used sitemap as a design reference to illustrate full application functionality. Dark blue screen is the initial login page, light blue the Home Screen, and Grey indicates further possible flows.

Wireframes

Login and Viewing the Home Screen of all of a user's classes are shown.

Login and Viewing the Home Screen of all of a user’s classes are shown.


The professor's flow when (1) Creating a Question then (2) Asking the Question from their smartphone is shown

The professor’s flow when (1) Creating a Question then (2) Asking the Question from their smartphone is shown


Answering a question and viewing (1) for a student (a) the correct answer and (b) their relative performance. (2) Professors & their Teaching assistants could quickly view class performance by question to be able to choose which topics needed to be covered better.

Answering a question and viewing (1) for a student (a) the correct answer and (b) their relative performance. (2) Professors & their Teaching assistants could quickly view class performance by question to be able to choose which topics needed to be covered better.

Visual Design

Color Studies

Minimalistic, Limited color palette. Aimed to give more dignity and sophistication to educational polling systems for the college audience; truly 'higher education'.

Minimalistic, Limited color palette. Aimed to give more dignity and sophistication to educational polling systems for the college audience; truly ‘higher education’.


Groups Menu

A more, colorful fun color palette. This variation was later abandoned in favor of the previous more restricted option due to the large amount of visual “noise” created by arbitrary color coding which added little real usability value, as measured by surveys taken after condition some paper prototype user tests.

Medium Fidelity Wireframe Concepts

Used mainly for self and internal team reference tools, these medium fidelity wireframes contained many notes as to why visual and interaction design decisions were made, including the pros and cons of the different options.

Used mainly for self and internal team reference tools, these medium fidelity wireframes contained many notes as to why visual and interaction design decisions were made, including the pros and cons of the different options.


Real-time view of audience responses.

Real-time view of audience responses.

High-Fi Visual Design Concepts

This is the product landing page, designed for customer acquisition. Visitors crucial to classroom adoption such as David can visit this page, and use a free trial or learn more, near the bottom of the page, these UI elements are enticing, leading to behavior that drives customer acquisition.

This is the product landing page, designed for customer acquisition. Visitors crucial to classroom adoption such as David can visit this page, and use a free trial or learn more, near the bottom of the page, these UI elements are enticing, leading to behavior that drives customer acquisition.


During the visual design phase of the project, many variations were created for the application and logo, building iteratively off of feedback during critiques, user testing, and the initial color studies shown in the previous sections

During the visual design phase of the project, many variations were created for the application and logo, building iteratively off of feedback during critiques, user testing, and the initial color studies shown in the previous sections

landing_page_testdrive_slide2ask browser_option mobile_landing_page_v9 login_vertical_v1_with_iPhone login_vertical_v1 simple_screen

Classroom User Tests

We created a click-through prototype tested using 100 students in the Freshman Introduction to information systems course. Through this trial, we were able to stress test the system’s request handling capacity and found useful information to improve the student’s UI, which was generalizable enough to be able to integrate these changes in our Carnival implementation.