Elements within Cambridge One pattern library.

Designing Cambridge One

The Press was one of the estimated 69% of companies who used agile processes to develop products. Among other things, this meant splitting their new online learning platform into nine key areas – with responsibility for each part given to one of six scrum teams.

As an Associate, my role was to support the sole designer embedded in one of these teams with their user stories. While this started as pure UI, it evolved – firstly into structural tasks (e.g. flows and information architecture), and ended with me acting as a de-facto user researcher, supporting all teams by conducting testing.

So how did this work?

For confidentiality, some information may be hidden or omitted. Design intention correct as of January 2020. All screenshots can be found on Cambridge One.
Cambridge One designs.

Background

English Language Teaching (ELT) material published by the Press generally targeted one of three markets; primary (age 5-11), secondary (11-16) and adult (16+).

Cambridge One, an online environment in which teachers and students could access all of their ELT material, aimed to follow this. However, accounts for primary and secondary age learners did not exist when a minimum viable version of Cambridge One was released in December 2019.

This article explains how a design solution was reached for registering primary age learners.

The problem

With only adult registration designed so far, there were countless questions about how primary would work with this.

Answering these would determine if primary registration could use the same process, or if a new flow was required.

  • Where did primary learners go to register? Did they use a specialist page? What would its URL be?
  • How did they register? Did they have email addresses?
  • If not, how could they register without one?
  • What data could be requested and held about children?
  • Who was in charge of a child account – the child, their parent(s) or their school?
  • And so on…

But was child registration a unique problem?

Adult registration flow.

Research

The answer was no.

Because of this, initial research efforts focused on two things – what users would expect to happen, and what happened on other platforms used by children. And so;

  • The product owner sent out a questionnaire to school administrators, teachers and parents asking who they expected to sign up learners of varying ages.
  • I spent some time trialing various registration and onboarding experiences for websites and apps aimed at children.
It was hoped that tackling the problem from different perspectives would highlight consistent trends.

Our findings were interesting. The vast majority of websites and apps designed for children required their account to be set up for them (normally by a parent). However, for Cambridge One, who would do this was unclear – with stakeholders having different opinions.

This debate was ended by the results from the questionnaire, which indicated that a parent should set up the account of primary age learners. Because of this, the decision was made to allow parents to register their children.

Responses from questionnaire sent to administrators, parents and teachers.
I was personally surprised by the results, as setting up a learner’s account seemed to be something the school (specifically admin) should do. However, these results were taken at face value.

The Product Owner had also been able to answer some of the questions in the first section. We now knew that primary learners would have their own URL, and that they would need to have a username to sign in. This would be valid across the entire site.

Flows and sketches

As a parent, I want to set up my child in C1 so that they can do their work.

Armed with a newly created user story, I started to sketch potential primary registration flows.

However, this was made challenging by to the fact that any solution had to fold into the existing architecture of Cambridge One – while also being flexible enough to adjust to any future changes.

Primary registration initial flow.
Legally, people aged 13-16 could be treated as an adult or a child (depending on their country). A business decision was taken to treat all under 16s as children, meaning secondary age registration ended up using the same flows as primary.

It quickly became obvious that this process had two parts. Parents would first need to sign in or register before creating an account for their child. As parent registration could reuse procedures used for other user types (e.g. teachers and adult learners), true design effort was only needed for the second portion.

Because of this, the user story changed from “primary age learner registration” to “proxy child registration by parent”. The main designer in the team then created sketches to visualise what this could look like, with the flows also having been amended.

Sketches for child registration by a parent.
The initial flows had usernames and passwords automatically generated by the system (to maintain consistency with previous designs). However, an additional step allowing parents to choose these was later added.

UI and testing

Thanks to our pattern library, these sketches could quickly be turned into interfaces ready to be handed off once they had been approved (see note). With stakeholders satisfied that the developers would definitely have something to build, it was only now that attention moved to testing the proposed solution.

Again, the findings were interesting.

The main surprise of testing was that the majority of issues were with parent registration section – which used flows implemented elsewhere on the website.

Parent account setup issues

  1. Confusion about the account type being registered (e.g. teacher, learner).
  2. “Your country” seen by people as either nationality or residence.
  3. No clear way to resend confirmation email, often leading to abandonment.

Child account setup issues

  1. Uncertainty about what the class key was, and where to find it.
  2. Ages of primary and secondary learners differed by country.

Problems we didn’t know existed were uncovered due to testing. But with the designs already being built, what could be done?

NOTE: I personally feel that testing should have happened at the sketch/wireframe stage. However, the Design Team did not have the capability at the time to carry out this in the timescales required. We now have shorter testing lead times, due to my work designing a new testing process after my role changed to that of a de-facto user researcher.

Next steps

Prioritisation matrices played a major role in determining what actions were taken in response to the results.

For items that required low design effort to return high user value, the solution was obvious – fix the problem ASAP. Changes that were made as a result of the findings detailed in the last section included;

  • adding user roles to the registration form,
  • creating a resend email confirmation button,
  • making the entry of a class key optional.
Screens redesigned because of testing results.
Fixes for low design effort, high user value items were created within a few sprints of the problem first being raised.

Things that needed little design effort (but gave low user value) were generally put into the sprint backlog, with plans to include them when there was time (e.g. the “your country” microcopy on registration forms). In some cases, incidental research and testing produced findings that were used to inform design decisions.

Research revealed that “your country” was seen as residence by teachers – but nationality by learners.

High user value items that also required a high amount of effort (e.g. ages of primary and secondary learners differed by country) were usually de-prioritised due to tight deadlines.

These were added to the mounting UX debt, with the aim to reopen them once focus had switched to refining Cambridge One.

Articles in the "Cambridge One" series

Want to read more?