Senior Product Design Leader

Snapshot

The portfolio focuses on products where connector setup, schema import, file testing, and credential retry can fail in expensive ways. The work usually starts the same way: map the real path, name the risky transition, and make the product or team artifact explicit enough for other people to use.

The cases cover data pipelines, generated setup, career ladders, calibration, and agent workflow systems. Unclear product status often points to unclear team expectations behind it: fuzzy ownership, uneven review, or choices that are hard to repeat. The strongest work tightened both the user-facing surface and the way the team shipped it.

Leadership Narrative

Platform Work Across Companies

Most of my design work has happened inside platform products: Pivotal Cloud Foundry, GitLab, Shortcut, and Nexla. The domains changed, but the job kept returning to the same pattern: clarify how the system behaves, reduce avoidable handoffs, and leave the team with decisions it can repeat.

My strongest work is where the product has operational stakes: data moving, permissions changing, generated steps, or teams trying to ship the same standard across many surfaces. Better UX in those products usually means better handoff, better review, and fewer unresolved delivery decisions.

Nexla: Workflows Where Trust Matters

At Nexla, I joined as the first full-time designer and partnered directly with the CEO and product leadership. The 50+ surfaces covered connector setup, schema work, flow creation, dashboards, reporting, Express.dev, and shared platform patterns. Interface polish would not solve the core challenge. The work was turning connector-heavy paths into something users could review, recover from, and build on when the system hit real-world complexity.

The Nexla work included a new 0->1 product, improvements to the core platform, and repeated decisions about how much automation to introduce without hiding the state users needed to see. The useful outcome was a more disciplined rule for AI in the product: automate where it helps users move faster, but keep review, data movement, and recovery visible.

After

Before

AI Inside the Workflow (Not a Side Chatbot)

The AI pattern that holds up best is assistance embedded in the workflow itself. The system can propose a mapping, transform, or next action, but the user still needs to understand what changed, preview the effect, and intervene before anything irreversible happens. The useful loop is propose -> preview -> apply, with guardrails and review points built into the product instead of pushed to the margins.

The distinction matters in enterprise and system-of-record contexts. When mistakes carry real cost, "helpful" is not enough. Users need to see permissions, reversibility, logs, and where data will move, and teams need patterns consistent enough to ship that behavior more than once.

Shared Platform Standards Across Two Products

As the product footprint expanded, the design problem expanded with it. The practical design work was to define the tokens, components, and workflow patterns that let the core platform and Express.dev reuse the same connector, schema, review-state, and execution feedback language. The standards then moved through prototypes, implementation reviews, PR feedback, and shipped changes with product and engineering.

The operating rhythm was part of the design work. Standards only mattered if they survived design review, code, PR feedback, and production iteration.

Where This Work Fits

The portfolio is built around products where mistakes are expensive: data movement, automation, generated steps, permissions, and review. Advanced capability only helps when users can see what changed, what will happen next, and where they can intervene.

The case selection focuses on workflows instead of isolated screens. The work is to make difficult actions easier to inspect, turn strong product decisions into buildable artifacts, and keep AI assistance inside behavior users and teams can review.

Case Map

The core product walkthroughs are Custom Code Flows and Schema Template Designer. Custom Code Flows shows how a fragile internal-tool pattern became a source -> code -> destination workflow with visible testing, logs, and handoff behavior. Schema Template Designer shows how dense schema work became a reusable contract model before the UI could feel reliable.

The rest of the page moves from core Nexla workflow work into AI interaction guardrails, Design Org Foundations, shipped platform briefs, and repo-backed agent workflow tools. The cases do not all carry the same weight; they show the same kind of judgment at different scales.

Fast Read

Fewer Steps, More Clarity

Problem (why leadership cared)

Custom code was powerful but behaved like an internal tool:

• Testing was slow/painful
• Errors + state were opaque
• Key actions were buried or required copy/paste
• UI patterns were inconsistent across the product

Solution (approved for v1 handoff)

A guided, IDE-like authoring model:

• Full-screen code editor + console
• Flow template on canvas (Source -> Code -> Destination)
• Explicit file selection + preview/download
• Simplified "write new vs library" without disruptive modality

Before / after path

Summary

Setup: Who the Custom-Code Workflow Serves

Primary Users

• Data engineers
• Platform engineers
• Solution architects

Typical jobs-to-be-done

• Normalize messy vendor files (PDF/CSV/JSON)
• Validate, enrich, or reroute records
• Debug issues quickly without needing support

Problem

Persistent Workflow Friction in Real Feedback

"Much of it is user experience... the same things that people have complained now for over two years on usability."

Internal review (Nov 2025)

"The flow to do that is really counterintuitive... you need to put a file path... hard-coded... then copy/paste."

Internal review (Oct 2025)

"The test here is slow and painful... you can't debug... error message is not easy."

Internal review (Oct 2025)

Design questions we had to answer

1. What is the minimal "developer-grade" workspace?
2. How do we make next steps obvious on the flow canvas?
3. Where does code live: in source config or as a first-class node?
4. How do we support both "write new" and "reuse from library" without confusing mode switches?

Context

First Attempt: Why the Drawer Model Failed

Why a right-side drawer initially made sense

• Fast to implement using existing panel pattern
• Reduced risk while backend behavior was still shifting
• Kept canvas visible (in theory)

What we learned quickly

