Milestone #1

Overview

Research

Define

Final Design

— Shipped

Helpjuice

I was the Design Lead, then Head of Product Design at Helpjuice — a knowledge base platform that helps teams create, manage, and scale documentation.

Product

Web

My Role

Head of Product Design — (April 2023 → Oct 2023)

Lead Product Designer — (May 2022 → March 2023)

Collaborators

2 Product Designers, 1 Product Manager, 5+ Developers, Customer Success, Marketing

Timeline

Q2 2022 — Q4 2023

Scope

Product Strategy, UX & UI Design, AI Integration, Prototyping, Design System

Organization Size

Enterprise

What is Helpjuice?

Helpjuice helps companies reduce support costs with a knowledge base their customers can search themselves. Teams at Amazon, Indeed and Coastal use it to answer questions instantly, without a call or an email.

Around 7,000 businesses run their documentation on the platform, and the articles written inside its editor reach more than 7 million readers. For the people writing those articles, the editor isn’t one feature among many — it’s where the whole job happens.

Some numbers for context

7M+

Active Users

7K+

Businesses Using Helpjuice

8.5K+

Knowledge Bases

My Role

I joined Helpjuice as Lead Product Designer and moved into Head of Product Design in April 2023. Across both roles my work was the same in shape: apply human-centred design to systemic problems in a mature product, and stay involved from early problem framing through to the details that get settled the week before launch.

I led design on several epics. This case study covers the editor redesign, which was the largest of them and the one that touched every customer.

Key Responsibilities

The redesign of Helpjuice's editor and its features — covered in detail below.

The design and implementation of AI features, delivered with the wider product team.

The redesign of Helpjuice's marketing pages, including the landing page and About.

Skills

Workshop facilitation, design thinking, user interviews, behavioural analysis, Jobs To Be Done, RICE prioritization, user journey mapping, wireframing, rapid prototyping, usability testing, design systems, visual design.

Results

I spent eighteen months at Helpjuice, moving from Lead Product Designer to Head of Product Design. In that time I rebuilt the editor every customer writes in, built the company’s first design system, and redesigned the File Manager, Translations, the client dashboard and the marketing pages on top of it. The editor was the largest piece, and the one this case study covers in full. The design system underneath it is the part that outlasted me — every redesign the company shipped afterwards started from it rather than from a blank file.

Impact

Redesigned the authoring experience used across 8,500+ knowledge bases — and three years on, it's still Helpjuice's production editor.

Shipped three long-requested capabilities in one release cycle — AI assistance, Request Review and Compare Versions — built on components made for reuse.

The friction patterns we set out to remove stopped appearing. The toolbar rage-clicks and homepage U-turns catalogued in session recordings were absent from post-launch sessions.

Those components became the platform's design system, which every redesign after the editor started from.

The work led to my promotion to Head of Product Design in April 2023.

Client Testimonial

“Ryan is a great designer. Had a pleasure working w/ him and wish him. He understands UI/UX well & needs little guidance around it.”

Emil Hajric — Founder & CEO, Helpjuice

Client Testimonial

“Ryan is a great designer. Had a pleasure working w/ him and wish him. He understands UI/UX well & needs little guidance around it.”

Emil Hajric — Founder & CEO, Helpjuice

Milestone #1

— Editor Redesign

Final design — The Helpjuice Editor: The rebuilt authoring surface: inline AI suggestions, a slash-command block menu, live article outline, and multi-language editing in one view.

Overview

Rebuilding the surface where the work actually happens

The editor was Helpjuice's most-used screen and hadn't had a significant update in close to four years. Our CEO made it a priority for the year and asked me to lead the redesign, with the interface as the starting point.

We agreed the redesign should cover the authoring workflow end to end, resolve the bugs and inconsistencies that had accumulated, and fold in the three capabilities customers had been asking for longest.

Project Goal

Rebuild the editor into a modern, reliable authoring experience that helps teams write, review and maintain documentation without leaving the page.

Main OKRs

Improve editor usability and reliability by resolving long-standing friction across navigation, formatting and layout.

Ship the three most-requested editor capabilities — AI assistance, Request Review and Compare Versions.

