Project - Design Decisions | Tom Rowson

Design decisions which create leads

A project showing the value of careful UX design in attraction and retention of trial users, with specific attention to Product-Qualified Lead milestones.

The essentials

The project

Improve conversion rate of trials to product-qualified leads by reducing the effort taken to reach the "aha!" moment. This project was for a B2B SaaS platform.

My roles

Leading the review and redesign of the user flow, ideating and managing ideation among others, and collaborating with other parts of the business - such as product marketing and engineering - to place this in the context of a better overall experience for trial users. This project was particularly successful because of those collaborations.

The impact

A far greater proportion of trial participants successfully reached our chosen PQL milestone, and reviewers reported a significant improvement in time to value and the flow of the trial process.

Decision: Make clear recommendations to keep users on the Golden Path

During the trial set-up process, users are given a choice how to proceed. In order to give them the best chance of success (and unable for business reasons to remove the alternative path) we redesigned parts of the flow to guide them towards the simplest path.

For example, in this panel we:

Gave the simpler (automated) option a primary button style (the buttons previously had equal priority)
Changed the mascot style to make the recommended choice clearer
Added a hint (using the little placard the mascot holds) that the automated route is faster
Changed the copy on the options and the buttons to provide more context for the user's choice (and improved the content of the inline help tooltips)

Decision: Careful UX writing to reassure and educate

In addition to the example above we went carefully through the process, reviewing the copy end-to-end.

We considered the following:

Is all button copy clear in intent (and verb-based)? Will the user be able to understand what action pressing each button will trigger?
Have we introduced any terminology the average trial user of our platform would not understand?
- Could we use more generic terminology?
- If not, could we explain in context?
- If contextual help couldn't be guaranteed to help, could we link out to the docs?
Are all decisions clearly enumerated to the user?
Does the copy tell a consistent, coherent story from one end to the other?

Decision: Be clear about what the system is doing on the user's behalf

On the automated set-up path, the system takes over from the user and configures the trial using defaults. As well as providing the typical progress indicator for this process, we supported the user's understanding by:

Explaining what was being set up, with a checklist when the system completed each item
Offering links out to the docs to explore key topics relevant to their trial while the process completed
- These were carefully curated to push different user types towards the product-qualified lead milestones relevant to them

Decision: Choose to add friction to provide reassurance

During one review of the updated process, we discovered that several participants were worried that an automated process might not have been successful (despite progress indicators).

Our initial response was to try adding a success message alongside some other controls upon completion of the task. However, several users still reported that they were unsure the task had completed successfully; they were missing the message.

In the end, we went against instinct and deliberately added back in some friction to the process, displaying a very clear success message on its own modal which had to be actively dismissed in order to continue.

Decision: Provide clear options for first steps, based on Jobs to be Done

Once the system is deployed and ready-to-use, the user needs to understand where to begin. Before this change, they were simply dropped into the system and given the freedom to find their way around. For many, this led to them getting frustrated before they had even started.

We added in a step giving them links out to the parts of the platform they might want to explore, based on the product-qualified lead milestones agreed with the product marketing team.

Additionally, we chose to draw attention to the one JTBD the majority of trial users were most likely to want to complete.

Decision: Make the most important step as simple as clicking a couple of buttons

Once configured and in the right part of the product, users only had to add an item to the system to have reached one of the main "aha!" moments.

Before these changes, they would either have had to create an API from scratch, or import one.

In order to make this last step and simple and efficient as possible, we designed and engineered in options to:

Use a template API (this option was primarily for new users onboarding to an already-configured system, where another user might have added a template)
Use one of our pre-canned examples, which could be added with only one click from the next screen.

We added visual clues with the mascot design to support the decision, and paragraphs of help text, in deliberate contravention of our standard policy of reducing words on the screen.

Decision: Make day 2 as easy as day 1

Beyond simply reaching the "aha!" moments we'd defined, we knew that for the product to be sticky it needed to be as simple as possible to navigate and use on the second, third, fourth day of their trial.

In order to do this, we made the following key changes:

We re-ordered and prioritised the left hand navigation menu to focus on the areas which supported key JTBD
- We also added a 'favourites' feature so users could pin navigation items to the top of the panel
We added a new landing page with recent items front and centre; before this change, users would be taken straight to an analytics view. The changes meant:
- They would be able to instantly access the last few items they were working on, as well as performing some quick actions
- They would still have the highest level (and highest value) metrics available on the same screen
- Trial users would be given a tips banner, which linked out to a set of suggested activities in the docs

Even more we couldn't do...

These were the items we also suggested, which for operational reasons we couldn't yet implement:

Reduce sign up effort and increase security by allowing federated sign-up with Google, Microsoft and GitHub in addition to the existing email/password option
Bring the docs into the product to reduce the effort to find help, especially the page of tips for new starters. This would be achieved with a slide-out side panel contextualised to the page in question and user status
To remove even more barriers to getting started, create a sandpit version of the trial which would spin up a fully configured environment for the user to play with (more than just an example item or two), and which could be reset or torn down as needed