Some projects do not fail because the team is weak.

They fail because one person sells a fantasy, calls it “Agile,” and forces everyone else to pay the price.

We have all seen that meeting.

The scope is tight.
The deadline is unrealistic.
The client wants speed.
The team already knows something is wrong.

Then someone says it:

We can skip design. It is just a simple rebranding. We do not need Figma. We can design directly in the browser.

It sounds lean.

It sounds efficient.

It sounds like delivery confidence.

But most of the time, it is none of those things.

It is bad planning wearing an Agile costume.

Zero-design does not remove design work

Skipping design does not remove design decisions.

It only moves them to a more expensive place.

Instead of resolving structure, hierarchy, states, responsiveness, accessibility, content logic, and visual consistency before development, the team is expected to figure everything out while building.

That is not speed.

That is chaos with a project plan.

A developer should not be expected to guess the UI and still deliver clean production code.

QA should not be expected to test expectations that were never defined.

Designers should not be asked to repair experience decisions after implementation and pretend this was a normal process.

This is the zero-design fallacy:

The belief that if you remove design deliverables, you remove the need for design thinking.

You do not.

You just hide the work until it becomes rework.

The real problem is ego

This pattern is rarely about efficiency.

It is usually about ego.

Someone promised too much. Someone avoided a difficult conversation with the client. Someone did not want to admit the scope was unrealistic. Someone confused saying “yes” with leadership.

Then the team gets the bill.

This is not stakeholder management.

This is stakeholder (mis)management.

A strong PM or BA creates clarity. A weak one sells comfort to the client and pressure to the team.

And when the team pushes back, the language becomes painfully familiar.

🗣️ What gets said: “We should not overthink this. We need to stay lean and deliver value.”

🧠 What it often means: “Please stop exposing the gaps in the plan I already sold.”

🗣️ What gets said: “We can mitigate the risks during development.”

🧠 What it often means: “I did not manage the risk earlier, so now engineering, QA, and design need to absorb it.”

🗣️ What gets said: “We need to think outside the box.”

🧠 What it often means: “I need the team to compensate for a bad decision without calling it a bad decision.”

This is how corporate gaslighting enters product delivery.

Valid concerns are reframed as negativity.

Risk awareness becomes “overthinking.”

Professional standards become “slowing things down.”

And the people trying to protect the product are treated like the obstacle.

The private conversations tell the truth

The real project status is often not in Jira.

It is in the side messages after meetings.

“Does this make any sense to you?”
“We warned them about this.”
“I can build it, but I do not know what they actually want.”
“QA is going to explode.”
“This will come back to us.”
“This is not rebranding. This is a redesign without design.”

These conversations matter because they reveal what the official status report hides.

The project may look green in a weekly update.

Inside the team, it is already burning.

Technical debt is visible. Human debt is not.

When design is skipped, the visible damage is easy to name.

Broken UI consistency. Messy front-end logic. Endless rework. Unclear states. Long QA cycles. Stakeholder confusion. Developers rebuilding the same thing again and again.

But the more serious damage is human debt.

Human debt is the stress created when talented people are repeatedly placed in impossible situations and then judged for not making the impossible look smooth.

It is the developer blamed for an inconsistent UI they were forced to guess.

It is the designer who ignored early and called back later to “quickly fix the UX.”

It is the QA specialist expected to catch decisions nobody made.

It is the team lead trying to protect morale while knowing the delivery structure is broken.

Bad stakeholder management does not just damage projects.

It damages people.

One ego can cost more than ten good people

I later heard about a situation where this exact mindset reportedly damaged four consecutive projects.

Not one. Four, with this person.

The same pattern kept repeating:

Skip clarity.
Dismiss concerns.
Push ambiguity downstream.
Blame the team.
Move to the next project.

Eventually, the organization recognized the pattern and the person responsible was removed.

But by then, the cost had already been paid.

More than ten people had carried the stress, confusion, impossible expectations, and fallout of that management style.

Some left.
Some were pushed out.
Some burned out.
Some were labeled as the problem while trying to survive a broken system.

That is the brutal part.

Sometimes companies protect one fragile ego long enough to lose ten capable people.

And when that person finally leaves, leadership acts as if the issue is solved.

But the damage is already inside the culture.

Agile is not an excuse for poor planning

Agile does not mean skipping thinking.

Lean does not mean removing clarity.

Speed does not mean pretending complexity does not exist.

Good Agile teams make uncertainty visible. Bad Agile theater hides uncertainty behind confidence.

Good PMs and BAs protect clarity. Weak ones protect their own promises.

Good leadership says:

“We need to manage this properly before it becomes expensive.”

Weak leadership says:

“The team will figure it out.”

And yes, the team often does figure it out.

At a cost.

Usually with overtime. Usually with stress. Usually with rework. Usually with resentment. Sometimes with resignations.

Final thought

If your project depends on developers guessing visual requirements, QA absorbing unclear expectations, designers fixing decisions after implementation, and the team staying quiet to protect someone’s ego, you are not moving fast.

You are building debt.

Technical debt. Design debt. Human debt.

