Increasing User Trust in Web2App Flows

"But it's an extra click" Yes, but would you rather... Click one more time, Or, send money to the wrong person? Click one more time, Or involuntarily see sensitive / graphic content? The truth is, friction still gets a bad rep But less clicks doesn’t always mean a better experience Less clicks doesn’t always mean a quicker journey Less clicks doesn’t always mean easier to use Sometimes that extra step, that extra click, that extra loading state, is good Actually, adding friction can be crucial → It can increase trust → It can reduce mistakes → It can keep people safe How? By giving people control  By enabling them to pause and evaluate their actions → Am I sending money to the right person? → Do I really want to delete all of my photos? → Do I actually want to mass email the company? → Do I want to see that graphic / sensitive content? → Did I mean to add 3 of the same things to my basket? → Do I believe that the system actually did what it said? → Did I create an account with the right details, or now will I be called Emilu? I’m not saying to always add extra steps for the sake of it But, we can’t underestimate the value of slowing people down So, what we can we do? → Map the journey (and system interactions). What decisions can people fly through vs where do we need them to slow down? Are there any destructive actions (like deleting) → Ask what could go wrong and think how it could be prevented. What actions can be make reversible? → Understand people's behaviours. What are they doing, intentionally or unintentionally. What behaviour are we trying to amplify or change? Where can we give more control? → Can we add friction to tailor their experience? It could be as simple as: → Adding an "are you sure prompt" → "Check your details" page at the end of the flow We can't define success by how many times we tap Design for the experience, not for the clicks Design for people, always 💛

Is it possible for a design to be too clean? Minimalism is great until it starts making your users anxious. We’re often taught to hide the technical 'noise' to keep the interface clean. But in high-stakes moments, that silence can actually create doubt. But in high-stakes moments, like waiting for money to arrive, minimalism can actually create doubt. If a user doesn’t see proof that the system is working, they start to worry. They might even close the app or call support. Here are the two directions I’ve been testing: Strategy A: This is about calm. It focuses only on the arrival date. It’s for the user who just wants to get in and out quickly. Strategy B: This is about transparency. I designed a vertical timeline to show the receipts of what’s happening behind the scenes. How I made the technical stuff feel human: I realized that terms like "Merchant Verification" just sound like robot-talk. So, I used labels that humans actually use: • Checking with the Store: Confirmed the purchase. • Security Check: Making sure the account is safe. • Preparing your Wallet: Getting the balance ready. • Final Payment: Waiting for the bank to release the funds. I used dropdowns to keep the screen clean. This way, the user isn't forced to read everything, but the proof is there if they feel skeptical. Now I want to ask the founders, product leads, and designers: What is your plan for building trust with your users this year? Are you keeping things simple, or are you showing them the work? Let’s chat in the comments P.S. I’ve dropped a quick GIF in the comments so you can see how these dropdowns feel in motion.

The real reason users quit at the SSN screen (+ the solution we discovered). A pattern we've seen across hundreds of onboarding flows: 1. User downloads app 2. Fills in basic info 3. Reaches SSN field 4. ...disappears The conventional wisdom? "People are private about their SSN." But that's not the whole story. The same user will happily provide their SSN to:  → Their employer's HR portal  → A mortgage application  → Their tax software What's different? It's about earned trust and clear value. Those other services have already demonstrated clear value:  → A job offer  → A path to homeownership  → Tax compliance But in fintech, we often ask for SSNs before showing any value at all. In 2024, users have a lot of choice:  → Hundreds of investing apps  → Dozens of neobanks  → More options than ever before Each promising similar benefits. Why risk your most sensitive data with an app you're not sure you'll love and a brand you’re just getting to know? The best fintech apps are flipping the script: 1. Demonstrate value first 2. Build trust gradually 3. Ask for sensitive info when it makes sense But there's an even better approach: Auto-fill it. We've found something fascinating: when users see their verified data auto-filled, it instantly creates trust. It places the service in the same category as banks, carriers, and credit bureaus. The mere ability to access this data signals trustworthiness. It's not just about convenience. It's about putting you in the same category as other trusted institutions. What patterns are you seeing in your onboarding flows? #FinTech #Finance #Onboarding #Signup #UserExperience #UX

🔐 Rethinking Registration Let’s be honest — most registration flows still feel like a chore. Email. Password. Confirmation. Password rules. Confirmation again. Forgot your password? But here’s the thing: users don’t care about your security model. They care about getting started — quickly, safely, and without friction. That’s why more and more products are shifting to email-only authentication. And I wanted to explore that shift myself. The goal was to simplify signing in to the product, eliminate the need to remember passwords, and increase user trust through transparent, intuitive logic. Here’s the flow I designed and tested: ❌ Email + password + confirmation ✅ Email → Send Code → Done No friction. No overload. No “reset your password” loop. 🔧 Key Solutions: 1. Separation into Microsteps Each screen contains only one action — this reduces cognitive load and helps the user move forward without distractions. The flow looks easy and manageable. 2. Predictability and Control The user understands where they are at any time: sending the code, entering, confirming. I added microtexts with hints — this relieves anxiety and reduces the likelihood of errors. 3. Alternative Scenarios Each screen has the options “Continue with Google/Apple” and “Already have an account? Login" — this creates a sense of choice and flexibility, without pressure. 4. Logic matches real behavior The user receives a code by email and enters it manually — this is how the real experience works. We do not overload the user with passwords, confirmations, access recovery, etc. 📈 Result: The flow turned out to be minimalistic, predictable and friendly. It reduces the barrier to entry into the product, suitable for those who value speed and do not want to remember unnecessary things. This approach works especially well in products with frequent sessions or sensitive information. ⚡️ I built this entire user flow in just a few hours — clean, intuitive, and ready for real users. Sometimes the best UX isn’t about complexity — it’s about clarity and momentum. Would you trust this kind of registration flow — or do you still feel safer creating a traditional password? 👇 Drop your thoughts in the comments. #UXDesign #ProductDesign #EmailCode #LoginUX #NoPasswords #MicroUX #UserOnboarding #SideProject #DesignToLearn #SerhCode #AuthenticationUX #UserExperience #MinimalDesign #TrustByDesign

A simple UX change that reduce permanent permission denial. We often see the problem that users deny some permissions or permanently deny permissions from ask permission dialog . Then the mobile OS doesn’t allow the app to ask for permission again. The only way left is for the user to go to settings and turn on the permission, which most users find annoying. The mobile app can then only guide the user on how to turn on the permission but cannot directly give the option to enable it. This behaviour many times make that feature broken. This happens because the app was not able to gain the user’s trust, could not clearly explain the reason for the permission, or sometimes the user simply doesn’t want to grant it. To handle this, a simple UX change can greatly reduce the problem. The solution is to first ask for consent through an in-app dialog, where you explain why the permission is needed and build the user’s trust. Then, only if the user agrees, show the native permission dialog. This approach helps prevent the OS from flagging the app as unable to request the permission again. Implementing this small UX change not only improves permission acceptance rates but also enhances overall user experience. Users feel respected and informed, which builds trust and increases engagement with your app. In the long run, thoughtful permission handling can reduce churn and make your app more reliable and user-friendly. Context -> Trust -> Allow