Every UI/UX project I take on follows a structured process — not because I'm rigid about it, but because I've learned, through dozens of real projects, that skipping steps costs time, money, and quality. This is that process, broken down honestly from the very first client call to handing over the final prototype.
Whether you're a designer wanting to see how someone else works, or a client trying to understand what goes into a proper UX engagement, this should give you a clear picture.
Why Process Matters in UI/UX
UI/UX design is not just about making screens look good. At its core, it's about solving real problems for real people — and that requires understanding those people deeply before picking up any design tool. A process gives structure to what could otherwise be chaotic and subjective work.
Without a process, designers make decisions based on personal taste rather than user needs. With a clear process, every decision is grounded in research, reason, and testing.
The Tools I Use
My 7-Step UI/UX Process
What Gets Delivered to the Client
At the end of a UI/UX project, the client receives:
- Research documentation — User personas, interview findings, competitor analysis
- User flow diagrams — Complete maps of how users move through the product
- Wireframes — All screens in low-fidelity with annotations
- High-fidelity designs — Every screen in final visual quality
- Interactive prototype — A clickable Figma prototype of the core user flows
- Design system — Component library, colour palette, typography guide
- Developer handoff — Specs, measurements, and asset exports ready for development
Inside My Figma Workflow
Figma is where the majority of my design work lives. Here's how I actually set up and work within a project file — because how you use Figma matters as much as whether you use it.
File structure
Every project gets one main Figma file with pages organised like this: 01_Research (personas, affinity maps), 02_Information Architecture (sitemap, user flows in FigJam), 03_Wireframes, 04_Design System (components, tokens), 05_UI Designs (all final screens), 06_Prototype (interactive flows for testing). This structure means any stakeholder can navigate the file and see the project's full story.
Components and Auto Layout
I build everything from components. Buttons, input fields, cards, navigation bars — all created as master components with variants for different states (default, hover, focus, error, disabled). I use Figma's Auto Layout extensively — almost every frame I create uses it. This means designs automatically adapt when content changes, which makes responsive design and content updates far less painful.
Design tokens and variables
For every project I define a token set: colour (primary, secondary, semantic tokens like `color/error/default`), spacing (4px base grid → 4, 8, 12, 16, 24, 32, 48, 64px), typography (scale from body to display headings), and border radius. Using Figma Variables means changing the primary colour or base spacing across 50 screens takes 10 seconds, not 10 hours.
Handoff for developers
Before handoff I run a complete audit: check every component is detached or linked properly, all colours use variables (no hexes floating in individual layers), spacing is consistent with the 4px grid, and all assets are named clearly for export. I share the Figma link with view access and record a Loom walkthrough explaining the design system and key interactions. Developers tell me this is rare — and it prevents a huge amount of back-and-forth.
Conducting User Research in Nepal
User research in the Nepali context has specific nuances that international UX textbooks don't cover. Here's what I've learned from doing it for real.
Language is a genuine consideration. Many users — particularly older demographics, small business owners in Terai cities, or tourism workers outside Kathmandu — are more comfortable in Nepali than English. I conduct interviews in Nepali when needed, and design research protocols that don't assume English literacy. For the Swaadd food delivery project, all user interviews were conducted in Nepali, and the app copy exists in both languages.
Smartphone usage patterns differ. Nepal has extremely high mobile penetration but relatively low desktop usage. Users are predominantly on Android, often on mid-range devices with 2–3 GB RAM. I test prototypes on actual mid-range Android devices — not just the latest iPhone. Network conditions matter too: designs that assume fast 5G connectivity fail users on 4G LTE with limited data plans. I optimise for slower connections, lighter image weights, and offline-tolerant UI patterns where possible.
Trust signals are different. In the Swaadd and खाना projects, research revealed that Nepali app users trust products with visible phone numbers and physical addresses far more than those without them — unlike Western markets where this is rarely a factor. Social proof via Facebook (not just star ratings) was the most referenced trust mechanism. These findings directly shaped the UI: we put contact information prominently visible on the app's home screen rather than buried in settings.
Remote testing works, but in-person is better. I prefer in-person usability testing in Nepal when possible. Screen recording tools and remote testing platforms like Maze are powerful, but face-to-face sessions in Kathmandu coffee shops or at the client's location reveal behavioural nuances — hesitation, confusion, workarounds — that remote testing misses. A user who confidently clicks through a remote test may reveal critical confusion when you watch them use it in person.
Accessibility — Designing for Everyone
Accessibility is not optional. It's not a nice-to-have for clients who ask about it. It's a fundamental quality standard that every design should meet — and in Nepal, where a significant proportion of users have older devices, slower connections, or varying literacy levels, accessible design often just means better design.
- Colour contrast: I check every colour combination against WCAG AA (minimum 4.5:1 for body text, 3:1 for large text). I use the Figma plugin "Contrast" to catch issues before handoff. This matters especially because many users with colour vision deficiency (around 8% of men globally) will use your product.
- Touch target sizes: Minimum 44×44px for all interactive elements. On mobile, cramped touch targets cause frustration and errors — especially for users with larger fingers or motor difficulties.
- Focus states: Every interactive element must have a visible focus indicator for keyboard navigation. I design these explicitly — they're often forgotten by designers who only use a mouse.
- Text legibility: Body text minimum 16px. Never use text below 14px for functional UI elements. Line height of 1.5–1.8 for body copy. These are standards I follow on every project.
- Error messaging: Errors should never rely on colour alone. Always include an icon and descriptive text. "This field is required" is better than just turning the border red.
The Biggest Lesson I've Learned
The most important thing I've learned doing UI/UX work is this: users don't think like designers. What seems obvious to someone who built or designed a product is often completely unclear to a first-time user.
This is why testing is non-negotiable. I've had designs I was deeply proud of completely fail in usability tests — and those failures made the final product dramatically better. Ego has no place in good UX design.
How Long Does a UI/UX Project Take?
It depends entirely on scope. A simple landing page or app feature can go from brief to prototype in 1–2 weeks. A full product — a multi-screen web app or mobile application — typically takes 4–12 weeks depending on complexity and the number of iteration rounds involved.
I always recommend building in time for at least two rounds of usability testing. The first round tells you what's wrong. The second confirms the fixes worked.
Working with Me on a UI/UX Project
I approach every project as a collaborative partner — not just someone who takes a brief and disappears. I involve clients at every major milestone, share work early and often, and explain my decisions rather than just presenting them.
If you have a product idea you want to bring to life, or an existing product that needs a proper UX overhaul, I'd love to hear about it. Based in Bhaktapur, Nepal — working with clients worldwide.