Chapter II – Removing the Friction
Great customer experiences aren’t created by adding more features. They’re created by removing more friction.
Before we wrote new features, we spent time shopping. Not on the Rasa Padhama website. On dozens of other spice and grocery websites.
We wanted to understand what customers experienced long before they reached our platform. What worked? What didn’t? More importantly, what had become accepted simply because “that’s how ecommerce works”?
It didn’t take long for patterns to emerge. The same frustrations appeared over and over again. We weren’t interested in reinventing online shopping. We wanted to make it feel effortless.
A single product would be duplicated five or six times, once for every available weight. Product pages stretched endlessly as descriptions, storage instructions, ingredients, and delivery information competed for attention. Customers had to jump between multiple pages to compare options, while recipes often became dead ends that required another search to find the ingredients they had just finished reading about.
None of these problems were catastrophic. But together, they created friction. And friction has a habit of quietly costing sales.
Questioning the Familiar
One of the first assumptions we challenged was something surprisingly common. Should every product weight be listed as its own product?
Many online grocery stores follow this approach. A customer searching for turmeric powder might see separate products for 100g, 250g, 500g, and 1kg. The catalog becomes cluttered, search results become repetitive, and managing inventory grows increasingly complicated as the product range expands.
Technically, it works.
From a customer experience perspective, it doesn’t. And that’s what the client wanted too; to have 1 single page to list all weights.
Instead of multiplying products, we used variable product architecture to consolidate each item into a single product page. Customers simply selected the weight they wanted before adding the product to their cart.
The interface became cleaner. Navigation became faster. Product management became significantly easier for the client.
Sometimes, the best solution isn’t adding something new. It’s removing unnecessary complexity that people have learned to tolerate.
Designing for Decisions
Every product page has one purpose. Help the customer make a confident purchasing decision. That sounds obvious, yet many websites unintentionally compete with themselves by presenting everything at once.
- Long paragraphs.
- Technical information.
- Shipping policies.
- Storage instructions.
- Related content.
None of that information is unimportant. It simply isn’t equally important at the same moment.
We reorganized product pages around priority rather than volume. The information customers needed immediately, such as product selection and purchasing options, remained front and center.
Supporting information was still available, but presented through clean, off-canvas panels that appeared only when requested. Customers could explore additional details without losing focus or leaving the page they were already on.
It was a relatively small design decision.
Collectively, dozens of decisions like this created a shopping experience that felt lighter, even though the platform itself was becoming increasingly sophisticated.
When Shipping Isn’t Just Shipping
Every ecommerce project eventually reaches the question of shipping. At first glance, calculating delivery charges seems straightforward. Until products are sold by weight. Suddenly, every change a customer makes has consequences.
Choosing a different product weight changes the total shipment weight. Changing the quantity changes it again. Removing an item changes it once more. Shipping couldn’t simply be calculated once at checkout. It had to remain accurate throughout the shopping journey.
We implemented a dynamic shipping engine that continuously recalculated delivery charges as the cart evolved. Customers always understood how their decisions affected delivery costs without needing to reach the final checkout page.
The calculations happened quietly in the background. The experience remained simple. Good engineering often works this way. The user remembers clarity. Not the complexity that created it.
Loyalty Is More Than Points
Back in Chapter I, we mentioned that the loyalty program wasn’t part of the original project request. It emerged during discovery.
Designing that system proved more challenging than simply awarding points after a purchase. Points had to reflect reality. Customers needed to trust that every purchase, redemption, adjustment, and refund would always produce an accurate balance. Behind every visible point total was a carefully synchronized series of transactions designed to maintain consistency across the entire platform.
Like many engineering decisions throughout this project, the goal wasn’t to create something customers would notice. It was to ensure they never had a reason to question it.
Rethinking the Recipe Experience
One of our favorite conversations during the project had very little to do with shopping.
It was about cooking.
The client wanted to build a growing collection of recipes that would inspire customers to use their products in new ways. Our first instinct was straightforward.
Build a blog.
The more we discussed it, the more we realized we weren’t designing another blog.
We were designing a cooking experience.
News articles and recipes may both be content, but they serve completely different purposes. Someone reading company news wants information. Someone following a recipe is usually preparing a meal. They aren’t browsing casually. They’re trying to keep moving.
Every extra search, every unnecessary click, every forgotten ingredient interrupts that flow. Those journeys shouldn’t feel the same.
Instead of forcing both into an identical presentation, we created separate rendering logic that allowed recipes and company news to share the same content management system while delivering entirely different experiences to visitors.
That decision became the foundation for what came next.
Then one question changed everything.
If every ingredient listed in a recipe already existed in the store, why were we asking customers to find it twice?
The answer was simple. We shouldn’t.
Every ingredient became directly connected to the shopping cart. With a single click, customers could add products without leaving the recipe they were following. If an ingredient had already been added, the interface intelligently switched from Add to Cart to Remove, helping customers avoid accidental duplicates while keeping the experience uninterrupted.
Looking back, this wasn’t really about recipes at all. It was about respecting momentum.
When someone decides to cook a dish, that’s the exact moment they’re most likely to buy the ingredients. Good software doesn’t interrupt that moment. It quietly helps it continue.
The result was subtle, but meaningful. Recipes stopped being content that simply inspired customers. They became one of the most natural paths from inspiration to purchase.
This became one of our favorite pieces of engineering throughout the project. If you’re curious about the journey behind it, we’ve dedicated an entire Engineering Insight article to the recipe experience. It doesn’t dive into code or technical jargon. Instead, it explores the questions, decisions, and design philosophy that transformed a traditional recipe page into an integrated shopping experience.
Then Everything Changed
By this stage, much of the purchasing experience had already taken shape. Many of the core systems were functioning exactly as we had planned.
Then the market changed.
Global supply chain disruptions began affecting several imported spices, particularly turmeric due to the geopolitical incident that started in late February of 2026. Products that had once been readily available suddenly required careful allocation.
Business rules that had made perfect sense only weeks earlier no longer reflected reality.
Our first instinct could have been to patch the affected features.
- Add another condition.
- Write another exception.
- Fix the immediate problem.
That approach might have solved today’s issue. It would almost certainly create tomorrow’s.
Instead, we stepped back.
Rather than hardcoding temporary rules throughout the platform, we redesigned the purchasing engine around configurable policies that could evolve alongside changing business conditions.
Products could now be designated as High Demand (limited availability) directly from the administration panel. Once enabled, the platform automatically enforced quantity limits, minimum purchase requirements, payment restrictions, shipping restrictions, and eligibility rules for Taste ePromise.
Customers received immediate feedback as they shopped, allowing them to adjust their carts before reaching checkout instead of encountering confusing error messages at the very end of the process.
The business gained flexibility, customers gained clarity. The software became far easier to maintain.
Looking back, that redesign became one of the most valuable engineering decisions in the entire project. Not because it solved one problem. Because it prepared the platform for problems we couldn’t yet predict.
Making Complexity Feel Invisible
As development continued, one principle guided almost every decision we made.
Customers shouldn’t have to understand business logic. They should simply enjoy using the website.
- Every product variation.
- Every shipping calculation.
- Every recipe interaction.
- Every purchasing restriction.
- Every loyalty transaction.
- Every configurable policy.
Each feature solved a different problem behind the scenes. Together, they created something customers rarely think about. A shopping experience that simply feels natural.
By the end of this chapter, the customer journey was beginning to take shape. The platform was becoming more capable with every iteration.
The challenge now wasn’t adding new functionality. It was ensuring every feature remained fast, responsive, and dependable, whether someone was shopping on a high-end desktop or an entry-level smartphone using a mobile connection.
That became our next engineering challenge.
Found this article useful?