Increase self-service adoption by making documentation faster to write and easier to keep current, reducing inbound support volume.

Establish a production-ready design system so the rest of the platform could be modernised from a shared foundation.

Protect existing workflows for 8,000 live knowledge bases while changing the surface underneath them.

Challenge

Four years of accumulated friction

The editor still did what it was built to do, but the gap between it and the tools authors used everywhere else had widened year by year. Meanwhile the engineering team was carrying a focused bug-fix sprint through the same period, which shaped what the redesign could realistically ask for.

User Challenges

The interface felt dated and users told us so, because polish and usability had fallen behind the standard people now expected from any writing tool.

Unresolved bugs and inconsistencies were eroding trust, because the same friction points produced rage clicks and U-turns in recordings week after week.

The capabilities customers wanted didn't exist yet, because AI assistance, review workflows and version comparison sat at the top of our request board with no answer in the product.

Our competitive edge was narrowing, because by 2022 tools like Notion had reset what authors assumed an editor could do — slash commands had stopped being a differentiator and become an expectation.

Editor v1 — the starting point

Research

Building empathy through data-driven insights and behavioral analysis.

Our release cycles didn't leave room for a formal research programme, so I built the picture from the instruments we already had: session recordings and heatmaps, user surveys, our public feature board, internal interviews, and the support queue — where I took shifts myself. With Hotjar we watched how people used the old editor and took notes on rage clicks, U-turns, minor bugs and the spots where users seemed unsure what a control did. That surfaced problems that had never been reported — the kind people work around rather than complain about.

User Recordings

I watched authors work through real sessions rather than a highlight reel, noting where they hesitated, backtracked or clicked repeatedly on something that wasn't responding. Cross-referencing those patterns with internal feedback gave us a shared, evidenced view of which problems were worth the redesign's budget.

Surveys

We ran user surveys to test whether what I was seeing in recordings matched how authoring actually felt. It did. Responses clustered around the same themes, gave us a usability baseline to work against, and surfaced a few issues that had never reached support.

Feature Requests

Using Canny, I reviewed submitted requests and upvote trends. The three most-requested editor capabilities had sat at the top of the board for months — AI assistance, review workflows and version comparison — with counts anyone in the company could check. That made prioritization a conversation about evidence rather than opinion.

"There were times where I would work as Customer Support, which enabled me to have direct 1-1 conversations with our customers and understand their pain points first-hand."

Finding the problems nobody reported
With Hotjar we watched how people actually used the old editor, logging rage clicks, U-turns, dead clicks and the places authors hesitated over a control they could not read. The value was not the volume of it. It was that these were problems nobody had reported — the kind of friction people work around rather than raise with support.
Deciding placement from where authors actually reached
Heatmaps over the same sessions showed which controls authors actually reached for, and how far they travelled to get there. That turned placement into a decision we could argue from evidence rather than taste: the most-used actions belonged closest to the work, which is Fitts's Law applied to a page people sit inside all day.
Learning from the fixes authors invented themselves
Some authors had invented their own fixes for problems we had not solved — and a workaround is the most useful thing a user can show you, because it points at the problem and the fix at the same time.
One author had shrunk their browser window so the article tools pinned to the far right would sit closer to the text — paying with screen space to buy back pointer distance. Nobody files a ticket about that. We shipped right-click access to article tools so nobody had to resize a window again.
Prioritising from a board anyone could check
Our public feature board carried 1,143 requests with upvote counts anyone in the company could check. That made prioritisation a conversation about evidence rather than opinion — what authors had been voting for over months went into the redesign ahead of ideas that only had a champion in the room.

