Design Leadership for Clio's Next Stage

Workflow clarity, team judgment, and customer trust in AI-era legal work

Mike Long | Manager, Product Design case study

How I Will Use the Hour

I will keep the prepared path simple: a short intro, then two cases that show how I make complex work clearer.

What this talk needs to prove

I will make the evidence visible without turning this into a rubric walkthrough:

How the work started and why it was worth doing
How customer pain changed the workflow and team contract
What changed, what I would measure, and what I learned

How I will run it

Two stories carry the prepared path:

BYO Code Flows: product/craft case from inside the work
Shortcut Org Reset: leadership and team operating-system case
Schema Template Designer stays in the appendix for scope judgment

What I want the panel to leave with

My management style is practical and inspectable:

Stay close to customers
Make tradeoffs visible
Build conditions where teams can own quality

Prepared path: short intro -> BYO product/craft case -> Shortcut leadership case -> Q&A

summary

3

The Throughline: Make Complex Work Legible

About fifteen years across consulting, cloud platforms, developer workflows, data products, and product-led growth
Managed product design, research, brand, and design systems across different company stages
Led teams that usually sat in the six-to-twelve direct-report range, with product designers plus research, brand, or systems depending on the company
Stayed hands-on enough to coach the work, but focused on making quality repeatable through the team

My Leadership Philosophy: With, Not For

The best mentorship happens in the work, before the decision is too expensive to change.

I do not wait for the one-on-one to coach the work
I help designers name the problem, evidence, tradeoffs, and decision rule
I work with PM and engineering because triad culture determines whether good design survives delivery

The manager job is not to be the best critic in the room. It is to raise the quality of decisions across the team.

Why Clio, Why This Role

What is compelling

Clio is moving from legal systems of record toward connected systems of action
International work forces clear decisions about what stays core and what must adapt locally
AI raises the cost of vague UX because lawyers need trusted context, next steps, and accountability

Where I fit

I have led technical products where hidden system behavior created user risk
I have helped teams improve craft inside engineering-led cultures
I am comfortable leading across time zones, disciplines, and ambiguous product constraints

What Keeps Me in the Work

I like hard domains because the product has to earn trust, not decorate complexity.

I am motivated by teams that want to understand the work deeply enough to make it simpler
I like being close to designers and triads while still building the rituals that let them move without me
Outside work, I am usually making something, learning a domain, or getting outside with family; the same curiosity shows up in how I approach product problems

The Leadership Problem I Keep Seeing

Powerful products fail when workflows, ownership, and evidence stay implicit.

Product risk

The user sees capability but not enough context:

Important logic hides in the wrong part of the flow
Status and recovery require insider knowledge
Local workflow differences get treated as text changes instead of product decisions

Team risk

The team ships ambiguity forward:

Design gets treated as service work
PM, design, and engineering reason from different facts
Modern tools make output faster without making judgment better

Manager job

The work is to make both systems clearer:

Customer evidence changes the frame
Design strategy gives the team a contract
Rituals help designers and triads own quality

I Will Be Explicit About I, We, and Evidence

This keeps the story honest: who changed what, who delivered it, and what evidence supports the claim.

I: where I reframed the problem, coached the designer, shaped the interaction model, or changed the operating system
We: where the team, triad, or organization delivered the work together
Evidence: quotes, transcripts, PDFs, public Clio context, or clearly labeled measurement frames
Constraint: I will not inflate outcomes when the source only supports a directional claim

Why Self-Serve Became the Work

What made it worth doing

Let customers bring custom code into Nexla-managed data flows
Give solutions architects a faster path for customer-specific transformations
Move from SA-assisted delivery toward a product customers could reason through themselves

My role

Reframe the problem from code editor UI to workflow trust
Coach the interaction pattern through live walkthroughs and prototypes
Align product and engineering around a smaller, buildable v1 contract

What Broke in the Real Workflow

The customer-facing signal was not cosmetic. It was comprehension, confidence, and recoverability.

The flow to do that is really counterintuitive because you need to put a file path here, which needs to be hard-coded.
Customer/SA walkthrough, 2025-10-21

As a first-time user who is self-serving, this is super confusing because I don't know whether I should click on run now.
Customer/SA walkthrough, 2025-10-21

Ideally, we want to get to a state where customers don't need our help to do everything.
Customer/SA walkthrough, 2025-10-21

The V1 Reality Check

The first version exposed capability but scattered the mental model.

The Design Contract: Make Code a Workflow Object

