The Design Process

How did My Milestones (MM) come to be?

After identifying the problem, I imagined what a potential Coursera user might be like by creating a persona. Meet Linda!

Keeping Linda’s behaviors, needs and goals in mind, I explored design stories — a list of things users can do with the feature.

This then led to illustrating user states, actions and decisions in a task flow diagram. Below are task flows for adding, viewing and prioritizing courses:

I looked at other task management tools such as Timeful,Wunderlist, and the Getting Things Done system for inspiration. This helped inform decisions such as whether tasks should disappear after completion (I decided to go with “yes”).

When it came to the user interface (UI), I found doing “6-Up Scenarios” incredibly useful because they prompted me to come up with six different ways of laying out a screen. For example, I initially thought that My Milestones would be more of a calendar view. Exploring other options made me realize that on mobile, this was not the best choice.

From UI sketches, I went into creating wireframes, or in other words, the barebones structure of the interfaces and their flow.

My assumptions are as follows:

• The user is already familiar with Coursera
• The user has already enrolled in courses (the wireframes do not show adding a course to My Milestones from the home page, although this was explored here)
• The user has already used the My Milestones feature (hence the first-time user walkthrough is not shown)

I made a low-fi interactive prototype that I did some user testing with. After feedback, I created a higher fidelity version:

Metrics

Not all users who sign up for a course have the intention to finish the course. Coursera often asks users to complete a survey to state their intention. Keeping this in mind, Coursera can measure the success of this feature if, of those who state their intent to complete a course:

The % of My Milestones users who complete a course is higher than the % of non-My Milestones users who complete a course.

Learnings and Further Explorations

This two-week design sprint uncovered a number of issues and questions about designing a new feature, and the above work reflects an initial look into higher level issues.

Questions of: “what happens to x after y” came to mind. A lot. I also became more aware of my own assumptions about conventions and affordances, when, for example, it came to thinking of how a user could prioritize a course. For this design sprint, I did not show the process of adding a course into My Milestones in the prototype, however a further iteration could explore this and the other issues mentioned below in more detail.

To explore further:

• Differentiating between paid (verified certificate/signature track) courses and free ones
• Edge cases such as if a user joins a large number of courses
• “Due by x Date” vs “Due Tomorrow/ in x Days” language
• If an “Add/Remove” to MM button is needed from the course home page after enrolling, or if it should auto-add
• A reminder/push notification for when an upcoming deliverable is due

For Coursera, this exercise uncovers a potential way to decrease attrition rates to meet business needs.

For the curious, this touches on the depth of work behind a feature (and we haven’t even talked about implementation). One key takeaway is that seemingly simple tasks can be quite complicated!