And human debt is the most expensive one because it does not stay inside one project.

It follows people.

It changes morale. It kills trust. It pushes good talent away.

The cost of design is visible.

The cost of skipping it is hidden until it becomes burnout, failed delivery, and cultural damage.

So before calling it “lean,” ask the harder question:

Are we removing unnecessary process?

Or are we removing the only thing that could have prevented the chaos?

Because sometimes the problem was never the design phase.

Sometimes the problem was the ego trying to remove it.

The “AI Doomsday” Illusion and Our Lost Professional Ethics

Every morning, we wake up to the same noise.

“AI is going to take our jobs.”

“Vibe coding is here, developers are doomed.”

“The tech industry is collapsing.”

But while everyone is busy doomscrolling, we are ignoring a much more tragicomic reality.

Everyone is applying to AI-generated job descriptions, using AI-tailored CVs, only to be filtered and rejected by another AI.

And somewhere in the middle of this absurd loop, real people are reduced to data points, automated rejection emails and “due to the high volume of applications” templates.

Maybe the real crisis is not AI.

Maybe the real crisis is the erosion of professional ethics.

I still remember something an Art Director of mine once wrote in his farewell message before leaving an agency:

“No matter what, if you don’t do your job properly, the person who has to clean up the rubble you leave behind is your coworker. The one you drink coffee and chat with during breaks. Even if you hate the company you work for, please have respect for your profession.”

That sentence stayed with me.

Because I have seen that rubble many times.

Half-baked designs. Unclear handovers. Spaghetti code justified with “it works for now.” Poor decisions passed downstream for someone else to fix later.

The worst part is that the person paying the price is often not the company.

It is your colleague.

The person sitting next to you. The person joining the same meetings. The person sharing the same pressure, deadlines and uncertainty.

The Bottom Line: Drop the Tool Fetishism

So yes, AI is changing the industry.

But AI is still a tool.

Just like Photoshop, Sketch, Figma, or any other tool we once thought would redefine everything.

The real question is not whether you use AI.

The real question is whether you use it with judgment, responsibility and respect for the people who will inherit your work.

Eventually, this era of noise and absurdity will calm down. The panic will fade, the titles will change, and we will be left with what has always mattered: Doing the actual work.

So maybe the question is not whether AI will take our jobs.

Maybe the better question is: Are we still doing our jobs properly?

The AI Doomsday Illusion and Our Lost Professional Ethics was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the Dune 3 trailer recently hitting the internet, it’s hard not to think about Frank Herbert’s universe, specifically the “Butlerian Jihad.” In the lore of Dune, humanity fought a massive crusade to destroy all artificial intelligence, establishing a strict commandment:

“Thou shalt not make a machine in the likeness of a human mind.”

Watching the design industry today, you can see a similar divide. Some designers seem ready to start their own Butlerian Jihad, dismissing AI entirely out of fear or pride. Others go the exact opposite route, treating it as a magic solution that will completely replace design thinking.

In reality, the most useful place for AI is somewhere in between.

Artificial intelligence is not replacing product designers. But it is quietly reshaping what senior-level UX and product thinking actually looks like. AI can support parts of the design process, but decisions, accountability, and product judgment still remain human responsibilities.

Think of it less as an autopilot and more as a junior research assistant. That is exactly how I use it.

A Real Example

While designing a multi-wallet fintech experience, I used AI to generate potential edge cases around transaction failures, currency switching, and regulatory messaging.

Instead of starting with a blank page, I prompted AI to simulate unusual user scenarios such as:

• failed transactions during currency conversion
• network drops between confirmation steps
• compliance messages triggered by international transfers

This helped surface several failure states much earlier than they would normally appear during QA or development.

The result was not a finished design.

But it accelerated the discovery phase significantly and helped me focus on the problems that actually mattered.

Killing the Blank Page Faster

The most dangerous phase of any project is the first hour.

The blank canvas.
The overthinking.
The paralysis.

AI can break that loop quickly.

Instead of staring at an empty board, I frame the problem clearly:

I’m designing a transaction history view for a fintech product.
Suggest ten potential user scenarios and edge cases.

Within seconds I get a list of possibilities.

Most of them are predictable.
A few are interesting.

That is exactly the point.

The goal is not to get perfect ideas.
The goal is to generate enough signal to start thinking critically.

AI accelerates the first draft.
Humans still own the progress of the design.

The Ruthless Edge Case Hunter

Designers are naturally optimistic.

We imagine the product working perfectly.

Reality is messier.

Users have empty balances.
Network connections fail.
Names overflow layouts.
Regulatory messages appear at the worst possible moments.

AI is surprisingly good at identifying these awkward situations.

After finishing an initial concept, I often prompt it like this:

Act as a fintech QA engineer.
Suggest scenarios where this payment flow could break.

The results usually highlight:

• zero-balance edge cases
• confirmation states that it might fail
• long account names breaking layouts
• unexpected system errors between steps

This is not creativity.

This is defensive design.

And defensive design is what often separates a polished product from a fragile one.

The Devil’s Advocate

One of the most dangerous biases in design is confirmation bias.

