I redesigned a defence communication platform for secure offline data exchange between Windows and RHEL systems, making connections, messaging, file exchange, and activity status easier to understand and manage.
SecureLink supported offline communication between Windows and RHEL systems, allowing operators to exchange messages, files, and operational information within a controlled local environment.
The existing experience exposed too much technical complexity during routine tasks. Users had to understand connections, identify devices, monitor transfers, and interpret technical errors before completing their work.
Make available connections easier to identify and select.
Make connection & transfer states immediately clear.
Help users understand progress & completion without checking.
Turn technical errors into clear and actionable next steps.
The research focused on existing workflows, connection behavior, transfer states, user friction, and technical constraints rather than assumptions from consumer communication products. The approach combined workflow evaluation, heuristic review, information architecture assessment, interaction analysis, and technical/developer discussions.
The goal was to understand not only where users experienced friction, but also what information they needed at each step to confidently connect, transfer data, monitor progress, and recover from errors.
“I need to know which device is connected, what is happening, and whether my data reached the right destination.”
How might we redesign SecureLink so defence operators can quickly identify the right connection, exchange files reliably, and clearly understand system status while working across Windows and RHEL systems in restricted environments?
Multiple adapters and technical connection details made it difficult to identify the correct device.
Users spent additional time checking connections before starting a transfer.
Users could not always tell which device was connected, available, or ready for communication.
Unclear system states created uncertainty during routine communication tasks.
Users needed clearer feedback to understand whether a file or message was transferring.
Limited feedback made users uncertain about transfer progress and completion.
Technical error messages did not clearly explain what went wrong or what users should do next.
Users had to interpret technical information before they could recover from an issue.
Instead of exposing network complexity directly to operators, SecureLink was structured around a clear operational journey: connect → verify → exchange → monitor → recover.
The information architecture was organized around the operator's workflow, keeping connection status, devices, communication, and transfer activity easy to access.
The dashboard was redesigned around the operator's immediate need: “What is connected and ready to use?” Active adapters, device status, connection state, and key system information were surfaced clearly to reduce network-related confusion.
Device selection was organized around Identify → Verify → Select, making available devices, connection states, and relevant details easier to compare before starting communication.
The file exchange experience was structured around Select → Send → Monitor → Confirm. Clear file information, transfer progress, speed, and completion status helped operators understand exactly what was happening.
Connection and transfer states were designed to communicate what happened, what is happening, and what happens next. Status indicators, progress feedback, and confirmation states reduced uncertainty during critical operations.
Instead of exposing users to unclear technical errors, the experience provided Problem → Explanation → Recommended Action. This helped operators understand the issue and recover without needing to interpret complex networking terminology.
The focus was on information hierarchy, navigation, data density, workflow steps, status visibility, primary actions, and interaction states.
The wireframes established the structural foundation for the workflows, and audit experience before moving into high-fidelity design.
| State | SecureLink Meaning |
|---|---|
| Connect | Active device connection / Ready for communication |
| Active | Message or file transfer currently in progress |
| Attent | Connection or transfer requires operator attention |
| Failed | Communication or transfer could not be completed |
| Offline | Device unavailable or not currently connected |
The central design challenge was how to simplify a technically complex communication system without hiding the information operators need to understand connections, transfers, and system health.
A technically dense interface makes routine communication tasks difficult to scan and increases operator cognitive load.
An overly simplified interface makes troubleshooting difficult when connections fail or transfers are interrupted.
The redesigned SecureLink experience was reviewed with developers and technical stakeholders to ensure that the proposed workflows were clear, technically realistic, and aligned with the communication system's operational requirements.
Users frequently selected inactive network adapters because the list was unorganized and treated all adapters equally.
The UI automatically highlighted active Ethernet connections and forced inactive adapters lower in the visual hierarchy list.
Faster adapter selection and fewer connection errors.
Users repeatedly clicked the Send button because there was no visual indication that the file transfer had started.
Introduced an animated progress bar, transfer percentage, estimated time, and clear success confirmations.
Increased user confidence, eliminated duplicate transfers.
This project taught me that system awareness is part of the task. Clear hierarchy, visible states, predictable actions, and meaningful feedback can reduce uncertainty without hiding the complexity behind the system. I also learned to respect existing workflows and validate changes before changing established behaviour.