• Too little space for real code
• Documentation and controls competed for real estate
• The drawer encouraged a brittle, modal workflow

Custom Code v1 Reality Check Before Redesign

Custom Code v1 Reality Check Before Redesign

1. Folder-first setup started in a dense multi-step shell.
2. Filters, processing, and scheduling competed in one long configuration surface.
3. Turning on custom processing introduced an immediate mode branch.
4. Testing UI appeared before file-path context was concrete.
5. Output panes consumed space while primary guidance remained thin.
6. Reusable processor selection interrupted flow with a full-screen modal.

Approach

State Model Before Screen Detail

The state model moved the work out of screen-by-screen debate and into behavior the team could review. Before committing to detailed UI, I named the valid lifecycle states, transitions, and impossible combinations so CTAs, warnings, test results, and handoff behavior could stay consistent.

The model became useful in senior reviews because it translated a messy workflow into something engineering could implement and product could reason about. It also made the prototype more useful: stakeholders reacted to proposed behavior rather than layout alone.

Key Workflow Decisions

Drawer vs workspace

• Direction: promote custom code to a full workspace.
• Rejected alternative: preserve the lower-effort drawer pattern.
• Decision risk: spend more UI surface on the primary developer job without bloating v1.
• Artifact result: editor, console, output, logs, and runtime settings stayed in one place.

Source config vs processor node

• Direction: represent custom code as a first-class processor in the source -> code -> destination flow.
• Rejected alternative: keep code hidden inside source configuration.
• Decision risk: make the workflow model visible without creating a new mental model for every connector.
• Artifact result: the canvas explained where code lived and what came next.

Write-new vs library

• Direction: make the choice explicit, then keep one stable editing model.
• Rejected alternative: let library selection reset the user's workflow.
• Decision risk: support reuse without introducing disruptive modality.
• Artifact result: the v1 flow kept one editing surface with predictable CTAs.

Local debug vs in-product debug

• Direction: support in-product file testing now; define local runtime harness as the advanced path.
• Rejected alternative: treat browser breakpoints and local runtime parity as solved in v1.
• Decision risk: improve validation without overpromising developer tooling.
• Artifact result: the handoff separated shippable v1 behavior from later advanced debugging.

Turning Point #1: Promote Custom Code to a Full Workspace

Turning Point #1: Promote Custom Code to a Full Workspace

Workspace changes

• Promote code to a primary task
• Keep console/results persistently visible
• Reserve right rail for "contract + runtime config"

Why the workspace mattered

• Less scrolling
• Fewer hidden controls
• Better parity with real developer workflows

Discovery and Evidence

Turning Point #2: Template-First Flow Guidance

Early setup dropped users into too many abstract choices at once: source setup, code placement, output, and destination rules all competed for attention. Pre-seeding the source, code processor, and destination gave users an immediate route to the first file test instead of asking them to assemble the canvas from memory.

• Source, code processor, and destination start in view.
• File selection and the first test stay connected to the canvas.
• The template shows what comes next before configuration gets deep.

Solution

Turning Point #3: Stable Write New vs Library Mode

"We have multiple patterns in the UI in how we handle the custom code... we need a consistent pattern."

Internal review (Nov 2025)

"When I go to provide your own function, we have some code already... Half the screen is documentation... confusing."

Internal review (Nov 2025)

Design move

Make the choice explicit upfront, then keep users in a single, stable editing mode.

• "Write new" generates stub + contract
• "Select from library" previews code before insert
• Avoid disruptive state resets

Implementation detail that mattered

A state machine defined valid transitions so we could:

• Prevent impossible states
• Show consistent CTAs
• Reduce edge-case warnings

Implementation

Make Iteration Fast: File Access + Runtime Feedback

File access (in-product)

• Select a file from the chosen folder (no path copying)
• Preview or download the original file
• Keep folder context visible while coding

Local debug (out-of-product)

• Provide a Docker-based harness that mimics the custom-code runtime
• Clear guidance on contracts for local vs cloud
• Long-term: CLI deploy from IDE (future)

"You cannot just select it from here and test it right away… copy this path… paste."

Internal review (Oct 2025)

"The only caveat is… we need a public-facing repository with the Docker image…"

Design review (Nov 2025)

"Telling them to bring the code in our UI and just run it… is always going to be painful. Debugging breakpoints will be hard."

Internal review (Nov 2025)

Results

Approved V1 Handoff

Approved handoff: the team approved a v1 design package for implementation: source -> code -> destination became the shared model, the design specified a primary path intended to remove file-path copy/paste, and the proposed test loop kept source file, editor, output, logs, and runtime settings in one place.

Reviews shifted from isolated screen preference to the behavior model: where code lives, how testing works, which state is valid, and when the user can continue.

Validation plan: after implementation, compare old setup steps against the new scaffolded path, track successful cloud-test completion, watch for continued path-copy workarounds, and review whether users could recover from test errors without leaving the workspace.

Reflections

Collaboration and Scope Discipline Made v1 Shippable

How we drove clarity

• Used interactive prototypes to get fast, specific feedback
• Kept a v1 scope line (basic workflow first)
• Clarified "v1 vs later" with Head of AI + Customer Success engineering

Fast Read

From Ambiguous Templates to Shippable Contracts

Fast read

Schema templates were capturing field names, but not enough meaning, validation logic, or import behavior to work as reusable data contracts.