We fall in love with our own solutions.

Before presenting a concept to stakeholders, I run a quick pressure test.

I ask AI to critique the idea.

For example:

Act as a skeptical CTO.
Critique this design concept considering scalability, cost, and long-term maintenance.

Suddenly the idea is challenged.

Sometimes it highlights technical constraints.
Sometimes it questions performance or complexity.

Good!

That means I can walk into stakeholder conversations already prepared for resistance.

Documentation Without the Pain

Design documentation matters.

But most teams struggle to keep it clear and maintainable.

I often use AI as a translation layer between rough design thinking and structured documentation.

For example, instead of writing scattered notes like:

• modal closes on backdrop click
• animation 300ms ease-out
• CTA disabled until input valid

I ask AI to convert these into clear acceptance criteria.

The result is cleaner documentation and fewer misunderstandings between design and engineering.

Tone and Language Calibration

Working in international product teams means language is part of the product.

AI is extremely useful for tone calibration.

For example, I often prompt it to:

• rewrite microcopy to sound clearer
• simplify error messages
• remove overly technical language
• keep communication firm but polite

This ensures consistency across interfaces and documentation.

What AI Is Still Bad At

AI is powerful, but it consistently fails at three critical things.

1. Understanding context

It does not know internal politics, business history, or hidden constraints. Those realities shape design decisions more than any prompt ever will.

2. Making trade-offs

AI can generate options endlessly.
But product design is about choosing what to sacrifice.
That decision still belongs to humans.

3. Taking responsibility

When a design fails, AI is not in the room.
You are!
Designers who outsource thinking to AI do not become faster.
They become replaceable.

The Human Is Still the CEO

In the Dune universe, banning AI forced humans to train their minds to become supercomputers (the Mentats). We don’t need to ban AI, but we do need to train our product judgment just as rigorously.

AI accelerates thinking, but designers remain responsible for outcomes. Using AI well does not make you a lazier designer. It requires becoming a sharper one. You still need to:

• filter aggressively
• think critically
• synthesize across disciplines
• defend your decisions

AI can generate output. But accountability, intuition, and product judgment are not generated. They are developed through experience. And that responsibility still belongs to the designer.

P.S.
AI helped polish the grammar, :)
But the experience, the scars, and every decision behind this piece are entirely my own.

Walk without rhythm, and it won’t attract the algorithm.

How I Use AI as a Research Assistant in Product Design was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX onboarding is one of the most critical moments in any digital product. Whether it’s a SaaS platform, an e-commerce app, or a fintech application, users must decide within seconds whether they trust the product enough to continue.

Think about the last time you downloaded a new digital product.

A SaaS tool.
An e-commerce app.
A fintech platform.

Before you even understand what the product does, the first screen asks for:

• your email
• your phone number
• sometimes even your ID.

Your instinctive reaction? You pause…

You ask yourself one simple question: “Do I trust this app enough to give them my information?”

Most onboarding flows fail at this exact moment. After years of designing digital products, I’ve noticed something consistent: The biggest cause of onboarding drop-offs isn’t poor UI. It’s lack of trust. And trust is significantly harder to design than interfaces.

Recently, I explored this challenge while designing a multi-wallet fintech experience, focusing on how onboarding can gradually build user confidence rather than demanding immediate commitment. The lessons apply far beyond fintech.

The Real Problem: Psychological Friction

Most onboarding flows are designed like operational checklists.

• Create account
• Verify identity
• Add payment method
• Complete profile

From a business perspective, this makes sense. But from a user’s perspective, the product is asking for commitment before trust exists. That creates psychological friction. In the fintech space, this friction becomes even stronger because users are dealing with something deeply sensitive: their money.

During the exploration phase of this project, four key friction points appeared repeatedly in existing wallet experiences:

• Low comprehension of multi-wallet structures
• Limited sense of control during setup
• Lack of transparency around balances and actions
• Security and compliance concerns

Interestingly, none of these problems were purely visual. They were structural.

Designing Around the User’s Mental Model

One of the most important insights was understanding how people naturally organize their finances. Users rarely think about money as a single balance. Instead, they mentally divide it into categories:

• daily spending
• savings
• travel
• shared expenses

Many fintech apps ignore this behavior and present money as one aggregated number. The interface forces users to adapt to the system instead of the system adapting to users.

To address this mismatch, the concept introduced purpose-based wallets. Each wallet represents a clear financial intention, mirroring how people already think about money. Before designing screens, the system architecture was mapped around this mental model.

Strategy 1: Soft Onboarding

One of the most common onboarding mistakes in fintech is introducing heavy identity verification too early. From a regulatory perspective, this is understandable. From a UX perspective, it creates an immediate barrier. Users are asked to prove their identity before they even understand the product.

To reduce this friction, the concept introduces soft onboarding. Users can explore the interface and understand the product’s value before completing full verification. Certain actions remain restricted until verification is completed, but discovery is not blocked. This shifts verification from a roadblock to a logical step.

Strategy 2: Reducing Commitment Anxiety

Opening a financial account is psychologically different from creating a social media profile. Users are afraid of making irreversible mistakes. This often creates what I call commitment anxiety.

