Classes Product

April 2012 (beta version released Dec. 2011)

The quarterly online class schedule was manually created using an exported filed from the printed quarterly class schedule, and manually updated thereafter. This was time consuming to update and prone to human error. There was a prior attempt to automate this information, but the project failed due to issues related to the data coming from a legacy system used by the State of Washington.

My team created an automated system that centralized all class information allowing students to easily find classes and up-to-the-second availability details when planning their class schedule during the registration process. This solution not only was able to work around the limitations of the legacy system, but also improve the college’s workflow during the development of the printed quarterly class schedule.

I am very proud of this product. I drove it from idea to implementation. It succeeded the second time around mainly because we utilized user-centered design methods to uncover and solve the needs of students as well as employees. Some of the key wins include:

• Helps close to 15,000 students a year plan their quarterly schedules and register for classes they need.
• Provides up-to-the-second class availability, which reduces stress related to closed classes. This not only gives accurate course availability, but also reduces overloads to the online registration system.
• Provides detailed class information, including course descriptions, prerequisites, outcomes and projections of when the class is offered, to better help in degree planning.
• Speeds up the workflow related to the print-production process of the quarterly class schedule.
• Simplifies all class information into “Classes,” reducing jargon required to find course information and quarterly listings.
• Other colleges are able to use the shared codebase, such as Peninsula College.

After early discussion within the team and the idea being shut down, one of the developers created a proof of concept using Drupal within a few days. The proof of concept showed how feasible it was to retrieve the data, but also highlighted it’s limitations. I used this proof of concept to have conversations with stakeholders and decisions makers. Later on, this was a key tool to sell the idea to upper management from the perspective of information accuracy and improving student success.

This proof of concept also uncovered that through the database, we had access not only to course descriptions and prerequisites, but access to other information that was previously not publicly published, such as course outcomes and information as to which quarters we anticipated a class to be offered.

After the proof of concept was created, I needed to get a full understanding as to why the prior attempt to build an automated class schedule failed and what needed to happen to mitigate the risks.

I began by interviewing key stakeholders across academic divisions as well as the publication manager to get some historical perspective and a full sense of the lifecycle of class information. This gave me a sense of the full paper-based and digital workflow of how a class is created, modified and sunsets. This also allowed me to understand the data structure in the legacy system and how this data was manually turned into the human-legible printed quarterly class schedule.

During this time I had casual conversations with a few Vice Presidents to gauge the institutional appetite for this kind of project.

With the all this information in mind, I consulted with our software developers and came up with a concept that not only mitigated the risks but also leveraged other opportunities to improve the workflow and data accuracy. I turned this into a proposal that tied the project to multiple college initiatives, including curriculum information accuracy, college transparency and student success. I sold the concept to key decision makers and we continued with the project.

In order to build an MVP, we conducted research with students during the period as well as academic advisors to get an idea of how they helped students during the lead-up to students enrolling for classes.

I participated in some of the research, but this effort was led by another designer and our quality assurance specialist went along to most of the research sessions.

The research was plotted into a Jobs to be Done framework and as a team we decided what jobs the product needed to serve for us to have an MVP.

Side note: During this stage of the project, I was focusing my time on continued conversations with stakeholders and upper administration as well as working on the Web Presence project. I jumped back into the project at this next stage.

Once the project was approved and we had conducted some initial research, we held a 2-part kickoff session organized as a design studio. This allowed us to present the findings to all our stakeholders and have them participate in the initial design session. This helped stakeholders influence the final product and feel as though they were part of the team.

I took the output from this session and started doing sketches of my own and later moved to creating wireframes. I centered my decisions around the Jobs to be Done framework.

These annotated wireframes highlight details what data should be displayed, expected interactions, and special exceptions.

I documented the interaction of all faceted filters in to articulate how each one should work and change as students interacted with them.

We launched an alpha version and later a beta version while we worked out the kinks in the product. During this process we published the manually updated class schedule alongside the Alpha/Beta versions of the product. This allowed us to notice inconsistencies in our product, data accuracy issues, solve technical problems, handle exceptions, and implement functionality to ensure this tool could be a workflow improvement for publishing class information in both print and web.

We utilized a feedback form to help people report issues with the product. Most of the feedback at first was thank you messages from students and faculty. This gave the project a boost.