• Design change: Reframed templates around shape, validations, annotations, and an unmapped-first apply workflow.
• Implementation handoff: Product and engineering could review one create -> preview -> apply flow instead of reconciling template, JSON, and mapping behaviors separately.
• Validation target: Measure time to valid output, select-to-import conversion, post-import edits, and support signals after launch.

Summary

Context & Users

When we joined this problem, "schema templates" already existed, but they were not yet functioning like reusable contracts. Teams could capture field structure, but they still had to rely on documentation and tribal knowledge to understand meaning, validations, and what would actually happen when a template was applied.

We reframed the work around a simpler promise: a template should help a team move from create to preview to apply without ambiguity. The reframing turned the feature from a loose collection of authoring and mapping ideas into one workflow product and engineering could align on, build, and measure.

After

Before

Problem

The UX debt

Most of the UX debt came from ambiguity, not missing capability. Mapped and unmapped fields were mixed together, calls to action changed meaning depending on context, and authoring still behaved like a sample-driven setup instead of a reusable contract definition tool. On the implementation side, the underlying system was already persisting separate JSON structures, which made it easy for technical complexity to leak into the user experience.

As one Eng/PM partner put it, "There's three separate JSON blobs I'm saving." The result was predictable: operators had to interpret too much before they could trust an import, and contract owners had no clear model for defining rules at scale. The feature existed, but the workflow did not.

Ambiguity cost

Context

Shape, Validations, and Annotations Diagram

The schema template work sat inside the dataset workflow, where two different users had to rely on the same system under deadline pressure. Operators needed a fast, low-risk path to close unmapped gaps. Contract owners needed to define structure, validations, and field meaning in a form that could survive repeated reuse.

As a product lead put it, "We were trying to add garnish... when we were missing a whole side." The scope constraint shaped the mental model. A template had to carry field structure, rules, and meaning together, and the work could not split into separate products for authors and consumers. Shape, validations, annotations, preview, and apply behavior had to work as one system across two linked workflows.

The working diagram became: shape defines the expected fields, validations define what good data must satisfy, annotations explain meaning, preview shows the combined contract, and apply state makes the operator's next change explicit before import.

Approach

Key Contract Decisions

Unmapped-first vs all fields

• Chosen v1 direction: default the apply workflow to unmapped gaps.
• Scale path: let users expand to all fields when they need full review.
• Evidence: unmapped fields carried the highest immediate risk and best matched the operator's job.
• Artifact result: the apply flow started where review mattered most.

Inline rules vs tabs

• Chosen v1 direction: show essential validation rules inline for v1.
• Scale path: move dense rule sets into tabs when rule volume grows.
• Evidence: decision confidence mattered more than scale polish in the first build.
• Artifact result: rules taught the workflow instead of disappearing into documentation.

Guided controls vs JSON

• Chosen v1 direction: support guided controls and JSON as two inputs to the same contract.
• Scale path: keep JSON-only authoring for advanced users if guided controls fell behind.
• Evidence: contract owners needed power without forcing operators to reason in raw JSON.
• Artifact result: guided UI and JSON fed the same shape, validation, annotation, preview, and apply model.

Preview vs editable output

• Chosen v1 direction: make preview a trusted mirror, not another editing surface.
• Scale path: add deeper preview controls later if adoption showed the need.
• Evidence: the system needed one source of truth for shape, validations, annotations, preview, and apply state.
• Artifact result: users could review output without creating a second editing path.

Solution 1: apply templates in the dataset workflow

We narrowed v1 around three decisions. First, applying a template should start with unmapped gaps, because that is where the operator's risk and attention live. Second, selection and import states needed to be explicit, so users always knew what was about to happen. Third, rules had to appear close enough to the workflow to teach, not disappear into documentation.

The unmapped-first approach kept the work grounded in real tasks instead of trying to solve every future scale concern in v1.

Discovery and Evidence

Solution 2: validations at scale

The major tradeoff in reviews was how much validation detail to show inline. An inline model made scanning and one-click import faster, which mattered in the mapping flow. A tabbed model would scale better as rule density increased, but it also risked pushing essential context out of sight too early.

I selected the inline model for v1 handoff because the immediate problem was decision confidence, with information overload deferred to the scale path. The fallback was deliberate: if teams later outgrew inline presentation, tabs were a scale strategy, not a prerequisite for shipping.

Solution

Solution 3: author templates

The final interaction model treated authoring as three inputs feeding one trusted preview. Shape came from sample data or pasted JSON. Validations could be defined through guided controls or JSON. Annotations captured field meaning so downstream users could understand intent and structure.

On the apply side, the workflow kept operators focused on unmapped fields first, made bulk selection predictable, and clarified import states before changes landed. Together, those moves made the template behave like a reusable contract instead of an ambiguous helper.

Implementation

The implementation spec turned the model into behavior engineering could build: default to unmapped fields, define select-to-import transitions, specify which authoring inputs fed the preview, and call out the edge cases where guided UI and JSON had to land on the same contract. The point was to remove decisions from the handoff, not make a prettier Figma path.

The v1 spec also named what we were not solving yet: dense validation navigation, governance signals, and heavier rule management. Those became follow-on paths after the core create -> preview -> apply loop existed.

Results

Delivered Workflow + Validation Plan

Delivered: one buildable authoring and apply workflow