To reduce this effect, wallet creation was intentionally designed as a lightweight process. Three principles guided the flow:

• Progressive disclosure: Core information is collected first, while optional actions such as funding appear only when needed.
• Editable decisions: All configuration choices remain reversible, giving users a sense of control.
• Low cognitive load: The interface reduces unnecessary complexity during the initial setup

When users feel safe changing their decisions later, their trust in the system increases dramatically.

Strategy 3: Designing for System Scalability

Trust doesn’t end with onboarding. The system must remain understandable as users grow more advanced.

Once onboarded, users can create additional wallets through a simplified flow. To avoid clutter, the interface introduces a wallet switcher that acts as a central control point. Instead of repeating the onboarding flow for each wallet, users can quickly add new ones while maintaining a clear overview of their finances.

Behind the interface, a service design approach aligns user actions with backend processes and compliance requirements.

The Outcome: Where Compliance Meets Usability

The final concept focuses on three core principles:

• Clarity
• Control
• Trust

Together they create a system that is intuitive, transparent, and scalable. The key outcomes include:

• Reduced onboarding friction
• Improved sense of user control
• Stronger alignment between UX and regulatory requirements

When onboarding respects the user’s mental model and gradually builds confidence, compliance and usability stop competing. They start working together.

Final Thought

Designers often talk about usability, accessibility, and aesthetics. But trust sits underneath all of them.

When users trust a product, they explore it. When they explore it, they learn it. When they learn it, they adopt it.

And adoption is what ultimately turns design into a successful product.

If you’re interested in the system architecture, user flows, and service design artifacts behind this project, you can explore the full case study here!

The Biggest UX Flaw in Onboarding: Why Trust Is Harder to Design Than UI was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the world of User Experience (UX), we often obsess over pixels, wireframes, or conversion rates. But at the end of the day, there is only one invisible metric that truly determines a product’s longevity: Trust.

The moment a user doubts the intent behind an interface, the churn process begins. This is exactly why Transparency and Trust are not just ethical requirements for Product Designers; they are the most potent growth strategies we have.

Why You Should Never Be HAL 9000

Remember Arthur C. Clarke and Stanley Kubrick’s masterpiece, 2001: A Space Odyssey? The film’s iconic AI, HAL 9000, was arguably one of the most advanced “user interfaces” in cinema history. His voice was calm, his answers were precise, and he knew everything.

However, the crisis between astronaut Dave Bowman and HAL is the ultimate example of catastrophic UX. The problem wasn’t just that HAL turned “evil”; the problem was that his transparency dropped to zero.

When HAL lied about the antenna malfunction and subsequently refused Dave’s command (“Open the pod bay doors”), the trust contract between the User (Dave) and the System (HAL) was shattered.

The Lesson: When a user cannot understand why a system is behaving a certain way (The Black Box problem), no matter how smart the system is, the user will eventually pull the plug.

Transparency Is Not a Luxury

In product design, transparency goes far beyond Jakob Nielsen’s heuristic of “Visibility of System Status.” Modern users have highly sensitive radars; they can smell “Dark Patterns” from a mile away.

Here is how you should integrate transparency into your design architecture:

1. Algorithmic Clarity: When Spotify or Netflix recommends something, they often say, “Because you listened to X.” This cracks the black box open slightly. Answer the user’s silent question: “Why are you showing me this?”
2. Honesty in Error States: Saying “An error occurred” is lazy. Saying “Our servers are currently overloaded, but your data is safe; please try again in 2 minutes” builds confidence.
3. Subscription & Cancellation Flows: Opening the front door wide (Easy Sign-up) but turning the exit into a maze (Hard Cancellation) might boost short-term metrics, but it kills long-term brand reputation. Avoid the “Roach Motel” tactic.

Trust: The Emotion Beyond the Data

When users share their data (location, credit card, photos) with a product, they are implicitly saying: “I trust you; don’t let me down.”

To protect this trust as a Product Designer:

• Contextual Permissions: Why does a flashlight app need access to my contacts? It doesn’t. Ask for permissions only when the user is performing an action that requires them (Contextual Permission).
• Amplify the Fine Print: Don’t hide potential downsides (extra fees, data sharing) in footnotes. Brave brands build loyalty by being upfront about the trade-offs.

Let Dave Open the Doors

The products of the future will not be those that manipulate users, but those that empower them. If your users feel like they are floating in a void, unable to predict what the system will do next, your design has failed.

When making design decisions, ask yourself:
“Am I designing this flow to be mysterious and manipulative like HAL 9000, or transparent and supportive like Iron Man’s J.A.R.V.I.S.?”

Here’s to not getting unplugged.

Although J.A.R.V.I.S. is a great benchmark, as a massive Batman fan, I have to pick my side: Neither HAL nor J.A.R.V.I.S… Long live Alfred Pennyworth. Now that is the ultimate User Experience.

Designing for Trust: Escaping the Black Box in the Age of AI was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Great Wall of Silence: Why Real Product Teams Build Bridges, Not Barriers

