Designing experiences with information

Daniel Stevens
Designing Atlassian
12 min readAug 10, 2018

“Nothing much has changed in Technical Writing for the last 25 years. I want you guys to change everything about the way the world thinks about technical writing.”

-Andrew Prentice 2014 (who gave us this touchstone as a mission)

Nothing like a big undefined challenge to unleash ideas! It’s a permission slip to take all your toys apart and put them together in different ways. My Information Experience (IX) team started working with other teams and their toys about three years ago. Together we’ve been designing better experiences, with information.

Information Experience and my team

Information experience at Atlassian is somewhat unique. Each of us consistently “cross the streams” between being a writer, a designer, an analyst, a researcher, and a strategist. It’s a challenge that prepares every IX writer to work closely with, understand, and apply a variety of research. This is critical to our vision of creating end-to-end information experiences and understanding if they are successful.

There is so much to say about how we approach information, documentation, and content at Atlassian that we can’t possibly capture it all here. There will be other blogs from other writers about what content means and how we work at Atlassian. For now we’ll define a few things and hopefully you’ll see what IX is from the actions my team and I take.

Touchstones that guide our work

My team uses these touchstones to design information experiences. It is how we steer our work. We are vulnerable to tight deadlines, short development cycles, and shifting resources like everyone else but we do our best to apply these to every piece we develop.

Hypothesis: Humans will more readily accept and adopt things which they can place in the context of a story. The more coherent the narrative the more pleasing the experience.

Experience: The experience we design must inform the user’s journey:

  • Functionally: you are able to understand and complete functional requirements required for a successful outcome
  • Perceptively: you see success before you even begin (this one’s a bit tricky to describe)
  • Emotionally: you are confident and supported on the journey to success and the software feels human not mechanical

Primary goal: To create an information experience that feels human, helpful, and leads to success for you and your team.

Bridging the gap: Fill the information/experience gap between the messages you receive before you log into an Atlassian product and the messages you receive in the form of:

  • Introductory states
  • Blank states
  • Directional and instructional text in the app
  • UI copy and its connection to user expectations and perceptions
  • Documentation and how it supports different functional journeys
  • So much more

On persuasion: Everything we produce must be technically accurate and complete. When and where we use persuasion, it should always be in support of the user’s experience and in their best interest.

Our tone can be persuasive but not beyond what is functionally possible and supported.

Making the connection

Here are just a few of the places a person might have their first (or 51st) information experience with Atlassian:

List of Atlassian sites someone might first experience our information

When we connect the stories from those sites to the experience you have in our products we create a complete narrative. You begin in a microsite, an advertisement, or a blog, and our IX team helps you implement what you’ve learned. When we do this well we support, reinforce, and direct the user’s journey to success by understanding and anticipating user expectations and perceptions across their information journey.

Early lessons

In 2014 I wrote “Write Measure Repeat” about how we can use growth marketing tactics (metrics, data, and success factors) to understand how our content was or was not working. In those early days the idea was to work more like software developers by building a set of reusable patterns that were measurably successful.

We learned:

  • That the connection between learning a process and a product is critical
  • That marketing has much better data tools and habits than we do
  • That we can measure, influence, and encourage behavior
  • That we can understand success better

We made a start on creating reusable patterns and how to measure them. Establishing and understanding those patterns now falls to another IX team who are developing patterns we can use across all of Atlassian. The real lesson we learned, though, is what led us to where we are today.

Creating collaboration

In a strange way this is actually the beginning of the story. It was just me and an idea about connecting stories. That early experiment with growth tactics showed me that if we constructively helped people learn processes (Git in this case) we could increase their success. That success led to a better overall experience with our product. So we began working with our marketing, content, and brand teams to start connecting the “stories” they tell about products, teams, and methodologies (like Agile and Git) to the experiences we design for our products you’ll see how next.

Connecting the Git stories

Change starts in small places, with small actions. One of those changes started with me walking over to Justine Davis’s desk and saying, “Hey, do you own the Git microsite?” That conversation turned into our first early partnership with marketing.

