AI SaaS Workflow Builder

Problem

AI-assisted workflows can feel opaque when the interface treats generated output as a simple success or failure. The product surface needed to help users understand progress, review recommendations, and recover from uncertain states.

Constraints

• AI latency and partial results
• Multi-step user decisions
• Existing product patterns
• Permission-aware actions
• Clear recovery from errors

Approach

• Mapped the workflow as explicit states instead of a chain of ad hoc loading flags.
• Separated generated recommendations, user review, and final submission into clear UI responsibilities.
• Defined reusable interaction patterns for pending, reviewing, accepted, rejected, and failed states.

Architecture decisions

• Kept workflow state close to the feature boundary while exposing typed view models to components.
• Used product-language component APIs so templates read like the workflow they represent.
• Designed loading and error states as first-class states, not afterthoughts.

Trade-offs

• A more explicit state model added upfront structure, but made edge cases easier to reason about.
• Reusable workflow primitives reduced repeated UI patterns, while still allowing feature-specific copy.

Impact

• Improved maintainability
• Clarified component ownership
• Made future feature work easier
• Improved consistency across similar workflows

What I learned

• AI SaaS UX needs interfaces that explain uncertainty, not just outputs.
• The best loading state is often a product state with a clear next step.