Pink Floyd said it best: “Just another brick in the wall.”
In many product teams, that is exactly what handoff has become.

A file is dropped. Silence.
A link is shared. No context.
A bug is filed. Finger-pointing begins.

This is not collaboration. It is a construction.
But it is a wall you never wanted.

After 14 years spanning fintech, enterprise tools, and agency work, I learned one truth.

Teams fail when they treat handoff as the designer’s finish line.

Handoff is not the end.

It is the moment where both sides must keep running.

If you stop, the product falls.
The dev falls.
You fall.
The user pays for it.

Treat Your Developer as Your First User

Developers are not “pixel printers.” They use your work before any customer does. They rely on your logic, your components, and your constraints. If your design is unclear or technically naive, the real user will never see a high-quality product.

The senior mindset is simple.
Do not design for Dribbble.
Design for the DOM.

Before pushing a single pixel, ask the right questions.

Is this animation heavy on older Android devices?

Do we already have a component for this logic?

Is this layout stable when real data hits it?

When I redesigned complex workflows for fintech and reduced drop-offs by 30 percent, it never happened because of a pretty UI. It happened because developers were involved early, not after everything was “polished.”

This is not limiting creativity.
This is designed for reality.

The Happy Path Is a Myth

Real Products Live in Edge Cases

Open a junior designer’s file. You will see a perfect world.
Stable internet. Perfect data. Perfect timing.

Open a senior designer’s file. You will see what actually happens.

Error states.
Loading states.
Empty dashboards.
Long names that destroy your layout.
APIs that freeze at the worst moment.

In fintech, there is no happy path.
There are only paths that hurt less.

When I built onboarding flows that cut drop-off by 30 percent, the improvement had nothing to do with colors or typography. It came from designing every state the developer would otherwise have to guess at 2 AM while trying to make the build work.

If you leave gaps, developers fill them.
Not because they want to, but because they must.
And that is when UX dies.

Documentation is a Love Letter

“It’s in Figma” is the root of half the problems in product teams.

Figma shows what the screen looks like.
Documentation explains how it behaves and why it matters.

During the years I led a design system used across more than 15 projects, one thing became obvious. A system is only as strong as its documentation. Without clear definitions, teams reinvent your components in slightly wrong ways, and everything collapses over time.

Real documentation contains:

Behavior rules
When the user scrolls 100px, the header shrinks and the shadow fades in at 20 percent.

Logic rules
Guest users never see this CTA. Admins see a secondary action.

Accessibility rules
This headline uses H1 semantics. Focus states must meet contrast requirements.

If you think writing this is not your job, you misunderstand the job.
Your work does not end at creating pictures.
Your work ends when the product behaves as intended.

The “Hot Potato” Method

Stop the Big Reveal Culture

The classic waterfall (Design → Handoff → Development → QA) only builds resentment. Designers feel ignored. Developers feel unsupported. Everyone feels stuck.

The better way is simple. Pass the work back and forth continuously.

Day 1
Rough sketch. Show the dev. Ask if the structure makes sense.

Day 3
High fidelity draft. Ask if the animation is feasible and which library supports it.

Day 10
Sit together during development. Adjust spacing directly in the coded build.

This removes the “big reveal” and the “big disappointment.”
You land the plane together.

This is how we accelerated delivery speed by 65 percent across large fintech systems. Not by designing faster. By collaborating earlier.

Great design is not a file. It is a conversation.

Design QA: Your Job Is Not Done Until It Ships

One of the most damaging assumptions in product design is that the designer’s job ends once code starts. The truth is the opposite. Design QA is where the product becomes real.

This is not pixel-policing. It is refinement.

Many times I saw a design that looked perfect in Figma but felt wrong in the browser. Animation too slow. Tap target too small. Line height off on non-retina screens.

A senior designer adapts.
You change the design based on how it behaves, not how it looked in your file.

This is the difference between design theory and product reality.

Tear Down the Wall

If you constantly say, “developers ruined my design,” it might be time to stop and reflect.

Maybe the wall was built by silence.
Maybe the wall was built by assumptions.
Maybe the wall was built by handoffs treated as endings.

Great products come from designers and developers who understand each other’s world.

Not rockstars and code monkeys.
Not silos.
Not walls.

Your screens live in Figma.
Your product lives in code.
You should care about both.

The product is real. The wall is optional.

Don’t Just Be Another Brick in the Wall was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

A while ago, I took the course “Service Design: How to Design and Deliver Great Experiences” by Thomas A. Stewart and Patricia O’Connell.

It reshaped the way I think about user experience, not as a set of screens or touchpoints, but as a living system of promises and expectations.

One framework in particular stuck with me: the difference between Ah Moments and Ow Moments.

It perfectly captured something I had been observing for years in my own projects but never had the words for.

We often say the goal of design is to “surprise and delight.”

But the truth is, surprise is unreliable. Delight fades.

What truly matters is predictable trust, the kind that turns every customer interaction into an Ah Moment.

The “Surprise and Delight” Trap

For the last decade, the design world has been obsessed with a single mantra: “Surprise and Delight.” We’ve been taught that the goal is to create unexpected, magical moments: a free cookie, a quirky animation, a confetti burst.