During this process, we kept the UI looking exactly like the wireframes, to give people a sense that this was a work in progress.

The wireframes were my design and I implemented the UI. Even though these looked like wireframes, under the hood, the markup was well thought out, semantically accurate and accessible.

As the product evolved, the wireframes started looking more and more like the final designs. You’ll notice how the comments on the files focused on Edge cases and more specific details.

This product combines everything that relates to classes together. It lists quarterly course offerings as well as a full list of classes the college offers, including its descriptions, prerequisites, course outcomes and quarters where the course is anticipated to be offered. This may seem like common sense, but it’s fairly unique. Or at least, it was in 2012.

Most colleges list their quarterly/semester class listing in the class schedule (or timetable) and the full courses and descriptions in a document called the Course Catalog. If you try to find this information online, you’ll likely need to go to those two different documents to get the information you seek. The reason for this is that state regulations spell out that colleges need to have course descriptions in a document called the “Course Catalog” and that this document needs to be available online.

At Bellevue College, after conducting some research, we learned that separating this information made it hard for students to find class descriptions and other important information. Because of this, we decided to organize the website by grouping information that made sense together instead of splitting information into an online “Course Catalog”. We still post the ‘Course Catalog” and “Quarterly Class Schedule” online, but as PDFs. Feel free to ping me and ask me how we came to this decision and how I led this separate initiative at Bellevue College.

After the release of this product, it successfully saved over 100 hours of workload 4 times a year in work related to publishing of the printed class schedule by cutting the amount of time required to format the printed class schedule and removing 1-2 cycles of paper-based proofing. This product also allowed the class schedule to become available about 3 weeks sooner than before, which gave more time for students to plan for the classes.

This product is able to cut down the workflow, because now college officials use this product as a tool to proof the information that will eventually be in the printed document. It also generates a document that is preformatted with the proper tags to be imported into their print publishing platform.

An important requirement for this product was to provide information related to the availability of classes, including number of seats available, if the class was closed or how long the waitlist was. The problem is that this information couldn’t be easily queried, and if we queried it for every class, the page would take a long time to load and we would overload the legacy server and it would block students from registering. With that said, we could get this information easily 2 times a day, which meant that at most it was 12 hours old.

To circumvent the problem we added a refresh trigger on every class, which allowed students to refresh the the availability information for each section. We also time stamped it and added it to the cache. This way students would know how old the information was.

Having this information not only gave students clarity about the status of each class, but it also made the registration system overload less. The registration system was tied to a legacy system and could only handle so many requests at a time before it got overloaded. Our hypothesis was that students were less likely to attempt to register for classes that were full because they had that information readily available to them. This in turn, turned to less concurrent usage of the registration system and less chances to overload it.

This project marked a turning point by having the topic of performance be a conversation about user experience.

It wasn’t uncommon for pages in early stages of development to take 30 seconds to load. By the time this project went live, you would never have guessed that performance was an issue because the site is so fast. In fact, some of the most heated conversations between team members in this project was about site speed and caching.

This project helped the entire team improve the way we queried large amounts of data and maintain site-speed. We had to pay close attention to the different levels of caching to ensure that students always saw the most up-to-date class information. As a designer, I had to fully understand these decisions as they impacted the user experience.

• This was my initiative, built a business case and saw it through to the end.
• Served as the product owner and lead designer: led the vision of the project, point person with all college stakeholders, prioritize the backlog and was the voice of the project.
• Led one of two kick-off design studio sessions. We had so many stakeholders, that we to broke it up into two sessions.
• Planned and conducted some of the user studies during the process.
• Designed the wireframes and final design of the project.
• Implemented a good majority of the HTML in a semantically accurate structure, most of the CSS and some of the javascript & jQuery.
• Conducted comparative analysis of similar tools at other institutions.
• Reviewed feedback provided from the website.

• Design methods: customer interviews, guerrilla user studies, defining audience, competitive analysis, value/complexity matrix, story mapping, sketching, white boarding, wireframes, surveys, proof of concept, roadmap
• Design tools: Fireworks, Illustrator, paper/pen/whiteboards, Google Analytics
• Dev tools: Visual Studio (MVC), TFS, Firebug

A technical goal of this project was to make it shareable across all Technical and Community Colleges in the state. An API was developed to assist this and to allow department websites to consume some of this data.