Case study:
La Trobe University Courses

Set goals

Having successfully campaigned for a MVP approach, our team had to decide on how we'd measure success. With some goals in mind, the Product Owner asked to benchmark current performance while the design stage kicked off. We added tracking attributes to key links and interaction points so we could ensure meaningful data analysis.

Information architecture

Looking at the course data we had, I identified over 700 course variations for a single year. I mapped different possible structures and presented these to the team noting pros and cons to each. I made a recommendation to the team based on my in-depth knowledge of our development platform and our SEO needs. This recommendation would mean there would be around 350 new URLs for the course pages. One URL per course title, with variations for year, domestic/international and campuses loaded onto it.

Knowing this, I was concerned that these new course URLs would compete with existing Handbook URLs. I raised this concern and we sort industry expertise and proposed mitigation strategies.

Cohorts

Through various ideation workshops, we fleshed out directions we might take and examined a shopping cart experience. With more than 350 courses across 6 campuses, we wanted to give users a familiar way to examine attractive options. No student would be interested in, or eligible to, all course. I proposed setting intelligent defaults.

Looking at our tracking data, we quickly confirmed that the majority of our audience is domestic looking to study an undergraduate course at our Bundoora campus.

I created a micro HTML prototype to test these defaults. Testing revealed that this greatly aided browsing for relevant course content and that changing the defaults, when presented in a similar fashion to shopping cart filters was a friendly user experience.

Data issues

The next challenge was connected with data. Some of the data was fixed to all versions of the course, while some was connected to a single variation. The BA had mapped all these data points and I had to workout how to present the correct data to the users overcoming the limitations of our CMS.

We also had to combine two types of data. Our approved course data (hard data) that had external stakeholders and Marketing content that our Product Owner had control of (soft data). With this in mind, I defined 4 data schemas. 2 schemas for "course container" data (one read only, one editable), and 2 schemas for course variation content (one read only, one editable).

The plan was for the hard data to define a course from which a page would be generated in the CMS. Variations to this page would be created separately in a course data bucket. Each variation created would be mapped to the course page.

Workshops

I created a proof of concept in our CMS to ensure this could be achieved. With this verified, I had a firm idea of what we direction our solution might take. I presented a strawman design with low fidelity wireframes to the project team to shake out any design issues and missing requirements. The concept held up and it was time to look at the interface.

Then we entered a deeper design phase where we matched design patterns to recommendations from third party reviews, the content we had available and the objectives of the project. In a paper prototyping exercise, we cut out design elements we found on competitors course pages and assembled elements that would cover all our requirements.

From this, low fidelity wireframes were created, reviewed, tested and revised. It was time to start working with real data in our CMS. I configured the required templates and our developer created nightly routines to populate the course data. The interface was populated using components from our design system to get us started.

Prototyping

With this baseline prototype using accurate data, we could test all the facets of our solution including data population, error trapping, data accuracy, the container/variation model, the hard/soft data model, our cohort defaults and switching course variations.

I continued creating the visual design for the new components we'd need to complete the prototype and then built them in the CMS. As the fidelity of our prototype increased, we we able to increase our testing audience and invited external stakeholders to review the solution and log any issues they uncovered. Via collaboration between the BA, the Product Owner and myself, we were able to address issues as they arose and consolidate a final design that could progress to user acceptance testing.