Dozens of features, hundreds of fixes, one product that finally holds together

TL;DR

Here is Archbee in 2023.

Here is Archbee in 2026.

Same product, three years apart. I joined in May 2023 part time, went full time in September, became Product Designer in July 2025.

I was the first designer the company kept long term. Dozens of features, hundreds of fixes, one product wide redesign with a component system under it.

Over 3,000 companies write their docs inside it, including Adobe, Cisco, and Bosch. I carry a problem from the sales call through to the production.

Where the company was when I walked in

Archbee is two products under one name. Writers work inside the CMS, and their customers read the site those writers publish.

Fern, ReadMe, Mintlify and GitBook pitch the same teams in the same week. Buyers compared four tools side by side and ours looked older.

There was no CLI, the GitHub integration was thin, and no AI anywhere. Nobody had ever owned the design side of it full time.

What I had to work with, and what was mine

No research budget, no analytics built for design questions, no research team. Every engineering hour was already promised to something else.

So I built evidence out of what a 15 person company already produces. I joined sales calls and heard prospects describe problems in their own words.

I traced support tickets back to the cause instead of stopping at the symptom. I ran interviews and usability tests when I could get people in a room.

AI in the product

I designed the AI features across both sides of Archbee, the writing tool on the inside and the published documentation on the outside. Here is each one and what it actually does for a person.

Ask AI

A reader lands on a company's documentation with a question in their own words. The site answers with page titles, so they hunt through navigation guessing which page holds it.

I designed a chat that sits on the published site and answers from that company's documents only. The reader asks the question they already have and gets it back in the same language.

AI Write

A writer knows a paragraph is too long or the wrong tone, but fixing it means leaving the page. They copy the text out, rework it somewhere else, and paste it back.

I put the rewrite inside the block. The writer selects a section, asks for shorter or clearer or a different tone, and the change lands where they already were.

AI Translations

A team needs their documentation in a second language and has no translator. They either pay per page or leave half their customers reading a language they do not use.

I designed translation that starts from the existing set and produces a working draft. It goes to a person to check before publishing, since a documentation error in translation is still a documentation error.

AI Agent Write

A rule changes across a whole product and every page needs the same edit. Someone opens a hundred documents one at a time and makes the same change in each.

I designed one instruction that runs across every document in a space. You describe the change once, in a sentence, and it applies to the whole set.

Recurring AI Agent Write

Some pages need updating on a rhythm, like an overview or a changelog. They fall behind because nobody owns the job, and outdated pages are worse than missing ones.

I designed a saved instruction that runs on a schedule. The result arrives as a branch, so a person reviews and merges it like any other change.

The smaller AI work

Answers get weaker when internal context is missing, external answers live outside the site, summaries never get written, and readers only find docs if they think to visit. I designed shadow docs the AI reads but readers never see, external sources so answers reach past the site, generated summaries and search descriptions the writer edits instead of starting blank, and an internal chat plus a widget that puts documentation inside a customer's own app.

documentation.new

You describe your product, upload drafts, and add API specification files. It returns a site with structure, navigation, pages, and API reference already built.

Archbee launched it in early 2025 and I designed the whole experience. It runs publicly and the demo video is made in Figma.

Then the generator moved into Archbee itself. Existing customers now start a space from a prompt instead of an empty page.

It runs at documentation.new, and the demo video is here. The demo video is made in Figma and edited in a video app.

It also did not stay a side product. The generator moved into Archbee itself, so existing customers now start a new space from a prompt and their own files instead of from an empty page. That is the outcome I would point at if I had to pick one. A top of funnel experiment the core product decided it wanted too.

Navigation that stops losing you

The left panel held the tree, search, settings, and space controls at once. Search sat inside the scroll area and disappeared as soon as you scrolled.

I decided the scroll area exists for the document tree only. Everything else got pinned where it belongs and stays visible.

I traded tree height for a search box that never moves. Someone new to the product needs search more than a taller tree.

The image block

Nearly every documentation page holds a screenshot, so this block is everywhere. Switching between edit and read mode shifted the content and moved your place.

Writers hit that several times an hour and never file a ticket. They just start describing the tool as annoying.

I rebuilt it across several releases instead of one, since the editor breaks for everyone at once. While fixing the shift I recreated it for dark mode images.

Branching and reviewing

Technical writers sit next to engineers and already branch, review, and merge. Without it they either message each other constantly or publish half written pages.

I mirrored the version control model they already know, so nothing needed teaching. Then I removed the parts that only make sense to engineers.

I kept it simpler than real version control on purpose. Power users want more, and everyday writers should not learn a system to publish a page.

The zoom bug I solved by not solving it

Comments in the editor broke when the interface zoomed from x1 to x1.15. A developer was ready to spend hours fighting the rendering.

I read the code with him until I understood what failed. Then I moved the range to x0.9 through x1 instead.

The user gets the same output on screen. The broken state no longer exists, so nobody had to fix it.

The arguments

Smooth stories are junior stories. Here are three that were not smooth, one where I folded and was right, one where I folded and it broke, and one where I fought the brief itself.

The category page, or what happens when you build what was asked for

A prospect said they would sign if we built a category page. I researched it, ran a competitor analysis, and designed what fit them and everyone after them.

The PM called it too complex to build and asked for less. I disagreed out loud, then designed the smaller version and shipped it.

They signed, said it fell short, and asked again for nearly the same thing. In 2026 someone from that team joined us and confirmed my first design was right.

The broken link checker, where I folded and the test environment settled it

I designed a scan that lists every broken URL in a documentation site. I set it to run on demand, since a real site takes minutes.

The CEO wanted it on Publish, because publishing broken links is the failure it prevents. His reason was better than mine and I gave in.

Results? Nobody could get through testing. I moved it back to on demand, kept a toggle for publish, and nobody uses the toggle.

The constant one, constraints as design input

When engineering pushes back, I do not argue with the constraint. I find out what the concern behind it actually is, then design the experience so the constraint stops being a problem. The zoom bug is the clearest example in this study. A limit you understand is a design input. A limit you fight is a delay.

That is also why my handoffs move fast. I read the code and the design library before I draw, so what I hand over is already inside what the team can build.

What this means for your team

Three years, one designer, one product that went from inherited to designed. I owned the navigation, the editor, branching and review, AI across both sides, and all of documentation.new.

You get someone who joins the sales call, reads the code before drawing, and tests next to QA. Nothing waits for a handoff that never happens.

Over 3,000 companies use what I built, including Adobe, Cisco, and Bosch. Open a 14 day trial with no payment and judge it yourself.