The delivered artifact defined shape, validations, annotations, preview, and unmapped-first apply behavior in one reviewable workflow. Product and engineering could evaluate the same behavior without reconciling scattered docs, JSON behavior, and mapping screens separately.

Measurement plan: validate behavior after launch

The measurement plan focused on time to valid output, select-to-import conversion, post-import edits, and support signals. The metrics matter because they reflect the underlying goal of the redesign: fewer ambiguous handoffs and fewer mapping incidents caused by unclear apply behavior.

Reflections

Learnings & next steps

The case reinforced a familiar enterprise UX lesson: when a feature is confusing, adding more places to configure it often makes the problem worse. Progress came from narrowing the promise: define the contract, preview the effect, and apply it to unmapped fields.

Taking this further, the next step would be usability testing with operators using real templates, followed by governance and denser validation management. But the core handoff should stay the same: create -> preview -> apply.

Fast Read

• What changed: Built shared career ladders across product design, brand, and research, then turned them into manager-ready coaching and calibration language.
• Why it mattered: The team had strong people, but no consistent way to define growth, calibrate expectations, or resolve handoff ambiguity and decision-rights confusion.
• Leadership move: Created one common language for scope, craft, and leadership, then tested it in manager conversations, peer review, and critique.
• Outcome: Designers had clearer growth paths, managers had a more reliable coaching tool, and product/design leaders had a less personal way to discuss ownership.

Evidence snapshot:

Summary

The work started during a period of growth when design needed clearer management structure while product, brand, and research work kept shipping. The immediate challenge was to create clear career paths across disciplines, reduce calibration inconsistency, and make product/design decision rights easier to discuss before they turned into delivery problems.

We built a shared ladder and performance system so expectations were explicit, comparable across disciplines, and usable in coaching and calibration. The useful outcome was the manager language: one-on-ones, promotion conversations, and product/design planning relied less on local rules in each conversation.

Problem

The organization had talented designers, but it did not yet have a shared way to talk about level, growth, or cross-disciplinary expectations. Managers were being asked to evaluate scope, craft, and leadership without a common language, which made calibration inconsistent and made advancement harder to explain or defend.

The ambiguity affected more than performance cycles. Unclear expectations showed up as handoff ambiguity, uneven critique patterns, unclear ownership, and decision-rights confusion across product/design work.

Context

The team was already shipping work across product, brand, and research, so the answer could not be a long internal strategy exercise detached from delivery. Any new performance system had to work while the organization was still moving, and it had to support both managers trying to coach well and designers trying to understand what growth actually looked like.

The delivery context created the central constraint for the work: move quickly enough to help the team now, but build something durable enough to support future hiring, compensation, and promotion conversations.

Approach

We started by defining a shared set of principles for how the organization should talk about scope, craft, and leadership, then translated those into discipline-specific expectations for product design, brand, and research. The test was whether managers could use the language immediately in one-on-ones, feedback, calibration, and promotion readiness without translating it differently person by person.

We pressure-tested the language with peer leaders and coaching networks to catch title inflation, discipline-specific silos, and wording that sounded polished but failed in real coaching. Peer review kept the ladder practical and made manager adoption more likely once it moved into use.

Discovery and Evidence

Reviewing manager notes, feedback patterns, and recurring confusion in growth conversations made the root issue clear: similar impact was being described differently depending on whether the work came from product design, brand, or research. Inconsistent descriptions made fair calibration harder. Critique notes showed a related pattern: strong artifact feedback often became a one-off correction instead of reusable guidance.

Cross-functional conversations exposed handoff ambiguity and decision-rights confusion. Product/design partners were often negotiating scope locally: who owned the product story, what quality bar applied before engineering handoff, and how critique decisions carried into delivery. The product artifacts in this case show those behaviors in context: unclear onboarding intent, cluttered app patterns, and a product story that needed clearer shared ownership.

Product friction showed where alignment broke down

Product friction showed where alignment broke down

Product Artifacts

The 2.0 prototype and brand critique sit inside that evidence set as supporting artifacts. The prototype showed we could simplify the interface, and critique exposed the missing reusable brand and system layer. Together, they gave managers and designers a concrete example for discussing critique follow-through, handoff quality, and repeatable standards.

Solution

The final package had three pieces: ladders tailored to each discipline, a shared competency spine, and performance language that translated expectations into coaching. We mapped scope, collaboration, and leadership behavior so managers could compare impact across product design, brand, and research without each group inventing its own standard.

Then we put the language into a regular coaching rhythm. The ladders became a working tool for feedback and development plans, and gave product/design leaders a less personal way to talk about handoff ownership and decision boundaries.

Key Operating Decisions:

Ladder Excerpt

Operating Rhythm

• Critique: name scope, craft, and decision quality using the same expectations.
• Calibration: managers could compare scope, craft, collaboration, and leadership consistently across product design, brand, and research.
• Planning: settle product/design decision rights before work hardened into handoff problems.
• Manager 1:1s: turn the ladder into development plans, feedback, and promotion readiness conversations.

What I Authored and What the Team Adopted

Career ladder

• I drafted the structure, level language, and cross-discipline expectations.
• Team execution: managers and designers tested language in real conversations.
• Leadership approval: approved as the shared growth standard.

Performance and calibration

• I translated expectations into coaching and calibration language.
• Team execution: managers used it in 1:1s, feedback, and performance discussions.
• Leadership approval: aligned it to org expectations and decision-making.

