Design in Transition: New Roles Through AI Tools

A developer builds the first working version of a feature in under an hour. It works, it's navigable, it can be tested live. In the same time, a classic design process would have just completed the wireframe phase. Anyone working in digital product development today knows this new speed reality. It's changing not just the pace of delivery, but the distribution of roles in the team and thus the position of design.

We at mindtwo experience this transformation in our daily project work: from conceiving scalable web applications to modernizing existing platforms. Anyone developing demanding digital products in the coming months will encounter a design discipline that looks different in many ways than it did two years ago. What matters now, which roles are shifting, and how a contemporary design and development process must be structured is the topic of this article.

Why the classic design process is losing its self-evidence

For years, a certain model was considered the gold standard: research and discovery, divergence with many ideas, convergence on a solution path, careful mockups, clickable prototypes, tests, then handoff to engineering. "Trust the process" was the maxim, and it had its reason as long as implementation was the actual bottleneck.

This bottleneck has shifted significantly. With modern AI-powered coding assistants, ideas can in many cases be converted into working code within minutes. A developer builds several variants of a feature in parallel, tries them out, discards them, starts over. All in the time that a single mockup cycle used to take. This has an immediate consequence for design: anyone who continues to produce eight elaborated mockups in the same time blocks the team's pace instead of leading it.

This doesn't mean that design competence is losing importance. On the contrary. It means that the distribution of attention within the discipline is shifting. UX and UI design is becoming a discipline that works more closely with implementation while simultaneously carrying more responsibility for strategic direction.

Two types of design work that count today

In modern product teams, two clearly distinguishable modes are crystallizing in which design becomes effective.

When engineering quickly builds prototypes, the most valuable design contribution is often not creating another mockup, but direct collaboration on implementation. Specifically, this means: a developer builds a first, rough version of a feature. It works, it shows the concept, but it's not polished. This is exactly where design comes in today: spacing, typography, micro-interactions, consistency with the design system, tonality of texts and hints, sequences, hierarchies.

Designers who can deliver this refinement need a different tool than pure Figma. They increasingly work directly in code, in the IDE or in the browser, and specifically change the last 20 percent that transforms a product from "it works" to "it feels right." This is not a technical gimmick, but a pragmatic answer to the question: where is the design contribution most effective?

Mode 2: Vision and direction

The second mode concerns what many teams lose in the pace of implementation: a shared target state. When any number of features can emerge in any number of directions, coherence becomes the scarce resource. This is where design work is needed that thinks forward, but differently than before.

Visions that reach five to ten years into the future and are formulated on 30 slides have hardly any justification in this environment. The technology landscape changes too quickly for a precise state in two years to be seriously described. Instead, directional images emerge that reach three to six months into the future and are often formulated not as a deck but as an interactive prototype. Their purpose is not to claim a final truth, but to give the team a common target point by which parallel implementation threads can orient themselves. Long-term design principles (such as brand, tonality, or architecture) remain important, but they run in a separate layer.

How time allocations in design teams are shifting

Anyone who worked in design teams two years ago typically knew this distribution: roughly 60 to 70 percent of time for mockups and clickable prototypes, 20 percent for coordination with engineering, the rest for coordination. In the teams we work with, this looks different today.

Mocking still accounts for 30 to 40 percent of design work in many projects, and we'll come back to why this percentage doesn't drop to zero. About the same proportion goes to direct jamming and pairing with engineering: developing solutions together, sketching on whiteboards, commenting on built versions, evaluating variants. A growing proportion, depending on seniority level and specialization, goes to one's own implementation in code.

This shift is not a fad, but an answer to the question of where design has the greatest leverage in the new pace. Anyone looking for a web agency today as a client or developing an existing design team should know this distribution. It has immediate consequences for competency profiles, tooling, and collaboration.

Why Figma isn't disappearing anyway

A common misconception is: if designers now work in code, they don't need Figma anymore. That's not true. Figma remains a central tool for two reasons.

First, design work is often variant work. Seeing eight to ten directions for the same element side by side, curating them, discarding them, combining them: this is faster and clearer on a design canvas than in a code iteration with an AI assistant, which is linear by nature. Building a variant in code means investing in that one direction. Thinking in Figma allows you to span the space of possibilities simultaneously.

