Build With Users Curated #1
A new format to end the year with a bang! 💥 Happy Holidays! 🎄
Heyyy there! 👋
Me, Gino, Steven, and Lennart are grateful you’re following along! Reflecting on 2020, we’re excited that we started this publication and that we’ve had such cool responses on the interviews so far! So… we’re definitely continuing that 👏 But…
…We’re also finding a lot of amazing content as we’re navigating through everything in the world of community ourselves.
That’s why we’ll start playing around with a brief bi-weekly mail in a different format that shares some of these things. Let us know how you like it as we go! (comment on an issue, or follow & Tweet us)
This very first one happens to have a bit of a theme. Recently, we started to dive deeper into developer communities. There are a ton of things to learn from them, and a lot of relevant topics for developer advocates and community managers in the space of developer and low-code / no-code. One of them: user documentation.
We organized a Jam (virtual meetup) on the topic this week, and you'll find something about this and related curated content in the Favorite Five section👇 Enjoy!
Hit the subscribe button (if you haven’t yet) and get a heads-up on the next issues! 👇
For our returning friends that love the content we’re putting out: we’d be grateful if you’d share some ❤️ on Twitter or share Build With Users with friends & colleagues!
🙋♂️ Build With Users Jam on User Documentation
Last Tuesday we ran an informal virtual meetup discussing the topic of user and developer documentation as a way to make community members and (potential) users of your platform more successful. It was a great one! 🎉
When you write anything that is going the be read by many people and is meant to bring across an idea (eg. a book), you will probably not write it out once and send it to a publisher.
That's because you know that your initial write up isn't perfect. Instead, you will probably share it with proofreaders, ask for feedback, and make revisions until you feel confident to publish it.
Interestingly enough, many software teams have similar ambitions but write and publish documentation in one go 🤯. Obviously, a book can't be revised after publishing. But online documentation can. Nevertheless, a lot of documentation is published once and doesn't receive much attention afterward.
And that is, if there is proper documentation at all because that can be a real challenge too. Keeping up can be extremely hard when new features or iterations are shipped often as the platform and community grow.
However, if you want some portion of your customer base to adopt your product/service independently and in a self-service manner, you need to take documentation seriously.
Especially, when your target customer is a developer. In that case, documentation = product, and thus part of the developer experience (DX).
We chatted about this topic and its challenges with a few of our readers and people interested in the topic. A big thanks to Angela, Femke, James, Julie, Katelyn, Romy, and Romaric for joining the Jam! ❤️
Here are just 3 very practical tips shared in this Jam to help you keep documentation on-points for the folks that are into this topic:
Use notifications in Slack to sync between development and customer-facing teams. It keeps everyone up-to-date about newly added or updated features. This transparency contributes to keeping documentation up-to-date.
Use search queries entered by your users in your documentation tool to pinpoint missing or insufficient documentation.
Do user onboarding sessions to see what people are struggling with and which questions they’re asking. Use these as input for your docs. Good tip, Angela!
🖐 Favorite Five
In every one of these bi-weekly issues, we’ll highlight at least one cool read, video, podcast episode, tool, and person to follow on Twitter. You’ll find some mixed resources with an emphasis on User Documentation for this issue.
📖 Favorite Read(s)
Deflect support, impactful open-source goal
3 min read – Most founders don’t realize that contributors and users are also the best people to write documentation, explain how to use the product, and provide actionable feedback on how to make it better. The article explains how to leverage this to minimize the need for support.
Principles for Developer Documentation
6 min read – Writing documentation for software developers can be hard. Most of the time, your reader has a keen sense of what they want to get done and an impatience to get started. Follow some simple principles to put your documentation on the right track.
📽 Favorite Vid(s)
As a developer advocate, you’re demonstrating much more than just how to use your product, framework, or service. You’re modeling “how to be a developer” as well. In this talk, you’ll learn five things you can do to model good documentation practice for your fans
🎧 Favorite Podcast Episode(s)
All Things Communities with Jacob Peters
~40 min episode – A great episode about touching upon a lot of things related to community building in general: what makes a great community, the difference between a community and a network, how to get a community off the ground, phases of communities and how to scale them, how companies can build community, how to think about monetization of a community.
🛠 Favorite Tool(s)
MeetButter – We have tried MeetButter for an interactive team session, combined with Miro for some remote whiteboarding. A great pair of tools for interactive workshops, we think!
🐦 Follow on Twitter
🧐 Question of the week
How much attention do you pay to documentation if you also happen to work on developer relations and what’s your biggest struggle we can help you with?
Cheers & Happy Holidays 🎄,