User contract

Source brings data into the flow
Code transforms or processes it as a visible step
Destination receives the output after the user can test and understand what happened

Team contract

Use customer evidence before solution debate
Name the state model before polishing screens
Separate v1 buildability from future architecture wishes
Review behavior in prototypes, not only static mockups

Decision 1: Move Code Into the Flow

What changed

BYO became a visible processing step between source and destination
The code container became a thing users could inspect, test, and understand
The flow diagram started carrying the mental model instead of hiding it

Why it mattered

Less hidden logic for customers
Clearer interaction object for engineering
A reusable pattern for future code-heavy workflows

Decision 2: Promote Authoring From Drawer to Workspace

Why the drawer failed

Code, docs, runtime settings, output, and errors competed for space
Important feedback was easy to separate from the code that caused it
The task needed continuity, not a modal-feeling interaction

What the workspace created

Code became the primary work surface
Console and output stayed close enough to support iteration
Configuration moved to a supporting rail instead of owning the experience

BYO full workspace editor with code, console, and supporting configuration

How I Coached the Work

What changed as we learned

The problem shifted from code editor to workflow trust
Testing became part of the interaction model, not a utility afterthought
Preview and download behavior became central to file-based debugging
Status and next action became design requirements, not backend footnotes

What I coached into the process

Show options early enough to expose tradeoffs
Separate v1 decisions from later architecture desires
Use reviews to name ambiguity before it hardened into implementation
Keep the team focused on user confidence, not feature inventory

AI Made the State Model Reviewable

The useful AI move was not faster decoration. It was making workflow behavior inspectable.

I use ChatGPT and Figma Make, which is Claude behind the scenes.
BYO design review, 2025-11-06

So I had ChatGPT create a state model in JSON.
BYO design review, 2025-11-06

That state model is basically telling Figma Make that there are different states to this and to trigger different things at different times.
BYO design review, 2025-11-06

Review Had to Move Beyond One-on-One Feedback

What I changed

Started with SA and customer-facing walkthroughs before solutioning
Used prototypes so stakeholders reacted to behavior, not abstract opinions
Widened critique from narrow reviews into broader team share-outs
Asked for feedback from the people who would have to explain the workflow

Why it mattered

Reduced vague preference debate
Exposed edge cases earlier
Helped the triad own the interaction model together
Made handoff easier for engineering and customer-facing teams

Final Model: Source to Code to Destination

What the user could understand

Where code lives in the flow
Which file or folder context the code uses
What happened when the test ran
What to do after success or failure

What the team could implement

Clearer state and CTA rules
Better separation between authoring and source setup
Reusable patterns for future code-heavy surfaces
A smaller v1 contract with room to evolve

Testing and Troubleshooting Moved Closer to Code

The design reduced the distance between action, feedback, and recovery.

You cannot just select it from here and test it right away. You need to put a file path here, which needs to be hard-coded.
Customer/SA walkthrough, 2025-10-21

Where do I go? Like from here, where do I go? I don't know.
Customer/SA walkthrough, 2025-10-21

If we had a badge here, like a circle saying, Hey, come over here, there's something wrong here.
Customer/SA walkthrough, 2025-10-21

What Changed, What I Would Measure

The sourced outcome is a clearer workflow contract; the launch metrics stay framed as measurement targets.

What improved directionally

The team had a stronger product contract:

Code was easier to locate in the flow
Testing was closer to file context
Status and recovery had clearer design requirements

What I would measure

The launch plan should test independence:

Time to first successful test
Support-free BYO creation rate
Actionable error visibility

What I learned

The most important craft decision was upstream:

Name the workflow object first
Prototype behavior before debating polish
Instrument customer confidence earlier

Measurement frame: self-serve creation, first successful test, actionable error visibility, and SA escalation rate

The System I Inherited

The leadership case starts with what I inherited: product debt, trust debt, and no clear path for design growth.

What I inherited

The team was not only missing a ladder:

Low trust across EPD
Disorderly designer-to-developer handoff
Research insights were largely dismissed
No career pathing for design roles

What I scoped

The work had to change how quality happened:

Create clearer growth expectations
Make systems work part of daily delivery
Rebuild rituals around evidence and iteration

Why this is in the main path

This is the people-leadership proof:

Team judgment improved through structure
Craft improved through operating conditions
Business pressure stayed visible

Adoption Was the Pressure

Customer signal

