The Difference Between Running a Prompt and Working as a Design Engineer

The method starts before the first prompt

The first mistake many people make when using AI is thinking the work starts when the chat opens. In practice, it starts before.

In this project, everything started in a meeting with the team responsible for the system. They presented the context, the technologies involved, the technical terms, the main user flow, what they hoped to value, and what was still open.

The briefing does not always come with all the answers. Many times it comes with good intentions, some technical certainties, and several doubt zones: how to better explain the value of the system, how to make the experience clearer, how to transform the core functionality into something that feels truly differentiated.

During the conversation, I asked the basics — which, sometimes, are not basic: does a design system exist? Is there any minimal visual direction? What do you expect as a deliverable? Are we talking about Figma, navigable prototype, code, or something else? Which parts of the flow need to become clearer? Which usability decisions are still undefined?

The answer pointed to something relatively contained: improving the existing Figma and organizing a clearer interface and experience direction. I even received a Figma file (Wireframe) as a starting point. In practice, I used very little of that file.

The decision was to focus less on the direct evolution of the existing screens and more on the structure of the experience: the flow, the states, the narrative of the product, and the form the core functionality should be perceived.

After the meeting came a decisive step: transforming loose understanding into a structured briefing.

I use my own script of questions for this. It is not a rigid form. It is more like a trail of reasoning. I read the questions, answer aloud, and organize the thinking as I speak. This audio becomes text with a local voice-to-text tool I developed, called flow-st8 (nothing original).

The advantage of this process is that it maintains the naturalness of speech, but does not let the briefing become improvisation. There is a structure behind it: navigation, behavior, states, restrictions, expectations, risks, doubts, validation criteria.

The structured briefing in markdown was equivalent to an 8-page document.

In parallel, I also assembled an initial visual guide: colors, fonts, visual references, tone of the interface, and some guiding principles for the first execution. This is important because the first prompt is not just an instruction thrown into the IDE. It pointed to a set of files: briefing, visual guide, and initial documents. The first AI task was not to "start coding". It was to combine these inputs, demonstrate understanding, and transform the material into a first structured deliverable: the frame.

In other words, the initial prompt does not come from a hastily typed sentence. It comes from a conversation, passes through a script of questions, gains a visual layer, and becomes a Markdown specification inside the project itself. That detail changes everything. Because AI does not guess intention. It executes from the context it receives. A vague prompt tends to generate generic results. A structured briefing creates direction.

From frame to product

After that, the material was condensed into a simple frame: what problem we are solving, and what result needs to exist at the end. Without this framing, any execution seems like progress.

With it, each decision can be evaluated: does this bring the product closer to or further from the expected result?

In the project, the initial briefing was not sent directly to execution. It became a compressed sequence of product, design, and development (front end).

Frame and shaping stay closer to product, business, and strategic design. Breadboard and slicing already begin to push into decisions that a development team would normally make: how to break the work, how to validate flows, how to transform intention into buildable parts.

Frame — defined the problem and the expected result.

Shaping — transformed this problem into scope: what goes in, what stays out, what experience decisions need to be made, and what is the general shape of the solution.

Breadboard — detailed the interactions: what places exist in the application, what actions the user can take, what states appear, and how the parts connect.

Slicing — organized execution into functional and demonstrable deliverables (the "slice of cake").

But AI only helps compress steps. It does not eliminate the need to think about each one of them.

For me, this is one of the central points of working as a Design Engineer: creating continuity between product intention, experience design, and technical materialization (the frontend). Part of the logic was inspired by Shape Up, the methodology created by Ryan Singer at Basecamp. Not as a pure application, nor as a methodological ritual. I used it as a reference to structure thinking: move from the problem, shape the solution, detail the interaction, and organize functional deliverables.

What came out the other side

What initially looked like a visual reference deliverable became a functional SPA (Single Page Application) with navigable flows and simulated states.

The delivered product had: 5 complete end-to-end flows — login, initial intake, conversion, profile, and history; mock authentication with local persistence; a simulation engine to represent the conversion process; loading, error, and success states handled in modals and overlays; a custom design system documented in Storybook; three mock scenarios for validation; a support panel for internal testing simulating data input, happy path, and error flows; animations and transitions; and a thorough readme for onboarding, ASCII headers on each page and component, downstream/upstream documentation, happy path, and error flows.

The team did not just receive an interface idea. They received something that could be run, tested, reused, discussed, and used as a concrete reference for the next technical stage.

