A general-purpose editor cannot know a team’s brand styles, design system or editorial habits. When the editor does not fit, every piece of content takes longer, and editors end up asking developers for help with tasks they should be able to do themselves.
We recently worked with a global client in a regulated industry to improve the rich text editor its teams use in Amplience. We turned a long list of editor requests into a phased roadmap. Then we delivered it: a larger and clearer editor, on-brand content blocks, richer tables, inline images, and in-editor find and replace.
This post explains how we approached the work and what we learned along the way. Later posts in this series look at each area in more detail.
Where we started
Amplience is designed to be extended. Its extensions framework lets teams add their own editing tools inside the content form. This means the editing experience can match the way a specific team works.
Our client's rich text field was one of these extensions: a custom editor built on Slate, an open-source framework for rich text editors. It had served the team well for years, but their needs had grown. The editorial team's day-to-day issues included:
A small editing area. Long content needed constant scrolling, and the page jumped when editors applied formatting.
Unclear style names. Text styles appeared as internal code names, such as "h1" and "b3", so editors had to guess which one to use.
No visible images. An inserted image appeared only as a text label with its file name, not as a picture. Editors could not see the image, or how it fit with the text, until they previewed the page.
Basic tables. Editors had few options for color, width or header rows.
No on-brand elements. Adding a call-to-action button or a pull quote needed help from a developer.
No find and replace. Updating a repeated phrase meant reading through the whole entry.
None of these issues were limits of Amplience itself. They were gaps between a general-purpose editor and the specific needs of one team and its brands. Closing gaps like these is exactly what Amplience extensions are for.
Listening first
We started by collecting the editorial team's requests. Some were small, such as clearer style names. Others were large, such as inline images with layout controls.
For each request, we documented five things:
How the editor worked today
What was needed to improve the editorial workflow
The likely technical approach to achieve the desired improvement
An effort estimate
The main risks
This gave the client's product owners a clear view of cost and value, so they could decide what to build first.
Scoping also showed where each change would live. Some changes were code in the editor extension. Others were configurations in Amplience, such as the content type schemas that control which tools appear in each field. Knowing this early meant the right people were involved from the start.
A phased plan
We grouped the requests into phases. Each phase delivered something useful on its own, so editors saw improvements early while larger features were still in design.
Quick wins. We made the editing area larger and resizable, stopped the page from jumping during formatting, and gave every style a clear name with its sizes.
On-brand content blocks. Editors can now insert call-to-action buttons, highlighted paragraphs, pull quotes, expandable TL;DR summaries and call-out boxes, all in approved brand styles.
Tables and images. Editors gained full control over table styling, and can place images directly in the text with options for alignment, size, spacing, borders, links and alt text.
Finding text. Editors can find and replace text within a content item. A new dashboard extension also searches the whole hub for a phrase and shows every live page where it appears.
What we learned
Show editors what readers will see. Some designs only work on the live page. A call-out box, for example, sits beside the main text on the website, but the editor can only show it in line with the text. Without a clear cue, editors cannot tell how their content will look until they preview it. So each new block has a distinct look in the editor, and where the live page differs, a short note explains how it will appear.
Build in accessibility and SEO from the start. The new content blocks use semantic HTML, meet WCAG AA color contrast, and work with a keyboard. Collapsed content stays in the page, so search engines can still read it. Adding these qualities later costs far more than including them from the beginning.
Give editors choices within brand rules. The client manages more than one brand in the same Amplience hub. Instead of fixed colors, editors choose from each brand's approved palette. They get creative freedom, and the output stays on brand.
Decide what not to build. Not every request made it into the roadmap. With clear estimates and risks for each item, the client could pause or drop some requests with confidence and focus the budget on changes with the most value.
The result
The editorial team has welcomed the changes. Editors now work in a larger, clearer editor where they can see the page they are building. They can create richer, on-brand content on their own, without waiting for a developer.
The rest of this series looks at each area in detail:
Custom Content Blocks in Amplience: Staying On-Brand Without a Developer: call-to-action buttons, highlighted paragraphs, pull quotes, TL;DR summaries and call-out boxes.
Tables and Inline Images in Amplience: Beyond Basic Formatting: the two largest features of the project.
Where Is This Text Used? Building Hub-Wide Phrase Search for Amplience: a dashboard extension that finds any phrase across the whole hub and traces it to every live page.
Is your editor working for your team?
Amplience gives organizations a flexible foundation. The real value comes from shaping it around to the people who use it every day. Small changes to the editing experience add up across every piece of content, every editor, and every brand.
At Achieve Internet, we help organizations get more from Amplience, from custom editing fields and dashboard extensions to search, integrations and content workflows. If your editors are working around their tools instead of with them, let's talk.
