The Tech Content Creator Series is a monthly interview series in which I interview people in technical content creation roles (i.e. technical writers, documentation engineers, developer advocates, and what have you) about their careers. The goal is to inspire, motivate, and hopefully impact you.

Amy Burns is a Senior Content Designer at GitHub, where she works with the documentation team to make the GitHub docs better for GitHub users. Last month, after she announced her promotion, I sat down with her (virtually, of course) to talk about her journey into tech, her career as a technical writer, her promotion, and what she does as a content designer.

Me: Hi Amy, once again, congratulations on your promotion. That’s very massive.

Amy: Thank you. It was a hard fought for promotion.

Me: So content design? Haven’t actually heard of that before. How did you get into the field?

Amy: Frankly, I didn’t even know content design was a thing a year ago. I’ve been a technical writer since like 2013. Along the way, I found out that what was really of interest to me wasn’t the writing. What I really enjoyed the most was anything that involved finding out what the user actually needed from a piece of content and how to provide that.

So, a bit of background: I used to work as a technical writer at a startup, Xamarin. The startup was later acquired by Microsoft and I got moved to a P.M role. That role opened me up to a lot of skills like conducting user research. However, I missed doing documentation, so I joined GitHub as a technical writer to work with the documentation team.

Influenced by my former PM role, I found myself wanting to do user research to understand what users actually needed from the GitHub documentation. As is typical in most organizations, we usually create content from a business standpoint, telling users things like "here's how to make a pull request, here's how to do this". But the question is, is that what the user actually needs to help them get their job done? Is it presented in a way that makes sense to them?”. So, I talked to my manager about what I did enjoy doing and what I did not, and we basically created the content designer role.

Me: Wow. Awesome. I love that GitHub is accommodating and flexible enough to allow employees to pursue their passions within the org. So, I think I have a vague idea of what content design is, but could you please define it in a nutshell for the sake of our readers?

Amy: I would say content design is the process of creating content that is solely focused on the needs of the intended user. In the tech industry, we frequently create documentation based on assumptions on how we think that the user might need them. There is never any real research done on the actual people who use the documentation. Content design is a shift away from that paradigm, to using user research to find out what users need from your documentation and giving it to them.

For anyone looking to grasp what content design is, I’d recommend the book Content Design by Sarah Richards. In fact, I think it’s a book everyone who creates content should read. It’s very handy. The 'a book apart site' is also a great resource. They publish these short books on design and writing.

Me: So, have you always been a technical writer?

Amy: My degree was in computing and IT originally, and I started as a software engineering intern. It’s quite funny, I actually got that job through Twitter.  I know how to program, but it’s not just in my heart. I just don’t have the wherewithal to keep at it. But because I've always been interested in computers and enjoyed working in technology, I knew it was an industry I wanted to stay in. Fortunately, towards the end of my internship, the company opened up a position in the docs team and sort of poached me. It was in that role that I learnt technical writing. You know, back in uni, I never knew that technical writing was an option. I had never heard of it.

Me: Do you think that your computing degree and your programming background gave you an edge when you switched to technical writing?

Amy: My first reaction would be to say no. However, I think having that knowledge helped me be familiar with code and gave me a foundation. But, I must say, that the most important skill for a technical writer to have is empathy for the user. A lot of the technical writers I know don’t have a technical background. They sort of learnt it over time.

Me: Ok. Cos, I get dms all the time from people asking me how they can get started with technical writing. I always advise them to start with taking an introductory computing course, because I feel that knowledge is essential to gain some foundation.

Amy: Yes, I totally agree, and I think that ultimately if someone does not have the background but is willing to learn, then it’s doable.

Me: So, say someone wants to pursue a technical writing career. What advice and tips can you share based on your experience?

Amy: I think Twitter (I have to come back to this, cos it's pretty awesome), and sharing any piece of writing that they’re working within their network. Another way is open source. You can build up a technical writing portfolio through contributing to open source docs like GitHub, Microsoft. Most recruiters are going to be looking at your profile to see some contributions. So that’s a great base. Start with small issues and build up.

Another important thing to have is empathy. It will help you be in touch with your users and be able to create quality content for them. Ultimately, that’s what we do this for. We’ve all read bad documentation, and the experience is never nice.

Me: Hahaha. AWS comes to mind.

Amy: It's funny you say that because I used to work in iOS development. Despite all the good things Apple does, they do a poor job with documentation. So, in my time at Xamarin, I told myself that this was something I was going to make a difference in.

In our Xamarin docs, a lot of our users were like having to provision iOS devices. So, I basically overhauled that section of Apple docs focusing on devs what coming to the docs for the first time wanted to see. The rewrite had so much impact on our users. I still think it’s one of the best writing I’ve ever done. We even found out that iOS developers, who didn’t actually use Xamarin, were using our docs because it was much better than Apple’s.

This brings me to the fact that companies should prioritize documentation. Some companies hire a million developers and then hire one docs person. So, they eventually end up with poor documentation. They forget that everyone whose going to use their product will come to the docs.

And I think that’s why what you’re doing with this platform is very important: educating people about technical writing as a viable career option. We need more creative and smart people who care a lot about the end users; people who can think of new ways to present content.  

Connect with Amy on LinkedIn, or Twitter.