Divya Shah

Freshworks · Freshdesk · 3 months · 4 phased releases

Knowledge Base revamp.

Where self-service meets scale and monetisation. I was the sole designer rebuilding Freshdesk's knowledge base natively in Mint: creation, governance, versioning and analytics, designed as one system that could keep absorbing features for years. It did.

EnterpriseSystem designEase of useUser-centered design
RoleUX Designer, sole designer with a PM
Team16: engineering managers, developers, QAs
Duration3 months
PlatformFreshdesk Mint, web
73%of customers explored the self-service module after the advanced features went GA
2.0×growth in Freshdesk's mid-market segment, within an installed base of 100,000+ businesses
643K+article views on customer portals, with creation activity up sharply
Freshdesk Knowledge Base home screen: Build your Knowledge Base, with entry points to create a new article, import from other products, import from cloud, or upload from device, above a category overview.
The new Knowledge Base home: every way content enters the system, one screen.

Support that answers before anyone asks.

Freshdesk is a cloud customer-support platform: email, chat, phone, social and knowledge base in one system, self-service first. A knowledge base article that answers a question is a ticket an agent never sees. "Best service is no service."

As Freshdesk was being rebuilt natively in Mint, a rare window opened, and I got it: rethink the knowledge base from the ground up, and introduce advanced, monetisable capabilities on a scalable foundation instead of porting the old module's limits forward. One designer, one PM, a team of sixteen, and three months.

100,000+businesses on Freshdesk (2018)
150+countries, startups to enterprise
2011the module's original release, showing its age

The problem, written down.

How might we enable content teams to create and evolve knowledge articles easily, with performance visibility and control, so self-service adoption grows and advanced capabilities can be monetised, all within platform, governance and scalability constraints?

This was my first large-scale knowledge base: learning how content is created, governed and consumed across teams while balancing speed, quality and adoption. The named challenges: designing a scalable content system rather than pages, balancing governance against content velocity, introducing roles and approvals without adding friction, and ambiguity throughout.

Five stages, measured at the end.

Requirement analysis & research

Understand and validate user requirements. Dismantle the module, find the pain points.

Redefine problem & scope

Personas, task flows, IA and a task matrix to support design development.

Ideate & design

Create mocks, iterate, validate, then high-fidelity designs.

Test & deliver

Usability testing and design deliverables, phased by release.

Measure

Instrument usage, watch adoption, feed learnings back into the roadmap.

How the research ran

  • Module teardown of the legacy knowledge base, screen by screen
  • Forum and call mining: years of feature requests from real customers
  • Competitive benchmarking: Zendesk Guide, Helpjuice, Wix Answers
  • User groups mapped into four personas with goals, pains, motivations

What it surfaced

  • Customers were asking, verbatim: article templates, "reporting is critical", version reports, manual linking of related articles, meaningful URLs instead of ID numbers
  • Benchmark split the market: versioning, language support and analytics were table stakes; approval workflows, roles and templates were where Freshdesk could pull ahead
  • The insight: market patterns and customer demand pointed at the same gap

"The knowledge base needed to evolve from a basic help tool into a scalable, measurable, monetisable content platform."

Four people, four different jobs to be done.

Content creator writes it

Goal
Create articles that resolve customer queries; manage the knowledge base.
Pain
No visibility into how articles perform or how to improve them.
Motivation
Ticket deflection and positive feedback on their writing.

Support agent shares it

Goal
Share articles that resolve issues, internally or with customers.
Pain
Finding the right article; requesting new ones for repetitive tickets.
Motivation
Articles that close tickets without escalation.

Content manager runs it

Goal
Manage the knowledge base and track its performance for the organisation.
Pain
Reviewing articles offline; the workflow had no online system.
Motivation
Great self-service that resolves customers' issues at scale.

Admin governs it

Goal
Approval workflows for quality, permissions, performance oversight.
Pain
No system existed to achieve any of this.
Motivation
A delightful, trustworthy experience for their customers.

I built the backbone before a single screen.

Screens age; structure compounds. I spent the scarce early weeks on three artifacts that every later decision would lean on: task flows for every job to be done, a rebuilt information architecture, and a task matrix mapping every action (create, publish, schedule, approve, reorder, move, delete) against the four roles.

The matrix became the contract for the approval workflow and the permissions model. When scope debates flared, we argued against the matrix, not against each other.

Only then did wireframes run ahead of the visual system: insights dashboard, folder trees, list views, bulk actions, filters. Each validated with users before high fidelity, then dressed in Mint with multi-portal support built in.

Four releases, each one earning the next.

Phasing was the strategy, not a compromise. Parity buys trust, versioning makes content trustworthy, approvals make it an operation, analytics closes the loop.

R1

Parity, multilingual, native in Mint

Release parity with the old module but with fundamentally better UX, including article creation in multiple languages and a clutter-free workspace focused on a single language at a time.

R2

Versioning and collaboration

Article versioning: go back in time to track every change and see how an article evolved. Freshconnect integration brought collaboration with full article context instead of side-channel threads.

R3

Approval workflow, content agents, templates

Drafts flow from writer to reviewer to published, with the new content agent role and article templates so quality scales past any single writer.

R4

Knowledge base analytics

Insights on visitors, search, article status and content performance, so creators finally see whether their articles work, and managers can run the knowledge base on evidence.

Two fights worth having.

The Preview button vs UI clutter

Conflict: the PM saw a persistent Preview button as redundant chrome.

My case: content writers needed instant, repeated visibility of exactly how an article appears on the customer portal to iterate with confidence.

Outcome: contextual Preview retained on every editing surface. Rework dropped and content quality improved before publishing, and it became one of the most-loved details of the redesign.

Deep hierarchy vs shipping speed

Conflict: I proposed a multi-level hierarchy for enterprise-scale content; engineering and PM flagged complexity, performance risk and longer timelines.

My call: launch with a three-level hierarchy to hold parity, cut technical overhead and release faster.

Outcome: a scalable baseline shipped quickly, with a clear roadmap to extend depth based on enterprise adoption and validated need.

Self-service became the product's growth lever.

After the advanced features went GA, 73% of customers were actively exploring the self-service module and article creation and management activity rose sharply. The clearest commercial signal came from the segment that stress-tests knowledge base capability hardest in evaluations: within Freshdesk's installed base of 100,000+ businesses, the mid-market segment doubled in the period after the revamp shipped, with advanced KB features like approvals, versioning and analytics repeatedly cited in those deals. Customer replies called out managing all articles on a single screen as a favourite improvement.

643K+views on portal
487K+new articles created
197K+bulk actions run
87K+manage actions

The honest ledger.

What worked

  • Preview on every page. Fought for against real pushback, and vindicated: writers stopped publishing blind and publish-then-fix cycles collapsed.
  • Designing with a vision. Each release slotted into the last instead of fighting it.
  • Phased delivery. Development ran faster and safer with designs phased out ahead.

What could have been better

  • Analytics came last, yet performance invisibility was the creators' loudest pain. I would sequence the measurement loop earlier.
  • Testing started at high fidelity. Lo-fi rounds in phase one would have killed dead-end directions cheaper.
  • Last-minute changes were absorbed, but ad hoc. An agreed change window would have cost less design debt.

Future scope

  • Article scheduling
  • AI/ML-powered knowledge base
  • One article, multiple folders
  • Translation integration
  • Trash and archive
  • KB activity in the customer timeline