BENCE HENZ
—
Design that works.
EIVA
100%
Designing clarity for complex maritime operations
CLIENT
EIVA
SERVICES
The challenge: preserve expert power while reducing friction
EIVA builds software for offshore surveying, subsea inspection, navigation, robotics, and data processing. Its tools are powerful because the work is technical, safety-sensitive, and expensive. My challenge was not to remove that complexity, but to make it easier to understand and act on.
I worked across research, product framing, information architecture, interaction concepts, workshops, and design systems to help shape the next generation of NaviSuite.
How might we make NaviSuite feel like one coherent product experience without weakening the flexibility and control maritime experts depend on?
NaviSuite supported a broad operational journey: configuring vessels and sensors, checking system readiness, acquiring and reviewing data, planning missions, controlling vehicles, and producing deliverables.
Over time, these capabilities had grown across multiple products, modules, menus, and interaction patterns. Users often needed deep product knowledge before they could complete the task in front of them. Newer users faced a steep learning curve, while experienced users still needed speed, precision, and control.
Field context showed why clear status and fast recovery mattered across dense displays and high-attention tasks.
Nested, product-specific controls created discoverability and consistency problems.
1. Find the patterns behind the friction
I conducted and synthesized 100+ external interviews with customers, trainers, and maritime practitioners. I combined those conversations with field evidence, customer-satisfaction comments, an existing acquisition UX report, surveyor input, and reviews with product, development, and domain specialists.
The interviews were semi-structured around current workflows, learning, recurring friction, frequently used features, and expectations for a future product generation. I clustered findings by sentiment, pain level, and engagement rather than treating every request as equal.
Several patterns repeated across participants:
New and experienced users struggled with too many options and inconsistent paths.
Hidden functions led some users to believe the software could not perform a task.
Setup and configuration felt like a separate skill rather than part of the workflow.
Recording, sensor, error, and readiness feedback needed greater visibility.
Different roles needed different levels of detail.
The personas distinguished operational responsibility, expertise, goals, and information depth across the platform.
2. Make existing capability easier to find
Interview participants described functions hidden across menus, project trees, right-click actions, and separate applications. In documented observations, novice users could not locate Vehicle Control; another user concluded that basic AUV mission planning was unsupported because the necessary action was hidden.
This showed that the problem was not simply visual density. Product structure was obscuring capability.
Because of this, I shifted the product framing from applications to one operational sequence:
Mobilize a vessel or vehicle.
Configure the project, sensors, offsets, and coordinate systems.
Confirm that the system is ready.
Acquire and monitor data.
Review quality and respond to issues.
Replay, report, export, and deliver results.
The workflow connected project setup to acquisition readiness and made critical dependencies visible.
To avoid oversimplifying the product, I compared the new model against the needs of each role. Everyday steps could be guided and surfaced, while advanced tools remained available for expert workflows, remote operations, autonomy, and fleet-level use.
Structure complexity around the user's workflow, not the product's history.
3. Make technical complexity understandable
External participants described setup as difficult to learn and easy to get wrong. A specialist review then showed why: project and survey terminology could conflict, important metadata was hidden, similar information could be entered in multiple products, and repeated entry increased transcription risk.
Configuration therefore became more than a settings problem. It affected data quality and whether users trusted that acquisition could begin.
I responded by organizing configuration around recognizable decisions:
Project metadata and geodesy
Vessel and vehicle definition
Sensors, offsets, calibration, and communication
Survey planning
Readiness checks before acquisition
The information architecture reorganized setup around recognizable decisions, helping connect technical configuration with readiness and data quality.
Review with survey and development specialists changed the requirements further. The direction evolved toward one pass-through project configuration, sensible defaults, bundled setup for combined instruments, help close to the task, communication testing, and visual feedback for reference points and sensor orientation.
This kept expert flexibility while reducing missed fields, duplicate entry, and uncertainty about whether the system was ready.
4. Design autonomy around trust and supervision
External interviews showed that users often could not tell whether everything was recording or healthy, while errors did not reliably explain the cause or recovery path. Four follow-up mission-planning interviews and domain reviews clarified the role split: planners needed route and behaviour detail, operators needed progress and alerts, and pilots needed vehicle health plus intervention.
That role split shaped the mission-planning and supervision concepts:
Mission objectives, templates, and validation
Map-based planning and quality control
Live mission progress, vehicle state, and alerts
Fallback states and intervention controls
Post-mission review, anomalies, and reporting
Early wireframes tested mission building, validation, monitoring, and completion before adding interface detail.
The concept brought planning, live supervision, vehicle state, and intervention into one view, making autonomous behavior legible and interruptible.
The same trust principle also informed my VSLAM and Discovery3D work: clearly communicate whether the system is connected, tracking, recording, producing usable data, or needs user action.
The concept brought planning, live supervision, vehicle state, and intervention into one view. The goal was not to hide autonomy, but to make its behavior legible and interruptible.
VSLAM reviews made the feedback model more specific. Requirements expanded to include automatic camera connection; connected, disconnected, and lost-track states; image-quality and coverage feedback; speed and overlap guidance; recording controls; and recovery after tracking failure.
5. Scale quality through systems and AI
A unified product also needed shared design language and a clearer path from design decisions to implementation.
I contributed foundations for typography, color, spacing, controls, themes, naming, Figma variables, component practices, annotations, and development handoff.
With developers, I reviewed OpenBridge, assessed its value, and helped adopt it as a shared design-system foundation.
This work compared shared foundations, interaction patterns, and governance needs so consistency could scale across teams rather than depend on individual screens.
AI-assisted design operations experiment
I introduced Claude Code with Figma MCP write access, supported by figma-use and figma-generate-design. Instead of only reading design context, the agent could inspect our published library and work on the canvas using the system already in place.
I used the workflow to map hardcoded colors to variables, replace raw typography values with shared styles, normalize tokens, and generate handoff documentation across large file sets.
This cut audit and documentation cycles by approximately 60%, enabling one designer to maintain component quality across a product suite previously requiring several contributors.
The experiment also exposed a limit: inserted components sometimes ignored a parent frame’s auto layout and became absolutely positioned, breaking when the layout resized. Human review remained essential. The larger lesson was that AI output mirrors system quality. Clear names, consistent tokens, and documented variants made automation reliable.
Outcome
My work helped turn scattered user input, technical requirements, and future-product discussions into a more coherent design direction for NaviSuite.
A traceable connection between user evidence, specialist review, and design decisions
A shared narrative for a more unified acquisition experience
A task-based model spanning setup, readiness, acquisition, review, and delivery
Clearer UX requirements for configuration, sensor state, data quality, and recovery
Mission-planning and supervision concepts for autonomous operations
Design-system and handoff foundations for greater consistency across products
Much of this work shaped product direction rather than a single public product launch, so I evaluate its value through the decisions, artifacts, and cross-functional alignment it enabled rather than claiming unverified metrics.
Use direct evidence to challenge assumptions, turn feedback into product decisions, and keep expert tools powerful while making them clearer and safer.
Portfolio note: Product details have been generalized. Internal names, customer information, and confidential roadmap material are omitted.
