back

Dark Patterns in UX

Designing with respect for users also means avoiding dark patterns. When does manipulation actually pay off?

Dark patterns are UX design tricks that intentionally mislead users. They’re effective, sure — but are they fair? And what do you do when marketing says, “We need more conversions, no matter what”? Exactly.

🔍 What Are Dark Patterns, Anyway?

Dark patterns are UI/UX elements that are deliberately crafted to nudge, trick, or push users into actions they probably wouldn’t take if given a truly neutral choice — like subscribing, buying something, or accepting all cookies with a single misclick. It looks like UX, but there's a bit of psychological bait in there.

💡 The Ones We All Know (and Hate)

• Roach Motel – easy to sign up, nearly impossible to unsubscribe
• Sneak into Basket – extra items added to your cart without consent
• Confirmshaming – buttons like “No, I don’t want a better life”
• Trick Questions – checkbox phrased to confuse you into opting in/out

💼 Why Do Companies Use Them?

Simple answer: they work. Dark patterns can lead to:

• higher conversion rates
• more newsletter signups
• longer user retention
• lower churn (though often artificially)

Some companies like Amazon, Booking, LinkedIn have practically mastered this. Want to cancel your Prime membership? Good luck finding that tiny gray text on the third page of the settings menu.

😬 When You... Kind of Have To

As a designer, you’re often caught in the middle. On one side: ethics, best practices, user respect. On the other: pressure from marketing, tight deadlines, and A/B tests showing that shady stuff works faster.

💬 Real-life example: “Can you make the ‘Accept All’ button look more clickable? People aren’t consenting enough.

Is it ethical? No.
Do you always have a choice? Not really.

In these cases, ask yourself:

• Can the user easily undo the action later?
• Can I design this in a way that’s less manipulative but still effective?
• Is there a persuasive alternative instead of a deceptive one?

⚖️ Ethics vs. Reality

Not every dark pattern is pure evil. Some live in the gray zone and can actually help — like reminding a user about an abandoned cart or encouraging a signup with a bit of FOMO (Fear of Missing Out).

But when you start to:

• hide costs
• obscure cancellation paths
• force data sharing
• play language games...

…you’re no longer designing for people — you’re designing against them.

🔨 How to Avoid (or Soften) Dark Patterns

• Test with real users – do they understand what they’re agreeing to?
• Build alternative versions – compare honest vs. shady
• Transparency matters – plain language, visible opt-outs
• Use team conscience – talk with devs, PMs, marketing

📚 Real-World Companies That Got Caught

• LinkedIn – automatic invites → class-action lawsuit
• Amazon – “unsubscribe maze” → investigated by the EU
• TikTok – misused children’s data → record fine (£12.7 million)

🚨 Legal Trouble is Coming

With GDPR, the Digital Services Act and FTC action dark patterns are no longer just shady — they’re becoming legally risky. Better to prepare your UX before a lawyer does.

🟢 So What Can We Do Instead?

Instead of manipulation – go for honest UX:

• clear choices
• solid copy without shame tactics
• thoughtful microinteractions

Good design still converts. It might take more effort — but it builds loyalty, trust and legal peace of mind.

✍️ In Summary

Dark patterns are like knives — you can slice bread or you can rob someone. Know them so you can:

1. Spot when they’re used against you
2. Understand why they’re tempting
3. Know when to walk away

In the end, it’s you, your conscience and a dashboard full of metrics.

back

Structure Breaking Ability

The ability to break patterns and create engaging structures can set an designer apart from someone who works more intuitively than intentionally.

1. It starts with structure 🧱

Before you break something — you need to understand what exactly you're breaking. In UI/UX, structure means:

• grid systems,
• visual hierarchy,
• typography,
• spacing and rhythm,
• layout behavior in responsiveness.

It’s like in architecture: before you design a building with tilted windows, you need to understand how the structure works. In design, structure is your static foundation — without it, everything falls apart.

2. Why It’s Sometimes Worth Going Beyond the Template 🧩

Many designers work on autopilot — a dashboard looks like a dashboard, a list like a list, a modal like a modal. But the user… has seen it all before.

Structure Breaking Ability is the skill of:

• deliberately breaking patterns,
• surprising the user with something fresh,
• while maintaining logic and usability.

Breaking structure doesn’t mean chaos. It’s a way to create something that is:

• rich, but not overwhelming,
• aesthetic, but not empty,
• unconventional, yet still readable.

3. Balance – Between Minimalism and Functionality ⚖️

A complex interface doesn’t have to feel heavy. A simple one doesn’t have to be boring.

What matters is to:

• reveal complexity only when it’s needed (e.g. progressive disclosure),
• avoid empty spaces that add no value (but don’t be afraid of breathing room),
• maintain hierarchy — so the eye knows where to start.

🔸 White space isn’t background – it’s a structural element of the layout.
Too little: chaos. Too much: emptiness.
🔸 Think of your interface like furniture in a room — it should feel spacious, yet functional.

4. The 60–30–10 Rule and Other Ways to Achieve Visual Balance 🎨️

Color is one of the most powerful tools for breaking patterns. But without control, it’s easy to go overboard.

🟢 60% – dominant color (e.g. background, main sections)
🟡 30% – supporting color (e.g. cards, secondary CTAs)
🔴 10% – accent color (e.g. buttons, alerts, interactions)

The 60–30–10 rule helps create both cohesion and contrast — without excess.

Breaking structure isn’t just about layout — it also means:

• variable spacing rhythm,
• unexpected transitions between sections,
• using color as a narrative tool.

5. Not Every Feature Needs Its Own Component 🔧

When designing a complex interface:

• don’t cram everything into the main view,
• use clear sections, priorities, and contextual layers (like tooltips, modals, popovers),
• don’t repeat the same components for similar functions — look for nuances and vary your solutions.

This is where breaking structure pays off the most.
The user feels the interface is alive, adaptive — not boring.

6. Break Patterns Wisely: When Not to Do It 🧠

Some areas require predictability:

• onboarding (when the user enters for the first time),
• transactional zones (e.g. payments, personal data),
• high-risk actions (e.g. deleting data, undoing operations).

In these cases, classic structure works best.
But even here, you can introduce micro-elements that add personality — like animation, icons, copy, or color.

7. Intuitiveness vs. Intentionality 💡

Many interfaces are created based on a "feeling" — they work, look okay and no one complains. But conscious design is something more:

• It’s asking yourself the question "Why this decision?"
• It’s building systems instead of random screens.
• It’s considering scalability because a good layout should “hold up” with more features, users and languages.

🔍 It’s not about every pixel being justified — but about every element being part of a bigger puzzle.

8. Microstructures and Micro-Breaks ⚡

You don’t have to break the entire layout right away. Sometimes it’s enough to:

• change the rhythm of the list (e.g., 2+1 instead of 3 in a row),
• use an unconventional card arrangement (e.g., overlap),
• add details like micro-animation, shadow, gradient, irregular padding,
• apply variable typography for emphasis: e.g., serif in the title, sans in the body text.

These little things break predictability without breaking usability rules.

9. Scale, Rhythm, Compression 📏

In large-scale products, this is one of the most important — and often overlooked — aspects of design.

Features need to be arranged in a way that maintains clarity and order, even within limited space. A dense layout works well where efficiency and quick access are key, while a more airy layout supports focus and gives the eyes room to rest.

Spatial hierarchy should guide the eye: from headings, through supporting information, down to actions.

This is where design stops being decoration — and becomes a tool for organizing complexity and supporting navigation.

10. Structure can be broken — because it bounces back 🪀

Good structures are like springs — you can stretch them, bend them, twist them… but they return to form.

That’s why breaking patterns is worth it. If your foundation is solid, the interface won’t fall apart.

💬 First learn the rules, then break them like an artist. – Pablo Picasso

back

[TOP 5] UI/UX Mistakes in Product Teams

In theory, everything works — then the user shows up and… yeah.

Designing a product that “has potential”, but somehow just doesn’t click? Users get confused, internal collaboration feels clunky and your interface looks like a Frankenstein of features?

Here are the top UI/UX traps product teams fall into — even experienced ones.

1. Late UX Involvement – “Make It Pretty at the End”

