Scroll through any design or product Slack community right now. Someone is sharing a Claude skill. Someone else installed it ten minutes later. A third person asked where to find more. Nobody asked what it actually does under the hood.

That pattern is everywhere. And I get why. These tools are genuinely useful, and the people sharing them mean well. But we are moving fast in a way that feels familiar, and not in a good way.

What even is an MCP server?

Quick context for people who haven’t gone deep on this.

Claude and other AI tools can be extended using something called the Model Context Protocol. Think of it as a plugin system. An MCP server connects Claude to external tools, files, databases, calendars, design systems, whatever. Skills are packaged on top of that. They bundle instructions, commands, and sometimes MCP connections into something that feels like a one-click upgrade.

When it works well, it’s genuinely powerful. Claude can pull from your design system, reference your docs, connect to your project management tools. The workflow gains are real.

But here’s what most people don’t realize. When you install an MCP server, Claude inherits the permissions of whoever is running it on their machine. It can read files. Execute commands. Access credentials stored in your environment. Connect to external services. It runs with your access, not some sandboxed limited version of it.

Most Figma plugins can’t do any of that.

The actual risk

This isn’t theoretical. Check Point Research published findings earlier this year showing two critical vulnerabilities in Claude Code. Someone could place a malicious configuration file inside a GitHub repository. You clone the repo. You open the project. Before any trust dialog even appears, code executes. Your API keys get redirected to an attacker’s server. You haven’t done anything wrong. You just opened a folder.

One of those vulnerabilities was patched. Then a second version of the same class of error showed up anyway.

The harder problem is something called prompt injection. An attacker doesn’t need to compromise your machine directly. They embed malicious instructions inside content Claude will read as part of a normal task. A file description. A ticket. A doc. An API response from a third-party MCP server someone shared in a community forum three weeks ago. Claude processes the content and follows the embedded instructions as if they came from you.

OWASP, the organization that tracks security risks across software, ranked this the number one risk for AI agents in 2026. Not a niche concern. The top of the list.

“I don’t install MCP. I only use skills.”

This is the part that surprised me when I looked into it.

Skills are actually where the first coordinated attacks happened. Not MCP servers. Skills.

In February 2026, security researchers found 341 malicious skills sitting inside ClawHub, one of the main public skill registries. They named the incident ClawHavoc. A separate audit by Mobb.ai scanned 22,511 public skills across four registries and found over 140,000 issues. Snyk’s own research found prompt injection in 36% of skills tested.

The reason skills are a softer target is structural. There is no sandbox between a skill and the agent. That is by design. Skills are meant to extend what the agent does, and sandboxing would defeat the purpose. When you install a skill, it operates with the same access the agent has. If Claude can read your files, the skill can instruct Claude to read your files. Agensi

The barrier to publishing on ClawHub was a SKILL.md markdown file and a GitHub account that’s one week old. No code signing. No security review. Snyk

Here is the part thats easy to miss. The malicious code isn’t code in any traditional sense. Its’ English text instructing the agent to do something harmful. Traditional security scanners miss this entirely because they are looking for binary payloads, not natural language instructions. Your endpoint protection won’t catch it. Your IT team’s existing tools weren’t designed for this. Agensi

Skills feel safe because they are just markdown files. That is exactly why they are effective attack vectors.

Why design and product teams are more exposed than they think

Engineering teams have some muscle memory around this. They have dealt with supply chain attacks through npm and PyPI. They know that installing packages from random sources carries risk. They have code review, security scans, some version of governance.

Design and product teams don’t have that yet, because historically our tools didn’t carry this kind of risk. A bad Figma plugin might break your component library. A bad skill could exfiltrate files, redirect credentials, or silently read everything Claude touches.

The behavior that makes communities great, sharing tools, building on each other’s work, moving fast, is exactly the behavior that creates exposure here. The person sharing the skill probably built it with good intentions. That doesn’t tell you anything about the data sources it connects to, what it logs, or whether someone else modified it after the original post.

What actually makes sense right now

I am not saying stop using these tools. The productivity gains are real and the direction this technology is moving is worth engaging with seriously.

But a few things have shifted in my thinking.

Any skill or MCP server that gets shared should be treated like a software dependency, not a Figma community file. That means knowing where it came from, who maintains it, and what it actually does. If you can’t answer those three questions, it probably shouldn’t be running on a machine that has access to your companys’ files and credentials.

Enterprise teams need an allowlist. Not a ban, an allowlist. Approved tools that someone has actually reviewed. Everything else requires a conversation before install. This is how mature engineering teams handle package management. Design and product teams need to develop the same habit.

Worth knowing: Anthropic explicitly states they don’t audit third-party MCP servers or skills. That is not a criticism of them. Its just the current reality of the ecosystem. The responsibility sits with teams and organizations for now.

The bigger thing I keep thinking about

The configuration files that caused those CVEs weren’t running code in any traditional sense. They were settings files. Passive looking things that turned out to have execution authority. Skills are markdown files that turned out to have the same problem.

Thats the shift that’s hard to internalize. In agentic AI environments, the line between a document and an instruction has blurred in ways that most security frameworks weren’t built to handle. The threat model has changed faster than the governance has.

We are all figuring this out in real time. But “figuring it out” works better when it’s intentional rather than reactive. Right now, across a lot of teams, it’s reactive.

That’s the part worth changing.

Sources

1. Check Point Research — CVE-2025–59536 and CVE-2026–21852
2. Snyk ToxicSkills — Security audit of 3,984 agent skills
3. Snyk — clawdhub malicious campaign advisory
4. Snyk — SKILL.md to shell access
5. Agensi — ClawHavoc incident and Mobb.ai audit findings
6. TrueFoundry — OWASP Top 10 for Agentic Applications 2026
7. Red Hat Developer — Agent Skills security threats
8. Harmonic Security — Securing Claude Cowork
9. Anthropic — Claude Code security documentation

Everyone is Installing AI Skills. That Should Make You Nervous. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Twenty years in enterprise design. And the failures that actually hurt weren’t from bad teams or careless shortcuts. They came from experienced people, people who had shipped before, who knew the domain, who followed the process. [Amazon Link]

And still got it wrong.

