Pinguin

Building a solution to college event management

Pinguin is an event communication application made with colleges in mind. This was a personal project that I developed with a friend outside of school and work.

My Role

  • UX Designer
  • UI Designer
  • Marketer

The Team

  • 1x UI/UX Designer
  • 1x Developer

My Tools

  • Photoshop
  • Illustrator
  • XD

The Challenge

The current system for communicating college events has room to be improved, either by improving the current systems or by developing a new one. This goes for both how colleges communicate their events to students and how students communicate between each other to discuss extracurriculars.

Background

An important part of student life in college is attending extracurricular events. School events provide a place for students to come together, meet each other, and enjoy time away from classes. A key task for schools then is to inform their students about what's happening around campus.

My friend and I realized there was potential to improve the college experience for both schools and their students. Colleges' traditional means of communication aren't particularly effective, and other event services aren't made with these problems in mind.

The question became then:

How might we build a system of communication between schools and students in order to build a stronger community?

Research

Before attempting to create an entirely new product or solution, I started doing research to understand what the market for event planning services looked like and where we could differentiate our design. Then we could have a conversation with potential users to find some of the friction points surrounding school events.

Competitive Analysis

There is an extensive market for event related applications: Facebook Events, Meetr, Trip Advisor, Meetup, Eventbrite, just to name a few. All of these services have different offerings and ways in which they differentiate, so I did some analysis on their strengths and weaknesses to get a better understanding of their positions in the market.

Facebook Events
Strengths
  • Established user base
  • Good categorization/search capability
Weaknesses
  • Less popular among college-age students
  • Not great at searching by location
Trip Advisor
Strengths
  • Planning & organizing
  • Community reviews for different
    locations
Weaknesses
  • Targeted towards tourists
  • Lacks emphasis on doing things
    with others
Eventbrite
Strengths
  • Functionality for sales
  • Wide variety of events
Weaknesses
  • Focused on ticketed events
  • Hard-to-access location
    information
  • Little social network capability
School software
Strengths
  • Already used by many students
  • Easy to add features that are relevant
    to the school
Weaknesses
  • Unrefiend interface
  • Underdeveloped functionality
Talking to Users

We talked with school administration about how they marketed their events to students. On the student side, we talked with fellow classmates to try to get an understanding for how they went about finding extracurricular activities. Here's some of the key points that seemed to keep showing up:

School Side

Difficulty converting advertisements to event attendance

Heavy use of print media

Poor accesibility of marketing for students

High spending on internal marketing

Student Side

Limited use of school's marketing

Reliance on word-of-mouth and alternative communication (GroupMe, group chats, etc.)

Only attending activities planned by student organizations (Greek life, clubs)

Sticking with friend groups

Define

Now that we had an idea of the differences between the school and the students, it was time to start defining some of the goals for the project. From the research it seemed there was a breakdown of communication between the school and the students. Our initial goals were:

  1. Elaborate on who the product is for
  2. Determine important features
  3. Establish constraints
User Personas

There are a few different type of people that would use the service. Schools would use it as a means of communicating with their student bodies, and students would use it as a way to search for, explore, and plan things to do with friends.



Casey - The Administrator

Casey is a school administrator. She's responsible for managing the promotion of school events and activities.

Goals

  • Minimizing time and effort on marketing
  • Maximizing student engagment
  • Accessing metrics to analyze success
Frustrations

  • Low attendance
  • Funds being wasted on ineffective promotions
  • Difficulty changing details last minute
Bryce - The Student

Bryce is a college student. He has fun just hanging out with friends, but sometimes he and they want to go out and look for something new to do.

Goals

  • Trying new things
  • Being able to socialize
Frustrations

  • Not being able to find the information
    he wants quickly
  • Learning about cool events only
    after they happened

Goals and Constraints

After some consideration we felt that developing a standalone application that was unassociated with the school or another software was ideal for our situation. This would provide a solution that could theoretically be expanded upon much more easily, say, to apply to a different school.

We explored the idea of building a social media side to the solution, wherein users could better interact with each other, form groups, and make/edit their own events. This became out of scope before too long, and we decided that focusing on the main issue of schools posting events and students discovering them would be best for a minimum viable product.

Solution

I started building some lofi prototypes to get a feel for how some of the interactions and visualizations would look. I wanted to have a view of a map because of how much more visual it was compared to a list view.

map view

list view of events

Experimenting with a hamburger menu

expanded menu

The home page ended up being somewhat complex, so I referenced Material Design to give the UI a stronger sense of visual hierarchy. It was important to me that the pop-up information be understandable and usable despite the complex background information from the map, and I found the Material guidelines worked the best to communicate the depth of the different elements.

a map for the home view with a date selector above the taskbar.

demonstration of selecting different dates

event nodes pop up to display details about the event

Outcome

My friend and I both come from a community college background before transferring, and while residential schools certainly have a more vibrant social scene than commuter schools, the same problems with event communication continued to appear. As transfers we had the perspective of students that missed their first two years at a 4-year school and the challenges of integrating that were presented as a result. There’s huge potential for improving one of the most fundamental aspects of college, and we hope our solution addresses it.

We didn’t end up finalizing the release of the service, so it’s impossible to make grand conclusions about how effective the product is or would be. Despite this, I learned some very valuable lessons on taking a project from idea to reality:



Insight #1

  • Communication shouldn't be taken for granted

  • Result: In the past I didn’t give a lot of thought to internal marketing: to me, marketing was just a way for organizations to communicate with others. Working on Pinguin helped me realize that there’s always room to improve how groups communicate with themselves, and making these improvements builds a more effective and beneficial system for everyone involved.

Insight #2

  • The value of in-person research cannot be overstated

  • Result: One of the biggest changes I would make were I to go back to the beginning of the project would be how we conducted research. My process lacked structure and relied on informally and haphazardly getting insights from potential users. There were several occasions where I realized mistakes long after they could have been avoided had organized research taken place. Design doesn’t happen in a vacuum, and I learned that the hard way on this project.

Insight #3

  • Translation from design to development isn’t always simple

  • Result: It’s easy for designers and developers to get caught up in their own language and jargon, which leads to details getting lost in translation. Even during moments of clear communication, I found that the capabilities of prototyping software are ultimately bound by the limitations of development: it doesn’t matter how cool a design is if it can’t be implemented. For that reason, clear, explicit design decisions make the implementation process that much smoother for everyone involved.



Return to Portfolio Return to Top