I get the appeal.

It’s fun.

It’s flashy.

But it’s also a shallow and unreliable strategy.

Why? Because “delight” is a sugar high. It’s fleeting. The real currency of any service, especially in a world of endless choice, isn’t delight. It’s Trust.

In my recent studies on Service Design, I learned a framework that fundamentally shifted my perspective. It’s the difference between “Ah Moments” and “Ow Moments.” And understanding this difference is the secret to building products that don’t just win a click, but win a customer for life.

The “Ah Moment”: The Power of Predictable Delight

Let’s be clear: The “Ah Moment” is not “Wow!” The “Ah Moment” is “Phew.”

It’s the quiet sigh of relief. It’s the moment of assurance when the customer receives exactly what was promised and expected, every single time. It’s the marriage of the experiential quality (how it felt) and the technical excellence (it actually worked).

This is the moment the customer “surrenders” to your service. They stop checking their bag at the coffee shop because their mobile order is always correct. They stop anxiously refreshing the tracking page because the package always arrives within the window.

They think, “Ah, I’m in good hands. I trust this.”

This isn’t magic. It’s the result of a meticulously designed service blueprint. It’s a predictable delight, and it’s infinitely more powerful than a random surprise.

The “Ow Moment”: The Crisis of Broken Trust

As the name suggests, the “Ow Moment” is pure pain.

It’s the “your package is lost” email. It’s the “payment failed, try again” error message, like in my previous fintech piece, the “is my money gone?” panic. It’s the 45-minute wait in a “priority” customer service queue.

It’s a moment of friction so painful that it can, and often does, cause a customer to withdraw permanently. It’s not just an inconvenience; it’s a breach of contract. The service didn’t just fail; it failed them.

Most companies are terrified of “Ow Moments.” They focus all their energy on avoiding them. But this is the wrong approach. “Ow Moments” are inevitable. No service is perfect.

The real test isn’t whether you fail; it’s what you do the moment you do.

The Magic: Turning an “Ow” into an “Ah”

Here is the single most important strategic opportunity your company has:

Any “Ow Moment” can be reversed and turned into an “Ah Moment.”

This is where the true masters of service design, the “Wizards of Ah’s,” separate themselves.

Think about it:

OW: A customer’s transfer fails during a high-value transaction. Panic sets in, and they assume the money is gone.

• Bad Recovery: A generic message appears: “Something went wrong. Please try again.”
• Ah, Moment Recovery: After we redesigned the flow, users received a clear reassurance: “Your transfer is safe. The system couldn’t complete it right now, but no funds were moved. Please try again in a few minutes.”

OW: A manager logs into a new analytics dashboard and can’t find yesterday’s transaction data. They assume something’s broken.

• Bad Recovery: A delayed support email says, “We’re aware of the issue.”
• Ah, Moment Recovery: We added a micro-status explaining data sync timing right in the UI: “Transactions are updating. Last synced 9:45 AM.”

Suddenly, the panic turned into patience. A simple piece of clarity turned frustration into trust.

The Blueprint Behind the Magic

Turning an Ow into an Ah doesn’t happen on the surface. It happens behind the scenes, in the blueprint.

Every recovery moment depends on invisible systems: clear ownership, escalation paths, automated messages, and empowered teams who can act fast.

The customer only sees the frontstage, but the real design work lives backstage.

When the blueprint is solid, recovery feels effortless. When it’s not, every small “Ow” becomes a full-blown crisis.

Why This Isn’t Fluff. It’s a Hard Strategy.

Still think this is soft, “customer service” talk?

A foundational study of B2B marketing executives found that customer experience (50%) trumps price (16%) by more than three to one.

In a world where features can be copied overnight and prices are in a race to the bottom, the only durable competitive advantage is your service blueprint.

This is why Service Design is a core strategic discipline. It’s not about designing a fancy interface. It’s about designing the end-to-end system, the backstage operations, the employee scripts, the error handling that ensures you can deliver your “Ah Moments” and master your “Ow Moment” recoveries. Consistently, reliably, and repeatably.

That’s the real work. That’s the real magic.

A huge thank you to Thomas A. Stewart and Patricia O’Connell for their incredible insights in the “Service Design: How to Design and Deliver Great Experiences” course!

Why Your ‘Ow Moments’ Are Your Biggest Opportunity was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

In finance, design is not about delight… It’s about trust.

Trust is the real currency of fintech. You can have beautiful interfaces, smart algorithms, and the fastest onboarding flows, but if users hesitate for even one second before pressing “Confirm transaction,” you’ve already lost them.

Over the years, I’ve learned that designing for fintech isn’t just about aesthetics or usability. It’s about psychology, risk perception, and the subtle signals that make people feel safe when money is on the line.

The Paradox of Trust

In fintech, users don’t want to think about design. They want to think about control. When people open a banking app or a payment screen, they’re not looking for delight; they’re looking for reassurance. Every pixel, every word, every loading state has to whisper, “You’re safe here.”

And yet, many products still treat design as a decoration layer, with bright gradients, complex animations, and flashy dashboards. They forget that trust is built through predictability, not novelty.