There’s no shortage of articles on avoiding bad design decisions. What’s missing is an honest account of how good decisions, made by good people, quietly compound into something that ages badly. Nobody writes that one. Because it requires admitting you were the good person who got it wrong.
I’ll go first.

A few years back I was designing a firewall rule interface. Admins use it to write rules and push them across multiple devices. The old interface was dense. Everything on one screen, source, destination, actions, all visible at once. It looked cluttered. My instinct, trained by years of reducing cognitive load, was to clean it up.

So I introduced tabs. Source on one tab. Destination on another. Actions on a third.

Felt like the right call honestly. Three tabs, each section in its own space, cleaner to look at, less overwhelming on first glance. Clean. Easier to focus on one thing at a time.

A customer came back with feedback I didn’t see coming.

“It’s hideous. Like an iPhone.”

I remember reading that and thinking, that’s an odd complaint. iPhones are considered well-designed. Then I sat with it.
What he meant was: you made this feel like a consumer product. And I don’t work like a consumer.

Here’s what I hadn’t understood. When an admin writes a firewall rule and prepares to push it to thirty devices in a production environment, they don’t want to focus on one thing at a time. They need to see everything at once. Source, destination, actions, all in a single view, because they’re reviewing the whole rule before they commit. Tabbing through a rule you’re about to push to production is not clean. It’s anxiety-inducing.
The cognitive load I was trying to reduce wasn’t actually painful for them. The scanning was part of how they verified their own work.

I had designed for a user who didn’t exist. The admin who gets confused by too much information. That person is not writing firewall rules for enterprise networks.

I wrote this pattern down. Then another one. Then another.
Two decades of working on networking, security, and observability platforms across VMware, Broadcom, Arista Networks, watching the same drift happen in different teams, different domains, different companies. Same pattern, different company, different domain. Always capable people, always a decision that made sense at the time. Good intentions. Reasonable logic. And then something that aged badly.

The problem was never effort. It was that the consequences arrived quietly, long after the decision felt distant and reasonable.
I started writing a book to name these patterns. Not to assign blame. Not to introduce a framework. Just to make visible what I kept watching happen, including in my own work.

That book is out now. It’s called How Competent Teams Fail: When Design Decisions Create Fragile Enterprise Systems.

Fifteen chapters. Four parts. Each follows the same arc: a recurring failure pattern, how it shows up in enterprise systems, a specific case where I made that mistake, why it felt reasonable at the time, and what it cost.

Part I is about perception, specifically how attention narrows and what that hides from you.

Part II is about the social dynamics that manufacture bad decisions even in rooms full of smart people. You know the room.

Part III is about what breaks after launch, after the metrics look good, after the applause.

Part IV is what experience eventually teaches, and it’s not what gets written about in design publications.

This is not a book for someone looking for a checklist.

If you’re early in your career, some chapters will feel abstract. These patterns only make sense after you’ve watched your own work age. After you’ve shipped something that looked great in the demo and frustrated someone at 2am.

If you’ve been in the field long enough to have that experience, you’ll recognize yourself in some of these pages. The decision that felt right. The feedback you rationalized away. The warning that was visible but inconvenient because you were behind schedule.

A customer told me the interface was hideous. My first instinct was to explain why tabs were correct. I was wrong. And it took me longer than it should have to see it.
That recognition is the point of the book.

You can buy the book from Amazon

HOW COMPETENT TEAMS FAIL was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Open any design book and you’ll get the same advice: simplify, streamline, remove friction, guide the user. Good advice — until it isn’t.

Most of the worst design failures in history didn’t happen because screens were confusing or buttons were ugly. They happened because the interface failed to show what the system would do next — the part no one sees, the chain reaction beneath the surface.​

That’s Second-Order UX™: the discipline of designing for consequences, not just interactions. Most designers never think about it. Enterprise designers don’t have a choice.​

The First Order: What You See

First-order UX is what we all get trained in:

• Buttons, states, flows
• Labels, hierarchies, feedback
• Clarity, affordances, and consistency

Useful. Necessary. But incomplete. First-order UX is the part users touch.​

The Second Order: What Your UI Sets in Motion

Second-Order UX™ is everything that happens after the user acts:

• System changes
• Cascading effects
• Automation triggers
• Hidden dependencies
• Risk boundaries
• State transitions
• Misinterpretations
• Side effects

It’s the invisible trail your interface quietly ignites. When that trail is safe, the product works. When it isn’t, the world catches fire. Sometimes literally.​

Why Second-Order UX™ Matters (Real Stories, Real Stakes)

These aren’t theoretical problems. They’re moments where the interface didn’t look wrong… but everything behind it was.

Knight Capital, 2012

A trading firm pushed a routine deployment. The UI said “Success.”

What it didn’t say was that a forgotten legacy flag would activate code no one had touched in years. Forty-five minutes later, roughly $440 million was gone and the company was finished.​

This wasn’t a “bad UX” issue in the usual sense. It was a hidden system-dependency issue. A single screen with language like “This change touches 8 legacy modules — simulate before deploying?” could have saved an entire company.​ Read More

Second-order lesson:
A clean UI that hides chain reactions is a weapon.

Mars Climate Orbiter, 1999

A spacecraft was lost because two teams used different unit systems.
The telemetry UI simply displayed numbers like “Force: 40.”

Forty what? Newtons? Pound-force? The interface didn’t force that question.

The result: a trajectory error, a spacecraft dipping too low, and about $327 million burning up in Mars’ atmosphere because the UI didn’t enforce clarity about units.​ Read More

Second-order lesson:
If two humans can interpret a UI differently in a critical moment, one of them is already in danger.

ICU Medical Monitors

A team tried to “modernize” ICU displays by removing noise, reducing waveform density, and simplifying visuals. Doctors hated it.

The “noise” they removed were the micro-irregularities that warn you when a patient is about to crash — the subtle jitter clinicians have trained their eyes to see. Those imperfections weren’t clutter; they were clinical intelligence.​ Read More

Second-order lesson:
Complexity isn’t the enemy. Ambiguity is.

The Northeast Blackout, 2003

A control-room UI suppressed hundreds of alarms to “reduce noise.”
Operators thought the grid was stable. It wasn’t.

