2025
Aviz Flight Management Pvt Ltd
My Role
Solo Product Designer — Research, IA, Interaction Design, Handoff
Platform
B2B SaaS · Desktop-first
Industry
Private Aviation · Europe
Project Duration
~14 weeks · Discovery → Handoff
Designing One platform to replac WhatsApp, email, and chaos
in private aviation.
AVIZ Flight Desk is a first-of-its-kind post-booking flight management and communication platform for private aviation operators and brokers in Europe — designed solo, from problem definition to developer handoff, with no competitor to copy and no margin for error.
01 - Core Problem
Private aviation operators were running a safety-critical business on WhatsApp.
In private aviation, every confirmed charter flight involves two distinct parties: the operator, who owns and manages the aircraft — crew scheduling, permits, fuel, slot coordination, and logistics — and the broker, who sells the seat, gathers passenger requirements, and acts as the interface between client expectations and operational reality.
Every confirmed flight generates a dense, time-critical stream of communication: passenger manifests, catering preferences, permit approvals, handling agent coordination, crew schedules, slot confirmations. Before AVIZ Flight Desk, all of this happened across WhatsApp, Telegram, and email threads simultaneously — with no shared context, no audit trail, and no single place to retrieve anything later.
USER LAYER
No unified trip context
Operators opened a flight in one system, then hunted through email or WhatsApp to find the related conversation. Trip data and trip communication never existed in the same place at the same time.
USER LAYER
No task ownership — messages fell through the gaps
When a broker sent a message, it was unclear which operator was responsible for responding. Everyone assumed someone else was handling it. There was no assignment, no confirmation, no fallback.
OPERATIONS LAYER
Documents scattered across three platforms
A catering request on WhatsApp. A permit update on email. A flight brief on Telegram. Retrieving any historical communication required searching three separate apps — with no cross-platform filter and no trip linkage.
OPERATIONS LAYER
No priority signal — everything looked equally urgent
A trip departing in four hours appeared identical to one departing in four days. Triage was entirely manual, ad hoc, and dependent on individual memory. There was no mechanism to surface what actually needed attention first.
BUSINESS LAYER
Zero compliance trail — a growing legal liability
European aviation operations require traceable communication for regulatory compliance. WhatsApp and personal email are legally invisible under those standards. As trip volume grew, this liability compounded with every conversation.
BUSINESS LAYER
The workflow could not scale
Managers had no visibility into team workload, no response-time data, and no way to identify who was handling what. The operation was unmeasurable — and therefore unmanageable at volume.
The core design problem: Design a communication and operations platform that replaces three consumer tools with one professional system — without asking experienced aviation professionals to abandon the mental models they've used for 20+ years.
02 - Research & Discovery
AVIZ started as a chat tool. User interviews changed everything.
Research ran across eight sessions over three weeks — covering the AVIZ CTO, operations leads, sales staff, and active operators and brokers who use Leon and FL3XX (the dominant flight management platforms in European private aviation) as their daily tools. Rather than asking what features they wanted, I focused on actual workflows: what does a typical day look like, where do things fail, and what is the real cost of a missed message in this specific environment.
What I heard in those first sessions fundamentally reframed the entire product.
The critical insight: Users don't spend most of their time in chat. They spend most of their time in the flight management panel — understanding which aircraft are scheduled for which trips, on which dates, with which passengers. Chat supports the operational picture; it does not replace it.
Stakeholder Interviews
8 sessions across 3 weeks. Covered the AVIZ CTO, operations team, and active operators and brokers. Focus on actual failure modes — not desired features.
Workflow Mapping
Documented the day-to-day flow of confirmed trip handling — from first broker contact to flight completion — to pinpoint exactly where current tools break down.
Regulatory Context
Reviewed European aviation communication compliance requirements — GDPR, operational traceability standards, data retention rules — that directly shaped the native email and audit trail design.
Competitive Benchmarking
Studied Leon and FL3XX — not as competitors, but as reference points for design patterns users had already internalized over decades of daily use.
03 - User Persona
Understanding who I was actually designing for — not a persona, a person.
Research surfaced two primary user archetypes. Rather than abstract profiles, each represents a specific combination of work pattern, cognitive load, and technical comfort that shaped every design decision downstream. These are composites built from real interview participants — not generalised user types.
PRIMARY USERS
30–60+ years old
25–30 years of industry experience. Familiar with Leon, FL3XX, and legacy aviation patterns. High expertise, low tolerance for unnecessary change or relearning.
COGNITIVE RISK
Unfamiliarity has a cost
Radically modern interfaces increase cognitive load for experienced users. In aviation, extra cognitive load has operational consequences. Trust is built on predictability, not novelty.
DESIGN PRINCIPLE
Familiar but better
Keep structural patterns users already trust. Modernise only the specific interactions that existing tools handle poorly — task assignment, communication threading, tag filtering.
What the personas confirmed: Both users are power users — not novices. The interface had to be information-dense and operationally direct, not simplified. Designing for "ease of learning" was the wrong goal. Designing for speed of operation under pressure was the right one.
04 - Competitive Analysis
Understanding the tools users already trust — to earn their trust.
There was no direct competitor to copy — AVIZ Flight Desk is a first-of-its-kind post-booking communication platform. But the ecosystem had two dominant tools: Leon and FL3XX, industry-standard flight management systems used by every operator and broker interviewed. These weren't competitors to beat — they were reference points to understand what patterns users had already internalised over decades.
Leon and FL3XX are restricted platforms — I couldn't request demos or access trials within the project timeline. AI-assisted research was used to build a structured understanding of how each system organises trip data and where known usability limitations exist. This fed directly into the "Familiar but better" design principle.
The strategic insight from competitive analysis: Neither Leon nor FL3XX solved the communication problem. They were never designed to. The gap wasn't a product flaw — it was a market opportunity. AVIZ doesn't compete with these tools; it becomes the communication layer that sits alongside them, eventually replacing the WhatsApp and email fragments that users had to manage separately.
05 - Product Srategy
Two panels, one platform. Operators and brokers have fundamentally different jobs — the design reflects that.
A core product architecture decision was made early: the Operator panel and Broker panel would be structurally distinct — not just role-gated versions of the same screen. Their different working realities demanded genuinely different information architectures. Showing every possible action to every user creates confusion and operational risk.
Six design principles that governed every decision:
Trip ID as the master key
Every chat, email, and document anchors to a Trip ID. If a message exists without trip context, it is effectively lost. This single architectural decision shaped the entire information structure of the platform.
Context, not context-switching
Users should never leave a trip to find its communication. Email and chat needed to be simultaneously visible — a principle that led directly to the three-pane split-screen design.
Explicit ownership
Every task needs a named owner. The design made it structurally impossible for a message to sit unanswered because responsibility was unclear or assumed.
Priority = departure time
Urgency in aviation is objective — it is time-to-departure, not a subjective judgment. The system auto-calculates and surfaces this. Users do not judge urgency; the platform does.
Security as UX
GDPR and European banking-level security weren't just engineering specs — they became UX features. Audit trails, session policies, and data controls are part of the designed experience.
Familiar but better
Retain the structural patterns experienced users already trust from Leon and FL3XX. Modernise only the interactions those tools handle poorly. Evolution, not revolution.
06 - Signature Design Decisions
The decisions that defined the product — and why each one was made.
1 — Operations-First Dashboard, Not Chat-First
AVIZ originally started as a pure communication platform — a unified replacement for the WhatsApp and email fragmentation. This was the obvious starting point. But before touching Figma, user interviews produced a finding that reframed the entire product direction.
Operators and brokers who use Leon and FL3XX told me clearly: Their primary daily activity is understanding which aircraft are scheduled for which trips, on which dates, with which passengers — and assigning those trips to the right people. Chat is secondary. It supports the operational picture, it doesn't replace it.
2 — The Three-Pane Split Screen
I started with the hardest UX problem first: how do you give an operator simultaneous access to a trip list, its email thread, and its live broker chat — without overwhelming users who are 30–60 years old and deeply familiar with more traditional interfaces?
The client's initial direction was separate pages for Chat and Email, navigated via a top nav. My position: navigating between pages in a high-pressure operational context isn't just friction — it's a structural failure. Every page switch breaks the user's mental model of the trip they're managing.
3 — The Hidden Task Management Layer
During interviews, the client explained that operator managers frequently assign trips and communication responsibilities to individual team members. At first, this sounded like a simple permissions feature. As I studied how it actually worked in practice, I realised this was an entirely implicit task management process running inside unstructured WhatsApp threads — with no tracking, no confirmation, and no visibility for managers.
I designed a formal task assignment layer on top of the chat system — visible only to operator managers — where broker conversations become assignable tasks with explicit states. The layer is invisible to Sales users, who simply see conversations assigned to them.
Why the workload count in the assignment dropdown matters: In the original WhatsApp workflow, managers had no idea how many active conversations each operator was handling. They assigned based on availability assumptions — which caused some operators to be overwhelmed while others sat idle. Showing task count per person costs the manager zero extra steps and gives them real capacity data for every assignment decision.
4 — The Tag System: Inline vs. Separate Module
Private aviation professionals use a common tag vocabulary: PAX (passenger information), PET (trips with animals), Catering, Special Request. The client's proposal was a dedicated Tags Module — a separate section where users would manually copy messages into the module and assign tags to them. The intent was reasonable. The execution would have been a usability failure.
07 - Operator Panel
Operators think in aircraft. The dashboard was built around that.
This was one of the most deliberate structural decisions in the product. A standard date-sorted list of trips would have forced operators to mentally reconstruct which aircraft was doing what. Instead, the dashboard is organised as a Tail × Date grid — each row is an aircraft (identified by tail number), each column is a calendar day.
An operator scans down their fleet and immediately sees availability, active trips, and assignment status — without navigating anywhere or opening any trip. The recent conversations panel on the right stays visible at all times.
01
Tail × Date Grid Structure
Each row is one aircraft (D-TAIL 1 / 2 / 3). Each column is one calendar day. A single glance tells an operator which aircraft is flying, idle, or unassigned — without opening any record.
02
"Not Assigned" as an Active State
Unassigned cells are explicitly labelled — not left blank. This passive prompt communicates planning gaps to managers without requiring a separate notification or report.
03
Recent Conversations Panel
Always visible alongside the grid. Assignment status shown inline: "You are working", "VBK is working", "HEJ is working" — the whole team's workload visible at a glance, no separate report needed.
Why the grid mirrors Leon and FL3XX: The Tail × Date structure is identical to how operators already think about fleet scheduling in existing aviation tools. This was a deliberate choice to reduce cognitive load — the visual grammar was familiar, only the interactions were improved.
08 - Broker Panel
Brokers manage portfolios, not fleets. The interface reflects that reality.
The broker panel was designed from a fundamentally different starting point. Because brokers typically work individually and don't coordinate within structured team hierarchies, the interface needed to be communication-first — rich in trip context, without the task assignment overhead that would add friction to a workflow that didn't need it.
01
My Trips / Org Trips Toggle
Brokers switch between personal assignments and the full organisational view. Managers use Org Trips to monitor workload distribution across their team — same design pattern, different information density per role.
02
Recent Conversations as First-Class Element
Unlike the operator panel where conversations are secondary to fleet operations, the broker's right panel is the primary communication hub. Their job is communication — the design reflects that priority directly.
03
10-Tab Trip Modal
Trip Details, PAX Data, PET, Catering, Special Request, Slots, Permits, Crew, Invoice, Chatbox. Tabbed structure made it possible to expand scope iteratively as stakeholder interviews revealed additional data categories — without increasing visual complexity.
04
Multi-Leg Trip Structure
Complex charter trips with multiple legs display each leg side-by-side inside the same modal — crew, PAX, EFT, and handling per leg. The broker sees the complete journey at once without additional navigation.
Why the grid mirrors Leon and FL3XX: The Tail × Date structure is identical to how operators already think about fleet scheduling in existing aviation tools. This was a deliberate choice to reduce cognitive load — the visual grammar was familiar, only the interactions were improved.
09 - Design Decisions
Every decision was made for a reason.
Below are the six decisions that most directly shaped the product's architecture and user experience — each framed as the problem it was responding to, the reasoning behind the decision, and the outcome it produced.
10 - Impact & Reflection
What changed — and what it cost to get there.
What this project actually taught me
A 14-week solo design engagement on a first-of-its-kind product produces a specific kind of learning — not theory, but scar tissue. Below are the four things I understood differently by the end of AVIZ than I did at the start.
The direction of AVIZ came from user interviews, not from screens or assumptions.
Instead of starting with design tools, I spent time understanding how users actually work and think.
If I had jumped straight into Figma, I would have built a system that looked logical but didn’t match real user behavior. The most impactful decisions in AVIZ came from conversations, not interfaces.
AVIZ users are professionals who already have strong workflows and mental models.
They don’t need simplification — they need clarity and efficiency.
The goal was not to redesign their workflow completely, but to improve what already works.
Designing something “familiar but better” proved more effective than creating something entirely new.
One of the key decisions in AVIZ was not implementing a requested feature — inline right-click tagging.
Although requested, it introduced friction and complexity that could negatively impact usability and adoption. Instead, a more structured tagging approach was retained.
This decision was backed by reasoning, usability considerations, and alternative solutions — not just opinion.
Working within GDPR and banking-level compliance initially felt restrictive.
But these constraints helped shape a more reliable and trustworthy product.
They forced better clarity in areas like data handling, permissions, and user communication — which ultimately improved the overall experience.