Finding the problems nobody reported
With Hotjar we watched how people actually used the old editor, logging rage clicks, U-turns, dead clicks and the places authors hesitated over a control they could not read. The value was not the volume of it. It was that these were problems nobody had reported — the kind of friction people work around rather than raise with support.
Deciding placement from where authors actually reached
Heatmaps over the same sessions showed which controls authors actually reached for, and how far they travelled to get there. That turned placement into a decision we could argue from evidence rather than taste: the most-used actions belonged closest to the work, which is Fitts's Law applied to a page people sit inside all day.
Learning from the fixes authors invented themselves
Some authors had invented their own fixes for problems we had not solved — and a workaround is the most useful thing a user can show you, because it points at the problem and the fix at the same time.
One author had shrunk their browser window so the article tools pinned to the far right would sit closer to the text — paying with screen space to buy back pointer distance. Nobody files a ticket about that. We shipped right-click access to article tools so nobody had to resize a window again.
Prioritising from a board anyone could check
Our public feature board carried 1,143 requests with upvote counts anyone in the company could check. That made prioritisation a conversation about evidence rather than opinion — what authors had been voting for over months went into the redesign ahead of ideas that only had a champion in the room.

Research

Expert Interviews with Helpjuice Employees.

Internal sessions with Helpjuice staff pressure-tested what we had found. Support and Customer Success could quote the recurring questions from memory — “is this article reviewed?” came up often enough that it went straight into scope. I grouped everything we had — recordings, surveys, the feature board, these interviews — by the moment in the workflow where it went wrong, not the screen it appeared on. That turned twelve scattered issues into three problems: finding your way, formatting as you write, and knowing an article’s state. Those three became the structure of the redesign.

Research

Competitive Analysis

I reviewed Notion, Slite and Document360 as they existed at the time. Knowledge base tools were consistently strong on structure and weak on the writing experience itself, while general-purpose tools outside our category had solved authoring far more convincingly. The conclusion wasn't to copy features. It was to calibrate what authors now arrived expecting — which is what let us separate must-haves from nice-to-haves once scope got tight.

Notion
Document 360
HelpDocs
Slite

Notion
Document 360
HelpDocs
Slite

Prioritization

Jobs To Be Done

I used Jobs To Be Done to frame the redesign around the progress authors were trying to make, rather than the features they were asking for: publish documentation their team can trust, and keep it accurate as the product changes underneath it.

The functional job was to write, review and update an article without fighting the tool — or leaving it to find the next one.

The emotional job was to feel confident an article was correct and current before it went live to customers. In a knowledge base, a wrong answer is worse than no answer.

The social job was to produce documentation the team would stand behind — something support could point a customer at without checking it first.

This changed the design question from “Which features should we add?” to “What does someone need in order to publish something they trust?”

That question is what put review states and version comparison in the same release as the interface work — they answer the same job.

Prioritization

Feature Prioritization using the RICE model.

JTBD told us which jobs mattered. RICE told us which solutions to build first — which mattered just as much, with engineering carrying a parallel bug-fix sprint.

Every proposal on the backlog was scored the same way: Reach, how many of our 8,500 knowledge bases would meet it in a normal week. Impact, how far it would move the job it was meant to serve, for each author who met it. Confidence, how much we trusted those two estimates. Effort, engineering weeks, against a team already committed elsewhere.

The persistent sidebar scored highest.

Every author meets navigation in every session, the recordings left little doubt about how much a fix would help, and the build was contained — broad reach and high confidence against moderate effort.

Slash commands beat the selection toolbar on effort, not on merit.

Both answered the same job — formatting without leaving the text — and scored almost identically on reach and impact. Slash commands cost a fraction of the engineering, so they shipped first and the toolbar bubble was scheduled for a later release, where it shipped as planned.

Compare Versions had the narrowest reach on the board and still made the cut

Because impact carried it — restoring the wrong version publishes an error to every reader of that article, and no other candidate prevented a failure that public.

The scores mattered less than the conversation they forced. Putting effort beside impact moved us off debating which problems were worst and onto agreeing what we could actually ship in the cycle we had — and naming the cuts out loud gave them a place on the roadmap instead of a quiet death.

Prioritization

Feature Prioritization using the RICE model.

JTBD told us which jobs mattered. RICE told us which solutions to build first — which mattered just as much, with engineering carrying a parallel bug-fix sprint.

The persistent sidebar scored highest.

Slash commands beat the selection toolbar on effort, not on merit.

Compare Versions had the narrowest reach on the board and still made the cut

Because impact carried it — restoring the wrong version publishes an error to every reader of that article, and no other candidate prevented a failure that public.

Final Design

What Changed