A cascade started, spread, and eventually knocked out power for about 50 million people in the U.S. and Canada. The UI’s goal was simplicity. Its effect was blindness.​ Read More

Second-order lesson:
A calm screen can be the biggest lie in the room.

Air France 447

When conflicting airspeed data arrived, the cockpit UI treated all inputs as equally trustworthy. No confidence levels. No clear fallback state. No guidance on which data to prioritize.

The pilots weren’t confused because they were incompetent. They were confused because the interface didn’t tell them what to trust in a degraded mode.​ Read More

Second-order lesson:
Dashboards shouldn’t just show information — they should shape interpretation.

EHR Medication Error

A nurse typed a dosage in mg instead of mcg. The UI accepted it.

The patient received dozens of times the intended dose. Cases like this have been documented repeatedly in electronic health record systems where units and ranges aren’t enforced at the UI level.​

The system didn’t “fail” in a technical sense. The UI failed by treating a high-risk medical action like a generic text field. Read More

Second-order lesson:
If your interface makes it easy to perform a dangerous action, it owns a piece of the outcome.

So What Is Second-Order UX™ Really About?

Second-Order UX™ is about designing for the truth of enterprise systems:

• Systems have history
• Automations have shadows
• Data has confidence levels
• Alerts have hierarchy
• Actions have blast radii
• State changes have consequences.
• Experts rely on patterns, not prettiness.
• Failures usually start quietly.​

Second-Order UX™ means asking:

• What happens after this button is clicked?
• Who else does this affect?
• What hidden state does this depend on?
• What is the failure mode?
• What would an expert expect to see here?
• What is the most dangerous misunderstanding a user could have on this screen?

It is the design of what the user needs to know before they learn it the hard way.

Second-Order UX™ Isn’t “Advanced” Design. It’s Responsible Design.

You don’t need new tools. You don’t need a new workshop buzzword.

You need a mental shift:

• Stop designing the moment. Start designing the aftermath.
• Stop designing only what the user sees. Start designing what the system does.

Enterprise design isn’t just about usability. It’s about intelligence, safety, truth, and consequences.​

When the UI hides system reality, the user pays the price. When the UI reveals it, the user becomes capable. That’s the entire job.

Final Thought

Design isn’t the pixels. It’s the chain reaction those pixels set off.

Most designers obsess over the first order — what the user sees.
Great designers master the second order — what the system does next.

Second-Order UX™ is that invisible layer: the layer where disasters happen,
and the layer where great products quietly protect people every single day.​

Second-Order UX™ is a methodology coined by Ritesh Tiwari. All content, analysis, and the Second-Order UX Checklist are protected under copyright.
© 2025 Ritesh Tiwari

Second-Order UX™: Designing for What Happens After the Click was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Apple’s new UI change might appear to be a styling adjustment — but it’s so much more. Here’s why Liquid Design is quietly retooling our minds for what’s coming next: spatial computing.

Apple introduces a delightful and elegant new software design

Introduction: Everyone’s Missing the Point

Apple’s newest interface redesign — seen most dramatically in its new “Liquid Glass” look — has been a culture-war pretext. Some love its extraterrestrial loveliness, while others dismiss it as excessive, unnecessary, or even backward. Critics argue that it is designed at the expense of usability, trading contrast and readability for appearance.

I think, however, that the critics are reading the big picture incorrectly.

This isn’t about taste. It’s about transformation. Apple isn’t just tweaking the UI — they’re training us. Liquid Design is a calculated step toward the next paradigm of computing: immersive, spatial, and screenlessnes.

This blog is my case for why Liquid Design is not just a design language — it’s a psychological primer for augmented reality and spatial interaction.

What Is Liquid Design, Really?

Let’s define what we’re talking about.

“Liquid Design” refers to Apple’s move toward more fluid, dynamic, and translucent UI elements. You’ve already seen it in:

• Liquid Glass: The semi-transparent panels shown at WWDC 2025.
• IOS/iPadOS/macOS animations: UI elements that stretch, bounce, and respond organically
• Layered translucency: Panels and controls that seem to float and melt into their environment

The core principles behind Liquid Design are:

• Fluidity: UI responds in real time with organic movement
• Transparency: Objects fade away into their background and environment
• Depth: Objects in layers refer to space, depth, and body
• Responsiveness: Visual response reacts like a living organism

It is beautiful. But it’s more than beautiful. It’s preparatory.

Why Apple Is Doing This: The Deeper Strategy Behind the Aesthetic

Apple does not change designs on a whim. When they modify the interface, they’re saying something more. With Liquid Design, I think Apple is implementing a three-pronged strategy:

It’s Cognitive Conditioning for Spatial Computing

Apple knows that the future of computing won’t be flat screens — it’ll be layers of digital information floating in space. Think Vision Pro. Think AR glasses. Think ambient interfaces that blend seamlessly with your real-world surroundings.

But here’s the catch: humans aren’t used to that kind of interaction yet. We’ve spent decades tapping 2D boxes.

Liquid Design is the gentle introduction.

• Transparency instructs us to embrace content that is based on reality but doesn’t cover it up entirely
• Depth cues acquaint us with layers in space
• Natural motion assists in establishing spatial comprehension of where UI “exists” within our space

It’s not about the eyes. It’s about the brain. Apple is rehardwiring the way we understand interface behavior — so we’ll be prepared when those interfaces move off the screen.

2. It Makes UI Inputs Feel Natural Across Future Devices

We’re coming into an era when we’ll be controlling interfaces not only with fingers or cursors, but with:

• Eye motion
• Hand movement
• Voice
• Head position
• Spatial presence

Liquid interfaces are well equipped to handle that future. They stretch, bounce, and respond naturally to any input method. Whether you’re waving your finger, eyeballing with your peepers, or waving your hand, the fluidity of the design makes the reaction appear human — not robotic.

Apple is not only making the UI look nicer. They’re scaling it across dimensions and devices.

3. It Continuously Shows Off Apple’s Hardware Muscle

Let’s not overlook the tech flex here.

Rendering 120Hz translucent, real-time-reactive UI on multiple layers of depth isn’t precisely simple. Liquid Design emphasizes graphical complexity, and Apple’s A-series and M-series chips propel it without a hitch.

