Designing a Scalable Editing System at Rippling
At Rippling, I led the redesign of how content is created and discussed across the product. What began as a document editor problem evolved into a foundational system that now supports long-form creation, comments, and structured input across multiple product teams.
Introduction
As Rippling scaled from SMB to Enterprise, documentation became mission-critical. Users relied on an editor that was optimized for print precision and not fast creation or collaboration. Users spent excessive time formatting documents and had to leave Rippling to collaborate over Slack or email, eroding trust in the platform. What initially surfaced as a single customer complaint turned out to be a systemic gap.
Role
Lead Product Designer
Duration
4 Months
Team
1 Product Manager, 1 User Researcher and 4 Software Engineers
Disclaimer
Due to confidentiality and NDA constraints, specific metrics and internal data have been intentionally abstracted. Impact is described qualitatively to reflect relative outcomes and scale
Problem
Rippling's Document Editor was built for printing documents. However, as teams grew, users spent more time
Fixing formatting and layout than, writing
Collaborating in Slack/Email to improve the content
Iteration became slower and risky
In parallel, other teams also needed a quick, lightweight editor for logging discussions and decisions in products.
The existing editor variants optimized for information transport, were blocking creation, collaboration and reuse.
Existing Document editor
Existing Text editor
Research
I partnered with User Research to conduct a foundational research enquiry to understand how content lived in Rippling over time, identify how broken are the existing editor models and verify if same needs appearing across platform.
Insights
Content was no longer short-lived.
Structure mattered more than formatting.
Collaboration anchored on parts of content, not the whole document.
Goal
User
Create with ease, collaborate in context, and trust your work to hold meaning over time
Business
Build once, scale everywhere powering enterprise workflows while increasing delivery speed and reducing long-term complexity
With a team of Product Managers, Engineers and User Researchers, we began collaborating on strategy, phasing and building fast to unlock parts of the new editor system based on the principles of Speed, Consistency and Modularity.
Building the architecture
We began by switching the content architecture from Monolith model to Block model. Block model provides flexibility with content types, reusability of content and modularity.
Learn more about Block editors here.
This work was intentionally invisible. Users didn’t see it, but it allowed every future surface documents, comments, inline inputs to speak the same language without breaking legacy content.
Editor Content Architecture
Designing the editor system
After creating the Block model, I designed the interaction layer for the new editor system. This consisted of designing the canvas, the content menu, the format toolbar, the reorder system.
These elements are modular and can be customized based on the needs of a product context. It also ensures that these elements remain consistent in their appearance and behaviour wherever they are placed.
Canvas placeholder invites users to just start typing
Select any content to add from content menu
Formatting toolbar appears on text selection
Designing all content blocks
I designed individual content blocks such as Text, Heading, Link, Media, Quote, etc. with specifications, interaction behaviour and guidelines to use. Each block in the editor canvas can add any type of content based on user selection while editing. These content blocks remain consistent across different editors with the same foundation thus enabling consistency within different contexts.
Icons for content types
Heading types available as blocks
Text, Inline and Card links with previews
Media block with contextual actions
Table block with customizations
Mention your team members in the canvas
File chips for uploading files in the canvas
Putting everything together
One the editor foundation and blocks proved stable, I designed the full screen editor as the first surface with most visible friction. This surface carried the highest expectations and the highest risk. It was where users drafted contracts, offers, and long-lived documents and where the old editor failed them most.
Shipping the full document editor did more than solve a local problem:
It validated the editor foundation under maximum complexity
It set a consistent mental model for creation across the product
It made future surfaces cheaper to build and safer to ship
Two editor modes • Same foundation
Impact
Time to publish reduced by 50%
NPS improved significantly
For product teams, editors can now be customized and used in the products, faster, with the same foundation.
Learning
Early engineering alignment reduces long-term cost
Small user pain often points to platform-level problems
Managing assumptions is as important as solving problems
To explore the full design story, system decisions, detailed interactions and impact, message me on Linkedin to access the detailed version of the project case study.