NABHASTRA
NABHASTRA
CLIENT • UI UX • BRANDING • 2025
CLIENT • UI UX • BRANDING • 2025
ROLE
ROLE
Product Designer (UI/UX)
Brand Designer
Product Designer (UI/UX)
Brand Designer
TIMELINE
TIMELINE
2–3 weeks
2025
2–3 weeks
2025
DELIVERABLES
DELIVERABLES
UI flows + key screens
Logo + brand basics
UI flows + key screens
Logo + brand basics
SKILLS
SKILLS
UI/UX Design
Information Architecture
Visual Design
Brand Identity
UI/UX Design
Information Architecture
Visual Design
Brand Identity
OVERVIEW
OVERVIEW
How do you make booking a drone farm service feel as simple as booking a slot?
How do you make booking a drone farm service feel as simple as booking a slot?
Nabhastra is a client project where I designed the end user booking experience for drone based farm services. The goal was to make a high trust service feel quick and obvious, while still respecting constraints like location, timing, and service completion.
As a solo designer, I shipped the customer journey in a 2 to 3 week window, working from a business vision doc and tight delivery timelines.
Nabhastra is a client project where I designed the end user booking experience for drone based farm services. The goal was to make a high trust service feel quick and obvious, while still respecting constraints like location, timing, and service completion.
As a solo designer, I shipped the customer journey in a 2 to 3 week window, working from a business vision doc and tight delivery timelines.
End User UX
End User UX
Designing the customer booking flow from discovery to confirmation, with clear steps and fewer drop offs.
Designing the customer booking flow from discovery to confirmation, with clear steps and fewer drop offs.
Brand Extension
After UI delivery, extending the work into branding by designing the logo and basic brand system to match the product.
Decision first UI
Building tight information architecture so users can choose service, location, and time without second guessing
Decision first UI
Decision first UI
Building tight information architecture so users can choose service, location, and time without second guessing
Building tight information architecture so users can choose service, location, and time without second guessing
Brand Extension
Brand Extension
After UI delivery, extending the work into branding by designing the logo and basic brand system to match the product.
After UI delivery, extending the work into branding by designing the logo and basic brand system to match the product.
THE REALITY CHECK
THE REALITY CHECK
Constraints I designed around
Constraints I designed around
No time for a full research sprint
So I relied on quick alignment with the client, clear assumptions, and fast iteration.
Not a normal booking problem
No time for a full research sprint
So I designed around real constraints like coverage, scheduling, and service completion.
So I relied on quick alignment with the client, clear assumptions, and fast iteration.
Not a normal booking problem
So I designed around real constraints like coverage, schedulinga and service completion.
No room for end-of-flow confusion
So the UI prioritised decision clarity, strong confirmations, and fewer dead ends.
Scope expanded mid-project
So I built the UI system to extend into branding quickly when the client asked.
No room for end-of-flow confusion
No time for a full research sprint
So the UI prioritised decision clarity, strong confirmations, and fewer dead ends.
So I relied on quick alignment with the client, clear assumptions, and fast iteration.
Not a normal booking problem
So I designed around real constraints like coverage, schedulinga and service completion.
No room for end-of-flow confusion
So the UI prioritised decision clarity, strong confirmations, and fewer dead ends.
Scope expanded mid-project
So I built the UI system to extend into branding quickly when the client asked.
Scope expanded mid-project
So I built the UI system to extend into branding quickly when the client asked.
No time for a full research sprint
So I relied on quick alignment with the client, clear assumptions, and fast iteration.
Not a normal booking problem
So I designed around real constraints like coverage, schedulinga and service completion.
No room for end-of-flow confusion
So the UI prioritised decision clarity, strong confirmations, and fewer dead ends.
Scope expanded mid-project
So I built the UI system to extend into branding quickly when the client asked.
SOLUTION
SOLUTION
From booking to completion, one flow farmers can trust.
From booking to completion, one flow farmers can trust.
I designed the customer journey for drone-based farm services, from discovery to proof of completion.
The system prioritises decision clarity, strong confirmations, and real-world constraints like coverage and scheduling.
I designed the customer journey for drone-based farm services, from discovery to proof of completion.
The system prioritises decision clarity, strong confirmations, and real-world constraints like coverage and scheduling.
Decision-first booking
Service, crop, and schedule are structured to prevent wrong requests.
Visibility during service
Live tracking + status states reduce anxiety and support calls.
Clear closure
Summary and confirmation make “done” feel trustworthy.
Visibility during service
Live tracking + status states reduce anxiety and support calls.
Clear closure
Summary and confirmation make “done” feel trustworthy.
Decision-first booking
Service, crop, and schedule are structured to prevent wrong requests.
Visibility during service
Live tracking + status states reduce anxiety and support calls.
Clear closure
Summary and confirmation make “done” feel trustworthy.
CORE FLOWS
CORE FLOWS
The journeys that carry the product
The journeys that carry the product
These flows reduce wrong requests and keep the service clear from booking to closure.
These flows reduce wrong requests and keep the service clear from booking to closure.
Booking a Service
A decision-first flow that turns a high-trust request into a clear, confirmable booking.
Tracking the Service
Live status + location visibility that reduces anxiety and support calls.
Buy or Lease a Drone
Compare models, pick buy vs lease, and submit a request in minutes.
Tracking the Service
Live status + location visibility that reduces anxiety and support calls.
Buy or Lease a Drone
Compare models, pick buy vs lease, and submit a request in minutes.
Booking a Service
A decision-first flow that turns a high-trust request into a clear, confirmable booking.
Tracking the Service
Live status + location visibility that reduces anxiety and support calls.
Buy or Lease a Drone
Compare models, pick buy vs lease, and submit a request in minutes.
DESIGN DECISIONS
DESIGN DECISIONS
Design decisions under real constraints
Design decisions under real constraints
With limited research time and real-world stakes, I prioritised decision clarity, guardrails, and strong confirmations over feature density.
With limited research time and real-world stakes, I prioritised decision clarity, guardrails, and strong confirmations over feature density.
The homepage limits decisions to four primary actions, and the booking screen turns a high-stakes request into two structured choices before scheduling.
Scheduling and payment were designed as trust moments: commit to a slot, verify the request, and close with proof
Tracking is designed to reduce uncertainty with visible status, ETA, and proof of completion, while keeping support one tap away
Buy/Lease is designed as a low-friction decision flow: compare quickly, validate with proof, reuse details, then submit with clear confirmation.
Scheduling and payment were designed as trust moments: commit to a slot, verify the request, and close with proof
Tracking is designed to reduce uncertainty with visible status, ETA, and proof of completion, while keeping support one tap away
Buy/Lease is designed as a low-friction decision flow: compare quickly, validate with proof, reuse details, then submit with clear confirmation.
The homepage limits decisions to four primary actions, and the booking screen turns a high-stakes request into two structured choices before scheduling.
Scheduling and payment were designed as trust moments: commit to a slot, verify the request, and close with proof
Tracking is designed to reduce uncertainty with visible status, ETA, and proof of completion, while keeping support one tap away
Buy/Lease is designed as a low-friction decision flow: compare quickly, validate with proof, reuse details, then submit with clear confirmation.
VISUAL SYSTEM
A UI system built for clarity in the field
I kept the interface lightweight, readable, and repeatable across booking, tracking, and buy or lease. The goal was low confusion, fast decisions, and a consistent trust feel
I defined a small set of reusable components that stay consistent across booking, tracking, and buy or lease. The goal was predictable decisions, fewer wrong requests, and clear confirmation at each step.
One decision per surface
Cards are single-purpose: select a service, choose a time, confirm a request. No mixed actions, no scrolling puzzles.
Green is reserved for commitment
#489841 only appears for primary actions, selected states, and success. Everything else stays neutral so users do not misread importance
Defaults reduce effort, not control
Saved details, suggested slots, and quick actions speed up repeat bookings, but every critical field is still reviewable before payment
Green is reserved for commitment
#489841 only appears for primary actions, selected states, and success. Everything else stays neutral so users do not misread importance
Defaults reduce effort, not control
Saved details, suggested slots, and quick actions speed up repeat bookings, but every critical field is still reviewable before payment
Status is feedback, not decoration
Tracking and progress states act as reassurance: stage, ETA, and what happens next are always visible.
Status is feedback, not decoration
Tracking and progress states act as reassurance: stage, ETA, and what happens next are always visible.
VISUAL SYSTEM
A UI system built for clarity in the field
I kept the interface lightweight, readable, and repeatable across booking, tracking, and buy or lease. The goal was low confusion, fast decisions, and a consistent trust feel
I defined a small set of reusable components that stay consistent across booking, tracking, and buy or lease. The goal was predictable decisions, fewer wrong requests, and clear confirmation at each step.
Defaults reduce effort, not control
Saved details, suggested slots, and quick actions speed up repeat bookings, but every critical field is still reviewable before payment
Green is reserved for commitment
#489841 only appears for primary actions, selected states, and success. Everything else stays neutral so users do not misread importance
Defaults reduce effort, not control
Saved details, suggested slots, and quick actions speed up repeat bookings, but every critical field is still reviewable before payment
Status is feedback, not decoration
Tracking and progress states act as reassurance: stage, ETA, and what happens next are always visible.
Defaults reduce effort, not control
Saved details, suggested slots, and quick actions speed up repeat bookings, but every critical field is still reviewable before payment
Green is reserved for commitment
#489841 only appears for primary actions, selected states, and success. Everything else stays neutral so users do not misread importance
Defaults reduce effort, not control
Saved details, suggested slots, and quick actions speed up repeat bookings, but every critical field is still reviewable before payment
Status is feedback, not decoration
Tracking and progress states act as reassurance: stage, ETA, and what happens next are always visible.
BRANDING EXTENSION
A minimal identity designed to scale from wordmark to app icon
After the UI delivery, the scope expanded into branding. I created a simple mark and wordmark that carry the same trust cues as the product UI, then validated it at app-icon scale
Consistent trust cues
The identity borrows the product’s calm, confirmation-first tone so the brand feels reliable, not flashy
Icon-first legibility
The mark is built to stay distinct at app-icon size and still work as part of the full lockup
High-contrast
Black and white usage ensures the logo holds up across devices, backgrounds, and real-world lighting
Easy to re-use
A minimal system makes it hard to misuse: one mark, one wordmark, clear spacing, consistent outcomes
Consistent trust cues
The identity borrows the product’s calm, confirmation-first tone so the brand feels reliable, not flashy
Icon-first legibility
The mark is built to stay distinct at app-icon size and still work as part of the full lockup
High-contrast
Black and white usage ensures the logo holds up across devices, backgrounds, and real-world lighting
Easy to re-use
A minimal system makes it hard to misuse: one mark, one wordmark, clear spacing, consistent outcomes
BRANDING EXTENSION
A minimal identity designed to scale from wordmark to app icon
After the UI delivery, the scope expanded into branding. I created a simple mark and wordmark that carry the same trust cues as the product UI, then validated it at app-icon scale
Consistent trust cues
The identity borrows the product’s calm, confirmation-first tone so the brand feels reliable, not flashy
Icon-first legibility
The mark is built to stay distinct at app-icon size and still work as part of the full lockup
High-contrast
Black and white usage ensures the logo holds up across devices, backgrounds, and real-world lighting
Easy to re-use
A minimal system makes it hard to misuse: one mark, one wordmark, clear spacing, consistent outcomes
Consistent trust cues
The identity borrows the product’s calm, confirmation-first tone so the brand feels reliable, not flashy
Icon-first legibility
The mark is built to stay distinct at app-icon size and still work as part of the full lockup
High-contrast
Black and white usage ensures the logo holds up across devices, backgrounds, and real-world lighting
Easy to re-use
A minimal system makes it hard to misuse: one mark, one wordmark, clear spacing, consistent outcomes
REFLECTION
REFLECTION
What I learned
What I learned
Trust is designed in steps
Trust is designed in steps
In high-stakes services, users trust the flow when every stage is explicit: selection, schedule, confirmation, tracking, closure. Progress states and proof matter as much as the booking
In high-stakes services, users trust the flow when every stage is explicit: selection, schedule, confirmation, tracking, closure. Progress states and proof matter as much as the booking
Guardrails beat freedom
Guardrails beat freedom
I reduced wrong requests by turning the booking into a few structured choices, not a dense form. Clear constraints and limited options kept decision-making fast and error-resistant
I reduced wrong requests by turning the booking into a few structured choices, not a dense form. Clear constraints and limited options kept decision-making fast and error-resistant
Systems thinking beats screen thinking
Systems thinking beats screen thinking
A booking app is not just UI. It is scheduling, coverage, service completion, and support. The interface needs to reflect the real operational model, not an ideal flow
A booking app is not just UI. It is scheduling, coverage, service completion, and support. The interface needs to reflect the real operational model, not an ideal flow
Constraints sharpen priorities
Constraints sharpen priorities
With limited time for heavy research, I leaned on alignment, assumptions, and iteration. The result is a clarity-first system that can be validated and strengthened with field testing
With limited time for heavy research, I leaned on alignment, assumptions, and iteration. The result is a clarity-first system that can be validated and strengthened with field testing