To avoid turning this into a mathematical promise, I prefer to look at it as equivalent effort: how much a traditional pipeline would probably involve to arrive at an artifact with a similar scope.

The point is not "look how fast it was". The point is: it was fast because there was coherence between the stages. Each artifact fed the next. Without that line of continuity, AI becomes a machine for generating rework at high speed. With method, it becomes a real extension of execution capacity.

The first response almost always has an "AI face"

There is a part of this process that does not appear in pretty prints or productivity metrics. The distance between the first result and the final product. This distance is where the real work lives.

The first AI output, even with a good prompt, is usually competent. But competence is not the same thing as intention. It works. But many times it has an AI face: visually correct, but generic. Correct text, but without voice. Correct interaction, but without personality — everything with an "AI face".

And it is precisely there that design work begins. Not in the superficial sense of "making it prettier". But in the more important sense: refining intention, perception, hierarchy, rhythm, emotion, and coherence.

In the homepage of that project, the change was not just swapping components or choosing a prettier composition. The screen needed to stop looking like an area filled with widgets and start communicating a concept. It needed breathing room, hierarchy, rhythm, and a clearer direction for what the product wanted to convey.

Another example was the use of text scramble animation in interface messages. It did not come from nowhere. It came from research on domain terms and the decision to transform that vocabulary into a layer of voice and personality for the product. While processing, fun phrases within the context were displayed.

AI executes this well when directed. But it does not wake up inspired and decide the product needs personality.

The real cycle of interaction with AI is less magical and more laborious: generate, evaluate, redirect, repeat.

This cycle seems simple. It is. But simple does not mean easy. Because evaluating requires repertoire. Redirecting requires clarity. Repeating requires criteria to know when to insist, when to change, and when to stop.

The role of fundamentals

Much of what I described here may seem basic. And honestly, it is basically basic. Briefing done right. Right questions. Problem clarity. User understanding. Visual hierarchy. Flow. State. Feedback. Handoff. Validation. Criteria. None of this was born with AI. And maybe for that very reason it is so important now.

The faster execution becomes, the more the fundamentals appear. Or better: the more their absence appears.

When an AI generates an interface in seconds, the differential stops being the ability to produce a screen. That became cheap. The differential becomes knowing how to evaluate whether that screen makes sense. Does it solve the problem? Does it explain the value well? Does it guide the user? Does it communicate the right sensation? Does it seem like product or template? Does it respect the context of that moment, that domain, that conversation, that company?

Fundamentals are what allow making these questions. Critical sense is what prevents accepting the first response just because it looks ready.

In design, there is still a layer harder to automate: feeling, perception, and context. An interface does not just convey function. It conveys security, sophistication, urgency, calm, trust, strangeness, familiarity. Sometimes it conveys all of that without a single word. AI works very well with patterns. But a good product does not always come from pattern alone. Sometimes it comes from perceiving that the right pattern, in that context, is precisely what needs to be broken.

Design Engineer is not "designer who knows how to code"

Design Engineer is not just someone who opens Figma and then writes React. It is also not a developer who "has good visual taste".

For me, the role is closer to an operational bridge between product intention, experience design, and technical materialization.

It is someone capable of asking: what problem are we trying to solve? What experience proves the solution makes sense? What is the smallest demonstrable product that allows real discussion? Which decisions need to be made now? Which decisions should be left for later? Where can AI accelerate without creating debt, risk, or confusion?

In this project, the focus was not to replace the future engineering work. It was to create a much stronger handoff for it. A functional frontend, documented, with simulated flows, predicted states, organized components, and test scenarios gives the technical team a concrete base to discuss backend, APIs, architecture, and real integration.

In the end, the time gain only matters if the decision improves

The velocity gain was large. Something that could take weeks of a traditional pipeline was compressed into dozens of hours of direction, revision, and assisted execution.

But that is not the most interesting part. What matters is what the recovered time allows doing better: revising more, testing alternatives, discussing product with more clarity, perceiving experience noise, and deciding with more criteria what should or should not advance.

AI accelerates execution. But fundamentals continue deciding quality. The more it becomes easy to produce, the more valuable it becomes to know how to evaluate. The more rapidly it becomes possible to generate, the more important it becomes to know how to direct.

The more AI delivers convincing answers, the more necessary it becomes to have criteria to not confuse product appearance with real product.

Without method, you gain code. With method, you start to appear product. With fundamentals, that product starts to have intention.