1293 lines
20 KiB
Plaintext
1293 lines
20 KiB
Plaintext
# Role
|
||
|
||
Act as a world-class product designer, interaction designer, information visualization specialist, and UI/UX art director specializing in complex real-time systems.
|
||
|
||
You are designing a **next-generation multi-UAV ground control suite (GCS)** for professional operators.
|
||
|
||
The product controls and coordinates potentially **50+ UAVs with approximately 5 human operators**, while allowing multiple GCS workstations to connect simultaneously to the same shared mission.
|
||
|
||
The goal is NOT to make a "military-looking dashboard."
|
||
|
||
The goal is to create a **professional, extremely usable, high-performance mission-control interface inspired by the interaction paradigms of modern RTS games**, while maintaining the clarity, seriousness, safety, auditability, and information hierarchy expected from real aviation software.
|
||
|
||
Create high-fidelity visual design concepts/mockups for this system.
|
||
|
||
---
|
||
|
||
# CORE PRODUCT IDEA
|
||
|
||
The central design philosophy is:
|
||
|
||
> **Do not make the operator control 50 vehicles. Make the operator control 5 intentions, and let the system translate those intentions into coordinated vehicle behavior.**
|
||
|
||
The system should abstract complexity.
|
||
|
||
Instead of forcing operators to individually control:
|
||
|
||
* UAV-001
|
||
* UAV-002
|
||
* UAV-003
|
||
* ...
|
||
* UAV-050
|
||
|
||
the system should organize them into:
|
||
|
||
* Missions
|
||
* Tasks
|
||
* Groups
|
||
* Roles
|
||
* Vehicles
|
||
* Operators
|
||
* Constraints
|
||
* Commands
|
||
* Events
|
||
|
||
The user should primarily interact with **groups and tasks**, while individual UAV control is available when needed.
|
||
|
||
Think:
|
||
|
||
**Mission → Tasks → Groups → Vehicles**
|
||
|
||
rather than:
|
||
|
||
**Vehicle → Vehicle → Vehicle → Vehicle**
|
||
|
||
---
|
||
|
||
# IMPORTANT DESIGN INSPIRATIONS
|
||
|
||
Take interaction inspiration from:
|
||
|
||
### Supreme Commander
|
||
|
||
Study:
|
||
|
||
* strategic zoom
|
||
* massive-scale unit management
|
||
* selection of many units
|
||
* control groups
|
||
* strategic vs tactical views
|
||
* command queues
|
||
* visual aggregation
|
||
|
||
### StarCraft II
|
||
|
||
Study:
|
||
|
||
* drag selection
|
||
* control groups
|
||
* contextual commands
|
||
* command queues
|
||
* extremely fast interaction
|
||
* selection feedback
|
||
* unit grouping
|
||
|
||
### Company of Heroes
|
||
|
||
Study:
|
||
|
||
* squad abstraction
|
||
* unit cards
|
||
* contextual actions
|
||
* tactical map
|
||
* clear unit state
|
||
|
||
### Homeworld
|
||
|
||
Study:
|
||
|
||
* 3D spatial awareness
|
||
* formations
|
||
* fleet relationships
|
||
* spatial visualization
|
||
|
||
### Total War
|
||
|
||
Study:
|
||
|
||
* army/group abstraction
|
||
* unit cards
|
||
* strategic/tactical hierarchy
|
||
* large numbers of units represented compactly
|
||
|
||
### Factorio
|
||
|
||
Study:
|
||
|
||
* automation
|
||
* system-level thinking
|
||
* minimizing repetitive manual actions
|
||
* letting the user specify desired outcomes rather than repeatedly operating individual machines
|
||
|
||
Do NOT copy their visual aesthetics.
|
||
|
||
Copy their **interaction principles** and improve them for a professional real-world system.
|
||
|
||
---
|
||
|
||
# DESIGN PHILOSOPHY
|
||
|
||
The interface should feel like:
|
||
|
||
**Google Docs collaboration + modern RTS + aviation mission planning + professional command-and-control software**
|
||
|
||
It should NOT feel like:
|
||
|
||
* a video game HUD
|
||
* a traditional military dashboard overloaded with tiny widgets
|
||
* a cockpit instrument panel
|
||
* a sci-fi spaceship interface
|
||
* a generic admin dashboard
|
||
* a cryptocurrency trading terminal
|
||
|
||
Avoid excessive neon green, glowing borders, unnecessary radar graphics, decorative HUD elements, fake holograms, excessive gradients, or cyberpunk aesthetics.
|
||
|
||
The interface must feel:
|
||
|
||
* modern
|
||
* professional
|
||
* calm
|
||
* precise
|
||
* information-dense
|
||
* spatial
|
||
* responsive
|
||
* trustworthy
|
||
* highly usable
|
||
* operationally serious
|
||
|
||
---
|
||
|
||
# PRIMARY USER SCENARIO
|
||
|
||
Create the visual concept around this scenario:
|
||
|
||
There are:
|
||
|
||
**5 operators**
|
||
|
||
controlling:
|
||
|
||
**50 UAVs**
|
||
|
||
inside one shared mission.
|
||
|
||
Example distribution:
|
||
|
||
ALPHA
|
||
|
||
* 12 ISR UAVs
|
||
* Area Search task
|
||
* Operator: Alex
|
||
* Status: GREEN
|
||
|
||
BRAVO
|
||
|
||
* 10 ISR UAVs
|
||
* Route Recon task
|
||
* Operator: Sara
|
||
* Status: GREEN
|
||
|
||
CHARLIE
|
||
|
||
* 8 Relay UAVs
|
||
* Communications task
|
||
* Operator: David
|
||
* Status: GREEN
|
||
|
||
DELTA
|
||
|
||
* 12 mixed UAVs
|
||
* Reserve / support
|
||
* Operator: Maria
|
||
* Status: AMBER
|
||
|
||
RESERVE
|
||
|
||
* 8 UAVs
|
||
* Available
|
||
* Operator: Ken
|
||
* Status: GREEN
|
||
|
||
The operator should NOT need to constantly look at all 50 aircraft individually.
|
||
|
||
---
|
||
|
||
# CENTRAL UI CONCEPT: SEMANTIC ZOOM
|
||
|
||
This is one of the most important design requirements.
|
||
|
||
The interface should support multiple levels of abstraction.
|
||
|
||
## LEVEL 1 — STRATEGIC
|
||
|
||
At maximum zoom-out, show:
|
||
|
||
* overall operating area
|
||
* mission boundaries
|
||
* 5 groups
|
||
* task areas
|
||
* major routes
|
||
* alerts
|
||
* fleet health
|
||
* operator activity
|
||
|
||
A group should appear as an aggregated entity.
|
||
|
||
Example:
|
||
|
||
ALPHA
|
||
12 UAV
|
||
SEARCH
|
||
82%
|
||
GREEN
|
||
|
||
Do not show 12 individual icons unless the user zooms in or explicitly expands the group.
|
||
|
||
---
|
||
|
||
## LEVEL 2 — OPERATIONAL
|
||
|
||
When zooming into ALPHA:
|
||
|
||
show:
|
||
|
||
* individual UAV positions
|
||
* group formation
|
||
* current task
|
||
* planned route
|
||
* group health
|
||
* task progress
|
||
* coverage
|
||
* vehicle availability
|
||
|
||
The user can see how the group is composed.
|
||
|
||
---
|
||
|
||
## LEVEL 3 — TACTICAL
|
||
|
||
When selecting a particular UAV:
|
||
|
||
show:
|
||
|
||
* position
|
||
* altitude
|
||
* heading
|
||
* velocity
|
||
* battery/energy state
|
||
* navigation status
|
||
* communication state
|
||
* current task
|
||
* next action
|
||
* alerts
|
||
* payload state
|
||
|
||
Do not permanently display all of these values.
|
||
|
||
Use contextual progressive disclosure.
|
||
|
||
---
|
||
|
||
## LEVEL 4 — ENGINEERING
|
||
|
||
Only when explicitly requested:
|
||
|
||
show:
|
||
|
||
* flight controller status
|
||
* sensors
|
||
* actuators
|
||
* logs
|
||
* configuration
|
||
* detailed telemetry
|
||
* parameters
|
||
|
||
Engineering information should not overwhelm the operational view.
|
||
|
||
---
|
||
|
||
# MAIN SCREEN
|
||
|
||
Create a high-fidelity desktop application screen at approximately:
|
||
|
||
**3840 × 2160 visual composition**
|
||
|
||
with a 16:9 aspect ratio.
|
||
|
||
The primary screen should be a **large interactive geospatial map**.
|
||
|
||
Use a realistic but fictional operating environment.
|
||
|
||
Do not use real military locations.
|
||
|
||
Use fictional terrain:
|
||
|
||
* coast
|
||
* hills
|
||
* urban area
|
||
* open land
|
||
* restricted zones
|
||
* task areas
|
||
* roads
|
||
* rivers
|
||
|
||
The map should occupy approximately **70–80% of the screen**.
|
||
|
||
---
|
||
|
||
# TOP BAR
|
||
|
||
Create a clean top command/status bar.
|
||
|
||
Include:
|
||
|
||
MISSION: ALPHA-17
|
||
|
||
Fleet:
|
||
48 / 50 ACTIVE
|
||
|
||
Tasks:
|
||
7 ACTIVE
|
||
|
||
Alerts:
|
||
3
|
||
|
||
Operators:
|
||
5 ONLINE
|
||
|
||
Network:
|
||
HEALTHY
|
||
|
||
Mission time:
|
||
01:42:17
|
||
|
||
At the far right show the currently logged-in operator:
|
||
|
||
ALEX
|
||
MISSION OPERATOR
|
||
|
||
Do not make the top bar visually dominant.
|
||
|
||
---
|
||
|
||
# LEFT SIDEBAR — MISSION STRUCTURE
|
||
|
||
Create a collapsible left sidebar.
|
||
|
||
Show:
|
||
|
||
MISSION
|
||
|
||
TASKS
|
||
|
||
FLEET
|
||
|
||
GROUPS
|
||
|
||
OPERATORS
|
||
|
||
ALERTS
|
||
|
||
HISTORY
|
||
|
||
Example:
|
||
|
||
GROUPS
|
||
|
||
ALPHA
|
||
12 UAV
|
||
SEARCH
|
||
● GREEN
|
||
|
||
BRAVO
|
||
10 UAV
|
||
RECON
|
||
● GREEN
|
||
|
||
CHARLIE
|
||
8 UAV
|
||
RELAY
|
||
● GREEN
|
||
|
||
DELTA
|
||
12 UAV
|
||
RESERVE
|
||
● AMBER
|
||
|
||
RESERVE
|
||
8 UAV
|
||
AVAILABLE
|
||
● GREEN
|
||
|
||
Use compact cards.
|
||
|
||
Each group should have:
|
||
|
||
* group name
|
||
* number of vehicles
|
||
* task
|
||
* health
|
||
* operator
|
||
* tiny status indicator
|
||
|
||
The sidebar should not feel like a conventional file tree.
|
||
|
||
It should feel like an RTS "army/group control panel."
|
||
|
||
---
|
||
|
||
# MAP VISUALIZATION
|
||
|
||
The map is the primary workspace.
|
||
|
||
Show:
|
||
|
||
* 5 UAV groups
|
||
* aggregated group markers
|
||
* individual UAVs for the currently selected group
|
||
* flight paths
|
||
* future planned routes
|
||
* task areas
|
||
* geofences
|
||
* restricted areas
|
||
* communication coverage
|
||
* points of interest
|
||
* alerts
|
||
|
||
Use subtle colors.
|
||
|
||
Suggested palette:
|
||
|
||
Background/map:
|
||
|
||
* dark charcoal
|
||
* desaturated navy
|
||
* muted terrain colors
|
||
|
||
Primary friendly/active:
|
||
|
||
* blue
|
||
|
||
Selected:
|
||
|
||
* bright cyan/blue
|
||
|
||
Healthy:
|
||
|
||
* green
|
||
|
||
Warning:
|
||
|
||
* amber
|
||
|
||
Critical:
|
||
|
||
* red
|
||
|
||
Planning/edit state:
|
||
|
||
* violet/purple
|
||
|
||
Avoid making everything colorful.
|
||
|
||
Color should encode meaning.
|
||
|
||
---
|
||
|
||
# GROUP VISUALIZATION
|
||
|
||
When ALPHA is selected:
|
||
|
||
Show 12 UAVs.
|
||
|
||
Represent them as small directional aircraft icons.
|
||
|
||
Each aircraft should have:
|
||
|
||
* heading indicator
|
||
* subtle velocity vector
|
||
* tiny status indicator
|
||
|
||
Show their planned paths using thin translucent lines.
|
||
|
||
Show the group boundary or formation using a subtle translucent shape.
|
||
|
||
Example visual concept:
|
||
|
||
ALPHA
|
||
|
||
12 aircraft
|
||
|
||
AREA SEARCH
|
||
|
||
82% COMPLETE
|
||
|
||
The group should visually read as ONE coordinated entity rather than 12 unrelated objects.
|
||
|
||
---
|
||
|
||
# GROUP CARD
|
||
|
||
Create a contextual bottom panel when ALPHA is selected.
|
||
|
||
Example:
|
||
|
||
ALPHA
|
||
|
||
12 VEHICLES
|
||
|
||
AREA SEARCH
|
||
|
||
82% COMPLETE
|
||
|
||
OPERATOR
|
||
ALEX
|
||
|
||
STATUS
|
||
GREEN
|
||
|
||
CURRENT
|
||
SEARCH AREA NORTH
|
||
|
||
NEXT
|
||
RETURN
|
||
|
||
Then show contextual actions:
|
||
|
||
TASK
|
||
MOVE
|
||
HOLD
|
||
GROUP
|
||
SPLIT
|
||
TRANSFER
|
||
DETAILS
|
||
|
||
Use large, easily clickable controls.
|
||
|
||
Do not create dozens of tiny buttons.
|
||
|
||
---
|
||
|
||
# SMART SELECTION
|
||
|
||
Demonstrate an RTS-style drag selection.
|
||
|
||
Show a translucent selection rectangle over an area of the map.
|
||
|
||
Inside it are several UAVs.
|
||
|
||
At the bottom:
|
||
|
||
27 VEHICLES SELECTED
|
||
|
||
FILTER:
|
||
|
||
ISR 14
|
||
|
||
RELAY 7
|
||
|
||
TRANSPORT 6
|
||
|
||
Then show:
|
||
|
||
[ CREATE GROUP ]
|
||
|
||
[ ASSIGN TASK ]
|
||
|
||
[ ADD TO GROUP ]
|
||
|
||
The UI should make it obvious that the operator can manipulate many vehicles simultaneously.
|
||
|
||
---
|
||
|
||
# SMART FILTER / QUERY INTERFACE
|
||
|
||
Create a visual example of intelligent fleet selection.
|
||
|
||
Example command:
|
||
|
||
"Select available ISR aircraft within 20 km of Task Bravo with more than 60% energy."
|
||
|
||
Represent the query as structured chips:
|
||
|
||
TYPE
|
||
ISR
|
||
|
||
AVAILABILITY
|
||
AVAILABLE
|
||
|
||
DISTANCE
|
||
< 20 KM
|
||
|
||
ENERGY
|
||
|
||
> 60%
|
||
|
||
TASK
|
||
NONE
|
||
|
||
Result:
|
||
|
||
8 VEHICLES SELECTED
|
||
|
||
The design should feel like a powerful professional filtering system, not a developer query interface.
|
||
|
||
---
|
||
|
||
# TASK OBJECT
|
||
|
||
Create a visual card representing a mission task.
|
||
|
||
Example:
|
||
|
||
TASK-143
|
||
|
||
AREA SEARCH
|
||
|
||
Priority:
|
||
HIGH
|
||
|
||
Area:
|
||
Northern Sector
|
||
|
||
Required:
|
||
4 UAV
|
||
|
||
Assigned:
|
||
ALPHA / 4
|
||
|
||
Progress:
|
||
63%
|
||
|
||
Health:
|
||
GREEN
|
||
|
||
Estimated completion:
|
||
18 MIN
|
||
|
||
Make this task visually connect to its geographical area on the map.
|
||
|
||
The operator should be able to select the task and immediately understand:
|
||
|
||
* what needs to happen
|
||
* where
|
||
* with what resources
|
||
* who owns it
|
||
* how far it has progressed
|
||
* whether there is a problem
|
||
|
||
---
|
||
|
||
# COMMAND QUEUE
|
||
|
||
Create a visual command/task sequence for ALPHA.
|
||
|
||
Show:
|
||
|
||
TRANSIT
|
||
↓
|
||
SEARCH AREA A
|
||
↓
|
||
LOITER
|
||
↓
|
||
RETURN
|
||
↓
|
||
RECHARGE
|
||
↓
|
||
SEARCH AREA B
|
||
|
||
Represent this as a clean horizontal or vertical workflow.
|
||
|
||
Allow drag-and-drop reordering.
|
||
|
||
The design should communicate that operators are specifying **intent**, not manually flying every UAV.
|
||
|
||
---
|
||
|
||
# COMMAND PREVIEW
|
||
|
||
Create a modal or side panel that appears before executing a high-level action.
|
||
|
||
Example:
|
||
|
||
ASSIGN TASK
|
||
|
||
6 VEHICLES SELECTED
|
||
|
||
Estimated completion:
|
||
18 min
|
||
|
||
Energy reserve:
|
||
OK
|
||
|
||
Route conflicts:
|
||
NONE
|
||
|
||
Geofence conflicts:
|
||
NONE
|
||
|
||
Vehicle compatibility:
|
||
6 / 6
|
||
|
||
Communication:
|
||
GOOD
|
||
|
||
Potential issue:
|
||
1 aircraft may require reassignment
|
||
|
||
Buttons:
|
||
|
||
CANCEL
|
||
|
||
PREVIEW
|
||
|
||
CONFIRM
|
||
|
||
The design should emphasize that the system validates the intended command before execution.
|
||
|
||
---
|
||
|
||
# MULTI-OPERATOR COLLABORATION
|
||
|
||
Create a second visual state showing five operators connected to the same mission.
|
||
|
||
Represent them subtly:
|
||
|
||
ALEX
|
||
Commanding ALPHA
|
||
|
||
SARA
|
||
Commanding BRAVO
|
||
|
||
DAVID
|
||
Planning
|
||
|
||
MARIA
|
||
Monitoring
|
||
|
||
KEN
|
||
Engineering
|
||
|
||
Show that multiple users can view the same map simultaneously.
|
||
|
||
When Alex selects ALPHA, display:
|
||
|
||
COMMAND AUTHORITY
|
||
ALEX
|
||
|
||
Other operators can see ALPHA but cannot accidentally issue conflicting commands.
|
||
|
||
---
|
||
|
||
# COMMAND LEASE
|
||
|
||
Create a visual interaction for temporary command authority.
|
||
|
||
Example:
|
||
|
||
ALPHA
|
||
|
||
COMMAND LEASE
|
||
ALEX
|
||
|
||
Expires:
|
||
02:34
|
||
|
||
Observers:
|
||
SARA
|
||
DAVID
|
||
|
||
Button:
|
||
|
||
REQUEST CONTROL
|
||
|
||
When another operator requests control:
|
||
|
||
OPERATOR B REQUESTS COMMAND
|
||
|
||
Reason:
|
||
Emergency intervention
|
||
|
||
Buttons:
|
||
|
||
TRANSFER CONTROL
|
||
|
||
DENY
|
||
|
||
This should visually communicate shared awareness and explicit authority.
|
||
|
||
---
|
||
|
||
# ATTENTION MANAGEMENT
|
||
|
||
Create a prominent but restrained "ATTENTION" area.
|
||
|
||
Example:
|
||
|
||
ATTENTION
|
||
|
||
🔴 UAV-27
|
||
Navigation degraded
|
||
|
||
🟠 ALPHA
|
||
Task behind schedule
|
||
|
||
🟠 BRAVO
|
||
Approaching constraint
|
||
|
||
Then show:
|
||
|
||
47 VEHICLES NOMINAL
|
||
|
||
The idea is that the system should suppress normal information and surface exceptions.
|
||
|
||
Do not create a wall of alerts.
|
||
|
||
---
|
||
|
||
# FAILURE / REASSIGNMENT CONCEPT
|
||
|
||
Create a visual state where one aircraft becomes unavailable.
|
||
|
||
Example:
|
||
|
||
UAV-03
|
||
UNAVAILABLE
|
||
|
||
The system automatically identifies potential replacements.
|
||
|
||
Show:
|
||
|
||
TASK:
|
||
ALPHA SEARCH
|
||
|
||
REQUIRED:
|
||
4 VEHICLES
|
||
|
||
CURRENT:
|
||
3 / 4
|
||
|
||
RECOMMENDED REPLACEMENTS:
|
||
|
||
UAV-19
|
||
READY
|
||
|
||
UAV-27
|
||
READY
|
||
|
||
UAV-31
|
||
READY
|
||
|
||
The design should communicate that the mission system can reason about resources rather than forcing the operator to rebuild the mission manually.
|
||
|
||
---
|
||
|
||
# STRATEGIC ZOOM CONCEPT
|
||
|
||
Create THREE visual panels side by side demonstrating the same map at different abstraction levels.
|
||
|
||
## PANEL A — STRATEGIC
|
||
|
||
Show:
|
||
|
||
5 groups
|
||
7 tasks
|
||
3 alerts
|
||
|
||
Only aggregated group markers.
|
||
|
||
## PANEL B — OPERATIONAL
|
||
|
||
Zoom into ALPHA.
|
||
|
||
Show:
|
||
|
||
12 individual UAVs
|
||
formation
|
||
task area
|
||
route
|
||
coverage
|
||
|
||
## PANEL C — VEHICLE
|
||
|
||
Zoom into UAV-07.
|
||
|
||
Show:
|
||
|
||
position
|
||
heading
|
||
energy
|
||
navigation
|
||
communication
|
||
payload
|
||
task
|
||
|
||
Make it visually obvious that the UI becomes more detailed as the user zooms in.
|
||
|
||
---
|
||
|
||
# INFORMATION HIERARCHY
|
||
|
||
The visual hierarchy should follow:
|
||
|
||
1. What is happening?
|
||
2. What needs my attention?
|
||
3. What is the mission doing?
|
||
4. What is each group doing?
|
||
5. What does this particular vehicle need?
|
||
6. Engineering details only when requested.
|
||
|
||
Do NOT invert this hierarchy.
|
||
|
||
---
|
||
|
||
# VISUAL STYLE
|
||
|
||
Use a modern professional dark interface.
|
||
|
||
Preferred aesthetic:
|
||
|
||
* dark graphite
|
||
* deep navy
|
||
* muted blue-gray
|
||
* restrained cyan
|
||
* subtle green
|
||
* amber
|
||
* red only for critical states
|
||
* occasional violet for planning/editing state
|
||
|
||
Use:
|
||
|
||
* soft shadows
|
||
* very subtle borders
|
||
* restrained transparency
|
||
* clean typography
|
||
* generous spacing
|
||
* clear grouping
|
||
* strong alignment
|
||
* high contrast
|
||
|
||
Avoid:
|
||
|
||
* excessive glow
|
||
* cyberpunk
|
||
* sci-fi holograms
|
||
* decorative radar screens
|
||
* fake military insignia
|
||
* unnecessary gradients
|
||
* excessive rounded cards
|
||
* tiny unreadable text
|
||
* excessive information density
|
||
* ornamental UI
|
||
|
||
The result should look like a product that could actually be used for hours by professional operators.
|
||
|
||
---
|
||
|
||
# TYPOGRAPHY
|
||
|
||
Use a modern highly legible sans-serif.
|
||
|
||
Possible visual direction:
|
||
|
||
Inter / SF Pro / IBM Plex Sans / similar.
|
||
|
||
Use typography hierarchy:
|
||
|
||
Large:
|
||
Mission / major group
|
||
|
||
Medium:
|
||
Task / group name
|
||
|
||
Small:
|
||
Telemetry / metadata
|
||
|
||
Monospaced type may be used sparingly for:
|
||
|
||
* IDs
|
||
* timestamps
|
||
* numeric telemetry
|
||
* coordinates
|
||
|
||
Do not make the whole interface monospace.
|
||
|
||
---
|
||
|
||
# ICONOGRAPHY
|
||
|
||
Use simple geometric icons.
|
||
|
||
UAV icons should be directional.
|
||
|
||
Groups should have an aggregated visual identity.
|
||
|
||
Tasks should have distinct but restrained icons.
|
||
|
||
Alerts should be unmistakable.
|
||
|
||
Avoid decorative military iconography.
|
||
|
||
---
|
||
|
||
# INTERACTION STATES TO VISUALIZE
|
||
|
||
Produce visual examples of all of the following:
|
||
|
||
1. Nothing selected
|
||
2. One group selected
|
||
3. Multiple groups selected
|
||
4. Individual UAV selected
|
||
5. Drag-selecting multiple UAVs
|
||
6. Task selected
|
||
7. Command preview
|
||
8. Command queue
|
||
9. Operator requesting command authority
|
||
10. Operator transferring command authority
|
||
11. UAV failure
|
||
12. Automatic replacement recommendation
|
||
13. Strategic zoom
|
||
14. Operational zoom
|
||
15. Vehicle-level zoom
|
||
16. Alert escalation
|
||
17. Collaborative mission planning
|
||
|
||
---
|
||
|
||
# CRITICAL UX PRINCIPLE
|
||
|
||
The system must always answer these questions visually:
|
||
|
||
### WHAT?
|
||
|
||
What is happening?
|
||
|
||
### WHERE?
|
||
|
||
Where is it happening?
|
||
|
||
### WHO?
|
||
|
||
Who/what is responsible?
|
||
|
||
### WHY?
|
||
|
||
Why is the system doing this?
|
||
|
||
### NEXT?
|
||
|
||
What will happen next?
|
||
|
||
### WHAT IF?
|
||
|
||
What happens if something fails?
|
||
|
||
### WHO CAN CHANGE IT?
|
||
|
||
Who currently has command authority?
|
||
|
||
These should be understandable within seconds.
|
||
|
||
---
|
||
|
||
# REAL-TIME FEEL
|
||
|
||
The interface should look alive.
|
||
|
||
Show subtle indicators of real-time state:
|
||
|
||
* moving aircraft
|
||
* updating progress
|
||
* changing task status
|
||
* operator presence
|
||
* live connection status
|
||
* changing fleet counts
|
||
* recent events
|
||
|
||
But do not make the interface visually chaotic.
|
||
|
||
The system should feel like a living operational environment.
|
||
|
||
---
|
||
|
||
# EVENT / HISTORY PANEL
|
||
|
||
Create a chronological event stream.
|
||
|
||
Example:
|
||
|
||
14:32:08
|
||
ALEX
|
||
Assigned ALPHA to TASK-143
|
||
|
||
14:32:14
|
||
SYSTEM
|
||
Route validated
|
||
|
||
14:32:21
|
||
SARA
|
||
Updated BRAVO search area
|
||
|
||
14:33:02
|
||
SYSTEM
|
||
UAV-03 unavailable
|
||
|
||
14:33:04
|
||
SYSTEM
|
||
Recommended UAV-19 as replacement
|
||
|
||
14:33:17
|
||
ALEX
|
||
Accepted replacement
|
||
|
||
Make the history auditable and easy to understand.
|
||
|
||
---
|
||
|
||
# DESIGN THE UI FOR MULTIPLE MONITOR SIZES
|
||
|
||
The application should support:
|
||
|
||
* laptop
|
||
* 27-inch monitor
|
||
* ultrawide monitor
|
||
* 4K command-center display
|
||
|
||
Do not depend on tiny controls.
|
||
|
||
The interface should gracefully adapt.
|
||
|
||
On smaller displays, secondary panels collapse.
|
||
|
||
On larger displays, additional information can appear without making the main map smaller.
|
||
|
||
---
|
||
|
||
# CREATE A DESIGN SYSTEM
|
||
|
||
After creating the main screen, show a small design-system panel containing:
|
||
|
||
* colors
|
||
* typography
|
||
* buttons
|
||
* status indicators
|
||
* group cards
|
||
* task cards
|
||
* UAV icons
|
||
* alert states
|
||
* operator presence indicators
|
||
* command authority indicators
|
||
|
||
This should look like a real product design system.
|
||
|
||
---
|
||
|
||
# IMPORTANT: SHOW REAL UI, NOT A CONCEPT ART SCREEN
|
||
|
||
The output should look like a **real, implementable professional software interface**.
|
||
|
||
Do not generate a cinematic image of a command center.
|
||
|
||
Do not generate people sitting in front of screens.
|
||
|
||
Do not generate a futuristic holographic battlefield.
|
||
|
||
Generate the actual application UI.
|
||
|
||
The viewer should be able to imagine a software engineer implementing it.
|
||
|
||
---
|
||
|
||
# VISUAL OUTPUT
|
||
|
||
Create a polished high-fidelity visual presentation containing:
|
||
|
||
### HERO SCREEN
|
||
|
||
Full 16:9 multi-UAV mission control interface.
|
||
|
||
### SCREEN 2
|
||
|
||
Strategic zoom → operational zoom → vehicle zoom.
|
||
|
||
### SCREEN 3
|
||
|
||
Multi-operator collaborative mission view.
|
||
|
||
### SCREEN 4
|
||
|
||
Task creation + resource allocation + command preview.
|
||
|
||
### SCREEN 5
|
||
|
||
Failure → automatic reassignment → operator confirmation.
|
||
|
||
### SCREEN 6
|
||
|
||
Command queue / mission workflow.
|
||
|
||
### SCREEN 7
|
||
|
||
Design system.
|
||
|
||
Use consistent visual language across every screen.
|
||
|
||
---
|
||
|
||
# FINAL DESIGN TEST
|
||
|
||
Before finalizing the visuals, mentally test the design against this scenario:
|
||
|
||
Five operators are simultaneously managing fifty UAVs.
|
||
|
||
Operator A manages a 12-UAV search group.
|
||
|
||
Operator B manages a 10-UAV reconnaissance group.
|
||
|
||
Operator C manages communications.
|
||
|
||
Operator D is planning future tasks.
|
||
|
||
Operator E is monitoring system health.
|
||
|
||
One UAV fails.
|
||
|
||
A new task arrives.
|
||
|
||
Two groups need to be reorganized.
|
||
|
||
An operator needs to temporarily transfer control of a group.
|
||
|
||
The system needs to continue operating without everyone fighting over the same controls.
|
||
|
||
The UI should make this scenario feel manageable rather than overwhelming.
|
||
|
||
The final visual design should communicate:
|
||
|
||
> **One shared mission.**
|
||
>
|
||
> **Many operators.**
|
||
>
|
||
> **Many vehicles.**
|
||
>
|
||
> **One coherent operational picture.**
|
||
|
||
Prioritize cognitive ergonomics, hierarchy, semantic zoom, group abstraction, collaborative authority, exception management, and high-level intent over decorative aesthetics.
|
||
|
||
### One thing I'd add to the Gemini workflow
|
||
|
||
Don't stop at the first generated dashboard. Ask Gemini to produce **separate iterations around specific interaction problems**.
|
||
|
||
For example, after the master prompt, give it:
|
||
|
||
> "Now forget the visual styling and focus exclusively on the interaction design for managing 50 UAVs with 5 operators. Produce 5 radically different UI concepts for selection, grouping, command authority, task assignment, and strategic zoom. Do not optimize for visual beauty yet. Optimize for reducing operator cognitive load."
|
||
|
||
Then another:
|
||
|
||
> "Take concept #3 and redesign it as if Supreme Commander, Google Docs collaborative editing, and a professional aviation mission planner had been combined. Show exactly how five operators can simultaneously manipulate different groups without command conflicts."
|
||
|
||
And finally:
|
||
|
||
> "Now create a polished production-quality visual design based on this interaction model. Remove anything that looks like a video game HUD. Keep the RTS interaction model but make the visual language appropriate for professional aviation software."
|
||
|
||
That **three-stage process—interaction → information architecture → visual design** will likely give you much better results than asking Gemini to jump directly to a pretty GCS screenshot. |