Blueprints

Context

Most workflow creation tools assume users think in components. They don’t.

Authors weren’t struggling with content - they were struggling with structure:

• Where do I start?
• What pattern should I use?
• What comes next?

This led to repetition, inconsistent workflows, and slow creation cycles.

Templates Use-cases ↗

Problem Statement

How might we help creators build high‑quality workflows quickly while preserving flexibility and consistency across organizations?

---

Key Insight

Users struggle more with structural decisions than content. They think in intent, not UI components

---

Research & Insights

Creators think in terms of intent, not UI components Templates reduced cognitive load but risked over‑constraining users Authors preferred starting from examples rather than blank canvases New users struggle with structural decisions more than content decisions Repetition of patterns was high across accounts and teams Manual binding of UI elements was the biggest time sink

Strategy & Thinking

The core insight was that authors don’t think in UI components; they think in intent and outcomes. Instead of asking users to assemble flows step-by-step, the system should start with _what they want to achieve_.

We mapped common enterprise use-cases (onboarding, compliance alerts, training, feature adoption) and translated them into reusable blueprints. To reduce cognitive load, I designed a flow where users move from:

Intent → Use case → Blueprint → Customisation

rather than manually assembling UI components.

Exploration

Finding the right level of control. We iterated across multiple approaches:

The Tension

Every iteration surfaced the same challenge:

How much should the system decide vs the user?

Too little → overwhelm Too much → loss of control

---

Proposed Figma Demo

• _Choose from Templates_

• _Prompt a Solution/Blueprint_

Solution : Intent-first Authoring

The breakthrough was shifting the starting point: Intent → Blueprint → Customize → Publish

Instead of constructing flows manually, users:

• Define what they want to achieve
• Receive a structured, editable starting point
• Refine rather than build from scratch

What I Designed

• Reusable blueprint system based on enterprise use cases
• Editable templates (not rigid) to maintain flexibility
• AI-assisted generation for first drafts
• Guided defaults to reduce decision fatigue

From Use-case _prompt_ to Goals to Solutions to Implementation

PoC Demo (AI enabled creation only)

Try it here https://v0-template-library-nine.vercel.app/ ↗

---

Designing the System

This required solving for system behavior, not just interface design:

The backend complexity directly shaped UX decisions - especially around transparency, editability, and control.

Trade-offs

Every decision balanced competing priorities:

Flexibility vs Standardization - Structure improved speed, but risked limiting edge cases Automation vs Control - AI reduced effort, but required clear user override Speed vs Accuracy - Faster generation needed guardrails for enterprise quality System Power vs UX Simplicity - A complex system had to feel intuitive and lightweight

Impact*

• ~75% reduction in creation time (60 → 10–15 mins); Significantly reduced time-to-value for new creators
• Improved success rate for first-time users
• More consistent workflows across teams
• Shifted mental model from _“how do I build?”_ to _“what do I want?”_
• Laid groundwork for AI-assisted authoring and scalable governance

---

Reflection

The real shift wasn’t templates - it was changing the mental model:

From “How do I build this?” , to “What do I want to achieve?”

The hardest part wasn’t designing the feature - it was defining the right level of opinionation, where the system guides without restricting.