Case Studies
Slide Templates

Schema Template Designer

Turning customer pressure and internal ambiguity into a buildable workflow

Mike - Product Design | Nexla | May 2025

Executive Summary: Define the Minimum Workflow Worth Building

Customer pressure and delivery constraints forced a sharper design decision.

Problem (what the team was hearing)

Template workflows were creating friction for customers and internal teams:

  • Customer-facing teams kept hearing preview complaints
  • Apply flow semantics were still confusing
  • Authoring risked becoming overbuilt before the core loop was clear

Solution (what I narrowed the work to)

Define the minimum viable contract workflow:

  • Shape + validations + meaning
  • Unmapped-first apply defaults
  • Read-only preview users could trust
  • A simpler authoring model engineering could code

Outcome (why this mattered)

The work got smaller and more buildable:

  • Clearer implementation target
  • Less debate about garnish versus essentials
  • A stronger link between UX choice and delivery cost

Context: Who Needed This Workflow to Work

Who this had to serve

  • Template consumer trying to close unmapped gaps quickly
  • Template author defining rules and meaning at scale
  • Customer-facing teams carrying the fallout when preview and apply were unclear

Constraints that mattered

  • Preview behavior was a repeated complaint
  • The system saved multiple JSON structures behind the scenes
  • The team wanted to reduce dev effort, not grow it
System flow from template authoring to template apply and destination

The Pressure Was Repeated Customer Pain Plus Delivery Cost

The conversation kept returning to two facts: customers were feeling the pain, and the team could not afford to overbuild.

I keep getting asked from a customer facing side of things is when is that getting solved?

Review sync (Saket Mike Niket 2025-05-14)

The preview is a problem that I keep getting from different customers, and we do need to fix it.

Review sync (Saket Mike Niket 2025-05-14)

I'm really kind of very hesitant on investing too much dev effort.

Review sync (Saket Mike Niket 2025-05-14)

context

5

Context

This work sat in a product area where schema rules, preview behavior, and mapping outcomes were tightly connected, but the implementation model was fragmented. The design had to help operators, contract authors, and customer-facing teams reason about the same workflow without pretending the complexity was gone.

approach

6

Approach

I treated the work as a scope exercise first: identify the few workflow decisions that would reduce customer pain and still be buildable quickly. That meant defining what should be explicit in the UI, what should stay read-only, and where existing JSON-based patterns were more valuable than a richer but riskier interface.

discovery-and-evidence

7

Discovery and Evidence

The strongest signals came from review conversations that tied preview confusion to customer-facing pain and engineering-effort concerns. The team was explicit that a polished answer to the wrong problem would still be a miss if it took too much development time or created a workflow we would need to undo later.

Design the Smallest Contract Workflow That Could Carry the Weight

Design decisions that unlocked v1

  • Treat the contract as shape + validations + meaning
  • Default apply to unmapped gaps first
  • Keep preview read-only so users trust what it represents
  • Use inline-first patterns now and reserve heavier scaling patterns for later

Why engineering could build it

  • Reuse existing JSON and guided patterns instead of inventing a new system
  • Avoid connecting every surface to every other surface in v1
  • Keep the implementation target smaller and more explicit
  • Reduce the chance of building something the team would need to walk back
Contract mental model diagram showing shape, validations, annotations, and preview

implementation

9

Implementation

The implementation direction stayed intentionally small: reuse guided and JSON-based patterns, define the contract workflow explicitly, and avoid coupling every authoring and preview surface. That gave engineering a tighter target and lowered the risk of backing into a more expensive redesign later.

What It Proved, and What I Would Hold It To

Directional outcomes now, with explicit success measures next.

Directional outcomes

  • Less ambiguity in preview and apply behavior
  • Better alignment between UX choice and dev effort
  • A clearer story for customer-facing teams to carry forward

Measurement frame

  • Time to valid output
  • Preview-to-import conversion
  • Edits after import
  • Support signals tied to preview and apply confusion
What this proves for Clio: strong IA work ties customer pain, scope discipline, and implementation reality together

reflections

11

Reflections

The lesson I would carry forward is that strong information architecture is often a scoping discipline before it becomes a UI discipline. When customer pain, internal ambiguity, and dev effort pull in different directions, the design job is to define the smallest workflow that can earn trust and still move the business forward.

appendix

12

Appendix

  • Primary evidence came from schema workflow review sessions and customer-facing feedback loops captured in the Context/Schema Template Designer transcripts
  • The strongest sources were Saket Mike Niket 2025-05-14.diarized.txt plus the UX-Design-Sync-* files that clarified apply, preview, and authoring tradeoffs