There are some questions that many designers feel, even before they formulate them out loud: What will the future be like? What do I need to do to stay relevant? Is design still relevant? The honest answer is: it depends. It doesn’t just depend on the market, the company, the maturity of the team, or the quality of the available tools. It depends, above all, on the type of designer each one is trying to continue to be.
If her professional identity is still too tied to producing screens, organizing components in Figma, delivering visually solid flows, and the ability to respond well to requests defined by others, she is in a danger zone. Not because that work has ceased to have value. It has value. But because it has ceased to be enough to differentiate her and, in many contexts, has ceased to justify the same level of dependence, time, or cost as before.
Design hasn’t lost importance. On the contrary, it has become more important precisely because products have become more complex, more distributed, more automated, and harder to make understandable. What has changed is the bar. Companies no longer need just designers who transform requirements into interfaces. They need designers who help realize if the requirements make sense, if the problem was well formulated, if the proposed solution respects the user’s context, if the trade-offs are acceptable, and if the created experience actually contributes to the product’s and organization’s goals.
This places us before an uncomfortable shift. The designer who waits for the briefing to start thinking is becoming too passive for the current pace. The designer who only enters when the decision has already been made will naturally be treated as a production person. The designer who merely improves the appearance of a solution, without questioning the premise that sustains it, will continue to do useful work, but will hardly be seen as someone strategic. And this isn’t solved with more tools, more templates, or more components. It’s solved with a change of posture.
The profession has changed, but many designers continue to protect an old version of the role
For a long time, the trajectory seemed relatively clear. A designer learns UX, masters prototyping tools, understands heuristics, knows how to build flows, organize information, do some research, prepare handoffs, work with design systems, and present solutions to stakeholders. This profile continues to be relevant, but it no longer represents, by itself, a strong competitive advantage.
The change didn’t happen because of a single force. AI accelerated part of the discussion, but it would be simplistic to reduce everything to that. The transformation comes from the combination of tools that make production faster, teams that need to do more with less, companies that demand clearer impact, products that depend on increasingly interconnected systems, and development processes that have no patience for long translation cycles between design and engineering. The result is a growing pressure on the designer: it’s not enough to produce artifacts; she must increase the quality of the decision.
That difference is fundamental. Producing artifacts means responding to an already framed need. Increasing the quality of the decision means entering the discussion earlier, clarifying the problem, making risks visible, bringing the team closer to reality, structuring alternatives, and helping to choose a direction with more awareness. The first role is useful. The second is much harder to replace.
That is why some types of designers will lose ground. The designer who only produces visual variations will lose ground. The designer who always depends on someone else to explain the problem will lose ground. The designer who needs weeks to materialize a simple hypothesis will lose ground. The designer who delivers impeccable files but doesn’t influence decisions will lose ground. Not because she is necessarily incompetent, but because the market is shifting value elsewhere.
Value is no longer just on the screen. It’s in the quality of the decision
I want to be clear: craft still matters. Visual quality matters, usability matters, hierarchy matters, accessibility matters, consistency matters, and attention to detail continues to be a hallmark of professionalism. It would be absurd to argue otherwise. The problem is that craft loses strength when it is disconnected from the right decision.
A well-designed screen for a bad idea is still a bad idea. A polished journey that solves the wrong problem is still a waste. An elegant flow that increases friction at a critical moment is still bad design. A visually impeccable feature that breaks the user’s trust is still a failure. The mature designer understands this and, therefore, does not limit herself to improving the surface of the problem.
Many designers get stuck exactly at that point. They improve the form but don’t question if that data really needs to be requested. They refine the dashboard but don’t ask if that information helps anyone decide better. They improve the onboarding but don’t discuss if the product is asking for commitment too early. They design the requested solution but don’t validate if the problem exists as it was described. They work well on the artifact, but they arrive late to the decision.
The jump in maturity begins when you stop asking only “how can I make this better?” and also start asking “should this exist in this way?”. This question is not arrogance. It is responsibility. It is the difference between accepting the problem exactly as it was handed over and participating in its formulation. And it is precisely this ability to formulate problems better that separates a merely competent designer from a designer who increases the team’s intelligence.
Good designers show work. Very strong designers communicate intent
There is a huge difference between showing work and communicating intent. Showing work is opening a file, going through the screens, and explaining what was done. Communicating intent is explaining what she is trying to solve, why that direction makes sense, what alternatives were considered, what trade-offs were accepted, what risks remain open, and what decision needs to be made.
Many designers still present work as if the goal were to demonstrate effort. That is not the goal. The goal is to help the team think better. A good design presentation should not be a guided tour of the file. It should be a mechanism for alignment, decision, and learning. It should reduce ambiguity, make reasoning more visible, and allow other people to contribute in a more qualified way.
When you present work, there are questions that should be implicitly answered: what problem are we solving, why does this problem matter now, what behavior do we want to change, what constraints influenced the solution, what options were discarded, where does risk still exist, and what decision is necessary at that moment. If the presentation doesn’t help clarify this, you’re probably just dumping outputs into the room.
Clarity of communication has become a core competency. I’m not talking about making pretty slides or artificial narratives. I’m talking about the ability to adjust depth to context. With leadership, she has to be able to summarize weeks of work into decisions, risks, and impact. With engineering, she has to be able to discuss structure, states, dependencies, and edge cases. With product, she has to speak about behavior, adoption, priority, and metrics. With other designers, she has to be able to discuss the system, consistency, accessibility, and experience quality.
This is not a secondary skill. It is a form of craft applied to thought and communication.
The world doesn’t need more perfect stories. It needs designers who know the reality of the work
There is a tendency to transform design work into an overly clean narrative; this is evident in most portfolios I see. The problem was clear, the process was exemplary, the team aligned, the solution emerged, the launch went well, and the results were positive. Everything seems coherent, progressive, and inevitable. But real work is rarely like that.
Real work has ambiguities, setbacks, conflicts, incomplete data, misaligned stakeholders, technical limitations, tight deadlines, solutions that seemed good but weren’t, difficult compromises, and parts that fell short. A mature designer doesn’t need to hide this complexity. On the contrary, she knows how to speak about it with precision.
The way she talks about work reveals the depth with which she actually lived it. If everything seems too linear, perhaps she wasn’t deep enough inside the problem. If she can’t explain the conflicts, perhaps she only participated on the surface. If she doesn’t know how to say what was left out, perhaps she didn’t have real influence on the decision. If she can’t show what she learned when she was wrong, perhaps she just executed.
This should also change how we build portfolios, do reviews, and have career discussions. What matters isn’t just showing the final result, but showing the quality of thinking. What problem existed? What ambiguity did she have to reduce? What difficult decision did she make? What trade-offs did she accept? What signals did she use to change direction? What part of the result was really hers? What did she learn that made her a better designer?
Maturity appears less in the ornamentation of the story and more in the precision with which she can explain reality.
Go to reality sooner
One of design’s biggest traps is falling in love too early with the version of the idea that exists in our heads. In the file, everything seems controllable. The flow fits, components obey, the narrative seems logical, states are handled, and screens get progressively prettier. The problem is that an idea can become visually convincing before it is conceptually right.
Then, when it hits reality, it breaks. The user doesn’t understand. The client doesn’t trust. The technical team reveals an ignored dependency. Support raises a case no one considered. Business shows a constraint that changes the priority. The expected metric doesn’t move. None of this is necessarily bad. What’s bad is discovering all of this too late.
Strong designers seek collision with reality while the idea is still cheap to change. They show early, test early, prototype early, talk to users early, discuss with engineering early, validate premises early, and expose risks early. They don’t wait for the solution to be pretty to find out if it’s wrong.
Beauty can wait. Truth cannot.
The traditional handoff is losing its central role
For years, many designers organized work around a relatively predictable ritual: understand the problem, design the solution, prepare the file, document states, write notes, and hand off to engineering. That model still exists and will continue to exist in many contexts. But it is losing its central role as the primary expression of a designer’s value.
What is changing is not the importance of collaboration with engineering. On the contrary, that collaboration is even more important today. What is losing strength is the model where the designer only manages to express the solution through a static file and a subsequent explanation. As tools bring idea, prototype, and implementation closer together, it becomes less acceptable for the designer to remain too distant from the actual behavior of the experience.
I’m not arguing that all designers should become engineers. That would be a reductive reading. What I argue is that all designers need to increase their technical literacy and their ability to create representations closer to reality. This can mean more functional prototypes, a better understanding of states and data, solid notions of accessibility and performance, the ability to use AI or no-code tools to explore hypotheses, and earlier participation in implementation discussions.
The designer who understands how the experience behaves, and not just how it looks, becomes much harder to replace. Not because she knows how to do everything, but because she reduces the distance between intent and reality.
You don’t need to know how to code everything. But you need to understand enough to not design in a vacuum
Whenever more technical designers are mentioned, a predictable anxiety arises: the idea that everyone will have to become a developer. It’s not that. But the opposite conclusion is also weak. It is no longer enough to say “that’s up to engineering” whenever the conversation turns to data, states, APIs, performance, accessibility, responsiveness, or instrumentation.
She may not write production code, nor master frameworks, nor build infrastructure. But she has to understand enough to design with respect for the reality of the product. She has to understand what states exist, what data goes in and out, what edge cases may arise, that an animation can have a cost, that a component is not just a visual layer, that accessibility isn’t a note at the end, and that performance is also part of the experience.
This doesn’t make her less of a designer. It makes her a more complete designer. And, above all, it makes her conversations better. The less she understands about technology, the more dependent she becomes on the translation of others. The more she understands, the more she can anticipate problems, negotiate trade-offs, and design solutions that better survive implementation.
Thinking in systems has stopped being special. It has become the base
For a while, systems thinking seemed like an advanced skill, reserved for senior designers, design system designers, or people involved in platforms. That time is over. Today, practically everything we design lives within systems.
Products are systems. Design systems are systems. Onboarding flows are systems. Pricing models are systems. Notifications are systems. Support is part of the system. Metrics are part of the system. Brand is part of the system. Trust is part of the system. A local decision is rarely just local.
When you change a pattern, you can affect the user’s learning. When you create a visual exception, you can weaken consistency. When you resolve a problem in a flow, you can shift friction elsewhere. When you add an option, you may be increasing cognitive load. When you oversimplify, you can hide necessary control.
The designer who thinks only of the screen sees only one part of the problem. The designer who thinks in systems sees the consequences. And the future will reward more and more those who can see consequences before they become debt.
AI doesn’t eliminate the designer. It eliminates excuses
AI is changing work, but public discussion tends to get stuck on the least useful question: “Will AI replace designers?”. The more relevant question is: which parts of design work stop justifying as much time, cost, or specialization?
That is where the change begins. Exploring variations became cheaper. Writing first versions became faster. Generating hypotheses became more accessible. Producing assets became simpler. Creating initial prototypes can be less dependent on long processes. Researching patterns and references became almost immediate.
This doesn’t eliminate the designer, but it eliminates some excuses. You can no longer take too much time to reach a first hypothesis. You can no longer defend the lack of exploration when tools accelerate exploration. You can no longer use production as the sole proof of value. You can no longer hide the lack of thinking behind manual work.
Value shifts to judgment, direction, taste, synthesis, ethics, the quality of the question, reading the context, the ability to decide, and responsibility for impact. AI increases average production, but it also makes those who really think well more visible.
Don’t delegate impact to product
One of the biggest mistakes a designer can make is accepting that strategy always belongs to someone else. Product defines the problem, business defines the priority, engineering defines feasibility, and design executes the experience. This model may seem organized, but it is dangerous if the designer accepts a passive role within it.
I’m not saying the designer should replace the PM, business owner, or engineering. I’m saying the designer cannot abdicate the responsibility of thinking about impact. She has to understand the business goal, understand the behavior intended to be influenced, know what metric might change, question if the solution respects the user, and realize if the feature creates trust or just seeks conversion.
If she only comes in at the end, she’ll be treated as production. If she only speaks about interface, she’ll be evaluated as interface. If she never discusses impact, she shouldn’t expect to be seen as strategic. This is simple, but it is direct: if she wants to have more influence, she must take more responsibility.
Ask for the ball, but accept being held accountable for the result
There are designers who confuse collaboration with consensus. They collect feedback from everyone, try to accommodate every point, soften any tension, and avoid taking a clear position. In the end, the solution no longer offends anyone, but it also no longer defends anything. This is a silent way of abdicating leadership.
A strong designer listens but does not limit herself to adding up opinions. She synthesizes, chooses a direction, explains why, assumes the trade-offs, asks for trust, and accepts being held accountable if she is wrong. This is uncomfortable because it changes the designer’s position. She is no longer just the person who facilitates the conversation. She becomes someone who proposes direction.
She won’t be able to please everyone and do excellent work at the same time. At some point, she will have to defend a choice. Not for ego, but for clarity.
The designer of the future thinks in worlds, not just flows
For a long time, we were trained to think in journeys, flows, and screens. That continues to be necessary, but it is no longer sufficient. Products are becoming more distributed, more automated, more personalized, and more present in multiple contexts. Experience no longer lives only on a main screen. It lives in notifications, emails, dashboards, agents, configurations, system states, error messages, documentation, support, onboarding, retention, and invisible moments.
The designer needs to be able to create coherence between all these parts. It isn’t enough to design a functionality. It is necessary to understand the world in which that functionality lives: what language it uses, what promise it makes, what behavior it encourages, what trust it demands, what expectation it creates, what error it can provoke, what support it will need, what metrics can confirm if it works, and what parts of the system it touches.
The future will value designers who can build coherence in complex environments. Not just screens. Not just flows. Systems of meaning, behavior, interaction, and trust.
Where to invest energy now
If you’re trying to figure out where to invest energy, I’d be pragmatic. Don’t try to learn everything at once, but don’t hide behind your current specialty either. There are areas where your evolution will have a direct impact on your professional relevance.
– Problem formulation: before designing, write the problem better. Define the behavior you want to change, clarify constraints, expose premises, identify risks, and ask what evidence would demonstrate success. – Technical literacy: you don’t need to become a developer, but you need to understand states, data, components, APIs, performance, accessibility, responsiveness, and instrumentation. – Prototyping closer to reality: prototypes don’t just serve to impress stakeholders. They serve to learn earlier and reduce the cost of being wrong. – Communication of decisions: don’t just present screens. Present intent, alternatives, trade-offs, risks, and the necessary decision. – Evidence and judgment: use product data, research, support, sales, behavior, and qualitative feedback, but do not confuse data with thinking. – Systems thinking: before resolving locally, ask what other parts of the system will be affected. – Impact ownership: do not hide behind the process nor delegate strategy to product by default. Influence demands responsibility.
What is no longer enough
I’ll be direct. It’s no longer enough to be good at Figma, have good visual taste, know heuristics, do good handoffs, say you’re user-centric, have a pretty process, or ask for more context without also seeking context yourself. It’s also no longer enough to complain that design enters late if, when it enters early, it doesn’t bring strategic thinking to the table.
The profession is getting less tolerant of designers who only work when everything is well-framed. The real world rarely comes well-framed. And perhaps that is exactly where maturity becomes visible.
Excellent designers will continue to have craft, but they will also have more than craft. They will communicate intent, know the real pain of the problem, seek early contact with reality, question premises, think in systems, understand technology enough to design better, use AI to accelerate exploration, build prototypes that generate learning, participate in strategy without trying to occupy every role, and accept responsibility for impact.
What the future holds
The future will not be kind to passive designers. It will be less tolerant of those who wait for perfect requirements, complete context, ready research, closed decisions, and safe space to just execute. But it will be very interesting for designers who want to move up a level, not necessarily in the hierarchical sense, but in thinking.
Move up from the screen to the system. From output to impact. From execution to intent. From opinion to criteria. From handoff to real collaboration. From isolated aesthetics to trust. From the tool to judgment.
The change that is happening doesn’t eliminate design. It eliminates the illusion that designing screens well, by itself, will be enough. If you are a designer, this is the moment to be honest with yourself: what part of your value still depends too much on production? What part of your work could be accelerated by tools that already exist? What decisions can you influence today? What conversations do you avoid because you don’t feel prepared? What technical literacy do you still lack? What real contact with users are you delaying? What impact can you prove? What type of designer are you becoming?
The world isn’t going to slow down to give you time to protect the old version of the profession. And perhaps that isn’t bad news. Perhaps it’s exactly the push that the discipline needed.