The Other Side of the Coin

But there’s another side to the story,

The money-driven stakeholders.

In fintech, it’s a delicate balance. A stakeholder’s obsession with short-term profit should never undermine the integrity of the experience you’re trying to build.

When design decisions start prioritizing revenue over trust, the user becomes the first casualty. The goal is not to eliminate business objectives but to align them with user needs.

UX and UI elements should be guided by real user feedback, not just by quarterly targets or conversion graphs. Because in the long run, products that genuinely serve users will always outperform those that merely try to extract from them.

Microcopy: The Smallest Words Carry the Most Weight

One of the first fintech projects I worked on taught me this lesson the hard way. A user error message once read: “Something went wrong. Please try again.” It sounded harmless until we realized that dozens of users assumed their money was gone. Panic calls flooded the support.

We changed it to:

“Your transfer is safe. The system couldn’t complete it right now, but no funds were moved. Please try again in a few minutes.”

The design didn’t change, just the words did. And that small change reduced user complaints by 82%.

Visual Design: Familiarity Over Innovation

Unlike e-commerce or social apps, fintech users don’t reward you for being “different.”They reward you for being reliable. A flashy redesign might look modern to you, but to a user managing savings or loans, it can feel risky.

In finance, design maturity is knowing when not to reinvent. Consistency, hierarchy, and clear feedback loops build far more confidence than gradients or neumorphism ever could.

Dark Patterns Are a Shortcut to Failure

Trust, once broken, is almost impossible to rebuild. Tricking users with hidden fees or manipulative CTAs may boost short-term metrics, but the cost is long-term brand damage.

Transparency is not just ethical… It’s profitable. The best fintech products don’t hide complexity; they translate it into clarity.

What Trust Really Feels Like

It’s not about being flashy or clever. It’s about being predictable, transparent, and calm under pressure.

A fintech product that inspires trust doesn’t need to shout. It quietly says, “I’ve got this.”

That’s why the best design compliment you can ever get in fintech isn’t “This looks amazing.”

It’s “I didn’t even think about it.”

Final Thoughts

Fintech design teaches humility. You’re not designing to impress. You’re designing to reassure.

Because when users trust your product with their money, they’re not trusting the interface;

They’re trusting you.

In finance, design is not about delight. It’s about trust.
And isn’t that the secret for every other project, too?

Designing for Trust: UX Lessons from Fintech was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the first part of this story, we agreed that good UX needs a great narrative to survive. But what happens after you’ve told the story?

Good UX Doesn’t Sell Itself

The Sequel No One Asks For, But Everyone Needs

You enter the feedback session. And that’s often where good stories and good designs go to die.

Picture the scene: you’ve just presented weeks of hard work. The user flows are elegant, the interface is clean, and the solution feels right. You hold your breath, look at the stakeholders, and ask the five most dangerous words in a designer’s vocabulary:

“So… what do you think?”

A pause…

Then it begins.

The marketing manager thinks the button should be a different shade of blue.

The CEO’s spouse saw a cool app that does things another way.

The feedback dissolves into a swamp of personal taste…

Suddenly, the entire project’s fate seems to hang on the curve of a button, and you feel a bit like Boromir at the Council of Elrond, lamenting, “It is a strange fate that we should suffer so much fear and doubt over so small a thing.” The project goals are forgotten. The user is forgotten.

The first rule of selling your work is to tell a good story. The second, and equally important rule, is to never let a bad question ruin it.

Why “Do You Like It?” Is a Career-Killing Question

Asking stakeholders if they “like” your design is a trap. You’re not just asking for feedback; you’re asking for trouble. Here’s why:

1. It invites subjectivity, not strategy. “Liking” something is a feeling, not a metric. This question instantly shifts the conversation from “Does this solve the user’s problem?” to “Does this please my personal aesthetic?”
2. It positions you as a junior. It signals that you’re seeking approval, not alignment. You sound like you’re asking for a pat on the back, not a strategic partnership.
3. It makes the feedback about them, not the user. You’ve just spent the entire presentation focusing on user needs, and now you’re asking a stakeholder to focus on their own.

Asking “Do you like it?” is like a doctor showing a patient an X-ray and asking, “So, do you like the look of your broken bone?” The question is irrelevant to the problem we are there to solve.

A Quick Case From Experience

A few years ago, I presented a redesigned dashboard for a B2B product. The user flows were simplified, key actions surfaced, and in testing we saw task completion improve by almost 40%.

But in the review session, I made the mistake of asking, “So… what do you think?”

That one question derailed everything…
Suddenly, the conversation wasn’t about workflows or user goals. It was about button colors and whether the sidebar should be on the left or top. Weeks of design work and research were overshadowed by personal taste.

In the end, the launch was delayed because we wasted cycles debating aesthetics that didn’t matter. That was the moment I learned: asking “Do you like it?” is not feedback facilitation.

It’s self-sabotage.

You’re Not a Note-Taker. You’re a Facilitator.

When you walk into a feedback session, your role is not to be a passive note-taker, dutifully writing down every comment. Your role is to be a facilitator.

