Contextual, in-product help

Content designers at Atlassian also own the support documentation experience. After some years developing a modern content management system (CMS) - one that serves content as a service through an API, rather than static web publication - I set out to show what our create-once-publish-everywhere approach to content storage and delivery could do for our customers.

Our support content wasn’t healthy. As measured by a “helpfulness score”, we found that 1 out of every 3 support documentation visitors self-reported that they weren’t helped by our content. I set a big, hairy, audacious goal of raising that metric to 8 out 10. I wanted 80% of helpseekers to say, “yes, that was very helpful, thank you.”

The brief was straightforward. From feedback channels on our support websites, I identified that content relevance was a big pain point for our help seekers. Around 20% of feedback showed that customers were either directed to content that didn’t apply to their situation, or was incorrectly supplied during search experiences.

I wanted to test a hypothesis about supplying help content directly in the product, personalized to the product experience and current task of the user.

The process

My first experiment was during a hackathon. The team consisted of myself, another content designer who could help execute on short-form help content, and a front end engineer. In 24 hours, we rented a solution called Elevio, and wrote 5 targeted articles for onboarding to Jira Service Desk. We associated product actions linked to activation (like inviting a new user) with specific help content to see if reading contextual help improved product engagement. Elevio allowed us to serve suggested articles based on the user’s URL. If they were looking at the product’s queue feature, for example, and reached for help, we served suggested articles concerning the queue feature and associated activation tasks.

Jira Service Desk productionized this experiment and expanded the content set to more key actions and journeys. But, it wouldn’t last long. Elevio changed their pricing model, making our service outlandishly expensive. During this period, I pushed and convinced the business that there was value in the concept, even if the tooling wasn’t right. I was able to secure two contractors to build out an in-house solution that integrated with our in-house CMS, Contentful.

Before getting started building, I led a strategy project to ensure the experience contributed to both customer needs and business goals. The strategy exploration involved defining a core strategy statement, editorial approach, experience vision, systems approach, and defining the people/processes needed to maintain the experience after it shipped.

To define the strategy, I led a small team, including a contractor visual designer and a contractor front-end developer, in exploring:

• Competitor analysis and help seeking trends across the tech space
• The moments and mindsets of help seekers as they approach documentation (through customer interviews)
• Problem definition and framing
• The jobs to be done that would define the experience
• Success measures (goals, signals, and metrics)
• Rapid and broad ideation for addressing the problem and customer jobs

We shipped an MVP experience to a relatively safe section of the Jira Software experience, at first. Since we built a bespoke solution, we were able to further explore the contextual nature of our help content. Rather than tie the experience to the URL only, we leveraged the products’ navigation router to interpret where the user was in the product experience and what they were likely trying to do. We implemented 2 different types of context: a direct context from a learn more link, that surfaced a specific help article; and an indirect context from the generic (?) help icon, that surfaced a list of suggested help content based on the user’s location and recent analytic events.

After analysing the results, we expanded to further parts of Jira Software. After more analysis, we revamped the design, incorporating feedback from users and stakeholders, and built out a standard web component for any Atlassian team to use in their own product space. That component was picked up by several product - Jira Service Management, Jira Work Management, Confluence, Jira Product Discovery, and eventually Compass.

My role shifted from driving the experience strategy and design execution, to consulting teams on implementation best practices and advocating for teams to adopt the solution.

The outcome

Our early experiment with Elevio showed that users were more active in their product after seeking help, and more successful in carrying out key actions. This built confidence in the solution and pushed Jira Service Desk to adopt it formally.

The experience strategy documentation we created to guide the experience throughout the years has been held up as the gold standard in product/content design strategy work at Atlassian.

Our MVP experience showed a number of results:

• In-product, contextual help content showed a 20% improvement in self-reported helpfulness scores, getting us much closer to our 80% helpfulness goal.
• Customers were 16% more likely to try new features after reading about them in help articles, in context and in situ of the product experience.
• Help seekers who read in-product help complete key product actions faster, more frequently, and over a longer period of time.

Anecdotally, product teams raved about how easy it was to implement a help service in their products. Developers at the team level wrote internal blog posts encouraging teams to include in-product help as part of their definition of done, simply because of how easy it was to implement and the value they believe it drove for their experiences.

This help experience, a personal project of mine, was fully funded in 2022. Atlassian funded a full product team (a PM, designer, and several engineers) to support this experience as it expands to more and more products.

I later helped expand the experience to include feature-flag-aware release note content, directly associated with the code as it’s deployed. But, that’s a whole other project in itself.

What I learned

This was a true case of using experimentation to build confidence in that value of an experience. I started scrappy, with a rented solution to prove the concept. Then, I moved into higher and higher fidelity, wider blast radius, and more complex use cases as we went. Some people call this Lean UX, but I never really fully grokked the term until practicing this approach during this project.

I learned a lot about storytelling and repetition. Since this project was never truly funded by Atlassian until the late stages of its development, I spent a lot of time learning how to advocate for our users and champion a solution that works for both our customers and the business. I learned how to speak product management, including learning SQL and what metrics were needed to tell a compelling business case. I also learned how to format strategies and recommendations so they inspire action from the business. Some of the best ideas die simply because we don’t take the time to communicate them properly.

I grew immensely over the life of this project. It was one of the first that I led completely autonomously, out of a desire to help the users that need it most - the ones that are lost and confused, that aren’t the bill payer or the admin, who may be forced to use a product they find complex, who are just trying to do their jobs in a modern age. I learned a lot about how to amplify their voices and prove the bottom line of experience-driven development.