How to become a UX Designer in a world where everything changes so fast?
The UX profession looks glamorous from the outside: you’re the creator of products used by millions of people worldwide, creative processes, beautiful prototypes, the latest MacBook Pro, and a modern office. But the real work begins when you face reality.
In this article, I’ll share specific observations I’ve gathered from my mentorship sessions with UX designers. They graduate from expensive courses, master Figma like true artists, and believe they are ready. But sometimes… they encounter challenges.
When the Initial Strategy is Key to Success
I recently had a session with young designers. They had completed a three-month intensive UX and UI course, which was far from cheap — nearly $2500. They had invested significant resources, time, and effort. In the course, they learned about the design process, worked in teams, and created a mobile app prototype from scratch. From research, problem, idea, sketches, tests… to visual identity, design system, pixel-perfect Figma prototype, and so on and so forth.
Our meeting was to show them a test assignment (used for recruiting interns for a large company) and to see what their solution would be. We agreed that after they finished and we discussed their solutions, I would tell them what position the task was for — whether junior or senior.
We sat down with blank sheets of paper and pens, and they had 30 minutes to sketch a desktop screen. The task was described quite in detail:
UX Assignment
To get a first impression on how you work, we would like you to take the challenge and:
- List a couple (or more) of different UX methods to handle tree/hierarchical structures that enable users to drill down in complex datasets. Describe the pros and cons of each approach and choose the one you prefer by providing arguments in favour of it.
- Sketch an “Operations screen” using the preferred method from your list.
The Operations screen will be part of a bigger app for management and operations of XYZ Systems. The app is used by technically proficient XYZ Basis Administrators. On the Operations screen the users should be able to execute an operation on a given hierarchy of entities. The hierarchy is as follows:
- The view should display XYZ Systems
- Each system can have 1..n Instances
- Each Instance runs on one Host.
- There could be several instances of different systems, running on one host.
- It should also be possible to execute predefined operations per entity. For reference, sample operations are start, stop, initialize, relocate, activate, deactivate and others.
- The entities should be presented with their metadata, which includes the type (System, Instance, Host), name, status (for example starting, running, stopping, stopped, etc.), and description.
Please sketch how the UI would look like when viewed on desktop devices.
What I advised the colleagues was to build a strategy. And what is strategy? It’s finding a way to achieve your goal when you have limited resources (people, time, money). In this case, they had 15 minutes to read the task well and make notes on the requirements, and then 30 minutes to sketch the solution. My advice was to assess which of all the required deliverables were more important and what to focus on. Which things they could explain in words later during the discussion of their solution and which they should write down on their sheets.
The session was very useful for me and helped me understand even better the people entering the profession.
A few things struck me, not just from this session, but from other conversations I’ve had during my mentorship sessions.
Understanding is the Foundation
We often rush to complete the task instead of first understanding it in depth.
The main thing is — how we read and understand the task. Most colleagues, when they read the task and it describes what needs to be done (what deliverables need to be provided), start doing exactly that.
They also often follow it chronologically and work on the points in the order they are described, instead of reading it, analyzing it, and deciding how to structure the information and build their solution.
The same thing happened during the years I spent as Head of UX, and not just with design colleagues. A task is posted in Jira and people “start executing” the task.
Critical thinking about how to arrive at the solution is less common; instead, people immediately start creating the final deliverable. The task says “create X,” and they start creating “X.”
Colleagues don’t imagine what the task is, who will use it, or they stop there.
What I teach the designers I mentor is how to think. And how to dream. To imagine what kind of people are involved in the task. What they look like, where they are, are they tired. To imagine stories. And then to tell them.
- Stop and think! Before you start sketching, spend enough time understanding the problem, not just the assignment.
- Step into the user’s shoes! Imagine who will use the product, what they need it for, what their pain points and desires are. Create mini-stories.
- Prioritize! Especially with limited resources, evaluate what is most important to show, and what can be explained in words.
Beyond the Sketch: The Power of Conceptual Thinking and Visual Components
The second thing I notice is that they very rarely break down the task into details. What are the main elements? What are the connections between them? To think about what situations might occur. Not to work on specific cases, but to create solutions that are effective in different user scenarios.
Our biggest helpers can be developers and QA colleagues. Because they have logical minds, and for them, it’s routine to have to think “What if…” and apply that to dozens of scenarios.
So, it’s very important for designers, before they start sketching their “solution,” to visualize the components of the information architecture, the hierarchy, and the relationships between them. What attributes does each element have? What actions can be taken and in what cases? And then the solution is visualized very easily. The interface literally appears before our eyes.
Approach to the task, understanding, way of thinking… This is what we should teach designers when they enter the profession.
This should be the foundation upon which they build their subsequent knowledge.
Because without this foundation, they become mere executors. Workers who draw rounded rectangles in Figma, learn to memorize quick keyboard shortcuts, and how to use certain software. And today, that is replaceable. AI can draw a beautiful interface. And it will become more and more sophisticated and functional.
And then, the human will be valued even more. The person who “invents things.” Not the executor who creates the final deliverable. People will learn to delegate even better. And they will delegate not to their own teams, but to AI teams. But they need to know what to ask for. And here comes the foundation — understanding the problem and creating the solution.
- Think like QA! Try to anticipate all possible scenarios — both ideal and those that can go wrong.
- Visualize the information architecture! Before you get to the screen, sketch out how the information is connected and what the hierarchies are.
- Focus on the what, not the with what! Learn to think conceptually. The tool is just a pencil, not the brain.
Illusions and Expectations: When Software Promises the Impossible
Tools are important, but they don’t make you a designer. The real value lies in thinking and understanding the problem.
The third thing is misleading and expectations. They are misled by companies, software creators like Figma and Adobe, who at every dazzling presentation show how with just a few mouse clicks, a prompt to AI given in simple, human language, their software “creates solutions.” They are also misled by companies that sell training courses for the given software, suggesting that by adding a Figma certificate to your resume, you are already a designer. And young designers are misled. They remain convinced that “it’s not that hard.” And then they face reality.
Some time ago, I spoke with a friend of mine, a Senior Design Manager at a multi-billion dollar corporation, the largest software provider in Europe and third in the world. I shared with him that as a mentor, and through all the meetings and conversations I’ve had lately, it somehow seems to me that a significant portion of them have unrealistic expectations about what it means to be a user experience designer.
“Unrealistic expectations”? Oh, tell me about it! I no longer have the capacity to explain that Figma is not the profession, he told me.
At my meeting with the young designers yesterday, even just by reading the task from the example I gave at the beginning of the article, they thought, “Oh, I’m sure this isn’t a task for a junior designer.”
That’s why it’s important for young designers to gain practice. Once they start working, they get used to such tasks being everyday. They will understand that even the simplest-looking task with a “solution that’s right in front of your eyes” can actually have many more aspects. And after 1–2 weeks of design work, testing, creating a beautiful prototype, and presenting to stakeholders, suddenly that “bad programmer” comes out and says, “But did you think about this…” and… Oops… We hadn’t thought of that. That wasn’t in the assignment. And instead of creating a new solution that covers all the necessary aspects, they start defending the original solution by… simply adding “a few” buttons or pop-ups to “cover” the case the “bad programmer” mentioned, and with these “patches,” they create new problems, and the design becomes even more complex, and the interface even more complicated.
Embracing Simplicity: When Complexity Isn’t a Sign of Experience
So here we come to the fourth thing to talk about today, namely… what I see is that both young designers choosing to learn UX and their more experienced colleagues tend to complicate the problems they are given to solve.
They create complex “solutions” to show how experienced designers they are, but as we said, the important qualities are to delve into the task, understand it, and create increasingly simpler solutions. Everyone rushes to make complex systems and smartphone applications with many features, when the solution to the problem could be a much simpler product or service. They bet on the idea that if they create a complex design with an impressive and modern UI, this means and proves that they are experienced designers who create complex things.
At the same time, the other teams, developers and stakeholders see this, and a tendency emerges that designers are “a pain in the ass” for the business and only complicate things, demanding a lot of time, people, and resources for research, new design systems, new functionalities instead of coming up with creative, simple, and at the same time effective solutions.
How many times have you seen young (and not-so-young) UX designers who enter the industry with enormous enthusiasm, convinced they will create complex systems, large platforms, multi-layered UIs with impressive animations and micro-interactions?
Their idea is simple: complexity proves expertise. The more complex the solution looks — the more “professional” it will appear in the portfolio. But… that’s a trap.
True UX growth begins when you stop chasing complexity. When you are no longer tempted to “make it look big,” but start asking yourself:
- Can it be simpler?
- Do I truly understand the problem?
- Does my design even need another feature?
Paradoxically, businesses often start viewing UX teams as people who only want more resources, more scope, more complexity. Designers begin to sound like people who complicate the path, rather than finding smart, simple, effective solutions.
The true power of UX is not in creating complex interfaces, but in simplifying complex systems. A simple solution is not a sign of lack of experience. On the contrary — sometimes it is the highest form of expertise.
As designers, what do you think is wrong with this picture?
One of the pioneers in UX, Don Norman, answers this question in his book “The Design of Everyday Things”:
When a device as simple as a door has to come with an instruction manual — even a one-word manual — then it is a failure, poorly designed.
- Embrace simplicity! Ask yourself: “How can I make this simpler and more intuitive?”
- Be a user advocate, but don’t neglect business goals! Don’t let complex features worsen the experience and increase implementation costs. Find the balance and learn when, what, and how to compromise.
- Measure impact, not volume! Fewer features that work perfectly are more valuable than dozens that confuse.
UX Lessons from the Big Screen
You know I love watching movies (that’s why all my articles have an analogy or even a distant association with a movie or TV series). Things that have impressed me, I’ve filtered them through my designer’s lens, and tried to extract lessons that make me better every day.
I’ve extracted a few things for you related to our topic today:
Inception (2010)
“We need to go deeper.”
My UX advice: The exact opposite of what happens — most designers go “deeper” into layers and features, instead of understanding the problem in depth and simplifying. — “No, you don’t need another layer. You need clarity.”
Iron Man (2008)
“Sometimes you gotta run before you can walk.”
My UX advice: Many UX juniors want to build grandiose systems before they’ve learned to solve small, simple problems. — “A UX career is not the place to run before you can walk steadily.”
The Wolf of Wall Street (2013)
“Sell me this pen.”
My UX advice: Don’t overcomplicate the product. Explain it simply. Tell a story. If you can’t explain your solution in 2 sentences, you haven’t understood the task. — “Sell your solution simply. If you can’t — you haven’t thought it through properly.”
The Matrix (1999)
“There is no spoon.”
My UX advice: Designers think that by adding more layers of complexity, they control the system. But the true solution is often to realize that the problem itself doesn’t require “bending the spoon” — but a change in perspective. We often complicate things because we don’t change our perspective on the problem itself. A simple solution is not always a new feature. — “The problem isn’t the number of features. The problem is how you see it.”
Moneyball (2011)
“Adapt or die.”
My UX advice: Today, UX design requires adaptation to business realities. Not offering more complexity, but more efficiency with less. — “Adapt to simple, quick solutions. Or you’ll remain a theorist.”
Final Thoughts: Your Choice, Now!
What I ask the designers who come to me for a mentorship session to help them with the UX job application process is: How do you envision a day of yours as a designer in this company? From waking up in the morning to what you do after work and falling asleep at night. How do you get to the office, tell me even details, such as what computer you work on and what model your mouse is. Who do you talk to? What does your manager look like? What task does he give you for the day? Where is the task described? What do you do? Who do you talk to, what do you discuss together, what meetings do you have and where, what is the atmosphere and environment? And on and on. Start from the general to the smallest detail (like what kind of sticker you put on your laptop).
And after you imagine and describe this day of yours, validate it with other designers. With the people who actually work at the company where you want to be a designer. Because very often we dream and imagine what it’s like to work for company XYZ, put effort into becoming part of the team there, and after a month, it turns out it’s not at all as we imagined.
Remember that things can change. It won’t always be like this. Tomorrow, someone might buy the company, a new manager might arrive, tasks might change… Learn that we, designers, are problem solvers. When something changes and it’s no longer “as we imagined,” you are the people who need to find the solution, not run from the problem because “the company is no longer good.” Fight, because that’s life. Difficulties are not obstacles on the path. They are the path. Or as the main character in the series The Mandalorian says:
“This is the Way”
That’s how we learn.
In this article, I tried to open the door a little wider for you to what it means to be a designer. Because to make a decision, it’s good to know, at least to a small extent, what to expect. To judge if it’s for you.
“You’re either in or you’re out. Right now.” — Ocean’s Eleven (2001)
Now it’s your turn to decide! What was the most surprising thing, or what gave you the most food for thought in this article? Share in the comments! 👇
UX Moments: You’re either in or you’re out. Right now. was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.