AI-assisted workflow design
01 / 08Designing Human–AI Collaboration for Workflow Creation
Turning a business goal into an editable workflow draft while keeping users in control
At a glance
Challenge Creating a template manually required enterprise users to understand each action first. As Moxo expanded to more businesses, relying on Customer Success for setup would not scale.
Response The team added a natural-language entry point. AI Copilot turns a business description into an editable first draft in the existing Builder canvas, so users can start without asking Customer Success to build the template.
Early signal More than 60 valid prompts arrived in the first six hours. That showed early interest, not long-term use or draft quality.
Context & Challenge
Turning business intent into reliable workflow logic
Moxo was already mature and needed to let more enterprise teams create Workflows on their own, without relying on Customer Success for every setup. The challenge was that Actions, Triggers, roles, and dependencies were hard to configure by intuition. Onboarding and Help Center guidance only went so far.
- Users can describe a business goal without knowing how to break it into Workflow logic.
- Natural language lowers the entry barrier, but it cannot fill in missing roles, Triggers, inputs, or dependencies.
- The team chose to let AI create an editable first draft. Users confirm the key details, then return to the existing Builder to review, edit, and publish.
Research Evidence
Customer Success showed us what AI needed to clarify
The Customer Success team shared the real SOP they use in customer conversations. It starts by clarifying the goal, roles, trigger, required information, order, and dependencies before anyone configures a Workflow.
I mapped that sequence into product behavior. When information was missing, AI asked for details that could change the workflow draft before generation.
This evidence defined what the product needed to clarify. It did not measure adoption, draft quality, or time saved.
Design Strategy
Defining how AI and people work together
I compared three ways for AI and users to divide the work. I looked at input cost, handoff, user control, and implementation complexity.
Customer Success brought examples from real setup conversations. I worked with Product to set the boundary for the first release, then reviewed the states and delivery cost of each model with Engineering.
Evaluation criteria
Four questions guided the comparison
These are evaluation criteria, not steps in the user flow.
Input cost
How much information must users provide before AI can act?
Handoff
Is it clear when AI stops and the user takes over?
User control
Can users inspect, change, and approve the result?
Complexity
How much new state and engineering work does the model create?
Decision 01
AI generates first; people review and edit afterward
Editing with AI in real time made ownership and state changes hard to follow. A separate AI mode kept the states apart, but forced users to switch modes and cost more to build.
I recommended the AI-first model. AI creates the draft and opens it in the existing Builder. The user can inspect it, edit it, and decide whether to publish.
Decision 02
Ask key clarification questions instead of generating immediately
I compared three prompting approaches. Direct generation forced AI to guess missing roles and workflow logic. Asking for everything produced a long setup process.
The final approach asks only for information that changes the workflow structure, then moves the user into an editable draft.
Decision 03
Turn the prompt into an editable workflow, not a conversational answer
I designed the handoff around three stages: describe the goal, fill the gaps that affect the workflow, and review the draft.
The draft opens in the existing Builder. Users can keep editing with familiar controls instead of rebuilding the workflow from scratch.
Phase I · Launched
Validate one complete creation loop
Start with a prompt, clarify missing structure, generate a draft, and continue editing in Builder.
Validation focus: Can users get a complete, inspectable draft from business intent?
Phase II · Designed
Extend AI to existing actions
Let users request a local change while preserving the rest of the workflow, its order, and its dependencies.
Scope boundary: Designed for the next phase; not presented as a launched result.
Phase I · Launched
From business goal to an editable workflow draft
The existing Canvas already handled manual add, edit, and delete actions. This release added the AI creation entry point and defined the handoff between AI and Actions, while keeping the Canvas structure and manual editing behavior in place. The first release covered one complete path: describe a goal, answer focused questions, and edit the draft in Builder.
Step 01
Describe the business outcome
The user begins in natural language, explaining the process they want to create rather than configuring workflow objects first.
Step 02
Confirm the information that changes the draft
AI detects missing details and asks focused questions about roles, logic, or integrations before generation.
Step 03
Review and continue editing in Builder
The generated workflow opens in Builder. Users can check its structure, fix issues, and keep editing with familiar controls.
Phase II · Designed
Use the same review model for changes to existing workflows
The next phase used the same handoff for existing workflows. AI could prepare a local change, but the user reviewed it before it was applied.
Expansion 01
Change one action without regenerating the workflow
A full regeneration could overwrite structure that users had already confirmed. Action-level AI kept the current workflow context and changed only the target action.
The flow had five steps: request, clarify, modify, review, and confirm.
Expansion 02
Turn repeated interactions into reusable patterns
Actions need different inputs, but they can use the same interaction rules: collect missing details, connect required tools, and confirm roles or business rules.
I ran recurring design reviews to apply these rules to new AI features and document the patterns for the team.
Expansion 03
Make problems visible and recoverable
Flow Checker showed where a problem occurred, what was missing, and what the user could do next.
The design defined the visible state and available actions for input, confirmation, processing, results, errors, and recovery.
Outcome & Measurement
What the launch showed, and what it did not
Phase I shipped the complete prompt-to-draft flow in the existing Builder. Users could begin with a business goal instead of configuring system objects first.
The first six hours after launch showed interest in this entry point. That signal did not prove repeat use, draft quality, or time saved.
in the first six hours after launch.
the end-to-end prompt-to-draft flow in the existing Builder.
Confidence after generation
Do users understand the draft and feel ready to continue?
Valid prompts and repeat use
Does the early signal continue after the first launch period?
AI-started workflows
How often does AI become the chosen entry point for creation?
Repeat workflow creation
Do users return to Copilot for later workflow creation?
Drafts completed and published
Can users reach a usable workflow without excessive repair work?
What this did not prove
Prompt volume showed early interest only. We still needed to track repeat use, repair work, completed drafts, and published workflows.
The hard part was defining responsibility
Generating a workflow was only part of the problem. The harder decision was where AI should stop and when the user should take over.
Users needed to see the result, correct it, and continue in familiar tools. Without that, a fast draft would not be trustworthy.
Next Project