Aadhib

Case study · In development

Why we reworked a CMS to feel more like Framer or Wix

The complaint was specific — uploading galleries and video was too complicated. That is a better requirement than most product briefs.

Role
Head of Software Development
Published
Reading time
1 min
CMSRealtime preview
01

Context

The site had a CMS. It worked, in the sense that content could be changed. It just could not be changed by the people who wanted to change it, which meant every gallery update queued behind someone technical.

02

Problem

Content that requires a developer does not get updated. Not because anyone refuses, but because asking is friction, and friction applied to a low-urgency task means the task never happens. The site goes stale for reasons that have nothing to do with the site.

03

Constraints

01
The editor is not technical
The person adding a gallery should not need to understand the content model, let alone deploy anything.
02
Media is the hard part
Galleries and video are exactly where most CMS workflows break down for non-technical users.
03
Preview must be trustworthy
If preview and published output ever differ, editors stop trusting the tool and revert to asking a developer.
04

Approach

I took the comparison seriously. People expect the ease of Framer or Wix because they have used them. Rather than treating that as an unreasonable benchmark, I aimed at it: realtime preview, direct manipulation, and media handling that does not require thinking about formats or sizes.

05

Architecture

Editing surfaceFull-site editing with direct manipulation rather than a fenced-off content area.
Realtime previewThe change shown as it will appear. This is the whole trust model.
Media handlingGalleries and video uploads without format or sizing decisions.
06

Solution

A CMS designed around the editor rather than the content model: realtime preview, simplified gallery management, easier video uploads, and editing scoped to the whole site rather than a content island.

The requirement worth protecting

Not "build a better CMS". A named person needs to add a gallery on a Tuesday without messaging anyone. That is concrete enough to design against and concrete enough to know when you are done — which is rare, and worth defending against the features that will try to attach themselves to it.

07

Lessons

  1. 01A specific complaint beats a feature request. "Uploading galleries is too complicated" is a better brief than "improve the CMS", because you can tell when it is fixed.
  2. 02Flexibility fights simplicity. Every configuration option added for an edge case makes the common path worse, and CMS software for non-developers has to be opinionated.
  3. 03Preview accuracy is the trust model. One divergence between preview and published output and the editor stops publishing.
  4. 04The benchmark is whatever the user has already used. Arguing that the comparison is unfair does not change who they are comparing you to.

Stack

What it runs on

CMSRealtime preview

The project

01Nexel visual CMS
All case studies