Knowledge Base Design Services: A Buyer Guide for SaaS Teams

A customer searches your help centre for “invite a colleague.” The relevant article is called “Workspace membership administration,” lives under a category named after an internal team and shows an older interface. The answer exists, but the customer still opens a support ticket. Repainting the help-centre homepage will not fix that journey.

Knowledge base design services should connect customer questions to accurate, findable answers. A useful engagement combines content analysis, information architecture, search behaviour, article design and publishing workflows. The result should be easier to use and easier to keep current.

This guide is for SaaS founders, product teams and support leaders commissioning a public help centre or a customer-facing knowledge base in the US, UK, UAE or Dubai. It explains what to include in an agency brief, which decisions your team must own and how to judge whether the work is ready to launch.

Define the customer task before the redesign

Start with the situations that bring people to support. A first-time user setting up an account needs a different route from an administrator correcting permissions or a customer investigating an unexpected result. Ask support and product teams to identify recurring questions, common misunderstandings and tasks where an incorrect answer would be costly.

Choose a bounded first release. For example, you could redesign onboarding and account administration before expanding into advanced integrations. Include difficult questions within that scope. A pilot made entirely of easy introductory articles will not reveal whether the structure supports troubleshooting.

Write the desired outcome in terms you can observe: a customer finds the correct invitation instructions, recognises which role is required and knows what to do if the invitation expires. Avoid making a lower ticket count the only goal. Fewer contacts can mean better answers, but can also mean that customers cannot find a way to ask for help.

For SaaS businesses, agree how the help centre connects to the product. Contextual links from an error message or settings screen may matter as much as the homepage. Include those entry points in the brief so the agency evaluates the complete journey.

Audit answers, not just URLs

An inventory should capture more than article titles. Record the customer task, intended audience, product version, content owner, review status and known dependencies. Note duplicate answers, contradictory instructions, missing prerequisites and screenshots that no longer match the interface.

Use actual support language where your organisation can provide it appropriately. A sample of recurring questions and search terms can reveal gaps between company terminology and customer wording. Remove unnecessary personal or confidential details before sharing examples with a supplier. The design team needs the problem pattern, not a customer's private account history.

Assign a disposition to each article: retain, revise, merge, retire or investigate. Keep a record of the decision and the person who can approve it. A designer should not decide whether a legacy feature is still supported based on the appearance of an old screenshot.

Prioritise by task importance and content risk alongside usage. An infrequently visited recovery article may still be essential. For content being moved between systems, use a separate migration plan covering links, attachments and URL changes; the website content migration guide explains that work in more detail.

Design navigation and search together

Ask for a proposed category structure with real article examples, not an empty sitemap. Labels should describe tasks or concepts customers recognise. “Getting started” can be useful, but a category called “General” often postpones the decision about where an answer belongs.

Test the structure with representative tasks before applying a full visual design. Ask someone unfamiliar with your internal organisation where they would look to change an account owner or troubleshoot a failed import. Observe their choices and the labels they misunderstand. This gives the agency specific decisions to revise.

Search deserves its own scope. Agree which content it covers, how titles and summaries appear, whether product or role filters are needed, and what happens when there are no useful results. A search box is only the visible control; the buyer should understand who configures the index and who maintains synonyms or promoted results where the platform supports them.

Prepare a small, reviewable query set using customer wording, feature names and known failure cases. For each query, identify the answer that should be findable and the misleading results that should not dominate. Re-run that set after content or search changes. Include a clear support route when the available material cannot resolve the question.

If an AI answer layer is proposed, price and evaluate it separately. Require traceable source links, a defined content boundary and a way to handle unsupported questions. Test whether it preserves product-version and permission distinctions. A fluent answer should not be accepted as evidence that the underlying advice is correct.

Make article templates useful in practice

Different questions need different formats. A short concept explanation, a step-by-step procedure and a troubleshooting decision tree should not all be forced into the same wall of text. Ask the agency to demonstrate templates using real draft content from your audit.

Place prerequisites before instructions. State the required role, relevant plan or supported version when it changes the steps. Screenshots should support the explanation; essential instructions should remain understandable in text. Include a named route for escalation when a task needs staff intervention.

Make long articles navigable with descriptive, logically nested headings. This follows W3C's guidance on heading structure, which explains how headings communicate organisation and support navigation. Include semantic structure in the implementation brief rather than approving headings only by their size or appearance.

Ask the UX design partner to demonstrate narrow-screen layouts, long titles, error explanations and keyboard navigation. Check focus visibility and the reading order of sidebars, search results and article content. Accessibility needs to be evaluated in the implemented templates as well as the design files.

