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.
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.
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.
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.
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.
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.”
