Skip to content
Book a call

Process Operation sheet

The process is part of the solution.

Every engagement runs the same operations. This is the long version; what can be bought is on Services.

  1. OP 10 Listen & Understand Before I propose anything, I go to where the work happens. I watch people use what they have now, read the system they inherited, and talk to the operators on the floor and the people who own the outcome, until I understand the terrain, not just the request. Assumptions come later, and cost less. OutputField findings and a current-state map
  2. OP 20 Frame the Real Problem The brief usually names a symptom, not the cause. I trace it back to a broken handoff, an unquestioned constraint, a decision made years ago and never revisited, and write the real problem in one sentence the whole room can agree on, with a clear line around what we are not solving. OutputProblem definition · scope · success criteria
  3. OP 30 Design & Advocate I design in cycles and test each one with the people who will actually use it, so real friction, not the loudest voice in the room, drives the next version. I hold the user’s case even when that’s the inconvenient position. The screen comes last; the model, the flow, and the states come first. OutputTested prototypes and interaction specs
  4. OP 40 Deliver & Stay Handoff isn’t an exit. I deliver specifications a developer can build from without guessing and a design system the team can keep extending after I’m gone, then I stay through development, in the reviews, answering the questions no drawing anticipated and catching the drift between what was meant and what ships. OutputProduction specs, design system, dev support

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.

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 of design, testing with real users and revision, 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.

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. Seven 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.

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.

Book half an hour or write

Ready to start?

A screen operators fight with, a platform that needs a senior designer, a studio short of one? I reply within 48 hours.

Book a 30-min callStraight into the calendar 60-min project overviewFor a framed problem