We decided to create a bridge from the Git microsite to the product with a simple, single tutorial and clear call to action, something like “Try this in Bitbucket Cloud.” We entered into this experiment with a few caveats:

  • The microsite remains centered on teaching Git for any team anywhere no matter which service they choose
  • The transition to the product tutorials must be subtle (but in no way deceptive) and directly connected to the mission of teaching Git

We connected the user story, the git story, the marketing story, the onboarding story, and the user acceptance story into a cohesive experience. It all begins with someone who searches for Git, that’s the pre-user story.

Search results for “what is Git”

Selecting our link from search is how they move to the Git story. We also open the door to the marketing and Bitbucket Git story with the interactive tutorial link. All the pathways are driven by user choice, our job is to anticipate those choices and provide easy paths.

What is Git landing showing Ready to learn Git? link

Information Experience picks up the story when they select the interactive tutorial.

Learn Git with Bitbucket Cloud tutorial page

Now we help move the story into the product itself. We’ll be using the results of this interaction more as we build better solutions.

Short survey about git experience

We direct and encourage the user to complete the set up process which completes the connection to product.

Bitbucket repository set up

We expose guidance but the story belongs to the user again, they drive the action.

Create repository modal showing selections with template and tutorial option

Progressive disclosure provides additional guidance and links back to the tutorial stories. They can follow the tutorial end to end or we’ll help them play in the sandbox.

Repository set up page

Then the information experience shifts to functional assistance because you don’t need a whole tutorial to clone a repository. Documentation still has a role to play in the experiences we design.

Clone a repository documentation page

What isn’t visible in this example is the user following the tutorial as they go. The text and terminology in the product are specifically designed to blend together with the tutorial.

Results matter

We weren’t sure people would sign up for Bitbucket essentially just to learn a concept. But, they did, and in the thousands. So the marketing side of the equation worked, huzzah! But, that’s not the half my team wants to measure most. We cared about making a better experience for anyone who uses Bitbucket Cloud and that is much harder to measure. What we do know is that people who signed up after the tutorial were more likely to stay.

Since then we’ve continued to contribute to the site where and when it can help people have a better experience using Bitbucket. We’ve also contributed a few short, single task, videos that are ranking well and will become part of that information experience. Finally we connected the experience outside the product to the UI. This is where the whole idea of end-to-end experience design starts becoming real. We are so glad that the marketing team took a chance and let us try something new.

Expanding the partnership

One of the big advantages of that early partnership was proving half of our goal: the marketing win. Now we needed to capture that win but not end up marketing writers (we love our marketing writers, they are awesome, just not our cup of tea). Around this time Claire Drumond, another brilliant marketing team member, was wrapping up comprehensive research on the buyer journey and how our documentation was both helping and hindering customers.

Claire and I started talking about where her research and goals meet our research and goals. We discovered quite a lot of overlap. We both wanted people:

  • To find the right information at the right time
  • To help people adopt our products and get value quickly
  • To feel confident using our products to lead teams and get stuff done

Not a bad place to start building a strategy.

We knew people were using our documentation as part of their decision making. What we didn’t know was how it was hurting the information experience and creating confusion. Claire found that many people who were trying to learn about the agile were landing on Jira documentation. Worse, they were landing on documentation for an old version of Jira Server so even the functional information was wrong, for most people. The positive side was that this was something we could act upon.

Fix a problem and grab an opportunity

We knew people were not finding the best agile information from search. We also knew that our “connect the stories” approach could help people who wanted to apply Agile methodology in Jira Software Cloud. With this in mind we took on one problem (search resulting in old information) and one opportunity (connect the agile story with the Jira experience) and got to work.

Execution plan — part one — search paths

Let’s start with search results, we had two core objectives:

  1. Get people to the right information in the right part of their journey
  2. Channel the audience to better content without loosing the audience