Second, there is an area where canvas and comparison remain indispensable: the micro-level of the visual. Typography scales, icon families, color scales, spacing tokens, component systems: such detail decisions benefit from a canvas where all variants are visible. This work hasn't become less, it's just focused much more precisely.

What changes is the function of mockups overall. They are no longer the main delivery to engineering, but a thinking tool, a sketch, a discussion proposal. And in many phases they compete with rapid prototyping in actual code, which has now become accessible to non-technical disciplines through AI tools.

The new toolbox: AI stack in everyday design

The toolbox in everyday design has become significantly more heterogeneous. Alongside Figma and classic design apps come coding assistants in the IDE, chat-based models for research, conception and texts, as well as agent-capable tools that take on longer tasks in the background.

A typical day can look like this: in the morning, a concept is sharpened in a chat-based model, texts are tried out in different tonalities, existing content is analyzed. In the late morning, some variant canvases for a new feature are created in Figma. At noon, there's a pairing session with a developer who has built a first prototype, and feedback flows directly into the code. In the afternoon, the designer herself adds refinement to the frontend. Via Slack, an AI agent responds to small, clearly defined tickets ("Icon Y is misaligned"), proposes a correction that a human reviews and merges into the main branch.

This is not future music, but everyday life in teams that have adopted agent-based software development early. What's crucial is that the tools don't compete with each other, but complement each other, depending on task, level of detail, and speed requirement.

Trust through speed: A new understanding of quality

One point initially seems paradoxical to many clients: if everything goes faster, doesn't quality necessarily have to suffer? The answer is more nuanced. A new understanding of quality is emerging, which we describe as "trust through speed."

In the old logic, a team built a feature for months until it was considered perfect, and then released it with a big launch. In the new logic, publishing happens earlier and more explicitly, often with a clear indication that a feature is still young and rapidly evolving. The gain in trust then doesn't come through completed perfection, but through two things: the early visibility of utility value and the demonstrably fast response to feedback.

For this model to work, three conditions must be met:

Clarity about status. What is a mature product interface, what is explicitly an early version? This distinction must be recognizable for users.
Visible response to feedback. Feedback is not just received, but visibly converted into improvements, ideally within a few days.
Continuous iteration. The publication cadence must be high enough for users to perceive progress. An early version where nothing happens for half a year damages trust instead of building it.

This model assumes that the underlying engineering machinery is actually fast enough to deliver corrections within hours instead of weeks. This is exactly where the investment in modern coding tools pays off doubly: it enables fast publishing and fast correction.

Which profiles are needed in modern design teams

Anyone building or expanding design teams today should move away from some classic search patterns.

The strong generalist (block profile)

The T-profile was long propagated: a broad base of skills and a deep specialization. This form remains sensible, but it's no longer sufficient for many tasks. What's valuable today is someone who belongs to the top 20 percent in several disciplines (UX, visual design, frontend implementation, product and brand understanding). This is rare and hard to find. Where it comes together, however, a mobility emerges that is enormously effective in fluid teams. Such profiles can switch roles depending on the project phase without the team losing a handoff.

The deep specialists

The counterpart are profiles with an exceptionally deep specialization. This can be a designer who is technically so proficient that they work almost at the level of a frontend developer. These profiles are crucial when models, APIs, and component architectures need to be co-designed. Or a specialist in visual identity who makes the difference between an interchangeable and a distinctive product. This very visual and iconographic refinement becomes more valuable in the AI era, not less valuable, because generic standard solutions are available at the push of a button at any time.

Talented career starters with a maker mentality

The third profile is often overlooked: young designers early in their career who bring two qualities, namely genuine curiosity and the habit of actually building things rather than just conceiving them. They carry no baggage from outdated processes. They reach for new tools without inhibition. They publish small projects, try absurd ideas, learn quickly. In an industry whose processes change every six months, this learning openness is a strategic advantage and a profile that is especially underestimated by smaller, focused teams.

Anyone wanting to build profiles of this kind should not focus exclusively on senior experience with classic methods in their personnel strategy. The combination of experienced specialists, generalist strong seniors, and curious talents is more robust against the changes that will continue in the coming months.

What's changing for management and leadership roles

Design leadership is also changing. Classic design management roles, which consisted almost exclusively of people management and process leadership, are being thinned out. In their place emerges a hybrid role: someone who provides direction, is technically close to the product, simultaneously takes responsibility for employee development, and if necessary pitches in themselves.