Decision rights and handoff

• I named scope, ownership, and decision-boundary patterns.
• Team execution: product and design teams applied the language in planning and critique.
• Leadership approval: used it to make partnership expectations more explicit.

Implementation

We rolled the performance system out iteratively rather than treating it like a top-down announcement. Early drafts went through managers and designers first, because the test was whether the language held up in real conversations, not whether it looked complete in a presentation.

Within about the first month, we had qualitative manager adoption: a usable version was already supporting live coaching and calibration. From there, the work shifted from definition to adoption: tightening unclear wording, using the language in performance discussions, and reinforcing the same decision-rights expectations in cross-functional planning.

How Adoption Started

Redacted manager cadence:

• 1:1s: name one ladder signal, one recent example, and one next behavior to practice.
• Calibration: compare scope, craft, collaboration, and leadership with the same terms across product design, brand, and research.
• Planning and critique: use the collaboration row to settle owner, reviewer, and handoff expectations before work hardened.

Results

The organization came away with a more credible growth system across product design, brand, and research. Designers had clearer visibility into what advancement required, and managers had a more consistent tool for coaching, calibration, and promotion readiness.

Outcomes

The same language gave product and design leaders a clearer way to discuss handoff ownership, critique follow-through, and decision boundaries, so later planning conversations depended less on personal interpretation.

Reflections

Org-design work needs the same discipline as product work, but the test is behavior change. The ladder mattered only if managers used it when the stakes were real. We rolled it out while work was still moving, tested the language in live conversations, and traded theoretical completeness for something people could use that month.

If the work were revisited, the first change would be adding adoption measurement earlier. Future revisions should have direct evidence from ladder use, not only manager anecdotes. The core decision would not change: start with clarity people can use now, then scale the system once the language is working in real conversations.

Fast Read

• What changed: Designed a prompt-first flow authoring experience where an agent could accelerate setup without hiding the underlying workflow.
• Why it mattered: Generated UI was only useful if users could understand what the system was doing, trust the next step, and recover cleanly when automation failed.
• Key design move: Made each generated step show its state, safe retry path, and manual canvas handoff before asking the user to keep going.
• Outcome: The team had an implementation-ready design baseline for future generated forms, quick actions, and canvas handoffs.

Concrete sequence

prompt -> generated component -> credential failure -> retry / handoff -> manual canvas edit

The case is strongest when it stays in that sequence. The agent can generate a useful component, but the product still has to explain when credentials fail, what retry is safe, when the guided path can no longer explain the next step, and how control returns to the canvas without forcing the user to restart.

Summary

The case focuses on how generated UI should behave when real connector setup gets uncertain. The goal was to make prompt-first setup useful while preserving the visibility and control technical users needed when credentials, connectors, or generated steps became unreliable.

We defined how generated forms, quick actions, and credential prompts should behave so users could understand what the system was asking, why it was asking it, and when to stay in the guided path versus move to the canvas for manual control.

Dark mode

Light mode

Problem

Prompt-first authoring lowered the barrier to getting started, but it also created a new trust problem. When credentials failed, generated steps stalled, or connector behavior was inconsistent, users had too little context to tell the difference between a recoverable issue and a broken path.

The missing context made the product feel asymmetrical: fast when the happy path held, but opaque when reality intruded. For a workflow product, the failure mode was serious. Users needed a reliable way to understand state, make the next decision, and recover without starting over.

Context

The experience was powered by an XML DSL that let the agent generate interface components on the fly. The XML flexibility was powerful, but it also meant the product needed a stronger interaction model than a traditional handcrafted flow. Without clear constraints, generated forms and actions could vary in ways that felt unpredictable or hard to trust.

The design challenge was to support two legitimate user needs at once: a guided path for people who wanted to move quickly through prompts, and a reliable escape hatch for people who needed the precision of direct canvas editing.

Approach

I defined the work as a recovery problem. The agent could only be useful if the product constrained what it could ask for, clarified the role of each generated component, and defined what happened when the guided path could no longer explain a safe next move.

The review process checked each generated step against a practical list: what state is visible, what action is safe, what retry path exists, and when should control move back to the canvas?

Key Interaction Decisions

Four Moments to Make Visible

Discovery and Evidence

In reviews, generated steps landed best when they were inspectable: a credential choice with a clear consequence, a quick action with an obvious next state, or a canvas handoff users could recognize. Trust dropped when credentials were invalid, actions appeared complete before backend sync finished, or a connector returned a state the UI could not explain.

A bad suggestion was only part of the issue. The product was too quiet at the exact moments users needed orientation. Was this retryable? Was it safe to continue? Should they move to the canvas and take over manually?

Solution

The design kept prompt-first setup, but made each generated component answer a practical question: what is being asked, what changed, and what can the user do next? Forms and quick actions stayed in the guided path, while the canvas remained the place for direct editing when the generated path could not explain a safe retry or next step.

Manual editing became a normal branch of the flow, not a failure state. Treating manual editing as expected flow let the assistant speed up setup without asking technical users to keep trusting it after credentials, connectors, or generated steps got messy.

Implementation

We partnered closely with engineering around the reliability moments most likely to shape user trust: credential selection, recoverable failure states, and completion signals that stayed honest when the backend still had unresolved work. The engineering goal was to make the assisted path dependable under real connector constraints.