The redesigned editor focused on reducing friction, restoring trust and helping teams create and maintain knowledge faster. Addressing the long-standing usability issues, modernising the interface and introducing smarter workflows turned the editor into a more intuitive and scalable tool for both everyday contributors and power users. Several generations of concepts were carried out. We considered directions that stayed close to the existing brand as well as ones that were deliberately provocative, then validated them against the constraint that mattered most: 8,000 live knowledge bases with authors who already knew where everything was. The bolder concepts demoed well but carried migration risk we couldn't justify. We landed on the calmest direction and spent the ambition on the workflows instead of the chrome.

What Changed…

Refreshed the visual design to align with modern standards while improving clarity and hierarchy.

Reorganised navigation and tool placement to surface frequently used actions to reduce cognitive load.

Introduced AI-assisted features to speed up content creation and review.

Added an explicit review workflow to support collaboration and quality control before publishing.

Improved layout efficiency, reducing time to first interaction and making writing the primary focus.

Resolved long-standing UI inconsistencies and bugs that had been disrupting author workflows.

Version 3 — The direction that shipped.
Version 2 — Middle Direction
Version 1 — Closest to the brand

Version 3 — The direction that shipped.
Version 2 — Middle Direction
Version 1 — Closest to the brand

Final Design

Streamlining navigation with an intuitive sidebar

User Problem

Newer authors backed out to the homepage to find their next article, even when breadcrumbs held the correct path — every article change restarted the session. For teams working through a documentation backlog, that turned navigation into the slowest part of the job.

Solution

A persistent sidebar surfacing categories, articles and filters inside the editor — without displacing the wayfinding authors already relied on.

What Changed:

A 49% reduction in the time it takes to switch articles, modelled at 10.3 seconds down to 5.3 — the dashboard round trip disappears entirely.

Authors move between articles without leaving the editor, so a writing session no longer restarts every time the subject changes.

Familiar navigation was preserved by keeping breadcrumbs and article-status filters inside the same workspace — a decision we arrived at the hard way, covered in the learnings below.

Final Design

Using AI to support the work, not replace it

User Problem

Drafting, revising and optimising took time, and details like descriptions and keywords were still being missed before an article went live. Competitors were shipping one-click article generation — matching them risked the accuracy a knowledge base is bought for, ignoring them risked looking behind the market.

Solution

Targeted assistance at four specific points in the authoring flow rather than one general-purpose box, with a deliberate limit on how far it goes. This was a team effort — title and subtitle suggestions had already shipped through the wider product team, and several of the more ambitious concepts were built as prototypes that shaped the roadmap rather than shipping in this release.

What Changed:

Every suggestion is accept, edit or dismiss. Inline and reversible, so the author stays the author.

Assistance appears at the moment of work — under the title, at the cursor, before publish — rather than in a panel authors have to remember to open.

We deliberately stopped short of full drafts. The argument I made was that a knowledge base is a trust product — a wrong answer in a help centre costs our customer their own customer.

Final Design

Bringing formatting to the point of action

User Problem

Formatting stayed pinned to the top of the page — the densest rage-click cluster in our recordings — so on long articles, bolding a phrase meant scrolling up and losing your place. And the toolbar was only part of it: five fixed rows sat above the article before the first sentence, pushing the writing surface down the page.

Solution

Insertion moved to the keyboard through slash commands, and the fixed interface above the article reduced to a single row. These were the same change, not two — bringing controls to the text is what made the chrome above it unnecessary.

What Changed:

A 26% reduction in the time to format a phrase, modelled at 9.2 seconds down to 6.8 end to end — or 46% of the interaction itself, once the shared reading and decision time is set aside.

A 33% reduction in the time to insert a block, modelled at 10.4 seconds down to 7.0 — and 63% of the interaction alone, the largest single gain in the redesign.

Five fixed rows above the content became one, with the table of contents moved to a quiet rail and collaboration tools present but silent until called.

The selection toolbar followed in a later release, completing the pattern once effort allowed.

Final Design

Making review status explicit

User Problem