Practically, this means that many experienced design leaders should at least temporarily return to operational work, not out of distrust of their teams, but to understand the changes on their own work piece. Anyone who hasn't used the new coding tools themselves and hasn't experienced firsthand how an engineer works with agents will have difficulty credibly leading teams in this reality.

A second, often underestimated point: the classic distinction between "high-leverage" and "low-leverage" tasks is shifting. When a CEO herself submits error reports, reproduces a bug, or reviews a pull request, this initially appears as a low-leverage activity. On second glance, it has a strong effect because it demonstrates product proximity, shapes standards, and forms team culture. Leadership thus becomes less defined by hierarchy and more by visible participation.

Psychological safety and high standards: Not a contradiction

An observation on team culture: in the most productive design teams, there's a mixture of two things that are often described as opposites, namely psychological safety and unconditional results orientation.

Psychological safety shows itself in seemingly incidental details: team members affectionately tease each other, leaders are gently parodied for their tics and phrases, critical feedback is given without status anxiety. The opposite, an atmosphere where every statement is examined as a potential career risk, not only slows decisions but lowers the quality of results.

At the same time, standards for work are high. Honest criticism is given without hurting. Follow-up questions are asked without humiliating. Both poles support each other: those who feel safe can tolerate high standards. Those who have accepted high standards draw confidence from the fact that the team is building a good product together. This culture cannot be created in a workshop. It grows from the behavior of participants, especially those who lead.

Where human judgment still decides

For all the speed, for all the automation, and for all the refinement through AI tools, one question remains that cannot be automated: what should actually be built? Which of the many possible features, which of the many conceivable directions, which variant of a solution deserves the next sprint?

The most difficult moments in product development are not technical in nature, but human. Two people disagree about which feature belongs in a version. One stakeholder group sees the product differently than another. Data contradict each other, and someone must decide which reading to follow. AI tools are valuable sparring partners here, but they don't take away the responsibility. Someone must ultimately say: "We're building this, not that, we're postponing that." This decision is personally carried and justified by a person.

For design teams, this means: taste, judgment, and strategy retain their value. They may even gain value because building has become so cheap that the question "what's even worth building?" becomes the actually scarce resource. Anyone who can give clear answers here is more important than ever as a designer.

What this means for projects and clients

For companies that develop demanding digital products, some practical consequences can be derived from these observations:

Adjust expectations for mockup phases. An extensive mockup phase with thirty fully elaborated screens before the first line of code is written is no longer the best approach in many projects. Early, working prototypes on which decisions can be tested are often more valuable.
Make iteration speed the contractual basis. Not the individual launch is the quality guarantee, but a team's ability to visibly improve in short cycles. This ability can be checked in advance, for example based on tools, architecture decisions, and team composition.
Don't only purchase design competence in the concept phase. Anyone who only involves design at the beginning of a project and then "hands it off" to engineering is giving away a large part of the value. Collaboration in implementation and refinement is where design has a significant impact today.
Pay attention to cross-functional team composition. Strict discipline separations (here design, there frontend, there backend) are obstructive in agent-capable environments. Successful teams have profiles that overlap and co-master the tools of neighboring disciplines.

We build web applications and platforms for demanding use cases, from initial conception to long-term further development. In current projects, it's clearly evident how much the interplay of design, engineering, and AI-supported tools shapes result quality. Anyone setting up a platform today or modernizing an existing product benefits from planning this interplay from the start, rather than adjusting later when their own team notices that the old processes no longer work.

An interim conclusion, not an end point

The design discipline is not facing its end, but one of its most interesting shifts. Mockups retain their place, but they lose their exclusivity. Designers work closer to code without becoming developers. Speed increases, and quality remains defensible if it's secured in a different way than before.

How it continues is open. The discipline's tools will continue to change in the coming months, the relationships between human and agent will be renegotiated, the profiles in teams will be further sharpened. What's becoming clear, however: the teams that successfully build digital products in the next wave are not those who cling most strongly to the old process. They are those who place their design contribution where it counts most today, namely at the interface to implementation, in the strategic direction question, and in defending the judgment that even the best tool cannot replace.

If you're thinking about the right setup of design and engineering for an upcoming project or platform modernization, please contact us. We share what we've learned from daily work with modern design processes and AI-supported tools.