Redesigning Nepal's
first user friendly
cloud ERP.

01 — Context

ERP was a four letter word in Nepal.

In Nepal, enterprise software like Tally is seen as a necessary evil. Businesses pay for multi day training sessions just to create a basic invoice. Desktop first tools dominate, but mobile phone adoption is skyrocketing, yet no ERP felt built for that shift.

The existing Providhy system had a structural problem: users had to navigate through a Tenant Portal → Master Section just to access core modules like Inventory, Sales, or Purchase. Every task required jumping between completely separate navigation contexts. Nothing was connected.

Businesses were refusing the product, not because they didn't want cloud ERP, but because the cost of learning it felt higher than the benefit of using it.

02 — Discovery & Research

I learned accounting before I opened Figma.

I had no prior accounting background. Rather than jumping straight into interface design, I spent the first weeks learning how businesses actually operate, how sales flow into purchase, how inventory connects to invoicing, how VAT reporting works under Nepali fiscal law.

How I researched

• Sat with business owners: watched real workflows, observed where they paused, got stuck, or used workarounds
• Ran merchant surveys: gathered quantitative data on how businesses track sales, manage rush hours, and handle inventory
• Interviewed customer support: over 60% of recurring tickets were navigation related
• Studied competitors: mapped Tigg, Finpro, Dynamic ERP, and Tally across pricing, features, and deployment
• Shadowed accountants: particularly to understand keyboard heavy workflows and Tally muscle memory

Competitor landscape

The Nepali ERP market was feature focused but usability blind. Every competitor competed on pricing tiers and feature checklists. Nobody was competing on ease of use. That was our opening.

03 — Design Decisions

Five decisions that changed the system.

With research complete, I mapped out the existing information architecture and identified five structural problems that no amount of visual polish could fix. Each required a deliberate architectural decision.

Decision 1 — Navigation architecture

The old system had a fatal flaw: "Master" was a portal hub, not a workspace. Every module (Inventory, Sales, Purchase, Accounting) had its own completely separate navigation context. Switching modules meant starting over mentally.

I explored three approaches:

• Option A: Full mega-sidebar: All modules and sub features in one panel. Too cluttered for 30+ items. Overwhelming for new users.
• Option B: Top navigation only: Horizontal tabs across the top. Doesn't scale. Creates scanning problems at wider viewports.
• Option C: Hybrid: Persistent sidebar + contextual top tabs: Sidebar holds high level modules (always visible). Top tabs handle sub navigation within each module. ✓ This is what we built.

The hybrid approach meant users could stay in their "mental space" (e.g., working in Sales all day) while top tabs gave fast switching between Invoices, Quotations, Orders, and Returns, without ever losing module context.

Decision 2 — Dashboard as command center

The old dashboard was a module launcher with an approval queue. It answered the question "where do I go?" but not "how is my business doing?"

Based on the merchant survey, the top business anxieties were: cash flow, overdue receivables, and pending supplier payments. The new dashboard was designed to answer these questions instantly, without navigating anywhere.

Decision 3 — Invoice form redesign

The invoice form was users' most frequent pain point. In the old design, a massive description text area pushed financial totals below the fold. Users scrolled constantly and lost their place. The action buttons (Save as Draft / Post Bill) competed with no clear visual hierarchy.

In the redesign, I grouped fields logically (Supplier/Customer → Reference → Dates → Line Items → Totals), brought Quick Payment and Additional Cost up as clearly labeled toggles, and kept totals persistently visible in the right panel regardless of line item count.

Decision 4 — Reports from wall of text to structured hub

The old reports page was arguably the biggest usability failure in the system. 25+ report names in 5 columns of plain text. No icons, no categories, no hierarchy. Users had to read every single item to find what they needed.

The redesign introduced clear category groupings with icons, consistent layout, and a search bar — a deliberate decision for power users who know the report name but don't want to scan the full list.

Decision 5 — Bulk upload as a first class feature

Adding 50 inventory items one by one was causing user churn before launch. Bulk upload wasn't a "nice to have," it was the deciding factor for whether a business could even start using the system.

I owned the end to end flow design: defining the required data format, the template generator, the 3 step upload modal (Upload → Summary & Edit → Import), and all error states with row specific feedback.

The critical design decision was introducing a template generator. Users wanted to upload their existing Tally exports directly, but Tally's export format was inconsistent across versions. Our template gave us control over data quality while giving users a familiar spreadsheet based workflow.

04 — Settings Redesign

From buried config tabs to a clear card system.

The old Configuration Settings page buried critical options (user permissions, billing, numbering systems) in tabs inside a single page. The new Settings hub uses a card grid pattern, each card has a title, icon, and description, so users can immediately understand what a setting controls without clicking into it first.

05 — CDXE Module

Designing a distributor connection network.

Beyond the core ERP, I also mapped the user flow for CDXE, which is a distributor management system module that allows businesses to connect with dealers and distributors through the platform. The module handles authorization, connection requests (Accept/Reject), order management, and automated notifications.

I created the full flow diagram to communicate the multi-party interaction model to the engineering team before UI design began, ensuring the technical architecture matched the user journey before any screens were created.

06 — Design System

Components that became the company standard.