Users couldn’t tell whether an article had been reviewed, was still waiting, or had gone straight to publish — status lived in people’s heads and in Slack threads. Support fielded the question often enough that both teams could quote it, and an unreviewed article reaching customers is a cost the platform absorbs.

Solution

Article state made visible in the product itself, with review turned into a named request instead of an informal ask.

What Changed:

Article state is visible on the article — draft, in review, approved, published — instead of inferred from memory or a chat thread.

Reviews gained an owner and criteria, so a request names its reviewer and what they’re checking, and approval carries meaning.

Requesting review became one action inside the editor, adding a quality gate without adding a process that lives somewhere else.

Final Design

Giving the editor header back to the writing

User Problem

Translation controls sat as a chip row across the editor header, competing for space with the writing surface on every article — including for the majority of authors who were not translating anything that day. Translators did not gain much from it either; the row was too cramped to actually work in.

Solution

The chip row became a workspace of its own, and the editor header was reduced to what a single-language author actually needs.

What Changed:

One of the five fixed rows removed from above the article, which is a direct contributor to the layout gain in the chapter above.

Translation stopped borrowing space from writing and got room proportional to how involved the task actually is.

The editor got quieter for everyone not translating, which was most authors, most of the time.

Reflection

A clearer way to create and maintain knowledge

The redesign gave Helpjuice a more coherent authoring foundation. Authors could move between content without restarting, reach tools closer to the work, request review with clearer states, and use AI assistance inside the editor.

Summary

Shipped to all 8,500+ knowledge bases — and three years on it's still Helpjuice's production editor, unreplaced and in daily use.

A 28% reduction in interaction time across a four-task benchmark, modelled at 38.8 seconds down to 28.0 — the largest gain on block insertion and, deliberately, none at all on review status.

The friction patterns we targeted stopped appearing. The toolbar rage-clicks and homepage U-turns catalogued before the redesign were absent from post-launch recordings and from the support themes we tracked.

Long-requested capabilities moved from the feature board into the product in a single release cycle, on components built for reuse.

The components became the platform's design system, which every redesign after the editor started from.

The work led to my promotion to Head of Product Design in April 2023.

At a glance

Less interaction time — modelled, four-task benchmark

Faster to switch articles

Faster block insertion

Reflection

A clearer way to create and maintain knowledge

Summary

Shipped to all 8,500+ knowledge bases — and three years on it's still Helpjuice's production editor, unreplaced and in daily use.

A 28% reduction in interaction time across a four-task benchmark, modelled at 38.8 seconds down to 28.0 — the largest gain on block insertion and, deliberately, none at all on review status.

Long-requested capabilities moved from the feature board into the product in a single release cycle, on components built for reuse.

The components became the platform's design system, which every redesign after the editor started from.

The work led to my promotion to Head of Product Design in April 2023.

At a glance

Less interaction time — modelled, four-task benchmark

Faster to switch articles

Faster block insertion

Impact

Sizing the change without instrumentation

The editor shipped without timing analytics, so I modelled the difference instead. The Keystroke-Level Model breaks a task into the elementary actions someone performs — pointing, clicking, keystrokes, scanning a menu — each with an established average duration. Run the old path and the new one, and what is left is the interface change with everything else held still.

These are modelled estimates, not measured user data. Every assumption sits in the sheet below, task by task, so the working is open rather than summarised.

One task models at no gain at all — review status, 9 seconds either way. The path did not get shorter, only more reliable.

Reflection

Mastering complex redesigns grounded in real user needs.

Redesigning the editor was an ambitious project driven by user feedback, competitive analysis and a clear view of what authoring should feel like. Some of what it taught us we learned the hard way.

Removing something familiar needs the same evidence as adding something new. We took breadcrumbs out in the first release, assuming the new sidebar made them redundant. Customers told us otherwise within days: breadcrumbs answered where does this article sit, and the sidebar answered what else is there — two different questions. We brought them back alongside the sidebar, and the combination worked better than either alone. It's the clearest reminder I've had that an assumption held by the design team is still an assumption.

Instrument before you design, not after you ship. I had observation at scale but no baselines, which means the redesign is well-directed and under-proven. Modelling the interaction cost afterwards closed part of that gap, but it is not the same as having measured it. Event tracking now goes in with the first beta of anything I run.

