CollegeNET Case Study

The Problem

College administrators needed a way to create events at their schools that fed back into the larger data on a student so they aren’t having to communicate across multiple systems (ex. using Eventbrite and importing data later) on their campus. They also would like this feature to incorporate the use cases that are relevant to them, such as making an interview scheduler that easily facilitates medical student interviews.

This feature needed to fit into the CRM CollegeNET provides to colleges, allowing them to create the following types of events with a large margin of flexibility: open houses (open registration, no capacity cap), interviews (known participant, limited capacity), and everything in between. We had roughly 5-10 examples of different variety of event types that colleges create.

This was to be one of the first major features to go into a new interface (Angular) supported by the legacy system’s back end. We used it as a case to start a pattern library of Angular components at the same time to start spanning across multiple products.

Role and Team

I was lead designer on this project and worked with one other designer while mentoring him (he had roughly 6 months of experience previously). My focus was in my strength of information architecture and working with the backend devs to define the system requirements. I helped with all stages of the project, from initial requirement gathering to wireframing and visual design to final design review in our test environment.

We worked with a team of 4 engineers to complete this project, it took around a year to be released fully featured (this was also do to some restructuring of the engineering team mid-way through). We work very closely with the engineers and consider them a critical voice in the design process.

Users and Audience

There were three audience types to consider depending on where they touched the interface:

1. Administrator: the admin is our main user, they are configuring the events and want to receive information on the event after the fact on attendance. This kind of information feeds into a large picture on the applicant’s engagement with the college

2. Facilitators: they will receive information about the event, when they show up they need access to the list of attendees and a way to mark them as attended

3. Attendees: these are prospective students for the school, they need to find out about events at the school, register, receive reminder emails, and then attend the event. Most importantly of all, have all the information easily available to them in a timely manner

Design Process

Requirements Gathering / Understanding the Problem

At CollegeNET it usually ends up being the design team’s job to gather the first round of requirements as user stories, gathering of use cases, and defining a rough scope. I work with the product manager and internal stakeholders to round out a rough idea of the feature.

Once the rough list has been created, it is vetted with product managers and internal stakeholders through a few rounds then ideally (but not always) these internal assumptions turned into a UXR project to validate the direction and use cases match up with what the college’s needs are.

During this time I also begin roughing out the system architecture and iterating on it as requirements are determined and as I begin discussions with the backend engineers. We also began looking at other successful event services for patterns that would work well for our users.

Final Designs / Documentation

Once the wireframes were in a good place and we felt like iterations would be at a minimum when development started, we moved onto final designs.

We provide full documentation in Confluence that hooks into the JIRA tickets for the developers. This includes screenshots and information on how each piece is expected to function.

We do an official handoff to the devs before work begins, answering all questions and making adjustments as needed.

Pattern Library

We put a lot of consideration into each of the components that we built as they were getting added as first drafts into our new pattern library. We looked for outside reference such as the material guidelines to make sure we were following best practices and working with our accessibility specialist to make sure the coded component follows WGAC 2.0 AA guidelines.