The product was not team-focused enough in research and prototype feedback
Onboarding confused first-time users and made the value harder to understand
The product looked outdated against newer competitors

Business signal

Retention was helped by switching cost, but adoption and activation needed attention
Activation and conversion were declining when I joined
The team needed smaller wins that could rebuild confidence while larger quality work continued

Design System as Workflow Infrastructure

Strategic choice

Do not wait for a full rewrite to improve the product
Use the design system to make cleaner UI and handoff repeatable
Create a UX-platform mindset so feature teams could stay focused on core product work

Operating choice

Hire and support a Design System Lead
Make component work visible in daily product delivery
Use end-to-end wins, like icons and onboarding surfaces, to prove the system could ship

Build Judgment Through Structure

The team needed better conditions for judgment, not just stronger taste from leadership.

Career journey maps made expectations visible across design disciplines
Specialized Design System Lead and Growth Design Lead roles created clearer ownership
Cross-functional design reviews gave PM, design, and engineering a shared critique surface
Iteration kickoffs helped designers name the problem before locking the solution
Experimentation rituals connected product choices to activation and conversion signals

Outcomes: Activation, Specialization, and Trust

The operating reset showed up in product and team outcomes.

Problem

The team had good people but weak operating structure:

Research was not shaping priorities early enough
Design-system work was not part of daily delivery
Onboarding confused users and hurt activation

Solution

I connected people systems to product systems:

Clearer growth paths and expectations
Specialized ownership for systems and growth
Rituals for critique, iteration, and experimentation

Outcome

The work became easier to align and measure:

Activation improved in a sourced A/B test
Systems practice became visible and practical
The team had more confidence moving from insight to shipment

What Changed in the Team

Designer judgment

Clearer expectations for what good looked like at each level
More structured critique around problem framing and tradeoffs
More confidence sharing unfinished work before it became expensive to change

Cross-functional trust

PM and engineering had clearer entry points into design decisions
Research and experimentation were easier to connect to roadmap choices
Design-system work became a delivery mechanism rather than a side project

What I Would Do Earlier

I would make the evidence and operating model visible sooner, especially for leaders outside design.

Translate research into decision rules earlier so insights are harder to dismiss
Make the activation measurement plan part of critique, not a separate growth conversation
Name the few team rituals that matter most instead of trying to fix every process at once
Use design-system wins to prove delivery value before asking for broader organizational change

What I Would Bring to Clio

Design management is the work of making customer evidence, product quality, team judgment, and business outcomes reinforce each other.

For International work: I know how to separate core product coherence from local workflow differences without fragmenting the experience
For AI-era legal work: I think trust comes from context, feedback, source grounding, and clear next action, not from automation alone
For triads: I build the rituals that help PM, design, and engineering reason from the same evidence
For designers: I coach judgment in the work so craft, strategy, and confidence develop together

Supporting Proof: Schema Template Designer

A compact scope-judgment case for Q&A.

Problem

The same preview issue kept coming back:

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

Solution

I narrowed the work to the minimum useful contract:

Shape, validations, and meaning
Unmapped-first apply defaults
Read-only preview users could trust

Outcome

This is the support case for scope judgment:

Customer pain tied to implementation cost
A smaller workflow engineering could code
A clearer measurement frame for launch

Source Map

Where the main claims come from.

Clio prep guide: timing and interview format
Transcript refresh: role context, triad/craft expectations, quick experimentation, AI adaptation, and legal workflow/domain notes
BYO transcripts: customer pain, self-serve goal, state-model prototype, and review behavior
Shortcut context deck: inherited org problems, operating reset, specialized roles, and 110% activation result
Schema transcripts: preview pressure, scope discipline, and buildability tradeoffs

Compressed 12-14 Minute Path

If the panel pivots early, keep the proof sequence intact.

Two-minute intro: complex workflows, shared judgment, Clio fit
Five-minute BYO: self-serve pressure, customer evidence, decision spine, AI state prototype, measurement frame
Four-minute Shortcut: inherited trust gap, operating reset, activation proof
One-minute close: what I would bring to Clio and where to go in Q&A

Likely Q&A Threads

The deck is built to support deeper discussion.

Interaction craft: state, next action, file preview, and testing patterns in BYO
Leadership: how rituals, ladders, and design systems build designer judgment
Business: where the metrics are sourced versus framed for future measurement
Modern tools: how AI-assisted prototyping helps without replacing design judgment
Clio fit: International workflows, legal-domain trust, quick experimentation, and triad health