Operation Sheet

How an engagement runs

It starts with a conversation, not a proposal. Before anything is scoped or priced, we talk about what’s actually going wrong — the stalled line, the tool nobody trusts, the process that produces motion but nothing that ships. I want to know whether the problem is worth solving, and whether I’m the right person to solve it. That first conversation is usually enough to tell.

Then I frame the problem before I price the work. The opening stretch of any engagement is OP 10 and OP 20 above: understand the environment, name the real problem. What comes out is a written problem definition, a scope, and the criteria we’ll judge the result against. If the framing changes what the project should be — and sometimes it does — better to find that early than at delivery. [[owner: rough duration of the framing phase]]

What I need from you is access and honesty. Time with the people who actually do the work, not only the people who manage it. A straight account of the constraints — the budget, the legacy system, the deadline, the politics — because I design around real limits better than imagined ones. The more of the mess I’m allowed to see, the less of it survives to the end.

Design runs in cycles, in the open. The work moves in short loops — design, test with real users, revise — and you see each loop rather than a reveal at the end. I share prototypes when they’re testable, not when they’re pretty, because the point is to catch a wrong direction while it’s still cheap to change. How many cycles it takes depends on the problem; I’ll give you a realistic count once it’s framed. [[owner: rough number or length of design cycles]]

Delivery is a build kit, not a folder of screens. What lands at the end is production-ready: specifications a developer can build from without guessing, the states and edge cases drawn, and a design system the team can keep extending once I’m gone. Where the work ships white-label or under NDA — as most of mine does — it’s handed over to live inside your product, under your brand, held to your standards.

And I stay through development. Handoff is the middle of the job, not the end of it. I stay in the build reviews, answer the questions no drawing anticipated, and catch the drift between what was intended and what compiles. I’ve spent enough time in industrial settings — where a misread screen stops a line — to treat “it shipped and it works on the floor” as the finish, not “it looks right in Figma.”

I work as part of your team, under your name. Eight years in industry, most often as the lead designer and product owner, and most of what I make carries someone else’s brand. That suits me. I’m based in Venice and work with teams globally — in person when it earns the cost, remote when it doesn’t. [[owner: how you prefer to structure engagements — retainer, fixed-scope project, embedded]] [[owner: typical engagement length]]

The first step is small. If any of this matches a problem you’re sitting with, start a conversation — no scope, no commitment, just enough to know whether it’s worth going further. That’s what the form below is for.