In-app Help

Role: Lead UX/UI Designer

Summary

Trial to paid subscription conversion rates had been dropping continuously for two years. I lead design for this project while working on the conversions team at Squarespace. Our goal was to mitigate trial abandonment by making in-app help more accessible to everyone.

Problem

How can we make help more accessible to users in their trial? Data showed that users who were able to access help in the first 24 hours of their trial were 80% more likely to convert to a paid subscription plan. Users who added/changed text or pictures to their sites in the first 6 hours of trail were 95% more likely to convert to a paid subscription.

Process

After collecting all of the analytics for trial conversions, I looked at how in-app help was currently functioning. I found that help was only available on the root menu for the editor, which meant that any time you were in any other menu panel (design, pages, settings) you couldn’t access the help site.

Help in the root menu

Users couldn’t find help in other panels

I wanted help to be available to users at all stages of editing whether they were in a panel or editing content blocks on their site. I had to account for different widths, viewports, and color schemes as well. Whatever I designed needed to not block critical actions the user was taking and it needed to be visible on light themes as well as dark themed websites. 

While I was doing research, engineers came to my office hours and told me about a shortcut in the editor that allowed you to type in the exact name of a panel you wanted to go to “font:style H1” and it would jump you to that panel. A lot of users were struggling to find where they could edit their site styles (the design panel was buried 3 clicks deep) and this felt like an incredibly useful tool to point users in the right direction. I decided that I wanted to combine the quick links with the help guide in the widget. I wanted the search to be contextual as well so that when a user searched for something like “How do I change my fonts” they would see quick links as well as “how to” articles to help them. I brought this idea to the engineers to see how feasible it was technically, and everyone was on board. They said it wouldn't be hard to repurpose the code they were already using for the quick link shortcut into the help widget. 

Screenshot - search shortcut

Wireframes - default home screen

I started by making wireframes of different design and layout ideas I had. I spent the most time working with the search interaction, I wanted to make it clear that the quick links were taking you to a different page in the editor but also show the user the path to get there to educate them to find the panel on their own in the future. 

Wireframes - different search iterations

After a few rounds of wireframes, I started building a fully functional prototype in Principle to use for testing. We brought 8 users into the office to do user testing with the prototype measuring their expectations as well as reactions. We asked the users to change the text on their website without any other guidance to see if they organically saw the help widget (6/8 did). 

After usertesting I went back to the wireframes and started cleaning up the visual design. I went through a few iterations of the search interactions as well as the default screen before taking it to the team for a design critique.

Solution

The in-app help widget searched cross functionally through the editor for quick links as well as the help site for guides. The default home screen had quick links and articles focused on guiding the user to edit text, add images, and change design styles (the 3 actions we found through analytics lead to the highest conversion rate to paid subscription).

Final comps - widget, home, help article, search

Final comps - search states

After the user interacted with the editor, we made the help widget smart enough to make suggestions on what they should do next. Oh, you just added an image? Do you want to know how to edit or crop the image? Etc.

Final comps - contextual homescreen

Final comps - contextual in panel

In addition, help was removed from the root panel of the editor so that it was available at every stage of editing the site. The pill's elevation was higher than the canvas and was omnipresent on every page. 

Metrics

6/8 users tested were able to organically find the help widget and complete the task assigned to them. I also tested comprehension of quicklinks vs articles and other interactions within the widget. “If I am reading an article and close the widget, if I open it again does it stay on the article?” yes. One of the most helpful points of feedback to come out of testing was that when users are reading an article they want the option to open it in a new tab and be on the help site, so I added that feature post-testing.

We used the zendesk API to launch an MVP with the help widget. The launch of the MVP saw a 20% increase in people accessing help with a 7% increase in conversion rates overall.

Learnings

In making help available everywhere in the editor, we ended up with a weird interaction state in full screen edit mode. If you have the widget open while you add content blocks, 80% of the content being edited is covered by the help menu and the block contextual menu. I think a way to improve this would be to have a different visual state for help in the editing state. One possible solution would be to make the help widget open as a drawer on the left.

Final comps - help in editor

If I could do it over - potential solution