Typedit

Turning fragmented content production into a structured editorial workflow teams could scale with confidence
Client
DoubleD Venture
Role
Senior Product Designer
Scope
Product, UX, content and AI governance
Typedit
Scale
Supported +360% growth in output volume
Coverage
Expanded off-hours output by +235%
Team impact
Human editorial output also grew +81%

Overview

Typedit started with a simple tension. Content teams wanted the speed of AI, but not the mess that often came with it.

Drafts could be generated quickly, but everything around them still felt broken. Sources lived in one place, editing happened in another, approvals were manual, and publishing depended on scattered tools and routines. Teams were moving faster at the beginning of the process, but not across the workflow as a whole.

The opportunity was bigger than designing a smarter editor. It was about creating a product that could support the full editorial lifecycle, from setup to publishing, in a way that felt clear, structured, and reliable.

That is what made Typedit interesting. It was not really a writing tool. It was a workflow product for content operations.

Drag or scroll to explore
No items found.

The problem

The real problem was not writing. It was coordination.

Most content systems do a decent job helping users produce text. Far fewer help teams manage everything that happens before and after that moment. Where does context come from? Which sources can be trusted? Who reviews what? What is ready to publish? What still needs work? How do you keep quality consistent when volume increases?

Those questions usually get answered outside the product, through habits, extra docs, Slack messages, and manual review loops.

Typedit needed to bring that logic into the product itself.

Not as extra admin.
Not as a heavy enterprise layer.
As part of the workflow.

My role

I worked on Typedit as a Senior Product Designer, focusing on the product structure as much as the interface itself.

My role included:

• shaping the experience across the full content lifecycle
• defining how users move from setup to creation, review, approval, and publishing
• designing the product architecture behind key workflows
• simplifying a fairly complex system without flattening what made it powerful
• helping turn a broad AI-content vision into a product with a clearer point of view

A big part of the work was deciding what the product should make visible, what it should automate, and where it should still leave room for editorial judgment.

That balance mattered. The goal was never to replace decisions. It was to make better decisions easier to make.

No items found.

Understanding the workflow

One of the most useful shifts in this project came from looking beyond the editor.

When I stepped back from the writing surface and looked at how content actually moved, the friction became much clearer. Teams were not struggling because they lacked a text box. They were struggling because the workflow around that text box was loose, fragmented, and hard to manage at scale.

Typedit reflected that reality in the way the product was organized. Instead of behaving like a single-purpose editor with a few supporting settings, it was structured around broader areas such as home, creation, progress, and configuration. That choice helped reposition the product from a place where content gets written to a place where editorial work gets managed.

This was a subtle but important difference. It changed the design question from “How should article creation work?” to “How should a content team operate inside this product?”

That question led to much stronger decisions.

Design approach

The design approach was guided by three ideas.

First, make the workflow visible.
Each piece of content needed to feel like something moving through a system, not just a draft sitting in a folder.

Second, bring quality signals closer to the work.
Editorial guidance, source awareness, fact-checking, and SEO support had more value inside the workflow than hidden in separate tools or settings.

Third, design for repeatability.
If the product only worked when a highly involved editor was constantly watching everything, it would not scale. The workflow needed to support consistency, not just output.

This pushed the product toward something more grounded and useful. Less “look what AI can do.” More “here is how a team can actually work with it.”

Drag or scroll to explore
No items found.

Design process

The process started by defining the system before polishing screens.

One of the earliest decisions was to treat onboarding as part of the product logic, not just a welcome flow. Users were asked to set up workspace context, add references, configure integrations, and define editorial style early on. That gave the system a stronger foundation and made later actions feel more relevant, because the product already understood something about the environment it was operating in.

From there, I focused on the main stages of the workflow:

• setup
• creation
• review
• approval
• publishing
• ongoing platform management

Working this way helped keep the product coherent. Instead of designing isolated features and trying to stitch them together later, the experience was built around how editorial work actually progresses.

That made the platform feel more intentional from end to end.

The solution

The final product brought the workflow into one place.

Users could set up the editorial environment, generate and refine content, review quality signals, move pieces through approval, and manage publishing from a shared system rather than across disconnected tools. The strongest part of the solution was not any single screen. It was the way the product connected moments that are usually treated as separate.

A particularly important decision was the approval flow. Instead of pushing every draft immediately into deep editing, the platform created a faster review layer where content could be approved, rejected, or sent back for editing. That made the workflow lighter for teams dealing with volume and helped reduce unnecessary review friction without removing editorial control.

The editing experience itself also carried more responsibility than a standard content editor. It brought writing, AI support, validation cues, source awareness, and optimization inputs into the same environment, which helped reduce context switching and made the work feel more continuous.

The result felt less like a content generator and more like a working system for editorial teams.

No items found.

Impact

Typedit helped turn content production into something more structured and easier to manage.

By connecting setup, creation, review, approval, and publishing inside one product, the platform reduced the operational gaps that usually slow teams down. It gave users a clearer sense of status, ownership, and next steps, while also making room for the kind of oversight that content teams still need when working with AI.

It also created a stronger foundation for growth. Because the workflow was supported by configuration, integrations, and API readiness, the product had room to evolve beyond article generation into a broader content operations platform.

That shift mattered.

The value of the product was no longer just speed.
It was clarity.
It was consistency.
It was having a workflow teams could trust.

Key takeaway

What makes this project strong is that it solves a real product problem, not just a UI problem.

Typedit shows how AI becomes more useful when it is placed inside a well-designed system with clear inputs, review logic, and workflow structure. It also shows the kind of design work I care most about: not just making software easier to use, but helping teams operate with less friction and more confidence.

For me, that was the core of the project.

Not designing a better editor.
Designing a better way for content work to move.

Let's build great products Together.

Start a conversation