Dependability required discipline in both product language and interaction behavior. We prioritized the states the team could defend, clarified the points where user control resumed, and avoided design decisions that would make the system feel more capable than it really was.

Results

Status: implementation-ready setup behavior that made assistant state visible, showed where control resumed, and explained how to proceed when the guided path stopped being the best option.

Outcomes

The work gave the team reusable interaction rules for future generated forms and quick actions: every assisted step needed a visible state, a clear handoff, and a recoverable next move.

Validation plan: track guided setup completion, credential recovery, retry completion, and manual canvas handoff without restart.

Reflections

Users trust AI-assisted setup more when the boundaries are visible. They can accept automation when they can see state, understand whether retry is safe, and know exactly how control returns to them.

The same principle carries into products that add generated steps to real workflows: each suggestion has to be easy to inspect, correct, and recover from before another automated layer helps.

Snapshot

JudgmentKit MCP started from a specific failure mode in generated interface work: agents can produce polished screens before they understand the activity those screens are supposed to support.

JudgmentKit adds a review step before generation: the agent names the user's job, translates it into actions and support cues, decides what should stay hidden, and defines the build handoff before drawing the UI.

The evidence is the committed comparison and replayable review chain: a recurring agent failure mode becomes a reusable check before UI generation.

Paired artifact evidence

The repo includes deterministic demos and paired artifacts, keeping evidence tied to visible output instead of a better-sounding explanation. The refund triage pair shows the core shift: the raw screen follows backend controls, while the guided screen follows the review activity.

Raw

Guided

Replayable repair path

original prompt -> raw UI -> JudgmentKit review -> generation handoff -> repaired UI -> review score

Abridged Review Contract

Context

Generated UI work often breaks when the backend model becomes the user experience. Tables become screens, schemas become forms, prompt templates become product vocabulary, and tool results become buttons.

JudgmentKit sits before UI generation hardens backend language into the product surface. The MCP layer gives Codex, Claude, and other clients a shared way to review the work first, without making any single frontend stack or design system the center of the product.

Problem

• Raw generation prompts were too easy to follow literally, even when they leaked database fields, JSON schema terms, resource IDs, or tool-call state into the primary UI.
• Visual polish could hide that the screen was supporting the wrong activity or asking the user to reason in backend terms.
• Teams needed a portable guardrail before the wrong interface had already hardened.

Build

What the review asks first

• Describe the user's work first: participants, objective, outcomes, artifacts, rules, and division of labor.
• Translate that work into user actions, decision support, meaningful states, and completion criteria.
• Decide what becomes user-facing, what gets translated into domain language, and what stays diagnostic.

Checks before UI generation

• MCP tools create activity reviews, surface recommendations, workflow reviews, build contracts, and frontend handoffs.
• The same guardrails apply whether the next step is deterministic, model-assisted, or handled by a separate agent.
• Review terms stay out of the primary product UI; they remain available for setup, debugging, auditing, and integration work.

What Shipped

• JudgmentKit gives agents a better order of operations: understand the activity, review the workflow, define the handoff, then generate the UI.
• The hidden-detail rules reduce backend leakage instead of relying on the final prompt to remember what not to show.
• The visible evidence is the raw/guided comparison, where the same brief shifts from CRUD controls and schema language to case review, evidence, policy context, and a handoff decision.

Website: judgmentkit.ai

Fast Read

One Dashboard Mode

The redesign centered the overview dashboard on a page-level org/personal mode, clearer section order, and jump navigation for summary, read, write, and resource sections.

• Original friction: The old page repeated context decisions inside modules, used a lot of space, and still did not explain how the dashboard worked.
• Shipped changes: Page-level mode, section navigation, CSV actions, and explicit chart-scope boundaries.
• Scope boundary: Chart redesign and deeper reporting behavior stayed out of this pass; placeholder regions and CSV paths made that boundary visible.

Scope evidence

Summary

I led the redesign around one decision users were already making repeatedly: whether they were reviewing org-level work or personal work. The old page answered that question inside individual modules. The redesign moved the choice to the top of the page, cleaned up the section order, added jump navigation, and kept chart placeholders scoped to the reporting behavior covered by the release.

Problem

The original dashboard asked users to re-interpret context in every module. Separate org and personal toggles appeared across sections, there was no clear page-level mode, and the layout consumed a large amount of space without delivering corresponding clarity. Review feedback made the issue plain: people could read the cards, but the structure of the page did not explain itself.

Previous overview page: local toggles and section-by-section controls made the page model feel fragmented instead of establishing one clear context up front.

Context

The team needed a redesign that could ship on top of the existing overview framework while leaving room for the dashboard to grow. The redesign had to make the current page easier to understand immediately while introducing navigation and structure that would still work once more overview sections and reporting surfaces were added.

Approach

We treated the page as an information architecture problem. One mode switch should set context for the whole dashboard. Sections should inherit that context instead of asking the user to re-decide it. The jump menu came from the same logic: if the overview was going to grow, users needed a way to move to a real section instead of scrolling through a long stack of cards.

Discovery and Evidence

A recording-backed product walkthrough surfaced three problems: there was no global mode switch, the page used a lot of space without adding much information, and every section taught the same context rule again. The walkthrough also clarified the scope line. Charts were not ready for deeper redesign, so the useful work was structure, navigation, and practical actions like CSV export.

Solution

