Ember Stevens 0:00 Hi, I’m Ember Stevens, and I’m a Senior Technical Writer at LaunchDarkly. I work with our documentation and developer experience teams to create technical content for developers working with our SaaS products. Over the years, as our product has grown and gotten more complex, so has our documentation. We now have over 500 pages of docs covering a wide range of tutorials, guides, how to procedures and so on. One of the challenges of managing all of this documentation is figuring out when to publish docs about what features for which audiences. For example, we recently had a major overhaul to our products user interface. We let our users choose when they wanted to switch from the old UI to the new UI. This meant that we had to maintain two versions of all of our documentation for months. One of the questions we wrestled with was how we could expect our customers to know how to find the right version of the docs for their UI. Were we just going to have two versions of every page? Were we going to have two completely separate doc sites? We weren’t really sure at first. Another example of a similar problem is, like many companies, we have three different subscription plans. Our enterprise customers, for example, have access to many more features than our starter plan customers. It is pretty common to show documentation for all of your features to all of your customers, regardless of what they actually have access to. But we wondered if there was a better way enter feature flags. You may be familiar with the term feature flags or feature management as part of the software development cycle. If you don’t know feature flags are small functions you add to your code that allow you to deploy two or more versions of that code at once, but display only one version of the code to customers, depending on your needs. So in the simplest version of this, you can flag a snippet of code as on or off. Here’s what that might look like on your mobile app. Here you can see two existing features, a purple feature and a pink feature. But soon you’re coming out with a shiny new blue feature. Now all of your code is ready, but it’s not quite time to release to your customers yet. Maybe you have a target release date in mind, or maybe you want the ability to quickly turn the feature back off if something goes wrong, so you wrap your feature in a feature flag and connect it to your feature management system. On the left, you can see two versions of your code. The true version contains the code for the new feature, and the false version is blank. Then Voila, by toggling the flag on, you can instantly display the feature. If you don’t want to display the new feature anymore, you can toggle the flag back off to hide it without having to redeploy or roll back. Okay. So what does this have to do with documentation? Well, if you use Docs as code like we do, you can use feature management to control your docs in the same way. One of the challenges my Docs team faces is we have many different features going out to customers at many different times, with frequently changing release dates. You can probably empathize. Previously, we more or less sat around with our fingers hovering over the Merge button in GitHub, waiting for the word that it was okay to merge and deploy our docs. Now we can hide our docs behind a feature flag, then merge at our leisure. When the feature is released, we just flip the flag on. If the feature needs to be rolled back, we can just flip the flag off again and the docs are re hidden. A little more involved scenario is when you want to display different docs content to different customers depending on their user attributes. When our customers log into our app, we know things about them, like their name, their company, what kind of plan they’re on. We also know whether they’re part of a small group of beta testers that we sometimes release features early to our app collects these user attributes and sends them to us as a user object. Our feature management system can then use the attributes from the user object to serve different versions of our docs depending on rules that we write. We definitely don’t want most of our customers seeing docs related to beta features, because they’re not ready for everyone to use and. May decide not to release them at all. So in this situation, we use our feature management system to write a rule that says, if the user has the beta tester attribute of yes, then display the content. If the user has the beta tester attribute of anything other than Yes, or if that attribute is blank, then hide the content. This lets us serve different versions of our docs to different groups of customers simultaneously. We can also do something similar with customers on different kinds of paid plans. When customers are logged into our app, we can look at their user attributes to know what kind of plan they’re on. In this example, one of these customers is on an enterprise plan, and one is on a basic plan. Over in our docs, we have an expanded version just for enterprise customers. We created a rule in our feature management system to display the full version of our docs to enterprise customers and the simple version of our docs to basic customers. Again, this lets us serve different versions of the same content at the same time. Finally, if you really want to get fancy with it, you can use prerequisite flags to only display documentation if the related feature is released. If your feature management system supports it, you may be able to make one feature flag dependent on another feature flag. So for example, imagine you have feature flag one that displays the actual in app code for a new feature when your developers flip flag one on, the feature displays when they flip flag one off, the feature is hidden. You can then create a dependent flag or flag two that says, display these docs only if flag one is displaying the future. This means flag two is dependent on flag one. You can flip flag two on but you know it won’t display the new Docs until flag one is also on. As soon as a developer flips on flag one, flag two automatically updates. We use this method frequently because it allows us to publish new feature docs the instant the feature is released, without any manual intervention on our part. No more hovering in Slack channels waiting for the pm to give the OK, we just set it and forget it. These are just a few of the ways my team uses feature flags to manage our documentation. If you use DOCSIS code, it could be useful for you as well. Thank you so much for listening, and please find me on LinkedIn or send me an email if you have any questions. Thank you.