crossfill
overview
shipped a dashboard that replaces fragmented manual workflows
overview
shipped a dashboard that replaces fragmented manual workflows

the optimization workflow happened across multiple tools. teams used slack for coordination spreadsheets for tracking google drive for storing outputs and google docs for reviewing optimized content.
this fragmented workflow created unreliable tracking, duplicate work, human errors and slower publishing velocity.
design a dashboard experience that supports the end to end optimization workflow and allows teams to take action directly in the product.
we partnered with customer success and engineering to understand how optimizations were currently managed.
1
with customer success, we audited how optimizations were managed day to day:
slack threads for approvals and updates
spreadsheets for tracking status and dates
google drive folders for optimized markdown outputs
we identified repeated failure points, especially around manual entry, missing context, and unclear ownership of next steps.
customer success shared consistent patterns from client interactions:
clients didn’t know what action to take without being notified
approvals for blog recommendations were a major bottleneck
clients had to leave the dashboard to review content or confirm status
internal teams frequently followed up just to move work forward
one key insight was that blog recommendations from google search console were already data-backed, but approvals were handled manually before optimization even started.
2
we partnered with engineering to define what was possible for the first release.
engineering confirmed:
we could link blog recommendations directly to gsc data
clients could accept or dismiss recommendations in the dashboard
accepted recommendations could automatically enter the backend optimization workflow
we could support permission-based admin controls in the same dashboard view
an inline editor was out of scope for mvp, but could be explored later
this helped us design a solution that reduced manual steps immediately, while leaving room to expand toward inline editing and deeper in-platform workflows that move the product towards being fully self-serve.
3
This v0 approach was a temporary solution while the content editor was in development. At this stage, teams will still rely on Google Docs, and the dashboard functioned primarily as a content tracking and state management tool, not a full self-serve tool.
Because the system could not automatically update states, content and admin teams manually moved items through workflows, created Google Docs, and pushed drafts or HTML to clients.
This workflow was used for about one month.
Idea #1
shipped
explored but not adopted
it introduced duplicated workflow logic that would be replaced once the editor ships
admins/content team aren’t looking at the same screen the client sees

Idea #1
shipped
explored but not adopted
too much information in one view
the panel competed with core actions and made it harder to focus on tasks

Idea #1
Idea #2
shipped
explored but not adopted
a single blog could belong to multiple topics, creating ambiguity about where it “lives”
cognitive load increases quickly as cards accumulate across columns
state visibility was secondary

this first release unlocked future improvements:
moving review and drafting further in-platform
exploring an inline editor for optimized content
deeper integration with search data and performance insights
versioning and re-optimization workflows