Mukund Sharma
All case studies

SafeSquid Labs Office Efficiencies India Private Limited

Cybersecurity · Design internship · 2024

Website Tester · Network diagnostics

Run four network checks in one desktop workspace.Reopen any result in one click.

Website Tester combines DNS, port, server-response, and proxy checks for technicians. I redesigned it as a persistent workspace so every command, result, and next action stays connected.

Challenge
Useful checks became disconnected output screens.
Design response
Turn every test into a persistent diagnostic thread.
Delivered
One workspace for four checks across Linux and Windows.
My role
Product design intern
Research partner
1 network technician
Scope
Workflow, IA, prototype, UI
Delivery
Completed desktop redesign
Redesigned Website Tester landing screen

Process overview

  1. 01

    Empathize

    Interview + workflow observation

  2. 02

    Define

    Problem + design principles

  3. 03

    Ideate

    12 low-fi alternatives

  4. 04

    Test

    Technician review on selected structures

  5. 05

    Refine

    Revised wireframes + hi-fi interface

Ownership and boundaries

I owned the product experience from audit to prototype.

The redesign changed how technicians moved through diagnostic work while keeping the underlying engine and technical evidence intact.

End-to-end ownership

  1. 01Interface audit
  2. 02Workflow model
  3. 03Information architecture
  4. 0412 low-fi directions
  5. 05Technician review
  6. 06Hi-fi prototype
Collaboration
1 network technician

Reconstructed a recent investigation and reviewed the selected interaction structures.

Fixed constraints
Engine + raw output

The diagnostic logic and one shared desktop model for Linux and Windows stayed intact.

01 · Empathize

Understand the real diagnostic workflow.

One technician reconstructed a recent investigation through six behavioural questions. The goal was to capture sequence, interpretation, comparison, handoff, and platform differences—not preferences about a mockup.

01

Participant

Network technician

06

Questions

Recent behaviour

03

Needs

Continuity · interpretation · reuse

Interview theme

Investigation sequence

What happened the last time a domain failed?

Which check did you run first—and why?

What emerged

The sequence changed with each result. A DNS response could lead to a server, port, or proxy check.

So I designed

A flexible workflow that preserves the investigation between checks.

Interview theme

Reading and comparison

How do you recognise a suspicious result?

When do you return to an earlier domain?

What emerged

Commands, status, and raw values had to be read together; earlier results were revisited for comparison.

So I designed

Interpretation without hiding technical evidence or previous results.

Interview theme

Handoff and platform

What happens after you understand a result?

What changes between Linux and Windows?

What emerged

Results were copied, shared, or rerun. Commands changed by platform, but the investigation stayed the same.

So I designed

Reusable actions and one task model across both command modes.

Previous Website Tester interface with raw DNS output and visually equivalent diagnostic rows
  1. 01

    Run

    One command becomes the entire screen

  2. 02

    Interpret

    Raw rows depend on technician memory

  3. 03

    Continue

    Previous domain and command disappear

  4. 04

    Reuse

    Copy, compare, and rerun have no clear path

02 · Define

Turn an output screen into an investigation workspace.

The core problem was not inaccurate diagnostics. It was lost working context: every command behaved like a new event, while the technician's real task continued across checks, domains, and actions.

Problem statement

Technicians could run useful checks, but the interface did not preserve the investigation those checks belonged to.

How might we

Keep every result understandable, retrievable, and ready for the next diagnostic action?

Continuity

Preserve continuity

What we learned

A diagnosis spans several commands and domains.

Design response

The interface must remember completed and active tests.

Interpretation

Explain without concealing

What we learned

Raw output is necessary but does not communicate priority alone.

Design response

Interpretation must sit beside inspectable commands and values.

Action

Support the next action

What we learned

Diagnostic work continues after a result is understood.

Design response

Copy, download, reopen, and rerun must stay attached to the result.

Success criteria

How the direction would earn its place.

  1. 01

    Platform and command context stay visible from entry to result.

  2. 02

    A completed test can be restored in one interaction.

  3. 03

    Interpretation sits beside inspectable raw values instead of replacing them.

  4. 04

    Copy, download, and rerun stay attached to the result they affect.

03 · Ideate

Compare structures before choosing a direction.

Twelve low-fidelity alternatives tested structure before visual polish. Each group converged on the option that best satisfied continuity, interpretation, and reuse.

Decision 01

Starting a diagnostic

How much structure should appear before the first command runs?

Evidence used

The technician moved between domains, commands, and operating systems, so all three had to remain visible at entry.

Option 01Not selected

Single command field

Rejected: speed came at the cost of hidden platform context and a greater chance of running the wrong command.

Option 02Not selected

Two-step modal

Rejected: the sequence was clear, but every new test introduced the same interruption.

Option 03Selected

Workspace header

