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.
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.
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.
The information architecture: six entry points, every downstream action accounted for.
1 / 3Only 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.
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.
The refreshed knowledge base home: drafts up top, every category and folder one glance away.
1 / 8Versioning 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.
Version history on every article: eight versions deep, one click to any of them.
1 / 3Approval 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.
The approval workflow: send for review, in review, approved. Publishing became a decision, not an accident.
1 / 3Knowledge 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.
The analytics overview: the whole knowledge base's health on one screen.
1 / 3Two 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.
Customer feedback after ship: forum replies and emails on the new knowledge base.
1 / 5The real test of a system: what it absorbs next.
The strongest validation came years after I shipped it. The structure has held: the same IA, the same workspace, the same workflows, now absorbing AI-assisted article generation and editing without a redesign. That was the bet behind building the backbone first: a system designed around roles and workflows, not features, gets to say yes to the future.
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