These four icons swap the whole page: gamer, kitchen, chef or biker. Same facts, four tellings.
1 / 2
Boring / Fancy
Boring drops the costume and the motion for a plain, skimmable page. Fancy is the show.
2 / 2
Player 1 · Tonight’s chef · Tonight’s tasting · On the road · Lead UX Designer · Hyderabad
VasudevanVenkataraman
Vasudevan is a UX leader who turns messy requirements into flows people actually understand, builds teams that run on curiosity rather than chaos, and asks “why does this need six clicks?” so users don’t have to.
He refers to himself in the third person because it sounds cool.
Rarity colours are vibes, not a ranking. Every quest shipped.Course labels are for fun, not a ranking. Every dish went out.Each course is a recipe: ingredients, method, plating and a taste test.Five stops. Each one taught something.Five projects, newest ideas first.
My role
No full case study for this role yet. The projects below carry it.
LegendarySignature dishCourse IStop 1
Dhruva Space
Earth observation · Indian aerospace · Minfy Technologies
Solo designer
UX Designer
UX Researcher
Visual Designer
Two applications. One lets a user plot a point on the map, see every satellite pass over it and book a pass for imaging. The other runs Ground Station as a Service, from start to finish, for ground stations.
ObstacleConstraintIngredientsTerrainProblem
Satellite operators share availability in three ways. Some publish their schedules, some show them only on request, and some are request-only.
The moveMethodMethodLine takenDecision
One booking module takes in all three models and generates the right request. Users plan a pass without learning how each operator works.
LootPlatingPlatingResultOutcome
Design came first on both apps, so the team never got stuck. Customers, including government agencies, used it again and again, and the product was white-labelled for a foreign space agency. Minfy still uses the work as its example of structured, scalable design.
Taste test
Customers, including government agencies, used it again and again, and the product was white-labelled for a foreign space agency. Minfy still uses the work as its example of structured, scalable design.
EpicChef’s specialCourse IIStop 2
Vanix
Indian IoT device for cows · Minfy Technologies
UX Designer
Mentor
The app for a device that tracks cows’ heat cycles and health.
ObstacleConstraintIngredientsTerrainProblem
Heat lasts only a short window. A farmer who hears late has missed it.
The moveMethodMethodLine takenDecision
A full-screen alert that cannot be ignored or swiped away, so the farmer knows the moment heat starts.
LootPlatingPlatingResultOutcome
The first project scoped with the SOW after discovery. Design and dev leads gave their input up front, and the team shipped with 15% of the timeline left.
Mise en placeThe SOW waited for discovery, with design and dev leads in the room. Prep before you light the fire.
Side questChef’s noteChef’s noteDetourSide noteHeat and fever both raise a cow’s temperature. A combined signal of temperature rise plus movement can indicate which one it is.
RareSeasonalCourse IIIStop 3
One Trace
Australian enterprise platform · Minfy Technologies
Solo designer
UX Designer
UX Researcher
Visual Designer
Requirements (FRD)
A platform between enterprises and vendors for machinery and part repair, by cost or under warranty.
ObstacleConstraintIngredientsTerrainProblem
Scope creep and delay.
The moveMethodMethodLine takenDecision
A feature requirement document for every feature, so each one stuck to its definition.
LootPlatingPlatingResultOutcome
The turnaround for each feature fell by about 65%, from two weeks to four days. The team still writes them.
Taste test
The team still writes them.
UncommonSide dishCourse IVStop 4
Tapeark
Australian tape-to-cloud backup · Minfy Technologies
Solo designer
UX Designer
UX Researcher
Visual Designer
Converts physical tapes into cloud backups for companies. The first Minfy project with a full team: PM, front end and back end.
ObstacleConstraintIngredientsTerrainProblem
The backend was already built and there was no SOP. Designs kept clashing with its constraints and had to be redone.
The moveMethodMethodLine takenDecision
After each sketch, the whole team sits together and discusses it before it is finalised.
LootPlatingPlatingResultOutcome
Feasibility gets settled at the sketch stage. Minfy still works this way.
Taste test
Minfy still works this way.
SpeedrunQuick biteCourse VStop 5
Gharpe Diagnostics
At-home lab tests · Minfy Technologies
Solo designer
UX Designer
UX Researcher
Visual Designer
Brings X-ray and ECG machines home for lab tests. The first project after joining Minfy.
ObstacleConstraintIngredientsTerrainProblem
One designer, one developer and a short clock.
The moveMethodMethodLine takenDecision
Design and prototype, end to end, built alongside the developer.
LootPlatingPlatingResultOutcome
Done in 16 days.
More projects, and my role in each
As a designer
Sumeria Space
Solo designer
UX Designer
UX Researcher
Visual Designer
Eberhard
Solo designer
UX Designer
UX Researcher
Visual Designer
Nextweather
Solo designer
UX Designer
UX Researcher
Visual Designer
ISOCS · one portion of it
Solo designer
UX Designer
UX Researcher
Visual Designer
Experience centre interactive visual · built for the Minfy office
UX Designer
Visual Designer
Stratumetrics
UX Designer
UX Researcher
Mentor
Ascent
UX Designer
UX Researcher
Mentor
As a mentor
Groome
Mentor
LSL Plus
Mentor
Eastwood · school intake examination app
Mentor
Global Nomad
Mentor
Illuminr
Mentor
Xovian Aerospace
Mentor
BARC
Mentor
More saves at MinfyMore dishes at MinfyMore courses at MinfyMore stops at MinfyMore work at Minfy
Xovian Aerospace · three more projects followedEastwood · school intake examination appProofs of concept: Asian Paints, Indus Towers, GoLive, Illuminr
Earlier savesEarlier kitchensEarlier menusEarlier ridesEarlier work
Lens Redesign · acquisition up 13%PulseProteinmetricsHospinet InfraHoovi ridesharingPet Adoption Shelter
PerksHouse rulesMise en placePit stopWorking practices
Habits that stayed at Minfy after the project ended.Rules that stayed in the kitchen after service.Prep before the fire. These habits stayed after service.What each ride taught, fitted before the next one.Practices that stayed at Minfy after the project ended.
Buy menu · pick a loadoutTasting menu · pick a courseTasting menu · pick a pairingRide mode · pick oneReorder for the role
Everything, in the order I would tell it.
Loadout pickCourse pickPairingMode pickRelevantLearned on Tapeark
Sketch reviews
Every sketch gets a team review with PM, front end and back end before it is finalised.
Feasibility settled early
Loadout pickCourse pickPairingMode pickRelevantLearned on One Trace
A document per feature
Each feature gets a requirement document, so scope cannot drift between design and build.
Turnaround per feature: down about 65%
Loadout pickCourse pickPairingMode pickRelevantLearned on Vanix
SOW after discovery
Pre-sales used to set timelines before design and dev had seen the problem. Now the SOW waits for discovery, with leads from both in the room.
Design’s share of the standard project timeline has at least doubled, after a lot of arguing.
2x or more design time
Skill treePantryPantryGearSkills
Filled markers have proof behind them. Click one to read it. Right-click or long-press any marker to ping it.
PartyBrigadeBrigadeCrewTeam
Onboarded and mentored 5 designers at Minfy, and 2 at Outliersoft. Leading 4 today.
Party leaderHead chefHead chefLead riderLead
Vasudevan
Reviews UX direction across projects and still owns UX strategy.
Senior designer
Lead in training
Being groomed into a lead, so there is always a backup.
Senior designer
Senior
Joins every brainstorm and review.
Junior designer
Junior
Joins every brainstorm and review.
Junior designer
Junior
Joins every brainstorm and review.
Brainstorming is a standing habit. Every project gets discussed, argued over and debated until the idea holds.
On Xovian Aerospace, the aim was to guide a newly hired senior designer without spoon-feeding him. The client was happy enough to send three more projects.
Career map. The fog is the next chapter.Career log, newest first. Tap a ticket.Eight courses served, dessert still to be decided.Every mile, start to now.Newest first.
May 2023 → now
Minfy Technologies
Lead UX Designer, May 2024 to now · Sr. UX Designer, May 2023 to April 2024
Joined as the first designer and the fourth hire, in the Intelligent Apps product team. Built the UX practice from scratch. It is now a team of 4 working across aerospace, healthcare, industrial services, logistics, weather analytics and data platforms. Wrote the team’s design SOPs. Of the policies I put to the company, one was adopted: discovery before the SOW, which works more as a design SOP. I also changed how design and dev work together. The whole team talks and brainstorms before design starts, so developers meet no surprises, and they build from a document and a prototype. A design system I built cut POC designs from four days to two.
Oct 2021 → Mar 2023
Zendrive Technologies
Product Designer
Revamped the customer journey for the Insurance Qualification Lens (IQL), and customer acquisition rose 13%. Publisher satisfaction went from 3.0 to 4.5. A full IQL redesign onboarded 3 new publishers to the White Label App.
Oct 2018 → Oct 2021
Outliersoft Technologies
UX Designer
Enterprise healthcare, aviation and analytics platforms for Prudential (Pulse, Proteinmetrics) and FedEx Aviation. Led and mentored a team of 2 designers.
Jul 2017 → Sep 2018
Embark Mobility Labs
Jr. Designer / Partner · Chennai
First design job. Co-built a mobility product from concept to prototype: research, UX strategy, interaction design and investor presentations.
Oct 2012 → Jul 2017
Tutorial zone · Before the kitchen · Before the kitchen · Before the bike · non-design
Amazon
Team Lead · Hyderabad
Led large-scale publishing operations and mentored the team.
2010 → 2012
Tutorial zone · Before the kitchen · Before the kitchen · Before the bike · non-design
Accenture, then Cognizant
Accenture, Jul 2010 to Dec 2010 · Cognizant (CTS), Feb 2011 to Jan 2012
2006 → 2010
Madras Institute of Technology
B.E. Automobile Engineering
Off dutyOff the lineAfter serviceOff the bikeOutside work
Side classes. Mostly harmless.Off the clock. Mostly edible.Off the clock. Mostly edible.Not riding. Mostly.Interests outside work.
Side classOff the clockOff the clockOff the bikeInterest
Gamer
Apex, Dota 2, CS2, Sekiro and Wukong. Overanalyses game interfaces, which counts as research.
Side classOff the clockOff the clockOff the bikeInterest
Biker
Rides a KTM 390 Duke. Prefers routes where nobody asks for six clicks.
Side classOff the clockOff the clockOff the bikeInterest
Chef
Mise en place before the fire. It is also why scoping now waits for discovery.
Side classOff the clockOff the clockOff the bikeInterest
Movie watcher
Avid. Five that earned a permanent spot.
Side classOff the clockOff the clockOff the bikeInterest
Songwriter
Writes songs and composes them.
Side classOff the clockOff the clockOff the bikeInterest
Photographer
Frames shot by me. Wheels, dogs, light.
Also an anime freak. *Self-proclaimed.
Join the partyReserve a tableReserve a tableRide with meContact
Search a place and see every satellite that can see it.
Domain
Earth observation
Company
Minfy Technologies
Platform
Web app
My role
Solo designer across UX, UX research and visual design
Timeline
Since January 2025, and still ongoing
The brief
One sentence, a lot of physics
Dhruva Space already builds satellites. They wanted to enter Earth observation and put that technology to work for people who need images of specific places on Earth, for surveys, security and other uses.
The ask came down to one line: let a user search a location and see every satellite pass around or over it.
When I have a place in mind, I want to see what can image it and when, so I can decide what to book.Job to be done
Who it was for The users were mostly corporates and agencies, including government agencies, who wanted to find a place and download photos of it.
The discussions
What sat behind the search box
We spent a lot of time on what the system could honestly promise. Four areas kept coming back.
Restricted areas
Some places cannot simply be imaged. Users need to find out early, and they need a way to ask.
Orbits and pass timing
Orbits change, and orbital decay moves where a satellite will be. Every time we show has to be one we can stand behind.
Ground contact
A picture only counts once it is back on the ground. That depends on ground station control, RF signal strength, what happens when a connection breaks, and how files are transferred. Big files ended up going out over FTP. An incomplete pass is finished on the next one by partial transfer, even without a new booking.
Cloud and weather
A pass can arrive on time and still return a picture of clouds.
The approach was direct. I built it on the patterns of a B2C platform, so the experience stays plain even though what sits behind it is not.
The structure
Sketches
Four low-fidelity sketches of how the product is laid out: one search bar, several ways to mark an area, passes by time range, and a clear path when an area is restricted. I redrew them for this case study from the flow map and the final screens, because the originals were not kept.
Landing. The screen opens on an earth view with one search bar for where, when and provider.Marking the area. The user clicks numbered points to close a shape, a coach mark guides first-timers, and a panel shows the coordinates and size.Passes. Fresh lists the passes that are coming up, Archive lists what has already been captured, and each one shows its cloud figure.Restricted areas. The warning comes during search, and the user can send a request with a reason and wait for an answer.
The flow
End user flow map
The map of the whole journey, from login to order history. It is the backbone for the screens and for the customer journey below.
Login onlyThere is no sign-up. People arrive with an account.
Place firstThe landing page opens on an earth view with no filters selected, so the first move is always the place.
Two time rangesFresh covers what is coming up, from the next 24 hours to all. Archive covers what has been captured, from the last 24 hours to all.
CreditsPayment is from prepaid credits, so the cart step is a short one.
Added laterRecurrence options and several passes in one order came after launch, from user feedback. They live in the cart, so this map does not show them. At launch an order was one pass.
The screens
What people saw
Six screens from the search step, from landing to a restricted-area request and the order. Provider names are blurred.
Landing. The screen shows an earth view and one search bar. The three area tools sit on the right, and no filters are picked.First-time tour. The tour walks the user through drawing a polygon, with Skip and Next on every step.Restricted area. The warning appears during search and gives the user the choice to send a request.The request. The user says why they need the area, and gets an answer later.Results. Each pass lists its angle, resolution, date and area, with filters across the top and a cart button on every row.Parameters. The user sets the tasking and the type of capture for each provider, and can save them as defaults.
The customer journey
From a place to a picture
Seven stages, taken from the flow map. Each one starts from what the person wants. The worries come from my time on the project, and the confidence line is my reading of them.
Likely confidence along the journey · my reading of the worries
1Arrive
Wants
The user wants to get to their place without a tour.
Does
The user logs in and lands on an earth view with an empty search bar.
Worry
The user may not know where to start, and the landing page decides whether they get going at all.
Design response
Nothing is preselected, and the search bar asks only for where, when and provider.
2Mark the place
Wants
The user wants to tell the system exactly which area they mean.
Does
The user types a place, drops a pin, sets a radius, enters coordinates, draws a shape or uploads a KML file.
Worry
The worry was discoverability. There are several ways to say where, and people may not find the one that fits them.
Design response
People already know Google Maps, so the map behaves the way they expect. The other ways of marking a place sit in the open next to it, which invites exploring, and KML is offered because people in the space industry already know it. An 8-step coach-mark tour helps first-timers, and a restricted-area warning gives a request path.
3Read the passes
Wants
The user wants to see which satellites can image the area, and when.
Does
The user filters by resolution, date, angle, cloud cover, imagery type (SAR or optical) and processing level, and switches between Fresh and Archive.
Worry
The user worries whether a pass will give a usable image, because of cloud, weather or an incomplete pass.
Design response
The cloud and weather projection is shown, with a plain note that a pass may not deliver. An incomplete pass is finished on the next pass by partial transfer, even without a new booking, so delivery is delayed but it still arrives.
4Build the order
Wants
The user wants to pick a pass and be done.
Does
At launch the user picked one pass and ordered it. Later, a single order could hold several passes and task types, and it could repeat.
Worry
Choosing among multiple passes was the worry, because at first it was one pass and done.
Design response
We launched with single orders to keep things simple. Multiple passes and recurrence came later.
5Pay with credits
Wants
The user wants to pay and move on.
Does
The user reviews the cart and pays from prepaid credits, and the balance sits in the header.
Worry
Payment was never a worry, because the credits are prepaid.
Design response
Prepaid credits keep this step short.
6Wait
Wants
The user wants to know when the image will arrive, and whether the pass failed.
Does
The user waits for the pass and the delivery, gets a notification when the job completes, and checks the order status.
Worry
The worry was the ETA of the delivery.
Design response
The ETA, and any failure of a pass or a connection, is stated directly and transparently through notifications and order statuses.
7Receive, return
Wants
The user wants to get the image and find it again later.
Does
The user views the photo, downloads the images, checks the order history with invoices, and can cancel or track an order.
Worry
The worry was how a big file reaches the user.
Design response
Large files are sent by FTP, which carries large volumes at high speed and is more secure.
The hard call
Single orders first
We launched with single orders: pick one pass and you are done. Choosing among several passes was the worry, so several passes in one order, and later recurrence, came after launch.
Every order shows the cloud and weather projection for its pass, and says plainly that there is always a chance it will not work. We wanted to keep it simple, and to see whether implementation and customer acceptance went more easily that way.
What happened
People kept using it
Customers came on board, including government agencies. They tried it, were impressed, and used it again and again. One ran it on site.
The product was white-labelled for a foreign space agency. The project is still going, and it began in January 2025.
Case study · Minfy Technologies
TapeArk
Move a company’s old backup tapes to the cloud, and get any file back when it is needed.
Domain
Tape-to-cloud data migration
Company
Minfy Technologies
Platform
Web: customer portal and admin console
My role
Solo designer: UX, UX research and visual design, with full control of the design
Team
A PM, front-end and back-end developers. Minfy’s first project with a full team.
The brief
Boxes of tapes, and no way to see them
TapeArk collects a company’s physical backup tapes, including legacy formats few others handle, audits them, loads the data into the cloud, and brings back any file on request.
The client came with the technology, a brand guide, user stories, a tentative feature set and a basic flow. The experience around them was still to be made.
What we had
How the system works, for the end user and for the admin
A clear idea of what was required
A brand guide
User stories
A tentative feature set and a basic flow
What we needed
Competitive research
Features split into priorities, and an MVP list
A customer journey map and an impact matrix
A flow map
Wireframes, visual design and a prototype
When my old tapes are costing me rent and few services can read them, I want to move the data to the cloud and get any file back when I need it, so I can stop worrying about the tapes.Job to be done
The research
Why not just rent a device?
I interviewed clients across different companies, and read the main alternatives: AWS Snowball, Google’s Transfer Appliance, Azure Data Box and IBM Cloud. The device-based options ask the customer to handle the logistics and the rental, and some tape formats are not supported at all. That left TapeArk four things to be known for.
Tape expertise
Built around tape, including legacy and niche formats.
End to end
Cataloguing, secure transport, restore and ingestion, all handled by one service.
Any cloud
Not tied to one provider, so the customer chooses where the data lands.
Tailored
Services shaped to the problem, such as unusual formats and data checks.
The customer journey
From a shelf of tapes to a restored file
The journey map from my research, redrawn. It is built from interviews with clients across different companies. The line is the customer’s mood: high where TapeArk takes work off them, low where they are left guessing. Quotes are close to their words.
Decide
Approach
Subscribe
Submit & pickup
Audit & ingestion
Complete
Does
Wants to move all the tapes to the cloud
Searches for options
Few options available
Not effective, because of the recurring rental charges
Legacy tapes are not supported
Finds out about TapeArk
Is happy with the offerings and customisation
Navigates to the website
The only way to make contact is a form
Fills in the form and gets a call back
Wishes there was a better way to set it up or check pricing
Gives size, number of tapes, from and to locations, and opts in for TapeArk to provide the shipping
Is given a price based on the details provided
Chooses between partial and full payment
Is told that after the assessment they will hear of any additional costs
Shipment is sent with labelled boxes, by the number of tapes mentioned
The user is called when the delivery partner has started or is nearby
The user fills the boxes
The partner picks them up and sends them to the nearest TapeArk facility
Is informed when the tapes reach the facility
An audit report is sent and ingestion starts
Is informed when ingestion is complete
Can view the files uploaded from the tapes to the cloud
Can choose to destroy or retain the tapes
After a few months needs a set of files from those tapes
Searches for the files and clicks restore
Gets the files on the requested medium
Said
“I have fewer options for migration, and I use legacy tapes that many do not support.”
“I only get a few options and I am not sure they are trustworthy.”
“I think this is almost the only service that supports older tapes, with a cost-effective way to migrate my tape data to the cloud, end to end, and easy restore.”
“I am not sure about this since it is new. I wish there was help content here instead of calling to get information and pricing.”
“Since they are providing the shipping, it makes my job easier.”
“If I could talk to the representative once I have decided how much it costs, it would be better.”
“I am not very sure about the data size, so I am glad a separate assessment is available.”
“If I could talk to the representative once I have decided how much it costs, it would be better.”
“There is only a limited set of payment types.”
“Easier, since they are providing the shipping.”
“I am unaware of my tapes’ pickup and drop tracking.”
“I get a call at every checkpoint.”
“I can choose to destroy the tapes if I do not need them, and view and search the files in the cloud.”
“I get a call at every checkpoint.”
“I am unaware of the progress of my data’s ingestion, and an ETA.”
“Has an option to restore on demand.”
“I can choose how fast I need the files, and in what format.”
“No interface to select and pick the files that need to be restored easily.”
The response
What I designed for each stage
The low points on the map became the brief for the screens.
1Decide
What hurt
Few options, and no sense of whether to trust them.
Design response
The landing page carries a quote estimator, so a price is in view before anyone has to talk to a person.
2Approach
What hurt
A form and a callback, with no help content.
Design response
A four-step wizard replaces the form and the callback: personal details, tapes, shipping, then ingestion choices.
3Subscribe
What hurt
Limited payment types, and no one to ask once the cost is known.
Design response
The quote is built from tape type, format and number. Billing can be in parts or in full, with a tenure, and the bill can be disputed.
4Submit and pickup
What hurt
No view of pickup and drop, and a call at every checkpoint.
Design response
A job ID is created in the account. Order placed and shipping become the first stages on a tracker, with courier details attached.
5Audit and ingestion
What hurt
No sense of how far ingestion has got, or when it ends.
Design response
Audit and ingestion each show progress and an ETA. The audit report puts what the customer said next to what was found.
6Complete
What hurt
No easy way to pick the files to restore.
Design response
Search by name, type or date. Pick files from different tapes into one cart, see an estimate, choose speed and format, then follow the restore.
The flow
The flow map
My flow map, redrawn: the public site from landing page to quote, then the customer’s account from pickup to restore, with the detail that each step had to carry. The admin console has its own section below.
The structure
Sketches
Four low-fidelity sketches of the main surfaces: the wizard, the order tracker, restore, and the admin job steps. I redrew them for this case study from the flow map and the final screens.
The wizard. Four steps replace the form and the callback, and the quote sits beside the tape details.Tracking an order. Four stages, tapes audited so far with an ETA, and an audit report that sets what the customer said against what was found.Restoring files. Search by name, type or date, gather files from different tapes into one cart, then choose format and speed.Setting up a job. The admin console takes a job from account to documents in seven steps, one screen each.
The screens
What customers saw
Two screens from the customer’s tracker. The admin console has its own section below.
Tracking, at audit. The customer sees where the order is, how many tapes are done, and what the audit found against what they said.Restore. Cloud or physical delivery, progress, and an ETA. A link arrives when it is done.
The admin console
Running the orders
The console came after the first release, once running the back end straight from the database had failed more than once. It began as a rough flow: the admin sees every order and client, and can act on a customer’s order at each step, from services and billing through shipping, audit and ingestion to restore. This is that early flow, redrawn.
The finished console turns that flow into a seven-step job: account, job, shipping, tape, ingestion, fee and documents.
Admin: account creation. Seven steps from account to documents, so a job is set up in one place.Admin: tape details. Type, number and format for each tape, the kind of job, and the files needed to run it.Admin: fees. Start a fee from scratch or choose one that already exists.
The hard call
An admin console, or just MongoDB
TapeArk wanted to run the back end straight from MongoDB, with no admin interface. After a lot of back and forth, the first release went ahead without one.
After a lot of failures, we built the admin console. It is the account-creation flow above: seven steps that take a job from account to documents, so a job is set up in one place instead of in the database.
Where the back end pushed back
Statuses it could not hold
I wanted order statuses that did not exist yet, and some that were partial, such as an audit that has covered 2 of 6 tapes. The back end, as built, could not handle them. The back end had been built first and there was no SOP.
Designs kept clashing with its limits and had to be redone. So after each sketch, the whole team now sits down together and discusses it before it is finalised. Feasibility gets settled at the sketch stage, and Minfy still works this way.
What shipped. The full product shipped and it is running. It is an enterprise B2B product, so there is no public site to link to.
Case study · Minfy Technologies
Vanix
A cattle-health app for dairy farmers in India. The moment a cow comes into heat, the farmer knows, and knows what to do next.
Domain
Dairy IoT and cattle health
Company
Minfy Technologies, for Vanix Technologies (MyBovine.ai)
Platform
Mobile app, Android first, built in Flutter
My role
UX Designer and mentor: I wrote the PRD and did the initial design, and guided two junior designers who carried the visuals and the execution
Team
Two junior designers I mentored, a product manager and an engineering lead
The brief
A collar that knows, and a farmer who needs to be told
Vanix makes a smart collar for dairy cows. It streams each cow’s temperature and movement, and the app turns that into one plain action: confirm heat, call a vet, log an insemination, record the milk.
The client already had an app, and we wanted a new start rather than a patch. Before drawing anything we spoke to farmers and to the client, and I wrote the PRD from what we heard.
Who it is for
The Farmer, the key persona. Works the cattle every day, on one farm or a few. Lower literacy, Hindi first, and needs the fastest path from something is wrong to done.
The Farm Owner. Runs one or more farms, oversees the alerts, manages the farmers and the vets, and approves milk edits.
What the PRD set out to do
Surface alerts the moment the collar detects them, in the farmer’s language
Give every alert one clear next action, never a raw data readout
Keep a trustworthy record of every status change, milk entry and vet visit
Work on poor networks, and give each role only what it needs
When a cow comes into heat, I want to know straight away and what to do next, so I do not miss the short window to inseminate her.Job to be done
The research
What we heard, and what it meant for the design
We spoke to farmers and to the client. The problem the PRD recorded came out of those conversations: events that decide a cow’s health and milk are caught late or missed, and nothing reliable is written down.
Caught late
Heat, fever and calving distress go unnoticed because spotting them means someone watching all day, across many cows and farms.
Records scattered
Memory, paper and WhatsApp, with milk written on paper first and logged after. Mix-ups happened, and a vet had no history to read.
Reading is a barrier
The key persona has lower literacy and works in Hindi, so a picture they can tie to an event beats a line of text.
Signal is patchy
The app has to work on poor networks and on a wide range of Android phones.
What stayed with me from those conversations, in my own words:
A missed heat is money lost. If a heat is missed, a calving can be missed with it.
A missed fever can cost the cow. Left unseen, it may kill her.
Pictures over text. We used pictures so a farmer can associate this picture with this event, instead of reading.
Paper first, then the log. Milk went on paper and was logged after. Mix-ups were common, which is why the edit option came in.
A direct click to action. Every alert goes straight from a tap to the thing to do.
The heat journey
From the collar’s flag to a logged insemination
The first scenario in the PRD, as a journey: the collar flags a cow in heat early in the morning, and the farmer has to act inside the window, in Hindi, quickly. That was the target the screens were designed to.
1Detect
The need
Know the moment the collar sees it, not hours later.
Design response
A full-screen alert that arrives like a push notification, with one cow on each card and a counter such as 1 of 3.
2Understand
The need
Know which cow, and when it was detected.
Design response
Cow, breed and belt number, the farm, and the time detected. The readings behind it sit one tap away, in View Details.
3Decide
The need
Say yes or no without reading a paragraph.
Design response
One question over a picture. Yes, in heat is the main button and sits on top, with No below it.
4Act
The need
Get a vet, at the right time.
Design response
Call vet is there in every phase. The farmer picks one of three onboarded vets, then the insemination log opens with that vet filled in. Early or late in the window it first asks whether to continue anyway.
5Record
The need
A record that a vet or an owner can trust, without much typing.
Design response
The log takes the method, the technician and the time. A 21-day observation starts, and the cow’s timeline keeps the record.
Heat and fever both raise a cow’s temperature. A rise in temperature together with movement can indicate which one it is, so the details page shows both graphs.Side note
The hard call
One full-screen card, not a string of alerts
I made the heat alert a full-screen card, and made it one card that changes as the hours pass, instead of a new alert at each stage.
Detection starts a single, real 24-hour clock. The farmer’s Yes or No only acknowledges it, and does not pause or reset it. The same card moves through the phases on its own, and the PRD records it as the accepted direction: one evolving heat-to-insemination card, not separate alerts per phase.
I pushed for it because one card is easy to keep track of. Multiple cards, each with its own status, become chaotic.
What we left out
Rejected, and written down
Two chips saying the same thing. A P0 chip stacked with an Escalated chip became one corner roundel.
An Afternoon milk session. Real farms log Morning and Evening only.
Green text on white. It fails AA. Green stays an accent, and text uses a deeper green.
Raw sensor charts as the alert. Farmers want the decision, so graphs moved to the cow profile and the details page.
One card, one clock
Pre 6hOptimal 12hSubopt 6h
Detected6h18h24h
Pre-insemination, 0 to 6 hours. The window is not open yet.
Optimal, 6 to 18 hours. Peak fertility.
Suboptimal, 18 to 24 hours. Fertility is dropping, but it can still be logged.
If the window closes with nothing logged, the card asks directly: was the cow inseminated, or was it missed?
If nobody acts
0 hoursThe farmer is notified, by push and in the app.
1 hourIt escalates to the Farm Owner.
2 hoursThe Farm Owner must act. It is critical now.
6 hoursThe heat cycle is confirmed in the system.
The cow’s year
IdleHeat-eligible.
Heat alertThen in heat.
Inseminated21-day watch.
PregnantThree checkpoints.
CalvedDelivery confirmed.
Milking250 days, in the Milk Log.
Dry60 days, then back to idle.
The structure
Sketches
Four low-fidelity sketches of the core loop: detect, decide, act, record. I redrew them for this case study from the PRD and the final screens.
The alert card. A picture, one question and one tap. The raw graph stays one step back, in the details page.The full-screen alert. One cow per card, with a counter. Answering moves to the next cow, and Yes is the main button.One card, three phases. A single 24-hour clock runs along the top, and the same card changes with it. Call vet is there in every phase.Farmer home. Two tabs and no graphs. Each row is something to do, and it opens the same card as the Events centre.
The screens
What farmers and owners saw
Six screens from the prototype. The alert cards are picture-first, so a farmer can answer without reading.
Farmer home. Priority first, one row for each thing that needs doing. A row opens the same card as the Events centre.Events. Cow and breed, one question, then No or Yes. The cow illustrations are AI-generated.The full-screen heat alert. One cow per card, with the main answer on top.Call a vet. Answering Yes on a fever card opens a sheet to pick one of three onboarded vets, so there is no typing inside the card.Cow profile. Last and next heat, and the temperature across 24 hours.The cow’s timeline. From collar assigned to milking started, one event per card.
How it was built
A working prototype, and a design system beside it
I built the prototype in code with Claude, as one HTML file that anyone could open and tap through, with a design system beside it. The developers got something to read and run, not a stack of static frames. Rules like these were written down and held:
Daylight first
A warm background, never pure white, to cut glare in the field.
Green with care
The bright green is an accent only. Text on white uses a deeper green that passes AA.
Big targets
Tap targets of at least 48 by 48, and no text under 14.
Room for Hindi
Hindi and Bhojpuri run 20 to 40 percent longer, so no fixed-width containers.
Working with two junior designers
I wrote the PRD and did the initial design. Two junior designers carried the visuals and the execution.
I reviewed their work from the ideation stage, starting at the sketches, and guided them to think the problem through rather than telling them what was right.
One engine, two roles
An owner opening a card in Events and a farmer tapping a priority row run the same flow. Owners approve milk edits, and farmers send them as requests, so one set of screens serves both.
What shipped
Built in Flutter, and the client was happy
The Flutter app was made separately from the prototype and shipped. The client was happy with it.
It was the first project scoped with the SOW after discovery. Design and dev leads gave their input up front, and the team shipped with 15% of the timeline left.
What came after
They liked it, so they gave us another
The client loved the work and gave us another project, DigiKhet, which we are working on now. It is about tractors, and how the admin, the mechanic and the farmer interact through it.
Case study · Minfy Technologies
One Trace
A platform where enterprises send equipment to vendors for repair or warranty. Designing it meant drawing a line around it, and keeping it there.
Domain
Enterprise machinery and part repair, and warranty claims
Company
Minfy Technologies, for an Australian enterprise platform
Platform
Web portal
My role
Solo designer: UX, UX research and visual design, and I wrote the requirements (FRD)
Team
A product manager, front-end and back-end developers, and an architect
The brief
Between the machine and the repair shop
An enterprise is a company that owns equipment. A vendor is the company that fixes it. If a company uses a gearbox and the gearbox fails, it goes to a vendor, either to be repaired at a cost or, if it is still covered, under warranty. One Trace is the platform between the two.
The people on it are the One Trace team, and the admins and users on each side.
OT super admin
The primary admin, with control of the whole application.
OT site admin
Looks after vendor engagement and onboarding, and the financials.
Enterprise
An admin, and users who can read and write.
Vendor
An admin, and users who can read and write.
When a request keeps growing after it is agreed, I want one document everyone has signed, so each feature stays what we said it was.The job the FRD had to do
The starting point
A wireframe that already existed
The client’s team already had a wireframe. I spoke to the team who made it, and I made my own wireframes against theirs.
Planned and actual
12 weeks planned, 2 of them for design
About 8 months of to and fro
It was meant to be a 12-week project, with two weeks for design. It ended up taking about eight months of to and fro, because there was no boundary and not one source of truth.
What went wrong
Said in the BRD, but not in detail
What they wanted was in the business requirements, but not the details. So the details kept arriving later. We want warranty. Then things were added inside warranty. Then forms were added.
It began as a simple status view of an application, with different steps. It became a full unit, where every step had several smaller steps of its own. It happened again and again.
The move
One FRD for every feature
After it happened a few times, I decided we needed a restriction and a single source of truth. So I wrote a feature requirements document, an FRD, for every feature.
Each one follows the same skeleton: a one-pager, the problem, the objectives, who it is for, the use cases, then what is in, what is out, the design rules and the open questions. Then it is signed off.
The team still writes them.
The hard calls
Two things I had to convince them of
The hardest thing was telling the client to split the product in two: an MVP first, and the extended product after it, to avoid crowding.
The second was about roles. They also wanted one admin role that could do everything. Convincing them of a user management system was mine to do. We defined a few roles, each with its own responsibilities and access, instead of giving everyone whatever role they asked for. That saved a lot of backend effort.
One FRD, close up
The reports page
The reports FRD is a good example of the line being drawn. The idea was a bird’s-eye view for One Trace members: the work, the users, the money and the timelines, so anything abnormal can be flagged for attention.
Scenario 1Observe the whole process at a glance, and get the big picture.
Scenario 2Get a cost-wise, time-wise and status-wise split of the items.
Scenario 3Identify which statuses take the longest.
Scenario 4Identify the cost spent on repairs and on warranties.
Features in
A static page of reports
A single type of graph, with no interactions
Selectable filters on top
A graph section at the bottom, with the graph type chosen on the left
Features out
Dynamic graphs
Interactive graphs with widget modules
An additional set of reports
Custom reports
Below that it got specific, so there was little left to argue about. Filters by type, currency, duration, vendor or enterprise, and material number. Repair graphs for dollars spent, items repaired and average time per repair. Warranty graphs for dollars spent, claims won, lost and ongoing, and the top five rejection reasons. Time on the x-axis of every graph, solid bars throughout, and a stacked bar only for claims.
It also said who sees what. The OT admin sees vendors and enterprises, and can pick one or all. A vendor sees the report against all enterprises or one. An enterprise sees it against all vendors or one.
The structure
Sketches
Four low-fidelity sketches: the reports page, who sees what, how the scope grew, and how the FRD fits in. I redrew them for this case study from the FRD.
The reports page. Filters across the top, the graph type picked from the left, and one static graph type. Nothing more was in scope.Who sees what. One page with three views, stated once in the FRD.How it grew. A status view with a few steps, and then every step carried smaller steps and forms of its own.The single source of truth. The brief says what they want. The FRD says exactly what is in, what is out, and who signed it.
The screens
What it looked like
Screens from the design file. The numbers and names in them are sample data, since the product is not live yet.
Reports
Repair reports. The filters from the FRD across the top, the three repair figures on the left, and the chart they switch.Warranty reports. The same page, switched to warranty. Claims won, lost and ongoing stack in each bar.
One workflow, end to end
Every step of a job is a status, and every status has its own small action. This is a single warranty claim, with the purchase order details on the left and the claim form in the middle.
One claim. The status row at the top shows where the job is. Everything below it belongs to that job.The status set. The statuses, the three warranty chips and the dropdown lists, laid out as one sheet so the build had a single reference.
One action. Submit Variation. A repair that changes mid-job asks for the type of change, the new value, a date and the paperwork.The actions. The menu a repair moves through, from receipt to closing the order.
Users and licences
The user management system sits behind its own tabs for enterprises, vendors, users and reports. The one admin who could do everything became roles, and each licence tier says how many of each kind of user it allows.
Licence tiers. Silver, Gold and Platinum, each with one client admin and a set number of read and write and read-only users.Inviting a vendor. The business, its primary contact and its primary admin, set up in one dialog.
What changed
A document the team still uses
Writing an FRD for every feature limited the scope creep. The turnaround for each feature fell by about 65%, from two weeks to four days, and the team still writes one for each feature. That is about 70% in calendar days and about 60% in working days, averaged.
What we learnt from it also changed how we quote to clients. If we say 12 weeks and it extends, it looks bad. If we say 14 weeks and deliver in 12, it is better. That saved a lot of time.
Where it stands
A second phase
We have been awarded a second phase. The platform is not live yet.
Case study · Minfy Technologies
Gharpe Diagnostics
X-rays and ECGs that come to your door. Everything ran on calls and email, so I designed the two apps that move the visit along: one for the customer and one for the technician.
Domain
At-home X-ray and ECG tests
Company
Minfy Technologies, for a doctor who ran the service
Platform
Two mobile apps: customer and technician
My role
Solo designer: UX, UX research and visual design
Team
One developer, building in parallel with me
Time
16 days, the first project after I joined Minfy
The brief
A doctor with the only portable machines
The client was a doctor who, at the time, was the only one offering ECG and X-ray tests at home. A technician arrives with a portable machine, does the test, and a doctor signs the report. When I started, the whole thing ran on calls and email.
Three people carry it.
Karthik, 25
Busy, tech-minded, and finds it hard to commute for tests. He is unsure which home-diagnostic services to trust. Nobody does home ECG and X-ray, because the machines live in hospitals.
Manday, 37
Looks after his parents. Weekdays go to the office, and weekends go to taking them to a hospital 14 km away. He worries what would happen in an emergency with that commute.
Lilly, 29
The technician. She wants accurate results, a comfortable patient and an efficient day. She cannot see a schedule, and a lot of the process is manual.
When someone in my family needs an X-ray or an ECG, I want it done at home by someone I can follow and trust, so nobody loses a day to a hospital 14 km away.Job to be done
Sixteen days, split like this.
1 day of research and interviews
1 day to synthesise what I found
3 days of wireframes
1 day for a brief design system
The other 10 days on iterations and visuals, split into modules: login, landing and so on
The work was cut into modules, so the developer could build one while I designed the next. Some were small, so I grouped them, and we built the groups in parallel. In the order a customer meets them:
Login
Landing
Booking: a test or a package
Booking by the body: upper, lower or by organ
Choose a slot
Book the test
Payment
Contact the diagnostician
Tracking
OTP
Report generation
Download
Payment
Rating
Health records
The research
Having the X-ray done on me
I spoke to the technicians. They came over, and I asked them to do an X-ray and an ECG on me, so I could see how it worked. At the time everything was manual, and email carried the results.
The three personas above evolved out of those conversations. I also drew a journey map for each side, from finding out about home tests to waiting for the next one. Here is what each one showed.
The customer’s map
Searches for the service in the Play Store and finds nothing, since there is no app
Does not understand what the packages mean
Gets no update for about two hours, then a call to confirm
Can track the technician only by live location, and cannot cancel
Gets results by email, and has to organise several of them by hand
The technician’s map
Phones the customer for details, and shares a live location to find the house
Has no way to reschedule if the time does not work
Has no way to tell the customer where they are
Sends the report by email, with no assured wait for the doctor’s signed one
Wants an easier way to handle all of this
The journey
From pain point to screen
The customer’s map has nine touchpoints. Here are five stretches of it, with what the map showed and what the screens do.
1Trust it
On the map
Scared of incorrect procedures and defective devices. Doubts about a portable machine, and how accurate it is.
On the screens
Intro slides before login: why GharPe, expert diagnosticians, fast and accurate results. The home screen repeats it: home testing, results in 30 to 60 minutes.
2Choose
On the map
Does not understand what the packages mean. Appointment set-up seems confusing.
On the screens
Individual tests and Packages on two tabs. Each package lists the tests inside it, and the price. An X-ray starts from the body: the area, then the part, then AP or oblique.
3Book
On the map
Manual work to check availability, location and timing.
On the screens
A time-slot sheet, an address step, and payment by wallet, card, net banking, UPI or pay after service. Booked shows as confirmed, searching for a technician.
4Wait
On the map
No update for two hours. No way to cancel or track, except live location.
On the screens
My Bookings, with Current and History. Each booking opens a step timeline. Call and Track sit on the technician’s card, and the map shows an ETA.
5Get the result
On the map
A report mailed by hand. Several results to organise manually.
On the screens
Health Records, with Completed and Pending tabs. Every record has Download and View, and the customer can rate the service.
The shape
Two apps, one visit
Each side had a journey map and pain points of its own, so there are two apps: one for the customer and one for the technician. The customer follows seven steps, from booked to the main report. The technician works through seven of their own, and moves the visit along as they go.
The hard call
Cutting to fit 16 days
The hardest call was delivering within the time we had. The preparation was there, but to deliver on it we had to restrict what went in.
The one thing I cut was waiting for a survey or direct interviews with patients. I worked from existing secondary research on the web instead. My team and the client agreed to it.
The structure
Sketches
Four low-fidelity sketches: the two sides of a visit, the X-ray picker, the tracker and the two apps. I redrew them for this case study from the wireframes and the research file.
Two sides of one visit. The customer books and follows. The technician accepts and moves the visit along. Both see the same record.Picking an X-ray. The research file holds a first picker: one sheet of body parts and an “I am not sure” link. The final screens ask for the area, then the part, then the view.The tracker. The customer follows seven steps, from booked to the main report. The technician works through seven of their own, from task started to payment received.The two apps. Five branches in each app. The customer books and keeps records. The technician manages a schedule and bookings.
The screens
The customer’s app
Six screens, from the welcome to the health record. The names and details in them are sample data.
Welcome. Intro slides before login, then a phone number.Packages. Each one lists the tests inside it and the price.X-ray, step one. The area of the body.X-ray, step three. The view, AP or oblique.Tracker. Seven steps, with the finished ones filled in.Health records. Completed and pending, with download and view.
The technician’s app
The technician signs in with an employee ID, and works down the same sort of timeline, one step at a time.
Sign in. A six-digit employee ID.Before the visit. Seven steps, with Call and Track on top.Mid-visit. Confirm that the test is done.After. Every step ticked, then Done.
What changed
One place for the visit
The booking, the technician’s visit, the report and the bill now sit in one place, and both sides can see where it is.
The client loved the product.
Where it stands
Not live
It is not live. I designed it and prototyped it end to end in 16 days, alongside the developer.
Case study
Sumeria Space
An Uber for satellites. A marketplace in the middle: a satellite owner finds a ground station that fits, the station partner supplies it, and the data comes down by laser, not radio.
Domain
Space: laser and optical ground-station networks
Company
Sumeria, a middle platform between satellite owners and ground stations
Platform
Web app, prototyped in Figma Make
My role
Solo designer: UX, UX research and visual design
Team
A full-stack developer, a product manager and two architects
Time
12 weeks, 4 of them for design. One of the first products we wrote a PRD for
The brief
A satellite, a station and the weather in between
Think of Sumeria as an Uber for satellites. It is a middle platform between satellite owners and ground stations, and it uses laser instead of radio (RF) to bring data from a satellite down to a station.
A satellite can only send its data down when it passes over a ground station that can take it. The station has to speak the right standard, be free at that time, and have clear enough weather. Sumeria puts that search, and the booking that follows, in one place.
Three kinds of people use it.
Satellite owner
Searches for a pass, simulates it, books it, and follows the session live. Then collects the data.
Station partner
Adds a station with its location, protocols and aperture size, connects its health and availability, sets a calendar, and reviews incoming requests.
Admin
Watches the network: stations that are up, weather, live sessions. Looks after partners and customers, and monitors the AI models for capacity, weather and pathing.
When my satellite has data to send down, I want to find a station that can take it at the time I need, so I do not lose the pass to weather or a bad match.Job to be done
The research
Who else is doing this?
I started with a competitive landscape study of laser and optical ground-station networks. It had three jobs: find the common UX patterns, their strengths and gaps, and use them to shape the design for mission control, scheduling, network health, weather intelligence and analytics.
What the three providers did well
Deep technical telemetry, over a large global network
A clean interface, with good scheduling and reliable pass management for radio
A large partner ecosystem, and optical stations on the way
What was missing
Each covered one slice: hardware, radio services, or isolated optical stations
No unified, optical-first operating interface
No AI-driven orchestration of the network
That gave me five places to aim at:
OneThe first operating interface for a laser network.
TwoOne view of missions, weather, the network and partners.
ThreePredictive, not a dashboard that reacts.
FourAutomated scheduling and pathing as the core difference.
FivePartners, customers and stations in one ecosystem.
The questions
Twenty-two things to settle
After the initial debrief, I wrote down twenty-two fresh questions. Some were about the user: how do you point at the place you want to image? A coordinate, a pin, a shape file, a satellite, or a station? Others were about the physics: do we account for orbital decay? Is it a cone of coverage or a direct beam? Some were about money: what moves the price, and are payments wallet credits or external? And some were about things going wrong: what if a station has several antennas and one is due for maintenance? What are the failure scenarios? Can it be white-labelled?
The flows
Three journeys through one network
Each role has its own flow, and the screen list that comes from them runs to 57 screens across sign-in, the satellite owner’s app, the station partner’s portal and the admin portal.
Satellite owner
Log in, land on a global map
Create a downlink request
Choose the date and window, the protocol and the satellite’s TLE
See candidate ground stations
Filter by weather, compatibility and capacity
Preview a simulation for a station
Confirm the booking
The session joins the mission timeline
Monitor it live
Collect the data, and go again
Station partner
Receive an invite, create an account
Add the station: location, protocols, aperture size, capabilities
Generate API credentials
Connect the endpoint for health and availability
Set the availability calendar
The station appears on the global map
Review incoming booking requests
Monitor live sessions
Admin
Log in to a network overview
See stations up, weather overlays and live sessions
Manage partners
Manage customer missions
Monitor the AI models: capacity, weather and pathing
Analytics and reporting
The shape
One map, three views
The same network shows up in all three. The owner starts on a global map, the partner’s station appears on that map once it is set up, and the admin gets an overview of the whole network.
The hard call
Every pass as a route
The hardest call was to use a route pattern to show the multiple passes a satellite makes. It is not a conventional approach for this kind of interface.
The founders, Craig and Chris, needed convincing. I argued that many more people would grasp a route drawn on a map at a glance than would read the same passes off a table.
The structure
Sketches
Four low-fidelity sketches: the three roles, the gap in the market, how a pass is found and booked, and the questions. I redrew them for this case study from my research notes, the flows and the prototype.
Three roles, one network. The satellite owner books, the station partner supplies, and the admin watches the whole network.The gap. The competitors I looked at each cover one slice. Nobody offered the whole thing in one interface.Finding a pass. Search the orbit and window, compare stations on a list and a map, then confirm. A hold goes on credits, and the charge comes after the data lands.The questions. Twenty-two open questions, grouped. Where to look, when, how good, what it costs, and what goes wrong.
The screens
The prototype
The prototype was built in Figma Make. The company, people and satellite names in it are placeholders.
The satellite owner
Search. The satellite, the standard, the window, the minimum elevation and the duration, over the map.Results. A list and a map side by side. The pass is drawn as a route across the map, with the stations along it. One carries an AI pick badge, and chosen stations collect in a cart.Confirm. “A hold will be placed on your credits. Charges apply only after successful data downlink.”My Orders. Past and upcoming sessions, with a status for each.
The station partner
My ground stations. Each card has its location, standard, data speed and status.Pass schedule. Start, end, duration, speed and volume for every contact.
The admin
Admin dashboard. Six totals, and two charts for traffic and growth.Clients. Who is on the platform, and their status.
What changed
One place for the pass
Finding a station, simulating the pass, booking it, and following it live happen in one interface in the prototype, with the partner and the admin in the same network.
The client was happy with it.
Where it stands
Live
Sumeria is live. Stratumetrics came to us through this client.