The shipped dashboard sets org versus personal mode once, at the top of the page, then lets the modules inherit that choice. The jump-to control gives users a direct route to summary, read, write, and resource sections. Where reporting depth was outside the release scope, chart placeholder regions stayed visible and CSV export paths covered practical data extraction.

Scalable navigation: the Jump to Section menu makes future dashboard growth legible without falling back to repeated local controls.

Implementation

Design and engineering aligned around a narrow set of implementation decisions: centralize the page mode switch, improve wayfinding, preserve chart placeholder regions where redesign work had not happened, and add CSV downloads where operators would benefit from extracting data. The narrow scope kept the redesign useful and shippable while leaving chart and reporting follow-up visible.

Concrete destination: the Resource Count section shows how the new navigation model lands users in a specific part of the overview instead of leaving the page as one long undifferentiated stack.

Results

Delivered: the page-level mode, section navigation, CSV paths, and explicit chart scope shipped as a platform iteration.

After the redesign, the page read more like one dashboard instead of a collection of unrelated modules. Users could set context once, move through sections with a predictable menu, and export useful data without waiting for a larger analytics rewrite.

Validation plan: review whether users understand the global mode, whether the jump menu gets them to the right section, whether CSV actions are useful, and what chart behavior needs a deeper analytics pass.

Shipped Scope

• Replaced repeated section-level switches with one page-level mode
• Added jump navigation for summary, read, write, and resource sections
• Kept chart redesign out of scope while adding practical CSV export paths

Reflections

The useful decision was sequencing dashboard structure before chart redesign. The page needed a better mode model and section order first. Once those were clear, the team could ship a better overview while tracking deeper chart and reporting behavior as follow-up work.

Fast Read

Task First, Flow Type Later

The change was a sequencing cleanup: start with user intent, then expose flow-type specifics after the setup had enough context.

• Entry path: Task-first CTAs replaced early internal flow-type selection.
• Resource cards: Action labels and permission states made the next step clearer.
• Scope boundary: Backend flow orchestration stayed intact; the release focused on sequencing, CTA mapping, and gated actions.
• Validation target: Measure setup drop-off, action completion, and permission-state clarity earlier in the flow.

Constraint map

Summary

We moved the flow creation entry toward the thing users understood: what they were trying to connect or set up. The old path asked them to pick from internal flow types too early. The new path started with task intent, then introduced flow-specific choices once users had setup context.

Problem

The product asked users to pick a flow type too early. Team conversations showed that users wanted to connect to systems first and only then handle flow-specific details. The mismatch caused confusion in onboarding and made the setup path feel brittle.

Context

The platform supported multiple flow types with different backend and wizard behaviors. Some flow paths were still half-baked and exposed to users. The team needed to reduce user-facing complexity without hiding product power.

Approach

We iterated toward a task-first sequence: make the initial call to action map to user intent, then place the flow-type choice behind the first task setup. The process stayed deliberately incremental because backend contracts, parallel PRs, QA capacity, accessibility, and role-based actions all had to survive the change.

Discovery and Evidence

Weekly design, product, and engineering reviews kept circling the same issues: users did not know which flow type to choose, some metric ideas could not be backed by available APIs, and a few actions looked equally ready even when permissions or implementation state said otherwise. The repeated review pattern gave us a practical cleanup list instead of a broad onboarding rewrite.

Solution

The revised interaction model introduced clearer resource cards, simpler call-to-action mapping, and permission-aware actions. We preserved visibility for non-admin users while gating actions they could not execute.

Implementation

Design and engineering reviewed edge cases in active/paused state semantics and reconciled API limitations with product language. We treated missing metrics as explicit scope cuts and documented follow-up work.

Results

Delivered: the shipped iteration put task-first CTAs and resource-card setup ahead of flow-type selection, clarified card actions, and used disabled or gated states for permission-limited actions.

The cleaner sequence gave the team a base for later modal and dropdown creation patterns without blocking the current release.

Validation plan: measure setup drop-off, action completion, and permission-state clarity earlier, so the team is not relying only on review notes to decide where the flow is still confusing.

Shipped Scope

• Put task-first CTAs ahead of flow-type selection
• Clarified action states in onboarding and resource management surfaces
• Created a safe path for iterative rollout with existing backend contracts

Reflections

The lesson was sequencing. Users can usually answer the goal before they can answer the internal mode. Future work should collect setup and action-completion evidence earlier, so the team is not relying only on review notes to decide where the flow is still confusing.

Snapshot

agent-memory-mcp started as a practical fix for a recurring workflow problem: every local agent session could reason well in the moment, but useful project context kept fragmenting across tools and threads.

The behavior is simple: local AI tools can retrieve the same durable project context instead of asking the user to re-explain the repo every session.

agent-memory-mcp lets multiple local clients reuse scoped facts without forcing teams into a single editor, host app, or orchestration shell. The repo evidence is the save, find, merge, and update path backed by a local SQLite store.

Operability sequence

Context

The memory layer sits in the part of the workflow most agent tools currently skip over: project facts that outlast one session and can be reused across different local clients.

For the people actually using Codex, Claude Code, and similar tools day to day, the gap was not raw model quality. The real cost was reestablishing context every time they changed threads, tools, or tasks.

Problem

• Local agent workflows were fast, but project memory was trapped inside whichever tool happened to be active.
• Repeated prompts recreated the same context instead of compounding on prior decisions, constraints, and repo facts.
• Teams needed something local-first and inspectable, not a black-box hosted memory service bolted onto one client.