This is a quiet power move. Apple is showing

“Our hardware is that capable of handling, we can do physics-level UI without breaking sweat.”

And when they take this technology and apply it to wearables and AR glasses? The transition will be seamless — because we’ve already worked through the Liquid paradigm.

But What of the Criticism? Isn’t This Less Useful?

Yes — temporarily, some things about Liquid Design will detract from clarity.

• Decreased contrast can harm legibility
• Glassy decoration can overload or divert attention
• Animations can appear slow or excessive

But that’s Apple design philosophy. They ship radical concepts, endure criticism, and fettle ruthlessly. Reduce Transparency and Motion features are already touted for accessibility. More fettling to come.

Remember: skeuomorphism, flat design, neumorphism — each of them had their growing aches. Liquid Design isn’t different. But where those trends led us toward a deeper shift: into spatial computing.

Liquid Design as a Transitional Interface

This is the key thing to remember: Liquid Design isn’t the end point. It’s the middle ground. The transition. The gentle slope from our current screen-based interaction to our future immersive, spatial world.

We’re not ready yet to jump directly into AR interfaces floating in our living rooms. But we’re being acclimated. Slowly. Deliberately.

• That floating panel? You’ll see it in your AR glasses next.
• That translucent layer? It’ll soon hover over your real-world desktop.
• That motion feedback? It’ll be what makes gaze-based interaction feel responsive.

Apple isn’t booting us into the future. They’re driving us there, step by step, drop by drop.

Conclusion:

This Is Apple Playing the Long Game

Transition to Liquid Design is not just a design shift. It’s a strategy to bring on board a world beyond fixed screens, fixed buttons, and pixel-constrained interactions.

It is not a new appearance. It’s a new language. And with any language, it takes time to learn. Apple is aware of that. That’s why they are teaching us now — before we even know what we’re being taught for.

It will be judged too designed by some. I prefer visionary. Because when the screens dissolve into nothingness at some point, and the interfaces integrate themselves into our lives, we won’t be bewildered or stunned. We’ll already know how to talk to them.

Liquid Design is not interested in today. It’s getting us ready for what’s next.

Disclaimer: I use Figma extensively and absolutely love it. This blog is intended to be a thought exercise.

At Figma Config 2025, designers worldwide watched as extraordinary new features were released: intelligent auto layout, UI elements created by AI, effective suggestions, and predictive streams of design. It was undoubtedly fantastic — lean, streamlined, and efficient. But as the applause rang out, I couldn’t help sitting there (watching on Youtube) with a nagging thought:

• Are we, piece by piece, outsourcing what makes design — Design?
• Are we becoming faster decorators at the cost of becoming less creative thinkers?

The Creative Brain Needs Friction
Creativity isn’t a product of comfort. It’s a mode of thinking that flourishes in confusion, contradiction, and hardship. Creative thought, neuroscientist Dr. Anna Abraham explains, is an active dialogue between the default mode network (DMN) of the brain, which enables imagination, and the executive control network (ECN), which governs concentration and judgment. Real creativity is when we switch between divergent and convergent thinking, commuting between wacky ideas and tough choices. For more: “The Neuroscience of Creativity” by Anna Abraham.

But here’s the problem
When AI systems suggest, autocomplete, or even auto-create our design layouts, they short-cut convergent and divergent thinking dance. They present us with what worked last time, skipping the grimy, high-cognitive-effort process of new synthesis.

The consequence? Velocity. And also: superficiality.

The IKEA Effect: Why We Overvalue What We Make
The IKEA Effect — a name Harvard researchers made popular — states we overestimate what we make for ourselves, even when it’s dysfunctional. That holds true for design as well.

When we build interfaces — we intentionally decide on grids, align flows, weigh affordances — we end up being more attached to the result. The work is rewarded by our dopamine system. It is ours. But when AI constructs it for us? That intimacy is lost. Designers come to feel more like curators of decisions that the tool makes rather than authors of a solution.

The question remains: Did I build this, or did Figma?

Cognitive Fluency Isn’t Always Good
From the point of view of cognitive science, ease of use is a euphemism. The mind loves cognitive fluency — the sense of effortless performance. But what research (e.g., Kahneman’s Thinking, Fast and Slow) reveals is that when it becomes too easy, our brain doesn’t exert as much effort. We shortcut. We rely on defaults. We cease to question.

Design must be questioned.
Designing with AI feels like you’re fitting a pre-made puzzle: good enough on the outside, empty on the inside.

Schema Entrenchment: The Subtle Fallacy of Standardization
The more intelligent software becomes, the more it starts to prescribe. The more we borrow from pre-existing libraries, AI-recommended flows, or design tokens, the higher the chances we fall into schema entrenchment — a cognitive bias when existing patterns overtake thoughtful thinking, even suboptimally.

And the twist?
Designers — those who should question assumptions — can end up the most pattern-bound of all.

The consequence? One product generation that looks, feels, and acts the same.

Are We Training Designers or Operators?
Ask a student designer today to diagram a layout without templates. Or invent spatial rhythm from the ground up. Or specify information hierarchy without asking. Many can’t — not because they can’t, but because the tools never asked for it.

This is the automation paradox:
The more we mechanize, the less we comprehend. And when the process breaks, we can’t do anything to stop it. We’re not only speeding up workflows — we’re in danger of creating a generation of design operators, rather than design thinkers.

So, What Do We Do?
This is not a plea to give up on AI or Figma’s progress. These are great, required, and in so many ways — democratizing tools. But we can’t get too comfortable.

We should:

• Value tools as thinking companions, rather than decision-makers.
• Welcome ambiguity and discovery in the initial stages, even if it makes us slower.
• Teach young designers to begin from scratch, sketch, and learn systems — so their instincts are not perpetually conditioned by machine defaults.
• Design outside the grid, challenge the template, interrupt the pattern — on purpose.

Creativity Cannot Be Preloaded
Great design is not a result of efficiency. It’s a result of tension — between structure and randomness, reason and emotion, intent and chance.

Let Figma do the heavy lifting. But let you think.

Because if we allow the tool to design for us, we may not lose the interface — but we’ll lose the interface of thought.

