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. On the market, on the company, on the maturity of the team. But above all it depends on the kind of designer each person is trying to keep being.
If your professional identity is tied to producing screens, organizing components in Figma and delivering well-drawn flows from requests that others defined, you are in a risk zone. That work still has value. It just isn’t enough to set you apart anymore, and in many contexts it no longer justifies the time or the cost it used to.
Design hasn’t lost importance. Products became more complex, more automated and harder to make understandable, and that made design more necessary. What changed is the bar. Companies no longer look for designers who turn requirements into interfaces. They look for people who help them figure out whether the requirements make sense, whether the problem was framed well and whether the trade-offs are acceptable.
This puts us in front of an uncomfortable shift. A designer who waits for the brief to start thinking arrives late. One who only joins after the decision has been made will be treated as production. And one who improves the look of a solution without questioning the premise underneath keeps doing useful work, but will hardly be seen as strategic. No new tool solves this. It is a question of posture.
The profession has changed, but many designers continue to protect an old version of the role
For a long time the path was clear. You learned UX, mastered prototyping tools, knew how to build flows, do some research, prepare the handoff and present solutions to stakeholders. That profile is still valid, but it stopped being a competitive advantage.
There isn’t a single cause. AI sped up the conversation, but it would be lazy to blame everything on it. There are tools that make production faster, teams that have to do more with less, companies that demand visible impact and development processes with no patience for long translation cycles between design and engineering. What comes out of this is a simple pressure: producing artifacts is no longer enough. You have to raise the quality of the decision.
Producing an artifact means answering a need that already comes framed. Raising the quality of the decision means joining the discussion earlier, clarifying the problem, making risks visible, putting alternatives on the table and helping the team choose a path with open eyes. The first role is useful. The second is much harder to replace.
That is why some profiles will lose ground: people who only produce visual variations, who always need someone to explain the problem, who take weeks to materialize a simple hypothesis, who deliver impeccable files and influence no decision. Many of them are good professionals. The value just moved somewhere else.
A well-designed screen for a bad idea is still a bad idea
Craft still matters. Hierarchy, accessibility, consistency and attention to detail are still marks of professionalism. The problem is that craft loses force when it serves the wrong decision.
A polished journey that solves the wrong problem is waste. An elegant flow that increases friction at the critical moment is bad design. An impeccable feature that breaks the trust of the people using it is a failure. An experienced designer knows this and doesn’t stop at improving the surface.
Many get stuck right there. They improve the form and don’t ask whether that data really has to be requested. They refine the dashboard and don’t ask whether that information helps anyone decide better. They polish the onboarding without discussing whether the product is asking for commitment too early. They design the requested solution without checking that the problem exists the way it was described. They work the artifact very well and arrive late to the decision.
The leap in maturity begins when you stop asking only “how can I make this better?” and start asking “should this exist in this form?”. There is nothing arrogant about that question. It is the difference between accepting the problem as it arrived and taking part in how it is framed.
If you only improve the answer, you accept the problem as it came. If you improve the question, you decide what is worth building.
Good designers show work. Very strong designers communicate intent
Many designers still present work as if the goal were to show effort. That is not the goal. The goal is to help the team think better. A good design presentation shouldn’t be a guided tour of the file. It should be a mechanism for alignment, decision and learning.
When you present work, some questions should be implicitly answered: what problem are we solving, why does this problem matter now, what behavior do we want to change, what constraints shaped the solution, which options were discarded, where risk still exists and what decision is needed at that moment. If the presentation doesn’t help clarify this, you are probably just dumping outputs on the room.
This means adjusting depth to whoever is in front of you. With leadership, weeks of work boil down to decisions, risks and impact. With engineering, you talk about states, dependencies and edge cases. With product, about behavior, adoption and metrics. With other designers, about the system, consistency and accessibility. Knowing how to do this is craft applied to thinking.
Real work is messier than the portfolio
Most of the portfolios I see tell the same story. The problem was clear, the process was exemplary, the team aligned, the solution appeared, the launch went well and the results were great. All coherent, all inevitable. Real work is rarely like that.
Real work has ambiguity, backtracking, misaligned stakeholders, incomplete data, tight deadlines and solutions that looked good and weren’t. Whoever lived it can talk about it with precision and without shame. If the story we tell comes out too linear, maybe we weren’t inside the problem. If we can’t say what was left out, maybe we didn’t influence the decision. If we can’t tell what we learned when we were wrong, maybe we just executed.
This should change how we build portfolios, run reviews and talk about careers. What matters is the quality of the thinking: what ambiguity you reduced, what hard decision you made, what signals made you change direction, what part of the result was really yours.
Maturity shows up less in how the story is dressed up and more in how precisely reality is explained.
Go to reality sooner
One of the biggest traps in design is falling in love too early with the version of the idea that lives in our heads. In the file everything is controllable: the flow fits, the components obey, the states are handled and the screens get prettier and prettier. An idea can look convincing visually long before it is conceptually right.
Then it touches reality and breaks. The user doesn’t understand. The client doesn’t trust. Engineering discovers a dependency nobody saw. Support points to a case nobody foresaw. The expected metric doesn’t move. None of this is serious. What’s serious is finding out late.
Strong designers look for that collision while the idea is still cheap to change. They show early, test early, prototype early, argue with engineering early. They don’t wait for the solution to look good to find out whether it’s wrong.
Beauty can wait. Truth can’t.
The traditional handoff is losing its central role
I’ve worked on the web for fifteen years and, for most of them, the ritual was always the same: understand the problem, design, prepare the file, document states, write notes and hand it to engineering. That model will keep existing. But it stopped being the main proof of a designer’s value. As tools bring the idea, the prototype and the implementation closer together, it is less and less acceptable for the person designing to stay far from the real behavior of the experience.
Not everyone has to be an engineer. You just need to understand enough not to design in a vacuum. You can never write production code and still know what states exist, what data comes in and goes out, what edge cases will show up, that an animation has a cost, that a component is more than a visual layer, that accessibility isn’t a note at the end and that performance is also experience. Today there are tools, AI included, that let you put together a prototype close to reality in an afternoon.
The less you understand about technology, the more you depend on other people’s translation. The more you understand, the more problems you anticipate and the better you negotiate trade-offs. A designer who knows how the experience behaves, and not just how it looks, is much harder to replace.
Thinking in systems is now the baseline
A few years ago, thinking in systems looked like something for senior designers or people working on platforms. Today almost everything we design lives inside a system. The product is a system, the design system is a system, and so are onboarding, pricing, notifications, support, metrics and the brand. A local decision rarely stays local.
You change a pattern and affect how people learn. You create a visual exception and weaken consistency. You fix friction in one flow and it shows up in another. You add an option and increase cognitive load. You simplify too much and hide a control someone needed.
And the experience no longer lives only on the main screen. It lives in notifications, emails, error messages, documentation, support, settings and in moments nobody designed on purpose. Designing a feature means thinking about the world it lives in: the language it uses, the promise it makes, the error it can cause, the support it will need.
If you think only about the screen, you see one part of the problem. If you think in systems, you see the consequences, and you see them before they become debt.
AI took away some of your excuses
The public discussion is stuck on the least useful question: “will AI replace designers?”. The question that matters is a different one: which parts of the work no longer justify so much time, cost or specialization?
Exploring variations got cheaper. Writing first drafts got faster. So did generating hypotheses, producing assets, putting together an initial prototype and researching references. With this, some excuses fall. You can no longer take weeks to reach a first hypothesis, or use production as your only proof of value.
Value shifts toward judgment, direction, taste, synthesis, ethics, the quality of the question and responsibility for impact. AI raises average output and, along the way, makes it much more visible who thinks well.
Ask for the ball and accept responsibility
A frequent mistake 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. It looks organized, and it is dangerous if designers accept the passive role that comes with it.
Designers don’t replace the PM or engineering, but they need to understand the business goal, the behavior they want to influence and the metric that can move. And they need to ask whether the feature creates trust or only chases conversion. Whoever joins only at the end is treated as production. Whoever only talks about interface is evaluated as interface. Whoever never discusses impact shouldn’t expect to be seen as strategic. More influence asks for more responsibility.
Some designers confuse collaboration with consensus. They gather feedback from everyone, accommodate every point, smooth over any tension and avoid taking a position. In the end the solution no longer offends anyone, but it doesn’t defend anything either.
A strong designer listens, synthesizes, picks a direction, explains why, owns the trade-offs and accepts responsibility if they are wrong. It’s uncomfortable, because you stop being only the person who facilitates the conversation and become the person who proposes a path. You can’t please everyone and do excellent work at the same time. At some point you will have to defend a choice. You do it for clarity.
What is no longer enough
It is no longer enough to be good at Figma, have good visual taste, know heuristics, do good handoffs or say you are user-centered. It is also no longer enough to complain that design comes in late if, when it comes in early, it doesn’t bring strategic thinking to the table.
The profession is less tolerant of people who only work when everything comes well framed. The real world rarely does.
Where to put your energy now
I would be pragmatic. You can’t learn everything at once, but it isn’t worth hiding behind your current specialty either. Five things with a direct return on your relevance:
- Framing problems. Before designing, write the problem down: the behavior you want to change, the constraints, the assumptions and the evidence that would show it worked.
- Technical literacy. States, data, APIs, performance, accessibility, instrumentation.
- Prototypes closer to reality. They help you learn earlier and make being wrong cheaper.
- Communicating decisions. The intent, the alternatives, the trade-offs, the risks and the decision that is still missing.
- Evidence and judgment. Product data, research, support, sales and qualitative feedback, without confusing data with thinking.
What the future holds
The future will be unkind to passive designers: the ones who wait for perfect requirements, full context, closed decisions and a safe space to just execute. And it will be very interesting for those who want to move up a level of thinking. Hierarchy is another conversation. From the screen to the system. From output to impact. From opinion to criteria. From handoff to real collaboration.
Design is still here. The illusion that drawing screens well is enough for everything is what is ending. If you are a designer, it is worth being honest with yourself. What part of your value still depends on producing screens? What decisions can you influence today? What conversation are you avoiding because you don’t feel ready? What impact can you prove?
The world isn’t going to slow down so you can protect the old version of the profession.