This was my first design challenge since December 2025.

Not because I hadn't been interviewing. Quite the opposite—I had submitted dozens of applications over the past few months. The reality is that companies are assigning design challenges less and less often. The market has become cautious. For years, candidates were sometimes asked to spend many unpaid hours working on projects where the line between evaluating skills and obtaining free work became blurred. As a result, many companies have abandoned take-home assignments altogether, replacing them with portfolio reviews and interviews.

So when I finally received a design challenge after several months, I approached it with some skepticism. I expected another exercise focused on designing a few screens. Instead, I discovered that someone wanted to evaluate not how well I could draw interfaces, but how I think.

The brief was simple: design a shared dashboard for two different user groups. Production managers and maintenance technicians. The same data. Completely different priorities.

There was no list of features to implement. No predefined user flow. No hidden "correct" answer. The assignment was simply to design a single solution for both user groups and explain why that solution made the most sense.

Suddenly, I wasn't designing a screen.

I was designing a decision-making process.

The first thing I did wasn't opening Figma.

It was asking questions.

Does a shared dashboard mean a single layout for everyone? Or can each user have a personalized view? Is the data refreshed in real time? Should I consider technical constraints, or should I treat this purely as a conceptual UX exercise?

I emailed the company with these questions—not because I didn't know how to design a dashboard. Quite the opposite. From the very beginning, I could already see three viable directions. I could use dynamic filters, tabs, or a personalized dashboard with saved user views. The challenge wasn't generating ideas. The challenge was recognizing that each decision would have different consequences for users, the product architecture, and the engineering team.

Their response was short.

"This kind of thinking is exactly what we are looking for."

At that moment, everything became clear.

The assignment wasn't about choosing between chips, tabs, or a dropdown menu.

It was about recognizing that every design decision is a trade-off.

Instead of jumping straight into wireframes, I explored three different concepts. I documented their advantages, limitations, and ultimately explained why I chose dynamic context filters positioned at the top of the dashboard.

Why this approach?

Because users don't need to open another menu and pause to decide which option to select. Every available perspective is immediately visible. They can switch context with a single click. At the same time, the solution leaves room for future evolution. If user research later shows that personalized layouts would provide additional value, they can be introduced without changing the overall interaction model.

This was also the moment when I revisited one of my previous projects.

A few months earlier, I had designed a dashboard for a platform supporting distributed QA teams. I reused a similar interaction pattern—not because I lacked creativity, but because I believe it's good design practice.

Designers often talk about UX research and benchmarking. I also rely on what I informally call technical research. I look for interaction patterns that have already proven successful in similar contexts. It makes conversations with engineers easier because everyone can refer to a concrete interaction model instead of discussing abstract ideas.

I'm not a software engineer, and I've never pretended to be one.

But over the years I've learned one important lesson:

The earlier designers collaborate with engineers, the better the product usually becomes.

There was one person I genuinely missed while working on this challenge.

An engineer.

If this had been a real product, I would have discussed the interaction model with engineering before making a final decision. I would have wanted to understand how the data is refreshed, how the architecture works, and what impact each solution would have on system performance.

Why?

Because User Experience doesn't end with the interface.

If a dashboard loads data too slowly, users experience that.

If personalization significantly increases architectural complexity and slows future product development, users eventually experience that too.

System responsiveness, fast access to relevant information, and the long-term maintainability of a solution are just as much a part of User Experience as button colors or widget placement.

This challenge reminded me of something else.

More and more often, I see job descriptions looking for someone who has designed exactly the same product, in exactly the same—or a very similar—domain. Ideally, someone who has already solved the identical problem before. I understand where this expectation comes from. Domain expertise can reduce onboarding time and lower perceived hiring risk. However, I'm not convinced it should always be the deciding factor. After all, I accepted a challenge involving an industrial machine dashboard, despite never having designed one before.

Designing digital products is fundamentally about understanding problems, asking the right questions, analyzing trade-offs, and making informed decisions. Domain knowledge is valuable, but it cannot replace a strong design process or a thoughtful way of thinking. Someone who has spent years conducting discovery, collaborating with business stakeholders and engineers, and justifying design decisions will often adapt to a new industry faster than someone who knows the domain but relies mainly on familiar patterns.

Perhaps that's exactly why I enjoyed this challenge so much.

It didn't evaluate what I had designed before.

It evaluated how I approach solving a problem.

And in my opinion, that's one of the best indicators of the kind of Product Designer someone will become after they're hired.