Build

Shared local memory

• Scoped saves keep repo facts, decisions, and user preferences retrievable without mixing unrelated work.
• SQLite keeps saved memory local, portable, and easy to inspect during development.
• The same save, find, merge, and update tools work across agent clients without custom glue per app.

What Shipped

• agent-memory-mcp turns repeated project context into something local agents can reuse instead of rebuilding it thread by thread.
• Designing for multiple agent clients forced clearer scope rules and a local-first storage model.
• The repo evidence is the behavior: users can save durable context once, find it in the next session, merge duplicates, and correct known facts across local clients.

Repository: github.com/mikeylong/agent-memory-mcp

Snapshot

SkillSkill came from a familiar failure mode in AI-assisted work: one session would finally produce a strong workflow, but the next person still had to reteach the same job from scratch.

SkillSkill writes the parts of a SKILL.md an agent needs: when to use the skill, what to produce, how to work, which edge cases to handle, and examples to route against.

The package turns tacit workflow know-how into a reusable file with a clear trigger, contract, edge cases, validation checks, and a path into local Codex or Claude setups.

Operability sequence

Context

Strong AI workflows rarely depend on the task statement alone. The useful part is usually the hidden discipline around what to include, what to exclude, how to structure the output, and how to handle messy inputs.

Tacit workflow knowledge is easy to discover in one good session and surprisingly hard to reuse afterward. Prompt snippets help, but they do not reliably tell an agent when a workflow should trigger, which files to read, what output to produce, or how to check the result.

Problem

• Good one-off sessions produced tacit instructions, not durable SKILL.md files.
• Ad hoc prompts did not make trigger rules, required context, output expectations, or edge cases explicit enough for repeat use.
• Cross-tool reuse was brittle when the core workflow and platform-specific packaging details were mixed together.

Build

Codify the reusable workflow

• Write a canonical SKILL.md around a routing description, binding contract, workflow steps, edge cases, and example requests.
• Keep the core workflow cross-tool by default, then add Codex or Claude packaging only when the caller actually asks for it.
• Support create, revise, and critique paths so weak skills can be repaired instead of abandoned.

Add validation and packaging discipline

• Ship a dependency-free validator that checks required files, one-line descriptions, contract coverage, examples, metadata, and packaging drift.
• Include quality checklist references so expectations stay inspectable instead of living only in the author's head.
• Add install scripts and committed package mirrors so the same skill can be reused across local Codex and Claude setups.

What Shipped

• SkillSkill turns a good AI workflow session into a SKILL.md that agents can route to, follow, validate, and install.
• Explicit trigger rules, output expectations, and edge cases let repeated work start from a checked file instead of a longer prompt every time.
• The contribution is the reuse path: write the skill, validate it, install it locally, and mirror the package for Codex or Claude when needed.

Repository: github.com/mikeylong/SkillSkill

Snapshot

codex-toolbar is a small macOS menu bar utility for people who use Codex enough that rate limits become part of the working environment, not an occasional surprise.

The first version made the current limit state visible at a glance. The newer pass adds the more useful planning question: whether the current 5h and Weekly usage pace is likely to last through reset.

The shipped utility makes the constraints of daily Codex work visible enough to manage without leaving the current task.

Five-second decision

Context

Frequent Codex use creates a background coordination problem. You need to know whether you still have room in the current window, whether the tightest limit is about to reset, and whether today's pace is going to create a problem later in the week.

The local README makes the product constraint clear: the utility had to live as a real macOS app, not a demo surface. Codex Toolbar needed to run as an app, refresh reliably, and fit naturally into the menu bar habits of daily desktop use.

Problem

• Rate-limit state was available, but not ambient. Users had to interrupt themselves to check it.
• The cost of checking was out of proportion to the decision: open the app, inspect the limit state, then decide whether to continue.
• Percentages answered the immediate quota question, but not the pace question. A limit at 75% remaining can still be safe or risky depending on how fast it is being consumed.
• Once the state was visible, there was still friction getting back into Codex quickly enough for the signal to be useful.

Build

Popover states across the rate-limit curve

Popover states across the rate-limit curve

The popover needed to keep the pace chart visible while the rate-limit state changed, so normal, warning, and critical states stayed comparable without becoming visually noisy.

Projected 5h and Weekly pace

The charts make short and weekly limits planning surfaces. They compare the current point in each window, projected empty timing, and reset timing so the user can tell whether the limit is on pace to last or needs attention before reset.

Productize the everyday utility

• Show a compact menu bar progress bar for the most constrained Codex window, including multi-week windows.
• Open a popover with remaining percentages, reset timing, 5h and Weekly pace projections, and an Open Codex action when the desktop app is installed.
• Refresh automatically on system clock minute boundaries and support manual refresh from the right-click menu.
• Ship as a real .app with launch-at-login support so it behaves like an everyday desktop utility instead of a dev-only helper.

What Shipped

• Codex Toolbar turns limit awareness and 5h/Weekly pace into a glance instead of a workflow interruption.
• The projection chart moves the decision from "how much is left right now?" to "can I keep working at this pace?"
• The Open Codex action closes the loop from signal to action by pairing ambient status with a direct route back into the Codex desktop app.

Repository: github.com/mikeylong/codex-toolbar

Website: codextoolbar.com