We defined success for different people and teams, did a few user journeys, and mapped the best content to each touchpoint in a journey. We took all the pages people were landing on mistakenly, listed all the titles and short descriptions, and built a comparison list to search metrics results. Our SEO, marketing, design, and IX teams all worked toward our objectives and the result was our strategy now had part one of an execution plan.

Execution plan — part two — connect the stories

To connect the stories our objectives were:

  1. Give people a path to learn the what and how of Agile development
  2. Influence expectations so people always think “Wow, I can do this”
  3. Help teams do Agile well with Jira Software Cloud
  4. Provide a better experience for every software team

We reviewed more data than we even knew we had: customer interviews, usability tests, analytics, marketing data, user flow, and more. We then combined that data with our user journeys and started to understand what content we needed to fill in the gaps. We now had part two of an execution plan.

Execution is everything

All the best hypotheses, designs, plans, and data are meaningless if you cannot execute effectively. We aligned our collaboration early and stayed connected throughout the whole process so we knew and trusted each other.

Claire Drumond really deserves the credit here, it was her plan, persistence, and strategic initiative that got us from idea to experiment.

Here’s how we did it:

I got Content Designers Kevin Bui and Hannah McKenzie working on new tutorials that would provide the transitional elements from concept (agile) to product (Jira)

We evaluated titles and search metrics. From that data we created new titles for several pages in our documentation including the one that was killing our SEO for agile. That page now looks like this:

The old page was the main reason people got to the “wrong story.” Now, it gives a variety of choices and people don’t waste time on the wrong information. I’d like to emphasize how much work it was to get this part right. It’s not easy to show in a flashy screen shot or diagram but this was a HUGE win.

When they click a concept link they return to the Agile story:

We’re still working through the UI interaction to connect this story to the product and I think we’re about to nail that one.

We revisited the whole journey, decided not to create an experiment, planned a publish date, defined success, and developed the metrics and data to measure it.

We asked other teams to restrain their efforts just a bit so we could get clear evidence from our work.

We took a deep breath and published, pushed, changed, and aligned all the changes across three organizations.

A lot of the details are missing (like about a month of work) but that is how we put our execution plan into action.

It worked!

We started getting data pretty quickly and the results were encouraging. Some were very encouraging:

  • The redirects were the first big win. We captured our audience and sent them to more relevant content.
  • The search results came along a little later but now the top results lead you to the appropriate content.
  • The new tutorials are gaining audience, ranking, and improving the experience of anyone learning Agile with Jira Software Cloud.
  • The people who came through this path were more likely to adopt Jira Software Cloud and the comments were positive.

It was much of what we had hoped for and more. Early evidence from customer interviews, surveys, and NPS all indicate we also built a better experience, though we’re hesitant to make that claim just yet.

Most important we gained new partners, new insights, and better ways to design experiences with information. So watch this space, cause we’re just getting started!

From an idea to an organization

We built the Information Experience team at Atlassian to take on new challenges and we’ve been successful beyond our own expectations.

Now it’s time to take another leap! We are taking all these ideas and so many more and creating an entirely new organization to deliver what we’ve proven at full scale.

Content Design

With Karen Cross as our new Head of Content Design this new organization will take everything we’ve done in Information Experience and push it to the next level. With an approach to content as part of the journey for every user we’re all excited to see what’s next. We’ll be expanding our team to include other parts of the content domain and a vision of a better content future. That will be Karen’s story to tell, though I expect my team and I will be writing a few chapters.

Just a little credit
I’ll take just a little credit for helping put great ideas together with brilliant people. In most cases the brilliance you need is sitting somewhere in the same building. All I did was find, influence, and connect them.

One last thing

If you’re thinking “I could never do that,” it all starts with one person saying “Hey, I’ve got an idea” and one person saying “Sure, what’s up?” There are hundreds of untapped ideas waiting to be captured in every company.

Perhaps you can…

There’s a revolution happening in content and I want Atlassian Content Design and my team to help lead the way.

Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.

--

--

Daniel Stevens
Designing Atlassian

I create content design for humans across the world of work and believe humankind still has a bright future to grasp.