Choose a CMS after testing your team's real publishing tasks, not after watching a feature demonstration. Can a writer prepare a change, a subject expert review it, a translator maintain its counterpart and a publisher release the approved version without excessive permissions? The right system supports those tasks with understood operating costs and support responsibilities.
This decision concerns a company website publishing services, articles and documents in Arabic and English. Not every business needs elaborate approvals. But undefined responsibilities can leave everyone dependent on one person, or give every contributor more access than their work requires.
Start with an actual working week
Ask editors about their last three changes. What changed, who reviewed it, where did it wait, and when was technical help necessary? Include routine work and awkward situations: correcting a published claim urgently or replacing a download without losing links already shared with customers.
Turn these into observable outcomes. For example: “The editor can revise a service description and save it for review without changing the public page.” GOV.UK's user-story guidance connects the actor, need and goal, with acceptance criteria used to check the outcome. Writing user stories.
Product Discovery and Requirements can establish which tasks are essential. Avoid requesting “complete flexibility.” Specify useful flexibility, such as adding an FAQ section or reordering a card, and the elements that should remain controlled, such as approved conditions or site settings.
Replace a shared login with a role/task matrix
| Role | Required task | Additional acceptance check |
|---|---|---|
| Writer | Create and revise a draft | Cannot release it without approval |
| Service reviewer | Confirm facts and return feedback | Cannot change system settings |
| Translator | Edit the counterpart | Can identify a changed source |
| Publisher | Preview and release approved content | Can recover from a wrong revision |
| Technical administrator | Manage configuration and access | Individual accounts and responsibilities exist |
One person may hold two roles. That does not mean every contributor needs unrestricted access. Role names differ between products, and configuration or extensions can alter their powers. Test the operation rather than trusting the label “editor.” Revision history also does not automatically provide bilingual approval.
Demonstrate difficult content before buying
Give each shortlisted supplier the same small test set: a long Arabic service page, its English counterpart, an image with a description, a specification table and a download. Have your employee perform the task instead of watching only a practiced salesperson. Record where explanation or developer assistance is needed.
The demonstration should include mobile preview, saving without publishing, returning a draft, correcting live content and handling a missing image. A successful plain-text page cannot establish that tables or mixed-direction numbers work. Website Design should balance editing freedom with reusable layout boundaries; editors should not rebuild the page structure every time.
Hypothetical example: a bilingual consultancy
Imagine a consultancy with an editor, a service reviewer, a publisher and an occasional external translator. This is an illustrative exercise, not a client result or platform endorsement. The team needs to change a service scope without leaving a new Arabic promise beside contradictory English copy.
In the first candidate, the editor's saved change becomes public immediately because permissions are too broad. In the second, it remains a draft, but the publisher cannot preview Arabic in the actual page layout. Both reveal gaps. Neither necessarily settles the purchase: ask for the cost, dependencies and support implications of closing the gap.
Acceptance requires the old public copy to remain until approval, visible language states, connected counterparts, a usable preview for both languages and a record of factual approval. If an extension or custom development is necessary, include it explicitly in CMS Development, with an owner for updates and maintenance.
Do not treat the configuration demonstrated by a supplier as proof that the same behavior is included in your quoted plan. Record the edition, installed extensions, custom components and any work still required. A successful demonstration is evidence for that setup, not every product carrying the same name.
Compare operations, not just licence fees
List ongoing work: platform and extension updates, account management, editor support, backups and any tools required for translation or approvals. Verify export and asset portability if suppliers change. Open-source software is not equivalent to cost-free operation; a subscription does not necessarily include bespoke changes.
Classify requirements as essential, temporarily manageable by a documented manual process, or optional. Do not buy complexity to prevent a theoretical problem while daily publishing remains difficult. Conversely, do not accept a manual approval workaround that your team cannot reliably follow.
Trial acceptance criteria
- The trial uses a configuration representative of the proposed scope, not unlimited demo access.
- Staff complete the agreed editing and publishing scenarios.
- Restricted users cannot perform unauthorized operations.
- Arabic, English and downloads appear correctly in preview.
- Extensions, costs, limitations and manual steps are disclosed.
- Defects and retests are documented through Quality Assurance.
Frequently asked questions
Should we choose the system our editor already knows?
Familiarity is valuable, but it cannot compensate for an essential missing workflow. Compare training effort with the cost of recurring workarounds and support.
Must every approval happen inside the CMS?
No. An external documented approval may work if it identifies a specific version and the process prevents an unreviewed revision from being published.
Must both languages always launch together?
Set that policy according to the consequence of divergence. Service scope and conditions need stronger control than a spelling correction that does not alter meaning.
What should handover include?
Appropriate accounts, task-specific instructions, practical training, known limitations and the support and export process. A generic platform video may not describe your site's configuration.
Before you select a platform
Bring LAB five real publishing tasks and your current role matrix. A focused comparison can establish fit before you commit to the entire website build.
Sources
- GOV.UK: user stories and acceptance criteria, reviewed 26 October 2026; used to frame requirements, not endorse a product.