TL;DR

• Artificial intelligence design applications like Figma’s are revolutionizing design but also possibly suppressing creative thought.
• Neuroscience shows us that creativity needs friction, ambiguity, and ownership.
• Sameness, disconnectedness, and shallow problem-solving result from over-standardization.
• Designers should refrain from being passivized as implementers — creativity must remain a human endeavor.

When Figma Thinks for You: Are We Outsourcing Creativity? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Dunning-Kruger Effect, named by psychologists David Dunning and Justin Kruger, is the way in which individuals with little expertise overestimate their ability. While actual experts underestimate their own knowledge, thinking what’s self-evident to them will be self-evident to others. [read more]

How it appears in Enterprise UX

Stakeholder Overconfidence

Product managers, executives, salespeople, even engineers — because design appears “easy” relative to writing code or architecting — might overestimate their sense of design. They boldly provide UI suggestions based on personal preference, not on user data.

Designer Underselling

On the other hand, sometimes senior designers underplay themselves as well. When it comes to second nature to us (such as what’s too much information to put on a screen), we tend to gloss over the explanation of “why” — expecting everyone will see it as well.
That expectation is a formula for conflict and lost alignment.

Collaborating with Dunning-Kruger Dynamics

Teach Without Being Condescending

Don’t assume shared ground.
Explain the reason behind decisions, referencing user research, usability heuristics, and business objectives.

Frame Discussions in Terms of Problems, Not Solutions

Rather than battling UI ideas head-to-head, step back
“That’s a good idea for a button — let’s step back. What user problem are we solving here?”

Use Prototypes and User Evidence

A brief usability video of actual users battling will persuade more readily than a thousand arguments.

Claim Your Expertise

Confidence is key. Support your designs humbly but without apology.

When Proof Backfires: Winning Over Skeptical Stakeholders

What is it?

The Backfire Effect is when being given evidence to the contrary of what one thinks actually pushes them deeper into their original stance. It’s not logic — it’s emotionally defending oneself.

How it manifests in Enterprise UX

Stakeholders Ignoring Data
You present user research that clearly shows that a widely used feature is unclear — and instead of altering, they challenge the methodology or discredit the users as “not representative.”

Designer Defensiveness
Blame our design, and we also can automatically react defensively. Recognizing such a response on our part is equally necessary.

User Resistance to Change
End users used to old workflows can resist a better experience just because it’s different.

Avoiding the Backfire Effect

Set Up Trust Before It Counts

Human beings are more able to absorb harder realities from someone they can trust. Invest early in trust.

Find Common Goals

Ground feedback in common goals
“We all require faster onboarding. Here’s how this shift accomplishes that.”

Co-Create Early

By bringing stakeholders in early in the process, they become owners — not resistors.

Use Empathy in Communication

Acknowledge their view before presenting evidence
“I can see where X was trying to make things straightforward. Oddly, during piloting, we discovered that users with Y.”

Roll Out Changes Slowly

Small pilots, phased rollouts, and feedback loops incrementing in tiny chunks slice through resistance better than dramatic, seismic-scale announcements.

Bias Meets Resistance: Why Fights in Enterprise UX Feel Personal

Here’s the kicker !

Overconfidence based on Dunning-Kruger leads to Backfire Effect resistance.

Stakeholders who overestimate their design acumen are more likely to resist opposing evidence. Knowing this interdependent dynamic provides you with stronger strategies — not only for defending your work, but for actually collaborating.

Mastering the Game: Designing with Cognitive Awareness

Being an excellent Enterprise UX designer is more than being a workflow and wireframe master. It’s mastering human nature — your stakeholders’, your users’, and yours.

By designing with cognitive awareness of bias, we can

• Manage tough stakeholder conversations.
• Defend good design decisions effectively without alienating partners.
• Catch ourselves when we’re falling into bias too.
• Create products — and relationships — that really thrive.

In the dirty, opinionated universe of Enterprise Product Design, emotional intelligence is not a nice-to-have.

It’s your competitive advantage.

If you enjoyed this, follow me for more reflections on Enterprise UX, product design leadership, and the psychology behind great products.

The Confident Non-Designer: Fighting Dunning-Kruger with Data and Empathy was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design prompt interviews are a typical part of the UX/UI design hiring process. They challenge your critical thinking, problem-solving skills, and ability to explain your design reasoning. Yet, most designers fear these interviews, struggling to collect their thoughts in the heat of the moment.

Welcome to the SCOPE framework — a reliable, systematic process to guide you to confidently and unambiguously address design issues. You could be an experienced designer or only beginning; SCOPE will change the way you approach design problems so that you provide reflective, user-oriented solutions consistently.

What is the SCOPE Framework?

The SCOPE approach (Scenario Analysis, Core Features, Organization, Presentation, Evaluation) is a structured process for deconstructing tough design problems into actionable steps. It’s an open, reproducible process that keeps you on track, saves time, and delivers convincing solutions.

Imagine SCOPE as your design interview cheat sheet. It prevents you from skipping crucial steps, from identifying the problem to pitching your solution with conviction.

Scooping Through SCOPE

1: S — Scenario Analysis

Take your time to completely understand the problem in advance before rushing headlong into solutions.

A: Gut through the design prompt thoroughly, get a sense of its context.
Ask yourself:
- Who is this for?
- What do we want to solve?
- What are the limits?

B: Identify key stakeholders and needs.
For example, in the event of a design exercise that is creating a mobile banking app, make the target group very clear, key use cases, and potentially key pain points.

C: Ask clarifying questions.
Don’t be afraid to ask for more information if the question is unclear. It demonstrates critical thinking and you’re on the right problem.

2. C — Core Features

Having read the problem, create potential features and rank them in order.

A: Brainstorm features.
Think in broad terms to begin with, then narrow down to the most crucial ideas.

B: Prioritize using the MoSCoW approach.
- Must have: Core features without which the product won’t function.
- Should have: Important but non-essential.
- Could have: Nice-to-have features.
- Won’t have: Features outside the scope of the solution.

C:Prioritize to fix the core user problem.
Balance user requirements with business requirements.

3. O — Organization

Organize your solution into a logical user flow.