You are the Gandalf in the Council of Elrond, keeping everyone focused on the mission. After all, as the wizard himself reminded us, ‘All we have to decide is what to do with the time that is given us.’ A feedback session is a finite amount of time; your job is to make sure it’s spent solving the right problems, not chasing subjective whims.

Better Questions to Ask

To get better feedback, you have to ask better questions. Ditch “Do you like it?” and replace it with questions that are specific, strategic, and user-focused.

• Instead of asking, “What do you think?” ask:
  “Does this solution clearly address the user problem we outlined at the start?”
• Instead of asking, “Is this confusing?” ask:
  “What information feels like it’s missing for you to complete the main task?”
• Instead of asking, “Do you like the layout?” ask:
  “From your department’s perspective (e.g., marketing, engineering), does this approach create any new risks or challenges we haven’t considered?”

These questions force stakeholders to put on their problem-solving hats, not their art critic hats. They anchor the conversation in strategy and user needs.

Ask Questions That Build, Not Just Validate

Selling your UX is a continuous process. It doesn’t end with a great presentation; it lives on in how you manage the conversations that follow.

The quality of your final design is directly proportional to the quality of the feedback you’re able to guide and gather. Stop asking for approval and start facilitating a discussion. Because great design isn’t about having all the right answers, it’s about asking the right questions.

Good UX Doesn’t Sell Itself, Part 2: Stop Asking “Do You Like It?” was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Anatomy of a Sacred Rule

In the world of UX design, “Mobile First” is scripture. For over a decade, it has been preached from the gospels of design blogs and chanted in the halls of product meetings. And for good reason. It emerged as a brilliant solution to a real problem, forcing us to prioritize what truly matters by starting with the smallest, most constrained screen. It was a philosophy of discipline.

But somewhere along the way, a brilliant strategy became a lazy dogma. Like a craftsman who owns only a hammer, we began to see every problem as a nail. We stopped treating “Mobile First” as a tool and started worshiping it as an answer… the answer.

The result? We are littering the digital landscape with broken desktop experiences. And we need to talk about it. “Mobile First” is not a UX strategy. It’s a dogma that’s holding us back.

The Wasteland of Giant Buttons

You know the look. You open a web application on your 27-inch monitor, and you’re greeted by a design that feels like a caricature. Giant fonts and buttons scream for your attention from across an ocean of empty white space. A navigation system that could comfortably live in a sidebar is instead hidden behind a hamburger menu, requiring an extra click for no reason. You scroll endlessly down a single column that was clearly designed for a thumb.

This isn’t a desktop experience. It’s a stretched-out mobile app.

We can call this “The Tyranny of the Afterthought.” It’s the direct result of a design process that treats the desktop not as a powerful, distinct platform, but as a bigger phone that just needs to be “filled in” later. This approach doesn’t respect the user; it merely tolerates their screen size.

Your User Isn’t a Screen Size. They’re a Context.

Here is the fundamental truth we’ve forgotten: the user sitting at their desk with a high-resolution monitor, a keyboard, and a mouse is in a completely different universe of intent than the user on a bus, swiping with one hand.

• The Desktop Context: This is the realm of deep work, comparison, data entry, and creation. The user expects power, precision, and information density. They have the tools for complex interactions and the mental space for in-depth tasks. Giving them a simplistic, stretched-out mobile UI is like handing a professional chef a single plastic spoon to cook a gourmet meal.
• The Mobile Context: This is the realm of quick lookups, immediate transactions, and on-the-go communication. The user expects speed, focus, and simplicity. A cluttered, desktop-style interface would be a nightmare here.

Good UX doesn’t just adapt to a screen; it serves the user’s context. By blindly applying “Mobile First,” we are optimizing for the mobile context everywhere, and in doing so, failing our desktop users completely.

The Solution: “Context-First” Design

This isn’t a call to abandon “Mobile First” entirely. It’s a call to put it in its proper place — as one tool among many. The new mindset we need to adopt is “Context-First” Design.

The first question in our process should not be, “How do we design this for mobile?” It should be:

“What is our user’s primary goal, and in which context are they most likely to perform it?”

• If your product is a complex analytics dashboard, its primary context is the desktop. You should be thinking “Desktop First,” leveraging the power of large screens and precision input, and then creating a streamlined, focused mobile version for monitoring on the go.
• If your product is a food delivery app, its primary context is mobile. Here, “Mobile First” is absolutely the correct strategy.
• If it’s a news website, the context is mixed and equally critical. This requires a truly “Adaptive Strategy” where both desktop and mobile are treated as first-class citizens, each with an experience crafted for its specific strengths.

Let’s Break the Dogma

“Mobile First” was a useful constraint, a solution for a specific problem at a specific time. It is not a universal law of good UX.

It’s time for our teams to stop asking, “What’s our mobile-first strategy?” and start asking, “What’s our context-first strategy?” Let’s stop building bloated mobile apps for the desktop and start designing experiences that respect the device in our users’ hands and the context in their minds.

“Mobile First” Is Not a UX Strategy. It’s a Dogma. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.