Notes on building products that people trust.

I have seen teams add AI, OCR, or automation into a workflow and expect users to welcome it immediately.

But when the outcome affects money, approvals, customer data, or operational decisions, that assumption breaks fast.

Users do not want a black box.

They want answers to practical questions:

• What did the system change?
• What is still waiting for my decision?
• Can I review it before it affects something important?
• Can I undo it if something goes wrong?

The pattern was clear.

People were not resisting automation itself.

They were resisting uncertainty.

In one workflow I worked on, automation helped convert quote data into a structured process much faster.

What made people trust the experience was everything around the automation:

• Clear review states before submission
• Visible highlights for extracted and changed fields
• Approval checkpoints for high-impact actions
• Easy correction paths when OCR or AI got something wrong
• A way to pause or stop the flow before it moves forward

That changed the role of AI.

It stopped feeling like something happening to the user.

It started feeling like something helping the user work faster.

Many AI experiences optimize for output.

Users are often optimizing for control.

Especially in fintech and B2B platforms, speed alone is not enough. When a workflow touches compliance, financial decisions, or customer records, trust needs to be designed into the interaction from the start.

My rule is simple:

Make automation visible.

Make decisions understandable.

Make responsibility clear.

That is how you increase speed without reducing trust.

Or in simpler terms: التحكم builds confidence.

I work with fintech and B2B SaaS teams on human-in-the-loop AI workflows, where this exact tension between speed and control shows up constantly.

How are you designing for trust when AI enters a regulated or high-stakes workflow?

A few weeks ago, I was reviewing a signup journey for a B2B financing product.

At first glance, things looked okay.

People were coming in.

The product was live.

Nothing looked obviously broken.

Then I opened the funnel properly.

That is where the real story started.

A lot of users were starting signup, but only a small percentage were finishing it.

And most of the damage was coming from one step in the middle of the journey.

So I stopped looking at the dashboard and went back to the actual behavior.

I rebuilt the funnel from raw events.

Watched the session recordings.

Checked the journey step by step.

The pattern was clear.

Users reached that step, slowed down, hesitated, and left.

The screen itself was understandable.

The timing was wrong.

We were asking for sensitive company information before users had enough context, trust, or reason to continue.

Fair reaction, honestly.

I brought the findings to the team.

The page had a real reason to exist, so removing it was not a tiny UI tweak. It affected validation, copy, flow structure, and downstream logic.

So we looked at the recordings, the funnel, and the business impact together.

Then we changed the journey.

We moved validation later.

Shortened the signup flow.

Rewrote the copy around the highest hesitation points.

The result:

Signup completion more than doubled.

In our measurement window, the improvement was 127%.

The critical drop-off almost disappeared.

More users reached the business-critical request flow.

Sometimes the step everyone thinks is necessary is the step quietly damaging the journey.

One badly timed question can reduce trust.

One misplaced requirement can block revenue.

Good UX work starts when you stop defending the flow and start listening to what users are already showing you.

One habit has helped me a lot:

I ask many questions.

Sometimes it can make me look like I don’t fully understand the topic.

That’s okay.

When a new feature is discussed, teams often move quickly to the solution.

I usually want to understand a few things first:

Who will use it?

What problem are we solving?

How do people solve this problem today?

And what does the business want to achieve?

The current way is very important.

It may be another app.

Or Excel.

WhatsApp.

A phone call.

A paper form.

Or a person doing the work manually.

If you don’t understand how people work today, you can easily build a digital product that makes their life harder.

These questions also help me understand the business and technical side of the feature.

So when I start designing, I already have much more context.

And when I present the solution, I’m not only showing screens.

By that point, the design already reflects the user, the business, the technology, and the real process behind the feature.

Many times, I’m not introducing a completely new idea to the team.

I’m showing them how the things we discussed can work together in one clear solution.

Ask enough to understand.

Then design.

I have been using Claude Code for months to explore multiple design directions directly in Figma through MCP.

I rarely use the generated output as the final design. I take the useful ideas, remove what does not work, refine the flows, and continue the design work inside Figma. So far, this workflow has been far more useful to me than Claude Design.

Recently, I also started experimenting with Codex.

Visually, its initial design output has been less impressive. But it is useful for exploring edge cases, challenging assumptions, and acting as another brain during the design process.

That is where I believe AI currently delivers the most value for designers.

Most new landing pages are now generated, at least partially, with AI. I keep seeing startups launching with very similar layouts, visual patterns, and interactions.

This makes design craft, product understanding, and experience even more important. AI can quickly generate a polished interface, but standing out still depends on the designer’s ability to create something intentional, relevant, and memorable.

AI can support research, help structure product requirements, identify missing states, generate alternatives, and speed up execution. But the designer still needs to direct the process, evaluate every decision, and determine whether the proposed solution actually solves the right problem.

AI is here to stay. Our job as designers is to understand where these tools are genuinely useful, where they fail, and how to use them without outsourcing our judgment.

We are moving into a space where the quality of your thinking will matter far more than how quickly you can push pixels.