STAYUX - Flow Fusion Form

My process starts with the problem, not the interface. Before any design tool opens, I align with stakeholders on what we're solving and why, then move into user research - interviews, behavioral data, or both - to separate assumptions from facts.

From there: problem framing, ideation, iterative prototyping at the lowest fidelity that generates a real signal, and testing before commitment. I document decisions and rationale throughout so the output is traceable - engineers, PMs, and future designers can understand not just what was built, but why.

Design decisions that can't be connected to a business outcome are very hard to defend - and harder to resource. I frame every significant design decision in terms of what user behavior it changes, and what that behavior change means for the business.

That means defining success metrics before design begins: activation rate, task completion, retention curve, support volume, NPS delta - whichever number reflects whether the user's problem was actually solved. I work with PMs and data to understand the product's growth model and where design has the most leverage.

My perspective on this comes directly from running my own agency as CEO, Product Designer and PM for 16+ years. Sitting on both sides of the table - as the person accountable for business outcomes and as the designer responsible for the product - shaped how I approach every cross-functional relationship. The most important skill I built in those years was learning to align and validate multiple perspectives before committing to a direction.

Trust with engineers and PMs is built through consistency and open communication. It comes from showing up prepared, following through on commitments, and being honest about trade-offs rather than overselling a design direction.

With engineers, the most effective thing I do is learn enough about the stack to have a real conversation - understanding constraints before they become blockers, and framing design decisions in terms that map to implementation reality. When engineers see that I'm not designing in a vacuum, the relationship shifts from handoff to collaboration.

With PMs, trust comes from connecting design work to the metrics they own. When I frame a design decision in terms of activation, retention, or conversion - not just usability - it signals that I understand what they're accountable for.

Backing decisions with testing and validation is what makes alignment durable. It removes the personal from the professional - the argument stops being about opinion and starts being about evidence.

That habit, built over years of running projects where I carried the business risk myself, is also what gave space for innovation and early adoption of new technologies and methodologies.

When you can demonstrate impact before you ask for investment, people follow.

Design should lead when the core problem is human - when the question is about behavior, perception, mental models, or how people make decisions. Those are problems that require user proximity, and design is the function closest to them. Discovery, problem framing, information architecture, interaction logic - these are areas where waiting for product or engineering to set the direction produces the wrong output.

Design should follow when the constraints are real and fixed - a hard technical limitation, a regulatory requirement, a business model that isn't negotiable. Following in those cases isn't deferring, it's being efficient. Fighting constraints that won't move wastes the credibility you need for the fights that matter.

The AI revolution isn't automating design - it's redefining it. The work is shifting from generating static visuals and mapping virtual interactions to building and testing real prototypes and MVPs. Designers who understand that shift will move upstream in the product process.

That shift unlocks something overdue: a sharper focus on UX quality and business impact. With AI handling production speed, there's less excuse to stop at the wireframe. Handoff becomes more precise - specs that are testable, not interpretable - and the conversation with engineering teams becomes more substantive because designers can speak the language of implementation, not just intention.

What that requires is literacy in the tech stack. Not the ability to write production code, but the ability to use LLMs, agents, and tools like Claude Code to build, validate, and stress-test ideas - with depth and research rigour, not just speed. Context engineering - knowing how to frame a problem so that both AI tools and engineering teams can act on it - becomes a core design skill.

The role in the near future moves toward spec-driven design: outputs that are precise enough to drive development directly and qualitative enough to be defensible. Less here is a mockup, more here is a tested, documented, buildable solution.