OVERVIEW

ACHIEVE OVERVIEW

Achieve is Macmillan Learning’s digital platform designed to be an online learning system and course management tool for higher ed instructors and students.  

ROLES

My Role: Product Designer
Research Partner: Kaitlin Tasker

PROBLEM 

The current solution for viewing content within the Achieve platform was not doing so in a way that was valuable for both instructors and students. Our beta users were having trouble navigating, and it required big tech commitment we we were maintaining three separate lists of content. The main goal of this initiative was to create a more streamlined, intuitive interface for our users to view their course content.

TOOLS

• Sketch

• Invision

• Abstract

• Principle

• Airtable

PROBLEM VALIDATION & SOLUTION DISCOVERY

PROBLEM STATEMENTS & TOP JOBS

Through discovery alongside my product and research partners, we were able to align on proposed problem statements that we ran through an exercise with both students and instructors. As well, during interviews we were able to identify top jobs, both at the beginning and mid-semester for both of our user groups.

SIFTING THROUGH THE NOISE— IA

My research partner and I utilized a ranking exercise to begin identifying where we could highlight the most important versions for both instructors and students

EFFORT VS IMPACT— TESTING TECHNICAL CONSTRAINTS

In this phase of testing, the team was having a larger conversation on whether to invest more holistically in our courseware framework given the associated tech costs. This led us to testing three versions to determine whether the added cost of a version corresponded to added value to the user’s experience (listed below are instructor versions):

• V1: an ideal version

• V2: a version keeping our current technical limitation of virtualized lists

• V3: the cheapest possible dev lift, separated lists

SOLUTION VALIDATION & ITERATION

WIDGET WOES— A REAL ESTATE PROBLEM

Because this project is seated in the foundational experience for our product, I was constantly navigating cross-team dependencies. This sometimes led to us adopting our second or third choice solution. However, measured testing along each version of the design allowed us to weigh value added against technical or cross-dependent sizing constraints.

RESULTS

SUS COMPARISON

As the design changed so much due to constraints, we opted to conduct SUS testing on both current state and the proposed solution to be sure effort was worth the impact.  

HAND-OFF SAMPLES

LIVE ON ACHIEVE