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. Understand the work behind the interface
I reviewed strategy and product material, interviewed stakeholders and users, studied operational context, and facilitated several workshops with domain experts.
I mapped goals and pain points across surveyors, ROV pilots, operators, engineers, processors, and client representatives, revealing different needs for information and control.
Across the evidence, several themes repeated:
Power was not the problem; clarity was.
Similar tasks behaved differently across products.
Configuration errors could undermine trust in collected data.
Readiness, recording, sensor health, and data quality needed greater visibility.
Emerging autonomy required supervision and intervention, not only direct control.
Synthesis turned individual comments into recurring product themes and priorities.
2. Reframe the product around user workflows
I shifted product discussions from applications and modules toward the work users needed to complete.
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.
This model supported simpler setups while leaving room for advanced, remote, autonomous, and fleet-level workflows.
The key design principle was simple:
Structure complexity around the user's workflow, not the product's history.
3. Make technical complexity understandable
Configuration became a focal point because it connected usability directly to operational confidence. Vessel definitions, sensors, offsets, geodesy, reference points, calibration, and outputs were technically necessary, but they were difficult to reason about as one system.
Separate project information from vessel and instrument setup.
Organize settings into clearer groups and sequences.
Make sensor health and readiness visible.
Guide calibration, offsets, and reference-point setup.
Surface blocking problems before acquisition begins.
Keep expert controls available without showing every option at once.
The information architecture reorganized setup around recognizable decisions, helping connect technical configuration with readiness and data quality.
This work treated configuration as part of the core product experience, not a hidden technical prerequisite.
4. Design autonomy around trust and supervision
EIVA’s move toward more autonomous subsea operations introduced a different interaction challenge. Users needed to plan and simulate missions, understand what the system was doing, monitor changing conditions, and intervene when necessary.
I translated autonomy strategy into an operational experience that included:
Mission objectives, templates, and validation
Sensor and vehicle readiness
Live mission progress and alerts
Map, vehicle, and video quality-control views
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.
5. Scale quality through systems and AI
A unified product could not be created through isolated interface concepts alone. Teams 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 research, technical requirements, and future-product discussions into a more coherent design direction for NaviSuite.
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.
Being a product designer often means learning an unfamiliar domain, finding structure in complexity, making ideas tangible, and connecting interface decisions to the wider product system.
Portfolio note: Product details have been generalized. Internal names, customer information, and confidential roadmap material are omitted.