Chosen: domain, platform, and command stay inspectable without adding another step.

Option 04Not selected

Command library

Rejected: it optimised command discovery, while the primary need was running and continuing known checks.

Final decision

Workspace header

Expected impact

Fewer setup decisions to remember, clearer platform context, and a faster path from domain to first result.

Decision 02

Preserving completed tests

What should become the persistent unit of work?

Evidence used

Returning to a domain required its command, platform, and status, while several results needed to stay comparable.

Option 01Not selected

Accordion history

Rejected: compact when closed, but comparison required repeatedly opening and collapsing domains.

Option 02Not selected

Session dashboard

Rejected: strong overview, but it separated the technician from the active diagnostic thread.

Option 03Selected

Named test tabs

Chosen: each domain becomes a retrievable unit with its command and result context attached.

Option 04Not selected

Vertical timeline

Rejected: chronological order was clear, but parallel checks became a long serial list.

Final decision

Named test tabs

Expected impact

One-click recall of a complete test thread and less dependence on memory or copied output.

Decision 03

Reading and reusing output

How should raw diagnostics become an actionable report?

Evidence used

The technician read command, status, and raw values together, then copied or reran the result.

Option 01Not selected

Raw table

Rejected: preserved every value but continued the original problem of equal visual weight.

Option 02Not selected

Summary cards

Rejected: improved scanning, but separated conclusions from the raw evidence behind them.

Option 03Selected

Grouped report

Chosen: each diagnostic group combines meaning, raw values, status, and relevant actions.

Option 04Not selected

Guided stepper

Rejected: imposed a linear reading order on an investigation that often branches.

Final decision

Grouped report

Expected impact

Faster scanning by diagnostic purpose while raw values stay inspectable and follow-up actions remain attached.

04 · Test

Test the selected workflow with a technician.

The prototype review focused on three real tasks: resuming a completed domain, switching command mode, and carrying a result into the next troubleshooting step.

Task 01

Return to a completed domain

Observed

The technician needed the command and status—not only the domain name—to resume confidently.

Refined

Expanded tabs restore platform, command, HTTP status, and port context together.

Task 02

Switch from Linux to Windows

Observed

The command changed, while the investigation structure remained familiar.

Refined

Platform mode became explicit without creating a second product flow.

Task 03

Carry a result into the next step

Observed

Understanding the report was not the end; the result still needed to be shared or repeated.

Refined

Copy, download, and rerun actions moved beside the result they affect.

From feedback to structure

Revise the wireframes from observed behaviour.

Each observation changed a specific part of the interaction model. The revised wireframes made that response explicit before the interface moved into high fidelity.

Revision 01

Return to a completed domain

Expanded tabs restore platform, command, HTTP status, and port context together.

Revision 02

Switch from Linux to Windows

Platform mode became explicit without creating a second product flow.

Revision 03

Carry a result into the next step

Copy, download, and rerun actions moved beside the result they affect.

05 · Refine

Build the hi-fi interface from the validated structure.

The visual layer now supports the interaction model already established in the revised wireframes: visible command context, retrievable test threads, explicit platform modes, grouped results, and attached actions.

01 · Start with platform and command context visible
Redesigned Website Tester landing page with platform and command controls
02 · Preserve completed tests as named tabs
A completed website test preserved in a compact named tab
03 · Expand a tab to restore full context
Expanded Website Tester tab showing command, HTTP status, and port checks

04 · Shared platform model

Linux and Windows change the command—not the workflow.

Website Tester switched to Windows command mode while retaining the same workspace structure
05 · Group results by diagnostic purpose and keep actions beside the report
Website Tester results grouped into DNS, HTTP, SSL, and port check sections

Outcome

Keep four checks connected in one reusable workflow.

The redesigned workflow keeps the technician's full investigation visible: what ran, where it ran, what the result means, and what can happen next.

04

Diagnostic checks

DNS, ports, server response, and proxy

02

Platform modes

Linux and Windows in one task model

01

Click to recall

Named tabs restore a previous result

03

Result actions

Copy, download, and rerun

Delivered impact

The interface now carries the cognitive load.

Less memory work
The workspace now carries domain, platform, command, status, and prior results between checks.
Faster return
Named test tabs restore a completed diagnostic thread in one click.
Clearer reading
Results are grouped by diagnostic purpose while raw evidence remains inspectable.
Stronger follow-through
Copy, download, reopen, and rerun remain attached to the relevant result.

Before

Each command ended at an isolated output.

After

Every result remains a reusable diagnostic thread.

Accessibility decisions

Meaning remains visible beyond colour and hover.

Written status labels support colour cues instead of replacing them.

Numbered diagnostic groups create a predictable reading order.

Platform, command, and status remain text—not icon-only context.

Result actions stay visibly labelled and do not depend on hover.

Back to case studies