"Everybody buys on feeling." - Tom Rinks co-founder of Sun Bum

Demo Magic

Live demos are hard to pull off because of the manual work required.

A live demo is the best way to demonstrate the power of Front to prospects, but the tool that sellers use to import an email live into an inbox is manual and slow.

I improved the tool by allowing a seller to import an email in one click.

The plugin tool now allows a seller to save a configuration of an email and then send it one click during their demo.

Now more live demos will happen, which means a higher top-of-funnel conversion percentage and ultimately more money for the business.

Before: 20 second, 10 click process.

After: 1 second, 1 click process.

The plugin, before and after.

What is Front you might ask? Front is a modern customer-experience platform that brings together all customer communication into one AI-powered collaborative workspace.

You can create a custom "plugin" in Front. These are web pages that have access to Front data and are embedded in the Front interface. Thus, this tool is custom built for sellers to import an email into an inbox, but is not a native part of the Front product.

I discovered the problem while giving my first demo at Front.

In early February, I was demoing Front to a potential customer and I noticed a major usability problem in the main tool used by sellers to showcase the product. I wanted to live demo the magic of the product: an email arriving into a shared inbox, our rules engine automating actions, and then real-time collaboration occurring.

"I'll now showcase an email arriving into the collections inbox, the email being automatically tagged, and then being round-robin assigned to the team."

I opened up our demoing plugin and began filling out the email fields: to, from, inbox, subject, and body. The pace of the demo screeched to a halt.

"So let me just take one moment to fill out our email importer tool." Cue me frantically copying and pasting information into the plugin and losing my train of thought.

My non-technical counterpart jumps in.

"While Jake is setting that up, I'll try to…"

The flow of the demo had been broken and it left Front looking unpolished.

Why live demoing even matters: live demoing is a more delightful and entertaining experience for prospective buyers.

As research shows, people make decisions based on emotion and justify it with logic. Thus demos should be an enriching and even entertaining experience for buyers. When this happens, more deals are won and the business makes more money.

Because of this manual and time consuming task to import an email live, it turns out that many sellers do not live demo, or only live demo a portion of their content.

Instead, they show existing conversations and laboriously explain what automations or history occurred.

So I set about trying to validate whether this was a shared problem and figure out how to improve the tool.

First, I asked the end-users of the plugin if they also experienced this problem. They resoundingly answered "yes."

Luckily, I work with the other end-users of this plugin. So I reached out to Solution Engineers who do custom demos frequently to see if they felt the same way. The sentiment was unanimous: yes they did.

"I've tried to structure my demos to where I'm only sending in one new message." – Last year's #1 Solutions Engineer at Front admitting the tool shapes how he does his demos, not the opposite.

"I don't use it during a live call because of the copy/paste required" - More confirmation of the pain point from another Solutions Engineer.

Now that I had confirmation this was a shared pain point, I created a visual explanation of how you could solve the problem to get buy-in from the engineering team.

It would be a simple solution that built upon the current tool but removed the manual process of filling out the email fields from scratch. The concept was a pattern that already exists: a template. This template would save a configuration of the email and its fields for later reuse or augmentation.

“That's an excellent visual explanation” - Software Engineer at Front who would be building the improvements.

The high fidelity mockups I went on to create were firmly grounded in the critical user journeys.

With no product manager to create user stories or a specification, I created these myself to solidify my understanding of the problem and serve as an underpinning for my designs. The functional needs should map directly to the designed user journeys. Here are three examples:

• Give plugin users the ability to save all the values entered in the Custom Email form as a template
• When wanting to send the same Custom Email again, users can choose to either:
  • Populate the fields from their template and make small adjustments before sending
  • Populate & Send which would populate the fields and send the email all at once for quickest use
• Users can name the templates upon creation for clarity

My designs were based on the existing design system. I reused components whenever possible while also identifying patterns that could be improved with this project.

In order to have a reasonable development timeline while ensuring a usable interface, I planned to reuse as many existing components as possible. Nonetheless, I identified areas to improve the design system, for example creating colored buttons, fixing some awkward padding issues, and removing unnecessary bold font in components.

The minimal design system that exists in code which I created in Figma components to be used for my high fidelity designs.

Upon receiving user feedback, I iterated on my designs.

When I received useful feedback from end-users on early versions of my designs, I incorporated their feedback to improve the designs before they were built. For example:

• Users mentioned that the lack of colors made it hard to quickly understand the action and severity of a button. Because of this, I added colors to the buttons.
• Users also mentioned that the copy of "Populate" on one of the buttons was unclear as to whether it meant populating the email in the inbox or populating the template into the form. Based on that feedback, I changed the copy to "Preview" which is much more clear.

Changes made on my designs based on user feedback.

The details matter a lot to me and I ensured the plugin was delightful to use.

Here are three of the user interface details that were important to maintain a discoverable and understandable interface.

• When users attempt to create a template with a name that already exists, they get immediate feedback before pressing the Confirm button – which would be disabled anyways!

• When users create or delete a template, they receive confirmation feedback in a clear location.

• Buttons are disabled when their actions are not possible or redundant. For example, you cannot use the Preview button again when you've just pressed it to load all its values into the form.

These changes had the desired effect.

Two months after launching these improvements, team members had on average nine templates created in their account. In addition, the amount of custom emails being imported into the demo environment increased 43% year over year in a given month. This suggests that quantitatively the project had the desired outcome of making it easier for people to demo Front live.

It should be noted that this entire project was self-directed.

All in all, I hope this project makes it clear that I love understanding how people use technology and utilizing my design skills to create solutions to help users succeed.