As the sole designer working across Inventory, Sales, Purchase, and Accounting modules, consistency was critical. I built a component library in Figma covering the core patterns used across every module, table layouts, row interactions, line item inputs, pagination, and status indicators.

These components weren't just for the ERP. The navigation pattern and component library became the company wide standard, adopted across all subsequent Providhy products.

07 — Localization

Built for Nepali business, not adapted from elsewhere.

One of the strongest design decisions was committing to deep localization, not just translating labels, but designing around Nepali fiscal reality. The VAT Summary Report uses Nepali fiscal month names (Shrawan, Bhadra, Asoj, Kartik, Mangsir), Nepali accounting terminology (करयोग्य बिक्री, जम्मा बिक्री/निकासी), and the Nepali fiscal year format (FY: 82/83).

Early in the project I had tried to simplify accounting terms into plain language. User testing proved this was wrong, accountants and business owners wanted the exact terms they recognized from IRD tax forms. Familiarity wasn't a limitation to design around. It was a feature to design with.

09 — Reflection

What I'd do differently.

Design for keyboard users from day one

I underestimated how deeply accountants rely on keyboard shortcuts. Tally users had years of muscle memory: Tab to move between fields, Ctrl+A to add, Enter to confirm. We built shortcuts post launch, but they should have been foundational. If I were starting over, I'd run a keyboard navigation session in the first round of user testing.

Test with real, messy data earlier

Our initial bulk upload tests used clean, well formatted spreadsheets. Real user data was chaos merged cells, inconsistent product codes, missing required fields. We fixed the error states post testing, but the friction could have been anticipated if we'd asked users to bring their actual Tally export files to the first session.

Familiarity is a feature, not a constraint

The biggest mindset shift I had during this project: in consumer products, innovation is rewarded. In B2B enterprise software especially in a market where users are migrating from a deeply familiar tool familiarity reduces friction. The best design decision I made was keeping IRD standard accounting terminology, even when simpler alternatives felt cleaner. Users didn't want simpler words. They wanted the words that matched their mental model and their legal obligations.

10 — Website Redesign

Fixing the front door while rebuilding the house.

While redesigning the core ERP product, a critical problem emerged: the marketing website wasn't converting visitors into trial signups. The product was getting better, but the acquisition funnel was broken. Bounce rates were high, value proposition was unclear, and visitors couldn't understand what made Providhy different from Tally or competitors.

I led the complete website redesign across homepage, pricing, contact, module pages, blog, documentation, and tutorials, working cross functionally with marketing, sales, and product teams to align messaging with real user needs discovered during ERP research.

The conversion problem

After analyzing session recordings, heatmaps, and running conversion funnel analysis with the marketing team, three critical issues surfaced:

• Weak value proposition: Visitors couldn't quickly understand what made Providhy different from Tally or other ERPs within the first 5 seconds
• No trust signals: Missing social proof, customer logos, testimonials, especially critical in a market where businesses are skeptical of cloud software
• Friction in signup flow: Trial signup asked for payment details upfront, causing 60%+ drop-off before even trying the product
• Feature-focused messaging: Old site listed features. Users wanted to know what problems it solved, not what buttons it had

Cross functional discovery process

Before opening Figma, I ran structured discovery sessions with three teams:

• Marketing team: Analyzed top acquisition channels, bounce rates per page, which landing pages converted best, and where visitors dropped off
• Sales team: Identified the 5 most common objections prospects raised during demos: "Is it as powerful as Tally?", "Can I access it on mobile?", "What if internet goes down?", "How long to migrate?", "Is my data safe?"
• Product team: Reviewed actual feature usage data from existing customers to understand which modules were used most vs which were just marketed loudly

Success & failure metrics (defined upfront)

Before design began, we aligned on measurable outcomes with stakeholders:

Design decisions across key pages

The redesign wasn't just a visual refresh. Each page was architected around a specific user goal and business outcome:

• Homepage: Shifted from feature list to benefit driven hero messaging. Added social proof above the fold (customer logos, testimonial preview). Introduced "See it in action" video demo to reduce uncertainty. Streamlined CTA hierarchy: primary = Start Free Trial, secondary = Watch Demo.
• Pricing page: Redesigned from confusing tier table to clear comparison grid with "Most Popular" tag on mid-tier. Added FAQ section addressing common sales objections. Introduced annual vs monthly toggle with savings callout. Removed payment requirement from trial signup (moved to post-trial conversion).
• Contact page: Replaced generic form with contextual options: "Book a Demo" (for sales), "Get Support" (for existing users), "Partnerships" (for resellers). Added expected response time and live chat widget for instant queries.
• Module pages: Created dedicated pages for each ERP module (Inventory, Sales, Purchase, Accounting) with module-specific screenshots, use cases, and customer stories. Designed for SEO targeting ("inventory management software Nepal").
• Blog: Designed content hub with category filtering (Product Updates, Accounting Tips, Business Growth). Optimized for thought leadership and organic search traffic.
• Documentation & Tutorials: Built structured help center with searchable docs, video tutorials, and step by step setup guides. Designed to reduce onboarding support burden and improve self serve activation.

Design system continuity

The website redesign extended the same design system built for the ERP product, same typography, same color palette, same component patterns. This created a seamless brand experience from marketing site → product trial → active usage. A visitor seeing the website immediately recognizes the product interface, reducing cognitive friction during onboarding.