THE SMITH FAMILY

EXPERIENCE AND INTERFACE DESIGN OF DIGITAL REGISTRATION FORMS FOR AN AUSTRALIAN CHILDREN’S CHARITY

PROJECT SUMMARY

This project focused on the design of online sign-up forms for enrolment in educational programs.

RESPONSIBILITIES

Responsive UX and UI Design
Design System
Prototyping and testing
Stakeholder Research
UX Copywriting

TIMELINE

7 Months

OVERVIEW

The Smith Family was issuing paper based registration forms to students for educational program enrolments. This paper-based process was wasting thousands of hours in manual data entry for TSF Program Managers.

My role was to design the digital program registration experience so that the majority or registration details could automatically be added to the CRM database.

From this...

...to this

The Smith Family needed to convert the paper-based registration process to online by finding a flow that would allow parents to quickly and easily register their children into educational programs.

Target Audience:

Parents of school-aged children from 5-18.

PROCESS

(Click to enlarge)

SCOPE AND
CONSTRAINTS

The functionality and field design had to be consistent across all 14 forms where possible.

I was constrained by use of Sitecore Forms for the development phase. This would create limitations around the design of UI components and dynamic field behaviours.

I had to take a modular design approach so that each of the forms could be made in a template-like fashion.

Forms would be developed with Sitecore Forms

ANALYSIS

Paper form sample

(Click to enlarge)

UNDERSTANDING THE PROBLEM

I read through all of the program registration forms and proposed a screen flow for each one, using a progressive disclosure approach, to assist with focus and error prevention.

I broke each form down like this, into sections to make it easier to consume.

(Click to enlarge)

Stakeholder workshop notes - sample

(Click to enlarge)

RESEARCH WORKSHOP

I copied the flows into separate Miro boards for workshopping with stakeholders (Program Managers and Program Coordinators).

Rather than create wireframes from scratch, it was quicker for me to work at a mid-fidelity level because I was able to borrow from the organisation’s pre-existing component library.

Stakeholders were encouraged to use these category notes to produce feedback in the workshop.

Discoveries:

Some of the forms were quite long and they were often not properly filled in by users.
Sometimes the forms were being completed by children because their level of English proficiency was better than their parents.
Certain questions had become redundant and could be eliminated.
I could reduce the lengthy 'feel' of the forms by breaking them down into common sections.

PROBLEMS

We decided to abandon the idea of allowing students to register as it became a problem when they got to the section requiring parental consent.

Decision:

It was more logical to design forms using language that just talked to parents.

Student signup proposal was abandoned

Many of the forms were being filled in by people from non-english speaking backgrounds. This meant language choice was very important.

Decision:

There were questions that were unique to each form so it was not possible to make a ‘one size fits all’ form.

Copy used was very important for error prevention

T & Cs were very inconsistent across forms

Click to enlarge (text obscured due to NDA)

The legal T & Cs (declaration and consent) had been built up over many years and had become lengthy and inconsistent for each program registration. This section needed to employ common language throughout, with only slight nuances of each program.

Decision:

The Declaration and Consent section was inconsistent from form to form and this would require professional legal advice make forms consistent.

LEGAL

LEGAL CONSIDERATIONS

I met with the Smith Family’s Legal Counsel to demonstrate the inconsistency of the declaration and consent for each program. She provided us with succinct wording that contained plain english. She gave advice over the nature of the language that could be used.

(Click to enlarge)

FRONT-LOADING POLICY INFORMATION

I front-loaded the privacy and child protection policies to reduce the length of the form. By placing hyperlinks to text-heavy documents outside the registration process, we could allow the user to make a choice about whether or not to read it.

Considerations:

The form would also have a 15 minute access period before locking the user out (for privacy reasons) so the registration process had to remove any potentially time-consuming reading tasks.

This was achieved by adding hyperlinks to the form registration landing page, before the user starts the registration process.

POLICY
ACKNOWLEDGEMENT

I created an overlay for policy acknowledgement. This would be displayed when the user clicked register/login. I had been given legal advice that the reader had to agree to these documents before they could continue with the registration.

The privacy policy overlay reduced policy reading and provided a faster signup

(Click to enlarge)

EFFICIENCY

(Click to enlarge)

SPEEDING UP THE EXPERIENCE

I designed a simplified flow for each form that would only present questions relevant to the user by making use of dynamic fields (conditional formatting).

I eliminated some questions and created new ones by adding dynamic fields to the form design. This meant certain questions would only need to be displayed depending on previous selections that had been made.

Authenticated login (left) VS New User (right)

(Click to enlarge)

I also designed a subset of alternative form flows for users who had previously registered for other programs (we called them ‘Authenticated’ users). The Authenticated version of each flow was designed to save the user time by pre-filling information by pulling data from the CRM.

HANDOFF

HANDOFF / DESIGN SYSTEM

Using Adobe XD, I created a UI master template that aggregated the fields used across all 14 forms. I used the 8 point grid system which was already in use at The Smith Family. It acted like a Design System where everything could be recorded in one place.

This provided the developer a place where he could reference each and every component, and quickly find information on spacing and advice on interaction and dynamic behaviour for relevant components.