I keep having this same conversation
"Can we make this under two or three clicks?”
And then— I look at my stakeholder who said: waiting for the punchline. There wasn't one.
Now, the irony: We were redesigning a mortgage application—a decision that could impact someone's life for 30 years—and we were treating it like ordering pizza.
This question comes up in almost every enterprise project I work on. Because - you know most of stakeholders think that decreasing click = more efficiency for the user, majorly employees.
Here's what I've learned:
Sometimes the best user experience isn't about moving faster. Sometimes it's about giving people permission to slow down.
The Friction Obsession (And Why It Exists)
Now, let me guess what you've heard (the classic examples):
"Amazon does it in one click!"
"Users abandon if there are too many steps."
Here's what really bothers me: They're not entirely wrong.
Consumer apps have trained everyone—including business stakeholders—to believe that speed equals success. And most of the classic experience examples to relate come from those popular, sorry, classic example apps…
But here's the question no one's asking:
What if your employee experience app isn't supposed to feel like ordering something on Amazon or doing restaurant table reservation?
The Restaurant Paradox: When Easy Becomes Too Easy
Imagine designing a restaurant booking system that’s “frictionless” – one tap and a table is reserved. Sounds perfect, right? Yet, many restaurants now require deposits. Why?
When booking became too easy, people treated reservations like browser tabs, opening dozens without intending to show up. This led to restaurant losses, uneaten food, worried employees, and genuine diners missing out on tables.
Introducing a deposit changed everything. Initially, it reduced bookings, but improved their quality with more reliable attendees.
Real Examples
Dineout (now Swiggy Dineout) charges a nominal ₹10-50 cover charge per person. It seems trivial, but it:
Dramatically reduced no-show rates
Allowed restaurants to plan effectively
Enabled genuine diners to secure tables at peak hours
Filtered out the “let me book 5 restaurants just in case” crowd
District by Zomato implemented a similar approach. You’re not paying extra, but the act of putting money down creates commitment. That’s it!
Psychological Shift
Before friction: “Free to book, free to cancel, why not book everywhere?”
After friction: “I’m paying ₹50. Do I really want to eat here? Let me cancel the other bookings.”
That small amount—less than parking—altered user behaviour. Not due to cost, but because it demands intention now
The Real Cost of "Frictionless"
The IT Service Request That Broke Everything
I was once redesigning an IT service request portal—you know, the kind where employees request new laptops, software access, equipment repairs, that sort of thing.
The CIO wanted it “streamlined.” When I asked what that meant, he said:
> “Make it under five clicks. Fewer clicks = easier to use = better experience. Look at Amazon—one-click ordering!”
So let’s play this out. What does a three-click IT service request actually create?
The “Fast” Flow
Click “New Request”
Select “Laptop” from the dropdown
Click “Submit”
Done! Three clicks. Beautiful done. The CIO is happy.
But guess what actually happens next?
The IT team receives: “Employee needs a laptop for design work.”
Looks complete, right? But here’s what’s missing:
Missing detail #1: RAM/Storage specs
The employee is a UI designer working with Figma and heavy design files. Standard 8GB won’t cut it. IT orders the base model. Two weeks later: “This laptop is too slow, I can’t work.”
Now IT has to:
Process a return/exchange
Order the correct spec (16GB RAM, 512GB SSD)
Wait for new delivery
Migrate the employee’s work
Total delay: 3-4 weeks instead of 5 days
Missing detail #2: Urgency/Start date
The request just says “needs a laptop.” IT assumes a standard 2-week turnaround. But the employee starts on Monday (3 days away). They sit idle for a week and a half with no equipment.
As per the CIO, the irony is that you “saved” the employee two minutes but cost them two to three weeks of waiting and frustration. They may have finished the form quickly but did they do so well?
What Those “Extra Clicks” Actually Prevented
The original flow with “too many clicks” included:
Selecting laptop specifications (processor, RAM, storage)
Choosing urgency level
Entering project code for billing
Adding budget approver
Writing brief justification
Reviewing summary before submission
Each of these “extra clicks” was actually:
Captures key info → Prevents back-and-forth → Enables correct procurement → Saves everyone time**
Or broken down:
Laptop specs → IT orders the right device first time
Urgency level → Sets proper expectations and prioritisation
Project code → Billing routed correctly, no finance follow-ups
Budget approver → Approval happens immediately, no hunting for sign-off
Justification → Context for future audits and planning
Review step → User catches mistakes before they become tickets
Ask yourself: Is speed worth the aftermath?
Stakes Multiplied
In employee experience apps, the stakes multiply:
An employee requests the wrong access level → security breach
Someone submits an incomplete leave request → scheduling chaos
A manager bulk-approves without reviewing → budget overruns
An expense claim lacks required details → compliance nightmare
The “slow” form that takes 3 minutes saves everyone 3 days of cleanup.
Why Multi-stepper forms now?
That’s why Multi-Step Forms have became new Standard now!
Ever notice how almost every well-designed service request, onboarding flow, or application process now uses a multi-step form? There’s a reason for that.
It’s not about making things longer—it’s about making them clearer.
A multi-stepper breaks down complexity into digestible chunks:
Step 1: Basic Details→ User focuses on what they need
Step 2: Specifications → User thinks through exactly what they want
Step 3: Justification & Approval → User provides why and who
Step 4: Review & Submit→ User gets one last chance to catch mistakes
The magic happens in that review step.
Instead of hitting submit and praying, users can:
See their complete request laid out
Catch that they selected “16GB RAM” when they meant “32GB”
Realise they forgot to add the budget approver
Notice the delivery date is during their vacation
Fix mistakes *before* they become tickets
This is intentional friction that feels like a safety net, not a hurdle.
Compare this to a single-page form where everything is crammed together. Users are overwhelmed, they miss fields, they rush through, and they hit submit without truly reviewing. Problems and Problems…
Then comes the regret email: “Actually, I need to get things right now…and things move in circle!”
Modern UX recognises that:
Cognitive load is real → Breaking it into steps helps users think clearly
Mistakes are expensive → A review step prevents costly errors
Confidence matters → Seeing a summary before committing builds trust
Context switching is hard → Grouping related fields together improves accuracy
The best part?
Users actually *prefer* multi-step forms for complex processes. They don’t feel faster, they *are* faster—because they eliminate the back-and-forth that happens when information is incomplete or wrong.
That “extra” review step isn’t slowing users down. It’s speeding up the entire organisation.
When "Innovation" Removes Important Friction: The Swiggy OTP Story
Now another classic example where renowned Swiggy App did perform innovation : where it removed important Friction of OTP manual click
Swiggy recently changed their OTP flow. Instead of manually entering and clicking "Submit," the OTP now auto-submits the moment it's detected—giving you just 5 seconds to cancel if something's wrong.
Here’s what I said :
Linkedin comment
Here's why the old "extra click" actually worked better:
The Problem with Auto-Submit
What happens in those crucial five seconds?
The user is still processing the arrival of the OTP. They might be distracted by a phone call, notification or conversation. They realise “wait, I actually want to change my order”. They think “let me just review the cart one more time”. But it’s too late. Your order is already placed. Now what?
Cancelling an order after submission is much harder. You’re now in customer service territory and refunds take 3-7 business days. You’ve wasted time and mental energy.
Psychological Shift/Earlier way better..
The old flow with extra click gave you a moment of pause: the OTP arrives, you see it in the field, you have time to think “Do I really want this?” and you consciously click “Submit”. The order is confirmed.
That “extra click” was actually a moment of intention – a last checkpoint before commitment.
When “Innovation” Ignores Context
Here’s what the auto-submit optimises for: the fastest possible checkout, reducing abandonment at the last step and impressive click metrics. It ignores users who second-guess their choices (common in food ordering!), accidental orders from auto-detected OTPs, the difficulty of cancelling compared to preventing mistakes and recovery time when errors occur. This isn’t innovation – it’s optimisation without considering the cost.
The Broader Lesson
Not every removed click is a win. Sometimes that click is: a moment to breathe, a chance to reconsider, a checkpoint before commitment or a prevention mechanism that’s easier than cure. In employee experience apps, this matters even more: imagine auto-submitting leave requests (no chance to verify dates), expense reports (no final review), access requests (no moment to confirm scope) or budget approvals (no time to double-check amounts).
The question isn't "how many clicks?"—it's "where do users need a moment to be sure?"
The Filter Fiasco (Or: How I Learned to Love the "Apply" Button without giving 2nd thought)
Here's a conversation I've had more times than I can count:
Stakeholders questioning the necessity of an “Apply” button on filters, suggesting that auto-refreshing as users select options would be fine. They preferred a single-click process over the six-click method currently in place.
Let me demonstrate the “Optimised” flow they desire:
Clicking “Department” triggers a page refresh.
Selecting “Engineering” also refreshes the page.
- Clicking “Location” refreshes the page again.
- Selecting “Bangalore” refreshes the page once more.
- Clicking “Status” refreshes the page.
Finally, selecting “Active” refreshes the page.
This results in a total of six clicks and six page refreshes.
In contrast, the “Slow” flow they detest is:
- Clicking “Department” followed by selecting “Engineering” results in a single page refresh.
- Clicking “Location” followed by selecting “Bangalore” also results in a single page refresh.
- Clicking “Status” followed by selecting “Active” results in a single page refresh.
This process involves only four clicks and one page refresh.
Cognitive Load Nightmare
But here’s the real problem:
The “Cognitive Load Nightmare” arises when an HR manager, attempts to filter the employee database. The goal is to find “Active employees in Engineering at Bangalore office.”
With auto-refresh:
- Selecting “Engineering” reloads the page, displaying 1,247 results (everyone in Engineering across all locations and statuses).
- The brain struggles to process this incomplete data.
- Selecting “Bangalore” reloads the page again, showing 423 results (Engineering and Bangalore but including inactive employees).
Confusion sets in: is this the final result? Wait..there's more..
- Selecting “Active” reloads the page once more, finally displaying 156 results.
This process involves a significant cognitive load, making it cumbersome and frustrating for users.
Your brain processes three different datasets each time you ask yourself, “Is this what I’m looking for? Or am I still building my query?”
With an “Apply” button:
You calmly select all three filters.
You review your selections.
You click “Apply” with confidence.
You see one result: 156 employees.
Your brain processes the dataset you actually want. Which feels faster to the user experiencing it?
The System Performance Tax
Let’s consider what your stakeholder isn’t seeing:
Each auto-refresh triggers a series of actions: database query execution, data serialisation, network transmission, UI re-rendering and state management updates. For our employee filter example, this translates to:
6 API calls compared to 1
6 database queries compared to 1
6 moments where the UI is locked compared to 1
What happens when 50 managers are simultaneously filtering during month-end reporting?
Your server becomes a very expensive space heater.
The “But Google Does It!” Argument
We often overlook the other side of the coin, which business stakeholder use to justify approach.
For example, a stakeholder might argue, “But Google search updates as you type! There’s no submit button!” While this is true, it doesn’t necessarily mean our approach is flawed. Consider how many filters you’d need to select in a Google search. Google’s solution is simple: one input field, predictive helpful suggestions, real-time feedback, and lightweight queries.
Now, let’s compare this to your employee app. It likely has multiple interdependent filters, complex database joins, and requires users to think through their queries. This can be computationally expensive and doesn’t always provide the same level of real-time feedback.
Different problems require different solutions.
When Auto-Refresh Actually Works
I’m not saying auto-refresh is always the best solution. It works beautifully in certain scenarios, such as when you have a single independent filter (like a search box), lightweight queries (data loads in less than 100ms), users expect real-time feedback (like search suggestions), or you’re using visual browsing (like colour filters on an e-commerce site).
However, for complex multi-criteria filtering in data-heavy apps, the “Apply” button is often the better choice.
Why Employee Experience Apps Are Different
After seeing these examples, you might wonder: "Why does this matter so much more in employee apps than consumer apps?"
Here's the key difference:
Consumer apps optimize for:
Impulse actions
Quick wins
Volume over accuracy
Employee apps need to optimise for:
Informed decisions
Confidence over speed
Preventing costly mistakes
Employees aren't "customers." They're:
Making decisions that affect their colleagues
Using tools they didn't choose
Dealing with consequences they can't easily undo
When you remove all friction from an expense approval flow, you're not making it "easier"—you're making it riskier.
Conclusion: Design for Outcomes, Not Metrics
The best UX isn't always the fastest UX. It's the one that helps people make decisions they won't regret.
In consumer apps, friction often is the enemy.
But in employee experience apps: story is bit different - The right friction at the right moment can be the difference between a tool people trust and one that creates chaos.
Stop counting clicks. Start counting:
Errors prevented
Confident decisions made
Money saved
Trust built
Because at the end of the day, your users don't care about your click metrics. They care about getting home on time without worrying they approved the wrong thing.
