MGP Best Practice Community

MGP creates products for healthcare professionals. Access to these is free and the company monetises its products through sponsored emails and hosting educational resources.

MGP’s websites – Guidelines and Guidelines in Practice – were attracting an increasing number of users however the number of people registering was lower than expected and three out of every four people that began the process did not complete.

My role

Working as Digital Product Manager I led the redesign of the registration process and managed the bi-weekly builds and releases.

I lead on analytics implementation and investigated and developed new tracking for the registration process and “paywall”.

Discovery

MGP uses Google Analytics (GA) to gain insight into user behaviour. One of my first tasks on joining the company was setting up tracking so the company could understand how people were moving through the registration process. This highlighted a big drop-off as people start registering.

My use of GA brought more insight to the company and revealed 10% of users were visiting the sites on Internet Explorer 8 (IE8) (Yes, in 2015 and 2016!). Eventually I was able to access an IE8 browser and visit our sites which revealed our current registration process was inaccessible on IE8.

At the start of the re-design I reviewed the existing registration flow with members of the management team. The current process had seven stages. We reviewed whether each piece of information was still necessary and compiled a list of fields we could remove. We agreed that users could gain full access to the sites after the most important information was provided and we would ask for additional information during subsequent visits.

I then reviewed the current processes in terms of flow, usability, defects, dependencies and development capacity. From this I re-defined the scope of the initial release to include enhancements to the sign-in journey and a less painful registration process for UK professionals only.

Design

My first step was to generate new user flows. I reconsidered the order of each piece of information from two points:

1. Obtaining a user’s email as soon as possible so we could use this to build a relationship – even if the user didn’t finish the registration process.
2. Presenting the order of fields in a way that flowed naturally as if we were in conversation with the user.

I detailed revised registration and log-in flows in Bizagi Modeler.

I shared these documents with developers and this lead to the specification of several backend requirements to streamline the databases and allow for different user statuses depending on how far along the journey the user went.

Front end research

Initially I started with the mobile experience as the existing user flow was not mobile optimised and we had more mobile users trying to register.

First I reviewed each input type. Talks I had seen by designers at gov.uk highlighted the importance of input types and how data entry in text inputs can be more efficient than scrolling through drop-down menus, for example. Adding input types on the front end would bring up appropriate keyboards for mobile and speed up data entry. I saw research from others in the field showing input labels above form fields are more likely to be visible within a mobile viewport and make it quicker and easier for users to process. I also leaned heavily on two articles from A List Apart demonstrating how to incorporate client-side error responses with HTML5 and research explaining how this makes form filling more efficient.

The low-fidelity wireframes were proofread and artworked by colleagues.

Build

I met with developers and requirements were reviewed and sized. Next I selected the first batch of requirements to develop given our velocity and two-week-long sprints. Developers were removing fields we no longer needed, updating existing ones with new input types, and improving the appearance of the forms so they were slightly easier to fill in. And it was here we ran into difficulties.

Before we could release developers came back with new estimates many times higher than initially given. Not only did we have two going on three websites to maintain but each site catered for several users each with three forms. There were 24 forms in total and the way the original code base had been set up meant each form label and input had to be updated individually. The developers realised the work was going to take much longer.

With this realisation the technical team recommended we move the registration process to a new fourth site that the other products would link to. Instead of having forms for each user type one form would be developed that would be customised depending on which type of user was registering. This modular approach saved a lot of development time.

Moving to a new site meant we would not release the final code until the full process was complete. We worked over two months during which time I organised company-wide user acceptance testing every two weeks. I ran scripted (we had almost 150 scripts) and unscripted testing and we tested on three major browsers, mobile, tablet and desktop devices.

Analytics

Meanwhile I investigated tracking options for our registration process. We had started migrating our analytics tracking to Google Tag Manager. I used Simo Ahava’s excellent blog as a tutorial for building tracking functionality and a springboard for creating our own scripts. I was able to:

• deploy tracking that sends pageviews on the registration site to the Guidelines or Guidelines in Practice website properties (Ahava, 2016)
• track how long users spent within each field (Ahava, 2015)
• track which fields users interacted with before abandoning the process (Ahava, 2015)
• segment article pageviews according to those that had the log-in form and those that didn’t
• understand how users interacted with the log in form

.