Gushwork AI Editor
Gushwork - AI Website Editor

Overview
Designing an AI editor which re-designs the existing websites of our customers.
Gushwork is a platform to generate qualified inbound leads from AI Search Engines on autopilot for your business. Gushwork’s AI agents help your business get discovered by your buyers, across AI search, Google, and paid channels, then turn that interest into marketing-qualified leads.
Problem statement
Solving for customer satisfaction and automating customer success workflows.
Gushwork helps hundreds of businesses across the US show up in search by producing a steady stream of content. The problem here was that every client has their own set of design and content guidelines which makes it difficult for us to templatise. But in order to make it automated, some parts of it was templatised and some derived from their existing site or guidelines. Until the editor was launched, clients used to directly convey the changes and our customer success teams would then relay that to our web developers and get those changes done manually. This costed a lot of loss in manpower which could have been more productive. The AI editor which I'll explain more about comes into play and makes this cumbersome process almost self-serve for the clients.
Research
Understanding what type of changes do our customers actually demand
I had to shadow a dozen calls and also go through 50+ recordings of meetings between our clients and customer success teams to understand what type of changes are they requesting us for. Is it more inclined towards aesthetics, structure or content? These were the 3 buckets which I classify the changes based on. We use Sybill to record the calls, and then use the transcripts to create a repository of all ctypes of changes ever requested to make sure all of it is covered.

Nuances
The catch here is that - given the advent of exponential rise in website editing tools like Lovable, Vercel, Emergent and more, people have become used-to a particular type of form factor when they are conversing with an agentic design tool. If you notice the pattern, it's always a chat bot on either side of the page and a large preview of the main crux which they are editing or producing. This was one of the biggest index point for us - we did not want to reinvent a newly invented way of editing/generating websites. That would be a fool's ambition. So, I took that baseline structure and started to test it for all our workflows. The other issue was timeline. We needed to ship this product in under a month because business was booming and the rate at which customer requests were filling in - we were almost at neck's length. So, time was of essence, keeping that in mind I detailed out the simplest approach to solving all our expected requests i.e via NLP. I decided to keep visual editing aside since that does not add much value to the outcome we need and also adds weeks to the development process.


Designing the final experience
Solution 1
Every word the interface says to the user is part of the product. In an AI tool the copy carries more weight than usual, because it sets expectations for what the AI will and won't do. I wrote the UX copy across the editor so that actions read as invitations rather than commands, errors explain everything with a solution, and the AI's suggestions are phrased as efficient alternatives. Small wording choices, "suggest a rewrite" instead of "rewrite," "review changes" instead of "apply," quietly keep the client in the driver's seat and makes them more intentful.
Solution 2
Generative tools spend real seconds thinking, and those seconds are where trust is won or lost. I designed the loading and in-between states with much thought so the editor never feels frozen or broken while the model works. Instead of a dead spinner, the interface shows that something purposeful is happening, keeps the writer oriented in their document, and makes the wait feel like the tool working rather than the tool hanging. Designing these states well is invisible when it succeeds, and painfully obvious the moment it is skipped.

Solution 3
The editor is built from a small, consistent set of pieces, the suggestion, the accept and reject controls, the AI invocation, the review view, so that once a writer learns one interaction they understand all of them. Buttons, inline suggestions, and review states follow one shared logic, which keeps a feature-rich editor from turning into a cluttered one. The consistency is what lets the AI grow more capable over time without the interface getting more confusing.


Outcome
Early signal that clients are effectively using the AI editor
In the first weeks after launch the editor was already pulling real, repeated use, with more than 750 messages sent to it inside the first month across a growing set of active customers. That early usage did something more valuable than any vanity metric: it showed us exactly what writers wanted the AI to do next. By watching the patterns in what people were asking for, we could see them naturally pushing the editor toward editing their forms, not just their words, which became the next thing we built, letting them prompt the editor to add fields, remove or replace existing ones, and define what happens after a form is submitted. That is the part I care about most. A good editor does not just get used, it tells you where to take it next, and this one started doing that within days of going live.