Version comparison shipped, and I would rebuild it. It met the brief, but looking at it again the comparison view asks people to hold too much in their head at once — which is the exact problem it existed to remove. It is not shown here for that reason.

Behavioural evidence surfaces what feedback doesn't. The friction that cost authors the most time was rarely what they wrote in a survey — people work around problems rather than report them.

Prioritization is more credible when the cuts are named. Saying out loud which features we weren't building, and why, kept engineering aligned and gave those features a real place on the roadmap.

Simplifying isn't removing. Reducing what sat above the content made the editor calmer without making it less capable — the depth stayed, it just stopped competing for attention.

The workshop cadence did more than the artefacts. Bringing support, marketing and legal in after every iteration caught problems earlier than any document would have.

More Work

— Beyond the Editor

Overview

Taking the same approach across the platform

The editor was one part of a broader product modernisation. Across my time at Helpjuice, in both the Lead and Head of Product Design roles, I also worked on the design system, File Manager, Translations, the Client Dashboard and key marketing pages.

Some of this ran alongside the editor work and some followed it. The approach stayed consistent throughout: build from shared components, validate with the teams closest to customers, and leave each surface easier to change than we found it.

Project Goal

Bring every surface a customer touched onto one shared foundation, so the product stopped changing character from screen to screen.

Main OKRs

Establish the design system as the starting point for new work rather than a library people remembered to check.

Extend the editor’s patterns to the surfaces closest to it — File Manager and Translations — so authoring felt continuous rather than handed between tools.

Bring the client dashboard in line with the product customers signed in to use, so the first screen matched the rest.

Align the marketing pages with the product being sold, so the first impression and the first session showed the same thing.

Reduce what had to be maintained twice by retiring one-off patterns as each surface moved onto the system.

Design System

User Problem

When I arrived, designs were being treated as reference rather than specification. Each developer built their own version of the same element and wrote their own styles for it, so the product and the marketing site drifted into different visual languages — and the codebase carried several implementations of the same component. There was no design system to point at, because the design team had never had one.

Solution

I built a centralised system and made it the single source of truth for design and engineering. Components were defined once, with their states, naming and behaviour settled, so a handoff became a blueprint instead of a suggestion.

What Changed:

Around 20% less code shipped for the same surfaces, because developers stopped rewriting styles that already existed.

Product and marketing stopped drifting apart, since both were built from the same components rather than each developer’s interpretation.

Every redesign after the editor started from the system instead of from a blank file, which is what made the rest of this work possible at all.

File Manager Redesign

User Problem

You could not tell what a file was without opening it — there were no real previews. There was no way back to something you had just been looking at, and search only matched file names, so finding anything in a knowledge base with years of uploads behind it meant remembering what you had called it.

Solution

I added in-depth previews so a file can be identified at a glance, a recent files view for picking up where you left off, and filtering by content type directly from the search field so results narrow as you type.

What Changed:

Files can be identified without opening them, which removes the open-and-close loop that made finding the right asset slow.

Recently used files are one click away instead of being found again from scratch every session.

Search narrows by type as you search, so a name you half-remember is no longer the only way in.

Landing Page Redesign

User Problem

The product had gained a lot since the page was last touched, and none of it was on the landing page. Visitors were evaluating an older version of Helpjuice than the one they would sign into, which made the page work against the product rather than for it.

Solution

Rebuilt the page around what the product actually did by then, on the same visual language as the redesigned application, with conversion as the outcome we designed toward.

What Changed:

The features shipped since the last refresh finally had somewhere to live, so the page argued for the current product rather than a past one.

Marketing and product stopped showing two different things to the same person days apart.

The page could be updated as the product moved, because it was built from the same components as everything else.

About Us Page Redesign

User Problem

The team had grown well past what the page showed, and it had not been refreshed in some time — so a page meant to introduce the company was introducing an older, smaller version of it.

Solution

Updated the page to reflect the team as it actually was, on the same components and typography as the new landing page.

What Changed:

The page showed the current company rather than the one that existed when it was last written.

The marketing site read as one thing instead of pages built in different years.