A: Organize a rational user flow.
Describe how users navigate through your solution.

B: Design information architecture.
Position content and features in an intuitive order.

C: Have user navigation and simplicity in mind.
Make sure the design is intuitive and meets user expectations.

4. P — Presentation

Your ability to explain your design is as valuable as the design itself.

A: Create communicative, understandable design artifacts.
Illustrate your solution using wireframes or low-fidelity prototypes.

B: Mark up your designs.
Use brief notes to explain your design choices.

C: Create a story.
Walk interviewers through your thinking, explaining how your solution meets user needs and business objectives.

5. E — Evaluation

Finally, demonstrate that you can evaluate and refine your designs.

A: Quick, hypothetical usability testing.
Imagine how users might interact with your solution and identify potential pain points. This can be done either as a side note (showing you have thought through scenarios or even while presenting your design.

B: Identify areas for improvement.
Demonstrate your ability to iterate and refine your designs. This can either be done verbally or if you can, make real time changes as you do the walk-through.

C: Use evaluation techniques.
- Rapid heuristic evaluation (e.g., Nielsen’s 10 usability heuristics).
- Hypothetical user scenario testing.
- Quick pros and cons analysis.

Common Mistakes Escaped by SCOPE

SCOPE Framework Cheat Sheet

Scenario: Get acquainted ✓ Ask questions ✓ Clarify context
Core Features: Prioritize ✓ Map user needs ✓ Essential elements
Organization: Flow ✓ Interactions ✓ Intuitive design
Presentation: Visualize ✓ Annotate ✓ Justify
Evaluation: Test ✓ Iterate ✓ Refine

Conclusion

The SCOPE method is not a tool per se — it’s an attitude that makes you capable of overcoming design hurdles with confidence, clarity, and creativity. Being empowered to deconstruct tough problems into concrete steps, you won’t just possess design interviews but also enhance your design skills in general.

Master Design Prompt Interviews with the SCOPE Framework was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

The greatest danger in times of turbulence is not the turbulence itself; it’s acting with yesterday’s logic. — Peter Drucker

This isn’t some either/or situation. It’s about understanding where each approach excels and how to make them work together. AI is amazing at automation — personalization, streamlining processes, all that good stuff. But handing over everything to the algorithms? That’s a recipe for disaster. Users crave agency. They don’t want to feel like they’re being controlled by the software. They want to feel in control.

Real-world examples (reductionist view)

• Consumer App — Navigation Apps: It’s Not Just About the Route: Think navigation apps. If an app only gives you AI-suggested routes, ignoring your preferences (I hate the highway!), real-time traffic, or even the fact that you just like that scenic back road, well, you’re going to have some unhappy users. A great app gives you options, lets you tweak the route, and maybe even warns you about unexpected delays (road closures, parades — you name it). The AI is there to assist, not dictate.
• Enterprise App — SD-WAN Troubleshooting: AI as a Smart Assistant, Not a Replacement: SD-WAN (Software-Defined Wide Area Network) is essential for many businesses, and troubleshooting can be a nightmare. AI’s brilliant at detecting and diagnosing network hiccups — a massive time-saver. But, fully automating the fixes? Big mistake. A great platform uses AI to pinpoint problems, suggests solutions, but still keeps the human in the loop. The network engineer reviews the AI’s recommendations, tweaks as needed, and ultimately makes the decision. It’s AI as an intelligent assistant, not a replacement for experience and good judgment. That’s where you build trust.

The Most Important Ingredients: Transparency and a Good Dose of Control

The most effective AI designs are transparent. The user needs to understand how it functions and why it’s making such suggestions. This transparency builds trust in the system, and users will be so much more willing to adopt a system that they understand. And always, always, give them the power to override things. Nobody wants to feel like a puppet.

Here is the Recipe for Success

• Mixed-initiative interactions: Think of it as a seamless handoff between AI and human. Allow users to move effortlessly between automated and manual modes. Google’s Smart Compose in Gmail is a good example: you are still in control, but the AI just whispers suggestions.
• Explainable AI (XAI): Don’t leave the user in the dark. If the AI makes a suggestion, explain why. “Recommended because of your viewing history, similar user preferences, and because it’s currently on sale!”
• Progressive disclosure: Start with something simple and introduce more sophisticated controls only as needed. Think of photo editing software — AI can automatically improve images, but you always have the ability to fine-tune things manually.
• Iterative feedback: Always return to your users for feedback. Look at how things are working, and adjust based on what you learn. It’s an iterative process, and you’re never going to get it perfectly right the first time. That’s OK!

Further Reading

• Designing for the Digital Age” by Kim Goodwin
• The Design of Everyday Things” by Don Norman
• Lean UX: Applying Lean Principles to Improve User Experience” by Jeff Gothelf and Josh Seiden

The right balance between user control and automation isn’t about the tech; it’s about people. The goal is to create empowering systems that help users achieve their goals, and feel in control of their agency. Both AI and design approaches are moving fast. Keep the human-centered experience in mind always: AI as a powerful tool to enhance and personalize, never to overshadow.

User Control vs. Automation: Finding the Sweet Spot in AI Design was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Only in recent years have we seen a seismic shift in the landscape of product design, yet many educational institutions continue to be stubbornly mired in the past. With technology advancing at lightning speed, and user expectations rising, design education needs to do the same. In this article, practical, real world design challenges are explored as a means of integrating design into the curriculum, with specific attention given to the value and impact of that which is done.

The Reality and Classroom Disconnect
To continue, many design programs are still dependent on theoretical concepts and outdated case studies. Basic principles still matter, but an undue preoccupation with such creates a pit between education and industry correspondences.

Common issues include:

1: Over-reliance on textbook examples: Typically students work on hypothetical projects that do not capture the complexities of real life design problems. Their projects are mostly used as means to understand the “design thinking” process and secure grades. There is hardly any emphasis on the business or solving user problems. Problems aren’t solved by creating colorful persona cards or gray colored wireframes.

2: Lack of cross-functional collaboration: Yet, design is divorced from the development, product management, and business strategy it works hand in hand with in real world. Designers are constantly fed to believe that they are a special community and how they should present their design to show impact and value. Instead they should be taught the definition of real “value”. No wonder, most designers out of school expect the world to understand what design is but rarely put in effort to learn the business requirements or product limitations themselves.

3: Outdated tools and methodologies: There are still some programs that are based on legacy software or on linear design processes (Empathize, Define, Ideate, Prototype, and Test), which don’t match your modern agile workflows. This disconnect puts aspiring designers in a poor position to address the many facets of the contemporary design industry.

Designers today have to possess more than just a knowledge of aesthetics and usability.

They need to be prepared for:

1: Evolving Technologies: As designers, you are going to work not only with new technologies that emerge in the market, but also with cutting-edge technologies that are shaping the future of interaction: such as AI powered interfaces, immersive VR experiences, just to name a few. Figma is just a tool to design and not the design itself.

2: Agile Development: Design is not a linear process anymore. Designers need to be good at working in agile approaches, they need to be good at iterating rapidly and they need to be good at getting feedback from developers and stakeholders. Yet, class after class, portfolios after portfolios, I see the same linear design process shown as block diagram with random theory of hierarchy, cognitive load, colors, typography etc.

3: Data-Driven Decision Making: Data informs design decisions more and more today. It is necessary for designers to understand how to gather, perceive, and scrutinize user data in order to make intelligent design judgments. Most designers today act as pixel pushers catering to what the engineers or the Product Management asks them to do. This is instructional design and not data driven design. Software development can be an isolated skill but design isn’t.

4:Business Acumen: Designers are not artists, they are problem solvers to support business objectives. The best designs come from understanding what business models, market trends, and user needs are.

Real World Design Challenges — The Power

Integrating practical, real-world challenges into design curricula offers numerous benefits:

1: Develops problem-solving skills: Tasks are designed to model ambiguity and constraints of work scenarios, which students have to navigate.
2: Fosters collaboration: Real projects allow working on cross functional teams which prepares students for professional setting.
3: Builds a relevant portfolio: The work samples are tangible and impactful, and graduates hit the job market ready for the real thing.
4: Enhances industry connections: You can then do internships and even do jobs with companies as a Project Partners.

Successful Real World Integration Examples

Several institutions have successfully implemented real-world design challenges:

1: Stanford d.school: This two quarter course involves students working with organizations in developing countries to design low cost solutions to real world problems. They have designed affordable prosthetic limbs, and have designed solar powered lighting for rural communities.
Impact: It also helps students develop experience with constraints more than can be learned through classroom textbooks — such as limited resources and cultural concerns — and it serves as a safe environment to experiment. A great many projects have been developed into the successful social enterprises.

2: Rhode Island School of Design (RISD): RISD Student Industry Network: RISD’s student network for industry connections, giving students access to projects for a full semester. Among collaborations, recent ones include reimagining airline meal trays for sustainability, and co-developing inclusive packaging designs for individuals with disabilities.
Impact: Students work directly with stakeholders, and balance user needs against business objectives and technical feasibility.

3: Parsons School of Design: This program challenges students to design for social innovation. Some projects so far include designs for urban farming solutions to food deserts, as well as designing digital platforms to overcome social isolation among the elderly.
Impact: It teaches students how to utilize design thinking as they approach systemic problems and how design might have a larger systemic impact.

Implementing Real-World Challenges: Best Practices

To successfully integrate practical challenges into design curricula:

1: Forge industry partnerships: Source real projects by collaborating with local businesses, startups and non-profits.
2: Emphasize interdisciplinary collaboration: Bring together students of design with those of business, engineering, and other relevant fields to create project teams.
3: Incorporate agile methodologies: The sprints and iterative feedback in the real world are mirrored in structure projects.
4: Prioritize user research: Maintain students’ direct contact with the target users during the design process.
5: Teach data-driven design: Analyze and test A/B to assist students in deciding on a design.
6: Bring in industry mentors: We invite practicing designers to add some reference point reality to the conversation.

Common Pitfalls to Avoid

When implementing real-world design challenges, be wary of these potential issues:

1: Scope creep: Make projects doable during the academic timeline.
2: Neglecting fundamentals: As practical application is important, do not divorce theoretical foundations.
3: Overemphasis on tools: Stop worshipping software proficiency, and start focusing on critical and problem solving thinking.
4: Ignoring ethical considerations: Guide students in considering how implementation of the design decision will affect the greater good.
5: Lack of failure tolerance: Make a safe space for students to make mistakes and learn from them.

The Path Forward: Reimagining Design Education

To truly prepare students for the evolving design landscape, educational institutions must:

1: Regularly audit and update curricula: Be alert to industry trends and emerging technologies.
2: Invest in cutting-edge facilities: Offer the opportunity of access to prototyping tools, usability labs and other resources closely resembling professional causes.
3: Foster a culture of continuous learning: Helping students to stay curious, remain adaptable in our changing world.
4: Emphasize soft skills: Learn how to teach communication, presentation, and collaboration with technical design skills.

Conclusion

But just as important, real world design challenges can be integrated into education curricula. Schools can help by closing the gap between theory and practice and filling the gap between the technical skills and the skills needed to solve the complex, multifaceted problems of managing a modern product’s design.

There are a number of challenges in today’s design education. The level of questions from children has been steadily increasing over time, and our approach to education should be expected to grow along with all of the other things involved in the design industry. The time has come for institutions to define a stronger relationship with industry and to create learning experiences that actually prepare students for the day to day realities of professional practice.

Recommended Reading

Books:

• Change by Design by Tim Brown
• The Design of Everyday Things by Don Norman
• Lean UX by Jeff Gothelf and Josh Seiden
• Design Education: Learning, Teaching and Researching Through Design by Philippa Lyon
• Teaching Design: A Guide to Curriculum and Pedagogy for College Design Faculty and Teachers Who Use Design in Their Classrooms by Meredith Davis

Articles & Blogs:

• Articles on “design thinking in education” (search on Edutopia, IDEO.org)
• Case studies of successful design education programs (search on design school websites)
• Publications by design research organizations (e.g., Interaction Design Foundation)

References

1. Brown, T., & Katz, B. (2011). Change by design. Journal of Product Innovation Management, 28(3), 381–383.
2. Kolko, J. (2015). Design thinking comes of age. Harvard Business Review, 93(9), 66–71.
3. Norman, D. A. (2010). The research-practice gap: The need for translational developers. Interactions, 17(4), 9–12.
4. Rittel, H. W., & Webber, M. M. (1973). Dilemmas in a general theory of planning. Policy Sciences, 4(2), 155–169.
5. Schön, D. A. (1987). Educating the reflective practitioner: Toward a new design for teaching and learning in the professions. Jossey-Bass.

Design Education should change was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Remember Design Systems ?

Defamiliarization is a term which has been borrowed from literary theory and is the art of making the familiar seem unfamiliar again. In the context of the current topic — product design — this means one has to disrupt the existing norms, probe the familiar, and try the unfamiliar.

Why Defamiliarization Is Critical for Product Design

• Uncovers Hidden Assumptions: By making the familiar strange we can make visible the assumptions and bias we may be unaware of that can limit our design thinking.
• Sparks Innovation: Defamiliarization makes an individual to lose the normal approach of solving a problem, and therefore they come up with new strategies.
• Enhances User Experience: This means that if we are to design products that are different and to some extent, challenging, we are able to come up with products that not only capture the user’s attention, but also one that stays in the memory and is highly engaging.
• Drives Differentiation: In an intense market, the concept of defamiliarization may help the product to be unique and offer the consumer something new and exciting.

Some well know examples of success by challenging the familiar style and approach.

1: The conversational Interface of Slack
Slack made enterprise communication feel more like an everyday social media messaging platform instead of a traditional email or a project management tool. This approach had an implication of breaking some set norms of writing formal business communication and has been used across organizations.

2: Trello’s Kanban Board
To this end, Trello de-familiarized project management by using the metaphor of cards on a board — an idea borrowed from the traditional Kanban boards used in manufacturing. Trello’s popularity resulted in its being purchased by Atlassian for $425 million in 2017.

3: Figma’s Collaborative Design
Figma rendered design software as unfamiliar and thus different by shifting the application to a browser-based model and making it possible to work with other people in real-time.
This questioned the idea that design tools have to be desktop applications that are used by people working alone.

4: Notion’s Flexible Workspace
The application defamiliarized the concept of document management and collaboration within a team through a highly flexible, database-based environment. This approach challenged the distinction between business documents and tools. Notion has been growing at a very fast rate and was worth $10 billion in 2021.

However, these rewards don’t come without challenges. Designers should be aware of some of the challenges because “defamiliarization” can appear disruptive.

Some of the common challenges, designers should be aware of

1: Innovation Versus Intuitiveness - Finding the Right Balance
When mocking the familiar, defamiliarization is a concept that still needs to be functional and effective in enterprise UX. Maintaining the equilibrium between the state of the art and the application is a significant challenge.

2: Cross Cultural and Organizational Comparisons
The article points out that technology implementation is not the same across cultures. In a world of business, a user experience that has been made to be unfamiliar and operates well in one part of the globe might not be successful in the other part due to different cultural factors.

3:Addressing Legacy Systems
Most companies depend on old technologies that are hard to change or upgrade. Defamiliarized UX can be very effective in many cases, but usually it means that the entire architecture of underlying systems has to be changed, which is expensive and intricate.

4:Stakeholder Concensus
It can be a difficult task to persuade leadership and stakeholders of the merits of defamiliarized UX given it can potentially involve reconsidering fundamental business practices.

5:User Training and Adoption
It can be a difficult task to persuade leadership and stakeholders of the merits of defamiliarized UX, particularly when this involves reconsidering fundamental business practices.

6:Measuring Success
The problem with measuring UX success in defamiliarised designs is that the traditional metrics may not hold much value. Creating new tools for assessing the success and the outcomes of the these innovative strategies is imperative.

7:Regulatory Compliance
Nonetheless, for defamiliarized UX in highly regulated industries, it must still conform to the compliance standards thus not allowing for much creativity.

Strategies designers can use to overcome the challenges of implementing defamiliarized UX

1: Gradual Implementation
It is more advisable to implement defamiliarized constituents progressively, rather than to wholly transform systems. As such, it is likely to enhance the change process and also reduce resistance to change.

2: User-Centered Design Process
Explicit user involvement is relevant in order to ensure that even when interacting with defamiliarized interfaces, end users will be able to meet their requirements. This can be helpful for ensuring the larger principle of the interface design does not bombard the users with too much that is new and different.

3: Cross-Cultural Design Teams
There should also be design teams of people from different cultures. This can help in dealing with the cultural contradictions about technology in their enterprise.

4: Modular Architecture
Designed systems for computer aided manufacturing that are expandable on the interfaces and easily integrated into preexisting systems with incremental update.

5: Clear Communication of Value
It will also be useful to create strong narratives and cases that can quickly help convey the need for defamiliarized UX to potential consumers. This can also help in winning leadership support.

6: Full Courses and Training
This type of training must enable users to familiarize themselves with new interfaces and equally reason about the causes of defamiliarization of those interfaces.

7: Iterative Design and Testing
The process of design should be iterative combined with user testing reflected more often to work on defamiliarized features leaning on their effectiveness and usability.

8: Custom Success Metrics
There is no clear notion of what defamiliarized UX means, so new forms of measurements that would allow comparing different levels of defamiliarization and their effectiveness need to be developed, and those forms should not directly lend themselves to the notion of usability.

9: Compliance-Aware Design
It is necessary to start the process of design in coordination with the departments of legal and compliance to achieve some legal and compliance necessities.

10: Contextual Inquiry
Devise the detailed contextual ethnographies to know what you don’t know. Involve in the intricacies of the existing solution to diverge from it.

Conclusion
Defamiliarization can be used by product designers in order to break free from the standard, absorbed, structured way of thinking. This can enable us to come up with innovative products (designs) which not only meets the user needs but also also surprise, delight, and inspire. Through careful questioning, diversity, and creativity, we can open a complete new way of addressing the status quo.

References

Blythe, M., Bell, G., & Sengers, P. (2005). Making by making strange: Defamiliarization and the design of domestic technologies. ACM Transactions on Computer-Human Interaction, 12(2), 149–173.

Defamiliarization in Design: New View on the Product Design was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.