Assign ownership before choosing a platform

A polished help centre can become unreliable if nobody owns the answers. Name a responsible product or support expert for each topic and a publishing owner for the overall system. Define how changes are requested, reviewed, approved and withdrawn.

Connect content review to product releases. A settings change should trigger a review of affected instructions and screenshots. Give each article a review state and a practical way to identify its dependencies. Avoid automatically updating a public “last reviewed” date when no person has checked the content.

Then evaluate whether your existing support platform can support the workflow. Compare editing experience, permissions, search configuration, version handling, translation and export options. A custom build may be justified by a concrete requirement, but visual preference alone is a weak reason to replace a workable publishing system.

Separate public instructions from authenticated, account-specific information. Decide which material requires sign-in and test that boundary with the implementation team. When the project includes private requests or account actions, compare the scope with the customer portal development guide; a knowledge base and an operational portal serve different needs.

Plan for markets, languages and product versions

Serving US, UK and UAE customers does not automatically require three copies of every article. Identify what actually differs: available features, support hours, date formats, commercial terminology or region-specific workflows. Keep common guidance shared where it remains accurate, and label genuine exceptions clearly.

If Arabic is in scope, include native-language editorial review and right-to-left template testing. Product names, email addresses, codes and screenshots can introduce mixed-direction content. Treat those as acceptance examples. Decide whether every supported article must be translated before launch or whether the first release has an explicitly limited language scope.

Define what happens when a translated answer falls behind its source. A visible language option should not quietly lead to outdated steps. Record translation status, revision dependencies and who can approve a fallback or temporary withdrawal.

Product versions need the same care. A customer using a legacy interface should be able to recognise which instructions apply. Decide how old articles remain accessible, how current search results identify versions and when unsupported guidance is retired. Put these rules into the content model before multiplying pages.

Write acceptance checks into the brief

Agree what the supplier must demonstrate before final approval. Cover representative tasks from entry point through answer and escalation. Review the published experience with real content, not only a prototype populated with short placeholders.

• Find an answer through categories, search and a direct product link.
• Complete a task with the correct role and identify what happens without it.
• Try a misspelled search, an ambiguous query and a question with no answer.
• Read a long article on mobile and navigate it with a keyboard.
• Follow migrated links and verify that images, downloads and anchors work.
• Update a draft, obtain approval and publish a correction using the actual editor.
• Check public and restricted content from signed-out and appropriate signed-in states.

Measure findability and usefulness after launch. Useful signals include unsuccessful searches, repeated reformulations, article feedback with context and support contacts linked to an attempted answer. Read a sample of the underlying journeys before drawing conclusions from a dashboard.

Establish a baseline where data is available and note product or support changes that could affect comparisons. Ask suppliers to explain what their measurement can and cannot establish. Do not accept a guaranteed ticket reduction or search-ranking improvement without a defensible basis.

Compare scope, costs and handover

Send shortlisted agencies the same sample articles, priority tasks, languages, platform constraints and review expectations. Request separate estimates for audit, structure, content rewriting, template design, implementation, migration and testing. Clarify how much content is included and who supplies subject-matter review.

Ask which deliverables remain usable by your team: the inventory, taxonomy, search query set, templates, editorial guidance, design files and publishing instructions. Clarify ownership and access to configuration, hosting and analytics. A handover should let your team maintain an answer without reopening a design project.

A sensible discovery stage should resolve enough uncertainty to price the next stage. Ask for explicit outputs and a decision point, rather than an open-ended research allowance. Identify recurring costs such as platform licences, search services, translation and maintenance separately from the initial design fee.

For Makreate, a useful starting conversation brings together your priority support tasks, existing content and platform constraints. Discuss UX design for the information and reading experience and website development where implementation is required. The right scope is the one your customers can use and your team can keep accurate.

Frequently asked questions

What do knowledge base design services include?

A defined engagement can include a content audit, category structure, search experience, article templates, visual design, implementation and publishing guidance. Specify rewriting, migration, translation and testing separately so proposals cover the same work.

Should we redesign our existing help centre or build a new one?

Start by checking whether the current platform can support your content structure, search, templates and review workflow. Commission a new system when a demonstrated requirement justifies the added migration and maintenance work.

How should a knowledge base redesign be priced?

Compare article volume and condition, template types, languages, integrations, access rules and review effort. Ask for workstream estimates, stated assumptions and recurring operating costs rather than comparing a single design fee.