Dev tool documentation examples

Nice way to show code and results straight from the React docs that people love.

And this pattern can be used outside of the docs for sure.

Anyway, a classic situation:

• you want to show the code
• you want to show the result of that code
• you want to let people play with the code/results
• you want to make it easy to read and copy/use  

And folks behind React docs solved it nicely by:

• Giving you a spit screen of code and results
• Not showing the entire code but giving you the option to "show more"
• You can change the code and see the results change (and errors pop up)
• You can use buttons to reset the example, copy it, or fork on CodeSandbox

Not groundbreaking maybe but a beautiful implementation that is just a delight to use.

So your differentiator is being self-hosted and you want devs to see it. This is a cool trick I saw that feeds into the way devs navigate your site.  

One navbar tab devs will click on or at least hover over the docs tab.

So putting your self-hosted deployment guide in there will land.

And likely this guide sits in the docs anyway, you just extract that important piece of information and frontload it. This is exactly what @n8n did on their site and I love this.

People see it first and I am sure (many) will remember that n8n is self-hosted which is one of their differentiators. Simple and strong.

In that vein, you can frontload other important pieces like quickstart/getting started or integrations. Especially when your docs is a toggle tab and not just a clickable link.

I'd argue that having that quickstart frontloaded in the docs tab would be a smart move from n8n too. But anyhow, this is job well done.

How to get people to sign up for your office hours?

Why not put it on your docs homepage?

Btw, I really like the concept of office hours.

• You give people the option to "get a demo" and answer their questions
• But you don't make them schedule anything, they can just come (or not)

You get your devrels or product to do those weekly and then you just have to figure out how to get people there.

Classic options are to put info in onboarding sequences, in the app, or on the website hello bar.

But Flatfile had another idea. They put it in their docs homepage header.

I find this idea brilliant as many people who browse your docs (especially for the first time) are in that evaluation mode and would actually want to do that.

Plus calls to action in the docs get more respect by design ;)

A docs header worth a thousand words.

For a dev platform or infrastructure tool it is hard to explain where you fit, what you do quickly, and how you connect to existing components quickly.  

Hopsworks docs team does a great job here.

So instead of using words, they use a diagram:

• You get a solid overview of where your tool/platform fits larger context
• It shows you which part of the workflow/infra the platform solves
• Every part of the diagram is a clickable docs link
• Shows where you can deploy it
• Shows what backend you can use.

All of that in a single diagram.

Now that is a dev-focused header visual.

"See docs" is one of my favorite secondary CTA on dev-focused pages.

TailwindCSS takes it to the next level by inserting docs search right into the header CTA.

This takes devs directly to the page they are interested in rather than have them try and find things for themselves.

They could have searched the docs in the docs, of course.

But this is just this slightly more delightful developer experience that TailwindCSS is known for.

What to say when you have many products? 

Dev tool companies over time grow from one product to suite of products to platforms with products built on top of the core one.

The result is that it is harder to communicate without going full-on fluff mode (my fav "built better software faster").

But for most companies, there is this core capability/product where people start.  The entry product. Why not use that?

I really liked what Stripe did on their docs page here:

• They have maaaany products: billing, tax, radar, identity etc.  
• But all of them are built on top of their core payments product
• So they focus on getting folks to start with the payments
• And make it clear that there are many other products

Even though this is docs, the same applies to homepages and other dev comms.

If you have many products, figure out what is the most important one, the one where most people enter. Focus on that. "Upsell" to other products later.

Pricing in your docs? That is how @Fly.io does it.

You click a pricing page link on their homepage and you go to the docs!

No 3 boxes with the "most popular" being the middle paid plan ;)

They just give it to you how it is. Exactly what you'd expect from the docs.

There are tables, explanations, and links to other docs pages.

Very bold decision imho. It definitely makes them feel super developer focused.

Plus if you do want a more standard, enterprise stuff you see:

"If you need more support or compliance options, you can choose one of our paid plans. These come with usage included and additional support options."

And that page looks like a classic pricing page.

But they focus on the developer buying experience here. Super interesting.