🧩 The problem: Designers are brought in only after features are scoped and business decisions made.
💣 The result: UX becomes surface-level. No user flow, no context, no strategy.
✅ Fix it: Include designers early — during discovery, ideation and priority setting
(design is not just about appearance – it's also about information architecture, flow and user needs).

2. Design in a Silo – "Not My Problem"

🔌 The problem: Lack of collaboration between designers, developers and PMs. Everyone does their own thing and the final product is a collection of inconsistent compromises.
⚠️ The result: Conflicts, delays, mismatched expectations, last-minute redesigns.
✅ Fix it:

• Regular design / dev reviews.
• Workshop sessions (e.g. Crazy 8s, collaborative user flow mapping).
• Establish a shared communication language (e.g. user stories instead of just "nice-looking screens").

3. No Testing = UX in the Dark

👀 The problem: UX decisions are based on team intuition ("I think it works") instead of research or user testing.
💀 The result: Low conversion, abandoned forms and support overwhelmed with questions.
✅ Fix it:

• Testing with just 5 users can uncover 85% of usability issues.
• You don’t need a big operation — a Figma prototype + 3 people from your target group is enough.
• Use tools like Hotjar, Maze, Lookback.

4. Feature Overload – because the Client Wanted Everything

📦 The problem: Trying to deliver as many features as possible at once — often "just in case."
🥴 The result: Overloaded interface, lack of focus, confusing navigation. The user doesn’t know where to start.
✅ Fix it:

• Prioritize based on user value.
• Design flows, not features.
• Try to follow the principle: “One primary action per screen.”

5. No Design System – UI Inconsistency Everywhere

🎨 The problem: No shared component library, consistent style rules or interaction patterns.
🧩 The result: Every screen looks different, elements behave inconsistently and the overall brand identity gets lost.
✅ Fix it:

• Even a basic design system (colors, typography, 5 core components) can bring order to the chaos.
• Use tools like Figma Libraries or Storybook.

BONUS: Ignoring Accessibility (a11y) – “Not Our Concern”

♿ The problem: Designing without considering the needs of people with disabilities — low contrast, small fonts, no keyboard support.
🚨 The result: User exclusion, legal risks, lower conversion rates and loss of trust.
✅ Fix it:

• Start with the basics: text contrast, font sizes and text alternatives.
• Use tools like Lighthouse and axe DevTools to test accessibility.
• Think of accessibility as making things easier for everyone, not just a "niche group."

back

Behind the Scenes of a Product Designer

It’s not just inspiration, but also trial and error. The real face of design.

When I tell people that I work as a Product Designer, I often hear: "Oh, so you're the one who makes all those pretty screens?" And while it's true that I spend a fair amount of time in Figma, aesthetics are just the tip of the iceberg. The real work starts much earlier and goes much deeper than just colors and grids.

On a daily basis, I'm involved in conversations, decisions, compromises and competing interests that aren’t always visible from the outside. That’s exactly what I want to talk about – what really happens behind the scenes of a product designer’s work.

🎨 UI vs. UX vs. Product Design

Many people wonder about the difference between UI and UX and how Product Design fits into the picture. Think of it like a car — UI is the body, color and cockpit design, UX is how smoothly and comfortably it drives and Product Design is the entire concept of the car — from the initial idea, through testing, to final implementation and support.

For me, a Product Designer is primarily a bridge between the user, the business and technology. Often, I have to act like a researcher, talking to customers and observing how they use the product. Other times, I work like a Project Manager, keeping track of deadlines and priorities. Sometimes I’m like a psychologist, trying to understand users’ motivations and emotions.

🧨 Trade-offs vs. Quality – When to Let Go, When to Fight for It

“Perfect is the enemy of done” — a saying I know all too well. At times, I have to accept that a product won’t be perfect at launch. But I also know that design debt is real — the small compromises that pile up over time and hurt the overall user experience.

I occasionally make small compromises in visual details or animations to ship faster. But I never compromise on what’s critical for the user — like accessibility or a clear, intuitive flow.

One example: I pushed back on removing a loading indicator that some saw as “just a spinner.” But to me, it was a key signal to the user that the system was working.

🧭 Decision-Making — How to Choose the Right Solution

I make decisions at the intersection of data, intuition, user insights and team input. Sometimes I have the full picture — solid research, analytics and test results — and everything aligns clearly. But just as often, I have to move forward with incomplete information and make confident choices despite the gaps.

In those cases, I rely on quick validation methods such as building prototypes, simplified versions of features (like clickable UIs without real functionality), or running quick internal tests. This helps me gather early feedback before committing to full implementation — and reduces the risk of designing in the dark.

🔍 Research that Matters – finding the What and the Why

Research is the foundation of a good project — without understanding users, it’s easy to design “in a vacuum.” I use both qualitative methods (interviews, observations, in-depth conversations, usability testing) and quantitative methods (surveys, data analysis, A/B testing).

When I run qualitative research, I usually prepare a scenario with questions and goals I want to check. But I don’t always stick to it rigidly — conversations often take an unexpected turn and that’s when the most interesting insights come up.

I treat quantitative research as a complement: it gives me numbers, trends and the scale of behaviors, which helps me see what’s really happening. I often combine both approaches — data shows the “what,” while talking to users helps uncover the “why.”

🕵️‍♂️ Competitor & UX Pattern Analysis – Inspiration vs. Copying

Before I start designing, I always run a competitive audit — a review of similar products and UX patterns.

It’s not about copying — it’s about learning what works and what doesn’t. Still, I sometimes see teams blindly following trends, even when they don’t fit their users.

UX patterns are a bit like road signs — they help users find their way, but only if they fit the context. In the wrong place, they can confuse or slow people down instead of helping them.

⚙️ System-Level Decisions – Designing like an Architect

Not every feature needs to be built from scratch. It’s tempting to create something “fresh” but when every element looks and behaves differently, users get confused — and the team wastes time.

That’s why I’m a strong believer in a systematic approach. It’s not just about having a UI kit in Figma — it’s about thinking in patterns. When I design a new modal, I ask: do we already have something similar? Can I extend what’s already in the system?

There was a time when someone created a custom profile card just because it “felt right.” The result? Three different card styles, poor scalability and frustrated users. Experiences like that are why I keep a close eye on the Design System — because design chaos costs more than it seems.

🧑‍🚀 Responsibility and Solitude – the Product Designer as a Leader

Being the only designer on a team isn’t rare. In those moments, I’ve had to take on a leadership role, even without the word “lead” in my title.

It’s about making decisions, keeping things consistent and setting standards the team can rely on. I often become the point of reference — the person others come to with questions about interactions, patterns or design principles. And when there’s no process or documentation yet, I create it. Sometimes I’m not just designing for users but for the team itself — building tools, guides and systems that help us work faster, more clearly and more cohesively.

Mentoring is part of that role too. I’ve had opportunities to support less experienced designers — showing how to approach research, how to communicate with stakeholders and how to stand by their ideas. Not from a place of authority but of partnership.

🧱 Behind the Scenes – sprints, chaos and ambiguity

The perfect project? It doesn’t exist. There’s always something missing: data, time or context. I work in sprints, so I often create iterative solutions. First a sketch, then a quick prototype, feedback, adjustments, testing and only then a high-fidelity design.

Everyday life also includes meetings, unclear briefs and last-minute priority changes. You have to learn to be flexible without being chaotic. To keep structure in your mind, even when everything around you feels like chaos.

🤝 Conversations with Stakeholders and Leadership

Leadership often views things through the lens of ROI, KPIs and the roadmap. Sometimes, they push for quick wins or changes that — from a user’s perspective — might feel unintuitive. In such cases, I try to explain the long-term consequences. Will the solution genuinely improve the user experience? Or does it just look good in a pitch deck?

In one project for a financial platform, I was redesigning a key dashboard. The existing version didn’t require scrolling (mostly) — everything was visible at once. Some long-time users strongly preferred it that way and resisted the idea of a scrollable layout, even though it's now the standard in the industry and used by financial competitors. They were simply used to the old structure. Instead of forcing the change, I gathered feedback, ran usability tests and demonstrated how the new design improves clarity, scalability, and mobile compatibility. Over time, we were able to shift the perception — not by dictating, but by showing the value of the new approach.

🧠 Collaboration with Analysts

For me, analysts are not just “data providers.” They’re partners in identifying patterns and understanding user behavior. Sometimes intuition suggests one thing, but the data tells a different story. That’s why before I redesign anything, I always check: where users click, where they get lost and when they drop off.

Analysts also help define key requirements — both technical (e.g. based on what we can pull from the existing system) and functional, related to the scope of the task or the definition of done (e.g. in Jira). Without their input, it’s easy to miss limitations or edge cases.

One of the more interesting cases involved a credit application form, where we noticed a sharp drop-off at a specific step. Users were abandoning the process when asked to upload a document — which as it turned out, was completely optional, but this wasn’t clearly communicated. After updating the copy and clearly indicating that the step could be skipped, the form completion rate increased by over 30%.

👨‍💻 Developers — partners, not just executors

Good communication with developers is fundamental. I always talk to them before diving into design details. I discuss the solution itself, propose ideas, and ask: Is this approach feasible? Can we build an MVP first and then expand?

While I strive to maintain good contact with every developer on the team, I work especially closely with frontend developers because they are the ones who “bring my designs to life.” As a designer, it’s important to me that the final result matches the design as closely as possible (ideally 1:1) because that way I can take responsibility for what I designed. If changes are made along the way without my involvement, the responsibility becomes unclear — and I want to avoid that.

I also have a background in Computer Science and at one point planned to become a frontend developer, which today greatly helps me communicate effectively with the technical team. I understand technical limitations, can anticipate what’s achievable within a given framework and often communicate in terms familiar to developers. Thanks to this, collaboration flows smoothly and in negotiations I’m often able to find solutions that benefit both UX (mostly😊) and implementation.

🧪 Testers and QA – the invisible heroes

QA specialists are often the last people to see the product before it goes live. I share scenarios, edge cases and explain why certain things work the way they do. As a result, testing becomes more focused and the feedback I receive is much more accurate.

Although I also test new releases myself across different test environments, I always encourage testers to look beyond the flow. I ask them to pay attention to how the UI scales, whether the interface matches the designs and to spot any visual inconsistencies. I might miss something — and that extra layer of attention is truly valuable before anything reaches the end user.

A QA tester once mentioned that the tools I shared — like the Dimensions browser extension (for checking spacing in the UI) and some tips for using the "Inspect Element" (F12) feature more effectively — really helped them catch small inconsistencies between the implementation and the design. They also said that seeing how much I cared about those “little details” on my end made them more motivated to be equally thorough — because it showed that I genuinely cared about the final quality.

🤹‍♂️ Product Manager and shared decision-making

I work very closely with the Product Manager — not just as a partner, but also because the PM often makes key decisions that have a real impact on the product’s direction. That’s why I make sure to stay involved and actively participate in discussions, so I can contribute my UX/UI perspective and influence those decisions as early as possible.

We talk about what’s most important, the dependencies and what can be released as an MVP. When the PM wants to push something out quickly, I check if it can be done without compromising UX. And when I want to refine something, the PM and I work together to find time for it within the sprint. It’s a daily balance that requires mutual understanding.

There have been times when we had to change the scope or approach — because something was too costly, for example. But it’s also happened the other way around: my prototype impressed the management so much that they fast-tracked its implementation.

📣 Product Marketing and Communication

Design doesn’t stop at the app. I work with the marketing team because they often shape how our product speaks to users — through messaging, emails, newsletters or the promoting website.

Sometimes we sit down together and break a message apart: What exactly do we want to say? Who are we talking to? In what tone? These conversations help me choose the right words in the UI, but also ensure consistency between what the users see on the promoting page and how the product communicates with them once they start using it.

I remember a situation where simply changing a headline on the website increased CTR by 30%. Another time, all it took was adjusting the illustration style to make the whole experience feel more cohesive and professional.

Newsletters and onboarding flows are great examples of where product and marketing meet directly. If a user sees a clear, friendly message on the site but then lands in a cold, overly formal onboarding — something feels off. I make sure the voice stays consistent, thoughtful and engaging from discovering the product to actively navigating through it.

Collaborating with marketing also gives me valuable insight into how customers think and talk about our product — and that’s essential for designing experiences that actually resonate.

🔄 Iteration as a Daily Practice

What I consider a final design today might become version 1.1 tomorrow — and that’s OK. Iteration isn’t a failure. It’s a natural part of a product’s life cycle.

After each release, I analyze data, gather feedback and observe how people actually use the feature. Sometimes, something that performed great in testing turns out to be less effective in the real world. When that happens, I go back and rethink the solution — without ego, with humility.

Once, I was designing a filtering system — after a month of usage, we realized most users didn’t understand the difference between “sort” and “filter.” We changed the interface and the copy. It worked. And that’s exactly why iteration isn’t about fixing mistakes — it’s part of the process.

The Beauty After the Build

What happens behind the scenes in my work is a daily balancing act between quality and time, empathy and business goals, vision and technical realities. But that’s exactly what I enjoy the most. Every successful implementation, every positive user feedback, every moment when the team starts to understand that design is not just about aesthetics — that’s what brings me the greatest satisfaction.

At the end of the day, design isn’t just what you see — it’s everything that happens before and after you see it.

back

AI vs Designer

How Artificial Intelligence helps (and sometimes gets in the way) in design.

AI is being talked about everywhere these days. Tools like DALL·E, MidJourney, Adobe Firefly or ChatGPT are increasingly making their way into designers' workflows. Suddenly, things that used to take hours of work in Figma or Illustrator can now be generated... with a single prompt.

For many, it sounded like a revolution. For others — a threat. I had my doubts at first too. But what’s the reality?

💣 1. The Fear Boom: Will AI Take Designers' Jobs?

In the media and various reports, experts have warned about the potential loss of creative roles. For example, Dario Amodei (CEO of Anthropic) predicted that 20–50% of office-based jobs could disappear within five years starting from 2025 (source).

The World Economic Forum identified graphic design as one of the 11 fastest-declining professions between 2025 and 2030. Superside also estimates that up to 41% of graphic designers may be at risk (source).
Across many workplaces, there was a strong sense that AI would revolutionize the job market — but will it really be in a destructive way?

🎯 2. The Fear Boom: Will AI Take Designers' Jobs?

After a few years of using AI in everyday work, we're starting to see the true picture. And it’s not as black and white as it may have seemed.

📉 Yes, some tasks are being automated. But...
📈 At the same time, AI helps us work faster, smarter — and often better.

An example? IBM shortened its campaign design process from two weeks... to just two days (source). The team still does the same work, only faster and with less stress.

What’s more, up to 83% of artists say they regularly use AI in their work (source). Research also shows that AI tends to complement rather than replace humans — enhancing efficiency while people remain in control of the creative direction.

✨ 3. What Does AI Actually Offer Designers?

👉 Faster prototyping and iteration – saving time and energy.
👉 Automation of routine tasks – format changes, cropping, multilingual versions.
👉 Inspiration – generating ideas and visual directions.
👉 Personalization and scaling – mass-producing visuals tailored to the audience.
👉 Greater accessibility – tools available to everyone, not just professionals.

🚫 4. But a Word of Caution — There Are Limitations

AI is a powerful tool, but still… it’s just a tool.

• It doesn’t feel emotions or understand cultural context.
• It won’t interpret a brief the way we do — as humans who know the client, the brand, the goal.
• There can be issues with copyright or strange artifacts in generated visuals.
• If someone relies too heavily on AI might start losing authenticity or even own creative skills.
• It can make mistakes, which is why content verification is essential.

That’s why it’s so important to treat AI as a support, not a replacement.

🔮 5. What Does the Future of Design Look Like?

More and more, we’re hearing that the future of design is about collaborating with AI, not fighting it.

🧠 Designers are becoming more like conductors than just “hands on the keyboard.” They can focus on refining ideas, overseeing projects and adding emotional and strategic value.
💡 Skills like creative and critical thinking, design ethics, tool literacy and the ability to write strong prompts are becoming increasingly important (source).
🚀 Design roles themselves are evolving — areas like UX, AI design and content curation are growing, not disappearing (source).

Now is a great time to grow, explore new digital possibilities and leave fear behind.

🧾 6. Summary

AI in design is not the end of creativity — it’s a new chapter.

✅ It helps you work faster.
✅ It simplifies routine tasks.
✅ It frees up more time for what really matters: concept, message, emotions.

But it doesn’t replace the human. Because you as a designer, illustrator, creator, know what works. You have the intuition, experience and sensibility that can’t be coded.

back

Design System Mania

How a design framework helps — and when it starts causing chaos.

A Design System is something that in the product world sounds like the holy grail. Everyone wants one, everyone talks about it, everyone showcases their component library on slides. But… it’s not always sunshine and rainbows. Sometimes what was meant to help can actually get in the way.

In this piece, I’d like to show both sides of the coin:
🟢 when a design system is a blessing
🔴 and when it can become a ball and chain

Why we all love Design Systems ❤️

Let’s be honest – a well-functioning Design System is pure gold.
There are plenty of benefits:

• Everything looks consistent (“you’re not embarrassed to send it to the client”).
• Developers don’t have to keep asking: “Is this the same button as that one?”
• Designers aren’t creating ten different versions of the same modal.
• New team members onboard faster – they have something solid to grab onto.
• Scaling the product doesn’t mean chaos.

But… sometimes it starts with chaos 😅

And here comes the other side: Design System Mania.

I once took part in a project where the Design System was the very first thing we built before even a single screen existed. It sounded great. Until after three weeks, the strategy, team and roadmap all changed… and it turned out that 90% of the components had to be thrown away or rewritten.

The result?

• Wasted time.
• A demotivated team.
• “Forced” components that didn’t fit the real product.

Myth: Design System from day one 🛑

I often hear: “We’re starting a new product – so let’s build the system first.”
But in many cases, that’s a mistake.

In the beginning, many things change: screens, flows, requirements, priorities. If we try to finalize the components too early, we will almost certainly have to redraw them again and again.

That’s why I support the approach:
🟡 First chaos – then system.
Let’s not be afraid to start with a rough draft. Chaos (small, in the early-stage) often sparks brainstorming sessions, leading to more informed and effective decisions.

A Design System makes sense when we already know:

• what repeats,
• what the real needs are,
• what works and what doesn’t,
• and what the approach to the product should be.

When’s the right time to start building the system? ⏰

Here are some signs that the time has come:
✅ You notice that certain elements start appearing repeatedly, often in very similar forms — meaning repetition is increasing.
✅ Developers begin creating their own unofficial versions of the same components because there isn’t a single, consistent version to use.
✅ Each screen has a slightly different look and behavior, which starts to bother the team.
✅ The development pace slows down because instead of using ready-made solutions, components have to be designed and implemented from scratch every time.

In one of my projects, we deliberately postponed building the Design System.
At the beginning, everything was changing — mockups, objectives, even the business model. Building the system then would have been a waste of time.
Only when we started repeating the same patterns and everyone was doing them “their own way” did a real need arise — that’s when we sat down and organized what was already working.
Thanks to that, the Design System became a solution to a problem, not an extra burden. And that’s when it worked best.

How to build a Design System smartly 🧠

In my opinion, the key is iterativeness.
Start with things that already work — don’t force it.

You can:

• Extract components from existing screens (and improve them as needed).
• Give them names, context, variants and introduce versioning that allows you to control changes and easily revert to previous versions.
• Write usage guidelines (directly where the Design System lives or in a dedicated place).
• Define ownership — who develops and who reviews.

And above all: close collaboration with the development team is crucial — especially when it comes to choosing and developing the framework or UI library that the Design System is based on. It’s important that everyone understands what we’re building on and what decisions we’re making, as this makes implementation and further development easier. A Design System is a joint effort, not a one-sided tool imposed from above.

How to stay sane 🧘

A Design System isn’t a religion. It doesn’t have to be perfect. It doesn’t have to be complete. It doesn’t need 500 components and a 100-page documentation.

💡 It’s better to have a small, living system than a massive, dead one.

I’ve seen Design Systems that looked impressive… but no one really used more than ⅓ of what they were capable of — or ones where 80% of the documentation was outdated after just three months.

To sum up:

• A Design System is a tool, not a goal.
• You don’t need to have one from day 1 — but it’s good to know when its absence starts to hurt.
• Build on what already works.
• Don’t be afraid of early-stage chaos — it’s often a necessary phase.
• The best systems grow with the product, not next to it.