John Antony — UX/UI designer in Bangalore. I work on operations software: dense, high-stakes interfaces where someone has to see what's wrong at a glance. Currently designing two live products at Big Wings LLC.
Experience
Big Wings LLC — Bangalore · US logistics technology
I own the end-to-end design of two products in the same platform suite — a B2B repair-shop operations portal for desktop and its companion mobile app for shop owners and mechanics. Research, design system, and dev-ready screens, presented and iterated with the VP and design lead.
Selected work
The shop-floor companion to the portal — requests, workshop status, mechanic management, inventory, payroll, and earnings. Includes the Figma token architecture handed to engineering.
A gallery companion that explains artwork in plain language and lets teachers build and share collections. Full UX process — research through a moderated usability study.
A turf booking app built around slot availability — dark theme, green accents, and a booking flow that keeps the next available slot in reach at every step.
A peer skill-exchange platform for desktop — light theme, warm tones, built around browsing people rather than listings.
Also
Big Wings LLC
End-to-end mobile flow and component library for the carrier product. Onboarding copy rewritten for clarity. Marked ready for dev in Figma.
Big Wings LLC
A 15-question, 4-section external research questionnaire for transport management systems — approved by the design lead and delivered to leadership.
Design Challenge
Neonatal monitoring — an Android caregiver app paired with a clinician web dashboard. Designed for high-stakes glanceability.
Design Challenge
Dark-theme SaaS CRM. 7 screens, 6 user flows, and a competitive research document.
Professional Case Study
A B2B desktop portal and its shop-floor mobile companion, built at Big Wings LLC. Competitive research, a 12-persona study, a locked design system, and six shipped modules.
This product is unreleased, so there are no screens here and the client goes unnamed. What follows is the thinking: the research that set the direction, the system decisions, and the critique I acted on. Happy to walk through the work directly in an interview.
Multi-bay repair shops run intake, technician assignment, parts, and billing across disconnected tools — phone calls, whiteboards, and spreadsheets. Nobody can see, at a glance, which jobs are slipping and which bays are free.
One operations console where a shop manager can take a request, assign the right technician to the right bay, track the job to invoice, and see schedule risk before it becomes a late delivery — with a mobile counterpart for the floor.
UX/UI Designer — owner of both the Repair Shop Portal and the Repair Shop mobile flow. Research, IA, design system, hi-fi, and dev handoff.
May — August 2026 — internship at Big Wings LLC, Bangalore. US-based product team.
Weekly review with the design lead and VP of Product. Figma handoff to engineering.
Two products, one system
Built for the shop manager at a desk. Data-dense tables, planning grids, and forecasting — the surface where decisions get made. Shops running multiple locations switch between them from a location picker in the sidebar.
Built for owners and mechanics in motion. Four core tabs — Dashboard, Requests, Workshop, Shop — plus payroll, earnings, and inventory. Optimised for glanceable status, not deep analysis.
Competitive Audit
I audited four platforms in the fleet and shop-management space to find where the category had settled into convention — and where it hadn't looked.
| Platform | Strength | Gap I designed against |
|---|---|---|
| Fleetio | Strong asset and maintenance records | ✕ Bay-level, day-of scheduling visibility |
| Fullbay | Deep repair-order workflow | ✕ Forward-looking capacity and demand signals |
| Truckdown | Wide shop network coverage | ✕ Operational tooling for the shop itself |
| GPTransco | Dispatch and logistics coordination | ✕ Technician workload and performance view |
The brief that came out of this identified five capabilities with no direct competitor equivalent — the ones that became the portal's differentiators: live bay intelligence, predictive parts pre-staging, service health scoring, demand forecasting, and margin intelligence with regional benchmarking.
Persona Study
The platform serves twelve distinct user types across the product. I built a 14-slide persona deck covering all of them, reviewed with the VP and revised on his feedback around age ranges and role framing. Designing the portal meant knowing which three of the twelve actually live in it daily — and building for them without breaking the other nine.
Defining what the dashboard measures
Before designing the dashboard I wrote a KPI recommendation document for the VP arguing which metrics a shop manager can actually act on within a shift, versus which ones only matter at month-end. That document decided the six-KPI row on the dashboard — the layout followed the argument, not the other way round.
One palette, shared by the portal and the mobile app. The interesting part isn't the hex values — it's that the palette is organised by role rather than by hue. A designer picks a colour by asking what the element is, not what it should look like.
Primary · Success · Danger & Warning · Base · Icons · Border · Surface · Font Colours · Neutrals.
Each status colour ships as a set rather than a single value — a base, a dark variant for text, and a faint variant for backgrounds. That means a warning chip and warning body copy both stay legible without anyone inventing a new value mid-file.
Dense tables need many closely-spaced greys — one for the row border, one for the hover state, one for the disabled label. Guessing at those in the moment is how a UI drifts, so they're enumerated once and reused.
Font colours are their own group, ordered by usage frequency, so the most common choice is also the first one you reach.
Plus Jakarta Sans across both products — it holds its shape at small sizes in dense tables, which is most of this product, without the neutrality of a default system face. Phosphor icons at a single weight, so a toolbar never looks assembled from two different sets.
The brand colour carries identity. Green, amber, and red carry status. The two vocabularies never overlap.
This is a product where colour has a job. A bay card that turns amber means a job is slipping; a red row means something needs a decision now. If the brand colour were also allowed to mean something operational, every screen would be arguing with itself — and the one signal that has to survive a glance across a busy shop floor would be the one competing hardest for attention.
So the brand colour appears in identity surfaces — the mobile hero header, brand moments, empty states — and is barred from anything that encodes state. It's a constraint that costs nothing visually and protects the part of the interface people actually make decisions on.
Token architecture (mobile)
Two Figma variable collections, deliberately separated:
Raw hex values. No modes. Named color/[hue]/[scale]. Nothing in the file is allowed to reference these directly.
Named color/[category]/[role], aliasing to Primitives. Components bind to semantic tokens only — so a palette change is one edit, not a hundred.
The separation costs a little setup time and buys the ability to rethink the palette without reopening a single component. It also gives engineering a token list that maps cleanly to their own variables.
Six modules, each shipped as a complete navigable flow. The step chains below are the real screen sequences.
Incoming Requests — 7 screens
Intake through to either a generated work order or a declined request. The rejection path was designed as a first-class flow rather than a dead end — declining a job sends the customer an SMS, so the reason screen includes a live preview of the message that will actually go out. The person choosing the reason can see what the customer will read.
Work Orders — 6 screens
The full commercial spine of the product — from an accepted job to money owed. Parts search sits inside the job rather than in a separate inventory module, because that's where the mechanic is standing when they need it.
Teams — 5 screens
Capacity planning matches incoming request volume against available technician hours using workload rings and bay status. Performance covers efficiency trend, fault categories, and certification expiry — the last one because an expired certification is a scheduling constraint, not an HR footnote.
Live Bay Intelligence heatmap, six-KPI row, revenue-per-bay card, an AI priority queue, and predictive parts pre-staging. The shift-opening screen.
Dense table with signature workload timeline bars, a right-hand detail panel, and a team KPI bar. Scan-first, drill-down second.
Service Health Score ring, a 7-day demand forecast, and margin intelligence benchmarked regionally — three views no audited competitor offered.
The shop-floor product. Onboarding, four core tabs, and the supporting flows that keep a shop running — Staff & Payroll, Earnings, Inventory, Manage Mechanics, Add Mechanic, shop profile, and notifications.
One navigation rule, applied everywhere
The violet hero header appears only on tab landing screens. Every drill-down screen uses a plain white topbar.
Mobile products lose people in depth — you tap three levels down and forget whether back returns you to a list or to the top. Making the header itself encode altitude means depth is legible before you read a single word. No breadcrumb, no extra chrome.
AI, used sparingly
A mechanic suggestion card when assigning work — surfaced, never auto-applied.
A daily brief at the top of the shift, plus inline warnings on jobs at risk.
Insight chips that explain a movement rather than just charting it.
All three are assistive and none of them block a task. Each is presented as a suggestion the user can act on or ignore — surfaced in cards and chips that sit alongside the real data rather than replacing it, so a prediction is never mistaken for a recorded fact.
Currently open
Review feedback on the Mechanics screen: the four stat cards and the filter tabs directly beneath them display the same four values. The screen states the same information twice in two visual languages, which makes the page feel busier than the data justifies. I'm reworking the treatment — most likely collapsing the stats into the filters so a number and its filter are the same control.
Splitting an overloaded signal
The problem: On the dashboard's bay cards, colour was doing two jobs at once — signalling schedule health and job state. A card could be amber because a job was running late or because it was waiting on parts, and those call for completely different responses from a manager.
The decision: Colour now encodes schedule health only — on time, at risk, overdue, not started. A separate pill carries job state — in progress, awaiting parts, queued. And a text label sits beside the colour, so the card never relies on hue alone. One glance gives urgency; a second gives the reason.
Critique I acted on
VP review of the Work Order flow returned two notes. The first was a UI problem. The second turned out not to be.
| Feedback | What was actually wrong | What I did |
|---|---|---|
| Status column | It conflated priority ("Critical") with workflow state ("In Progress") — two different axes stacked into one column, so neither could be sorted or scanned reliably | Split into two independent indicators |
| "Waiting Parts" | It appeared as a status but didn't exist in the underlying work-order state model. If a repair can genuinely be blocked on parts — and it can — that's a missing real state, not a label to delete | Raised it with the team as a product gap rather than quietly removing the chip |
The second note is the one I learned most from. The fastest fix would have been deleting the status and moving on. Tracing it back to the state model meant the product got a real answer to a real operational condition instead of the interface quietly lying about one.
Designing across two surfaces
Multi-location shops needed a location switcher on both surfaces — sidebar on the portal, and now being brought into mobile so the mental model doesn't change between devices.
The portal's "Accept & Share Estimates" step is being brought into mobile, which currently jumps request detail → accept job → assign mechanic. Estimates shouldn't be a desktop-only privilege.
ArtLens — Full Case Study
An end-to-end UX project for a mobile art history gallery companion — research, personas, journey maps, competitive audit, sketches, storyboards, wireframes, design system, usability testing, and high-fidelity screens.
Gallery visitors walk up to artworks, read jargon-filled wall labels, and leave confused. There's no accessible, engaging way to understand art in context — especially for students and teachers who need to go deeper.
ArtLens will let gallery visitors instantly access plain-language artwork context, let teachers build and share curated collections with students, and show design students how classical movements shaped modern visual design.
Solo UX/UI Designer — end-to-end. Research, synthesis, design, and prototyping.
April 2026 — 2-week usability study window, Bangalore
Figma for all design. Google Meet for remote sessions. Paper for early sketches.
Can users find and understand artwork information quickly without frustration? Can teachers build, organise, and share collections naturally? Where do users get stuck or drop off? Does the language feel accessible to people without an art background?
Moderated usability study using a Figma prototype. 5 participants, 4 tasks each, 30–40 min sessions. In-person in Bangalore + remote via Google Meet. Screen-recorded (with consent). Post-task SUS questionnaire after all prompts.
Primary Research Questions
| Question | What we're measuring |
|---|---|
| Time to find + save | How long it takes to find an artwork, read context, and save to a collection |
| Unguided navigation | Can users go from home to a completed saved collection without help? |
| First impression | Do users understand what the app does within the first 30 seconds? |
| Export flow clarity | Is the Save + Export flow clear enough for a teacher to use independently? |
| Hesitation points | Where do users pause, go back, or express confusion? |
| Content accessibility | Does the detail screen inform without feeling like a textbook? |
5 participants — 2 school teachers/educators, 2 design/fine arts students, 1 casual gallery visitor. Ages 20–45. Regular smartphone users. 1 participant using accessibility features. Incentive: ₹500 Amazon voucher.
Takeaways
"I want my students to feel something when they see a painting — not just memorise dates."
"I know modern design owes a lot to classical art — I just can't figure out the connection easily."
Meera's Journey — Building a Collection for Her Class
Arjun's Journey — Finding Design Inspiration
Three existing apps audited to find gaps — Google Arts & Culture, Bloomberg Connects, and Smartify.
| Feature | Google Arts & Culture | Bloomberg Connects | Smartify | ArtLens |
|---|---|---|---|---|
| Artwork scanning | ✦ Yes | ✦ Yes | ✦ Yes | ✦ Yes + faster |
| Plain-language descriptions | ✕ Academic tone | ✕ Curator-heavy | ~ Partial | ✦ Core focus |
| Teacher / educator tools | ✕ None | ✕ None | ✕ None | ✦ Key differentiator |
| Collection creation | ~ Favourites only | ✕ None | ~ Basic lists | ✦ Named, shareable |
| Export / share flow | ✕ No export | ✕ No export | ✕ No export | ✦ PDF + share link |
| Art → Design connection | ✕ None | ✕ None | ✕ None | ✦ Unique section |
No existing app combines plain-language accessibility, teacher-specific tools, and a bridge between classical art and modern design. ArtLens fills that gap.
A wide-angle view of Meera's full journey — from planning a gallery visit to her students opening the shared collection. It shows the real-world context the app lives in, not just the screens. Drawing this first meant the interface had to answer a problem that exists before anyone opens the app.
A screen-level breakdown of the same journey — exactly how Meera interacts with the app at each step, from opening it to sharing the final collection with her WhatsApp group. This board became the spec the wireframes were built from.
In the close-up storyboard, Meera finds an artwork by typing an art movement into a search bar. That felt obvious when I drew it — a teacher planning a lesson thinks in movements, so search seemed like the natural front door.
Usability testing said otherwise. Participants standing in front of a painting didn't reach for search at all; they looked for a way to point the phone at the artwork. Scanning wasn't a secondary convenience, it was the action people expected to be primary — and in the lo-fi round it wasn't prominent enough to find quickly.
So the hi-fi design promotes scanning to a floating action button, visible on every main screen in terracotta, while search stays available for planning sessions away from the gallery. The storyboard was drawn around one assumption about how people would enter the app, and testing replaced it. That gap between what I assumed and what five people actually did is the most useful thing this project taught me.
Four key screens translated into Figma wireframes — used directly in the moderated usability study to keep participant feedback focused on how things worked, not how they looked. Testing grey boxes is what caught the save-button and scan-discoverability problems before either reached the visual design.
Warm parchment background evokes gallery walls and aged paper. Terracotta accent brings energy without breaking the museum atmosphere.
Playfair brings editorial authority. DM Sans keeps body copy clean and readable — feels like a well-designed magazine.
Spacing
4px base unit across all screens. Keeps the layout consistent without thinking about it every time.
Accessibility
WCAG AA contrast on all text. 44×44px minimum touch targets. Designed with one participant who uses large text mode in mind.
Icons
Line icons, 1.5px stroke. Labels under every nav icon — learned from testing that icon-only nav creates hesitation.
Built in Figma with warm parchment palette, Playfair Display + DM Sans, terracotta accent. Two complete prototype flows: Visitor flow (scan → read → save) and Teacher flow (collect → organise → export).
The visitor flow opens on scan rather than search — the reverse of what the close-up storyboard assumed, and the single biggest change testing produced.
View Live Prototype ↗
5 participants completed all 4 tasks using the hi-fi prototype. Average SUS score of 85 — above the industry benchmark of 68, placing ArtLens in the "Excellent" range. All participants completed every task successfully without prompting.
Observations clustered into three themes. These shaped the final hi-fi design decisions.
Pattern Identification → Design Decisions
| Pattern Found | Insight | Design Decision |
|---|---|---|
| Scan discoverability | Users expect scanning to be the primary action — the storyboard had assumed search-by-movement would be the front door | Floating action button, always visible, terracotta colour |
| Save icon recognition | Bookmark universally understood — text buttons in headers are low-salience | Bookmark icon in action bar with "Saved!" toast feedback |
| Export accessibility | Teachers use Export as their primary goal — shouldn't require hunting for it | Export CTA promoted to collection detail header |
| Content tone | All 5 users found descriptions more readable than any gallery app they'd used | Plain-language approach validated — kept as-is |
| Offline need | 2 users asked about offline access — gallery Wi-Fi is unreliable | Saved artworks cached automatically, offline badge added |
About
I'm a BCA graduate from St. Joseph's, Bangalore — and I got into design the way most people get into anything they care about: by doing it obsessively until it started making sense.
I care about the whole picture — understanding what someone needs before I ever open Figma, and sweating the details until everything feels like it couldn't be any other way.
Right now that means two B2B products at Big Wings LLC, where I've learned that designing for people doing a job under time pressure is a different discipline from designing for people browsing at leisure — denser, less forgiving, and far more interesting.
Open to UX/UI roles — internship or full-time — in Bangalore and remote. Always happy to talk through a problem.