Skip to content

Consulting / Legible systems

Make complex products legible—and easier to choose.

I work with AI and developer-tool companies whose products are technically powerful, strategically important, and hard to explain.

Together we sharpen the mental model, build credible proof, and create the materials and experiences that help people adopt the product with sound judgment.

How I work

The method follows the actual adoption problem: people need a model, evidence, and a way to learn.

What is this, really?

Clarify

Find the simplest honest model for the product: who it is for, what changes for them, how it behaves, and which tradeoffs deserve to stay visible.

Work may include

  • Product and category narrative
  • Audience and adoption diagnosis
  • Mental-model and message architecture
  • Developer journey review

Why should anyone believe it?

Demonstrate

Build or shape the artifact that proves the product can do the important thing under real constraints, with enough visibility for people to evaluate it.

Work may include

  • Reference application or prototype
  • Evaluation plan and evidence
  • Architecture pattern or technical demo
  • Launch-ready proof narrative

How will people learn to use it well?

Teach

Turn the model and proof into documentation, workshops, technical content, and feedback loops that help developers build sound judgment.

Work may include

  • Documentation and learning path
  • Workshop or technical talk
  • Launch and editorial material
  • Developer feedback program

Ways to work together

Start with the shape of the problem. The engagement should leave a useful artifact behind.

Engagement shape

Legibility review

Diagnose where a complex product loses people across the concept, developer journey, evidence, and explanation.

Leaves with

A prioritized map of the core model, friction points, and high-leverage changes.

Engagement shape

Proof sprint

Turn an important product claim into a reference application, prototype, evaluation, or working demonstration.

Leaves with

An inspectable artifact and the technical story required to present it credibly.

Engagement shape

Teaching system

Create the learning path around a product launch, new capability, or changed developer workflow.

Leaves with

A connected set of documentation, workshop, content, and feedback-loop recommendations.

Working principles

Mechanisms over claims

Show how the important thing works.

Artifacts over decks

Leave something teams can use and test.

Learning over exposure

Design for judgment, not content volume.

Tradeoffs stay visible

Credibility grows when constraints remain inspectable.

Start with the difficult part

Tell me what customers, developers, or your own team struggle to understand.

I’ll respond with the questions I would investigate and the smallest useful engagement shape.

Email Richard