Keysight’s KS8500B PathWave Test Automation Cloud lets teams run, monitor, and share test results across distributed instruments and global labs, on a platform supporting 300k+ engineers worldwide using Keysight products. The dashboards are where teams monitor system health, debug failures, and make time-sensitive decisions.
I led AI-first UX design for those dashboards: research, strategy, and the design of AI-assisted workflows, working with Keysight’s team in Silicon Valley. The project ran from secondary research in April 2025 to high-fidelity final designs in December 2025.
◇ marks a waypoint. Click one and the stage beside you changes.
The existing dashboard surfaced large amounts of information without prioritization. Error states were hard to interpret, important signals were buried, and getting context meant leaving the tool. Users described working across Excel sheets, Slack channels, email, dashboards, and self-made tools to answer a single question.
Teams work across time zones, so a delay or missed signal can stall a test cycle until the next handoff. For the lab that means lower station utilization, slower test cycles, and more errors in results.
I planned and ran with lab managers, test engineers, and design engineers.
The pattern across roles: teams had the data, lacked visibility into what needed attention, and lacked guidance on what to do next. Metrics were hard to interpret, and views could not adapt by role or context.
The raw research synthesized into four themes: Visibility for decision-making (quick, at-a-glance insights), Understandability (complex data made clear and easy to interpret), Workflow efficiency (fragmented layouts and unnecessary clicks slow people down), and Customizability (different roles need control over what they see). Each became a How Might We question, and ideation worked inside the themes so concepts stayed connected across workflows instead of becoming isolated features.
The .
The first buildable concept was a unified dashboard driven by templates: choose a template for your role, customize it, see everything in one place.
Why start here?
It answered the research directly: one place instead of five tools, with role adaptation through template choice. It was also quick to wireframe and cheap to test.
Usability tests on the template concept showed that participants already relied on mature dashboard tools. That left the unified dashboard with no case: a version that looked and worked like Grafana or Tableau gave users no reason to switch, and a version that worked differently would fight habits they had already built. Jakob’s law describes the second half of that trap: people expect new products to work like the ones they already use.
How do we make this meaningfully better than the dashboards users already trust?
We prototyped both candidate answers and tested them side by side: , and .
Neither version won outright. The direction that carried forward combined them. Each of its three core features shortens one stretch of the path from data to decision: starting a dashboard, reading it, and acting on what it shows. They follow, as refined through the second and final iterations.
Creation starts from a dataset and a prompt. You select the data, describe what you need in plain language, the AI suggests charts, and you drag the useful ones onto a canvas. carry the detail work.
Why suggestions rather than full generation?
: recommendations in context, not a separate AI mode. Suggestions make starting fast, and manual composition keeps engineers in control of what their team will rely on. Every AI feature kept a manual path to the same result.
The main view combines filters, , and an AI summary of the dashboard’s current state. The charts themselves stay plain and legible. At scale, .
The summary earned its position through testing. The first version hid summaries at chart level, visible only in an expanded view. : automatic detection of deviations that are not typical of everyday operations, shown somewhere accessible, in a dedicated area. The final design moved the AI Summary to the left panel, always available, with the top three insights each linking directly to the chart behind them.
Why put AI in the summary and not in the charts?
The research gap was interpretation. Engineers trusted their charts and knew how to read them. What they lacked was a fast answer to which of these signals needs my attention, and the summary answers exactly that question.
Drill-downs trace a signal to its cause without leaving the tool. From any analysis, the AI drafts a report, so findings can be shared without rewriting them somewhere else.
. Participants wanted summaries brief on screen, with real detail arriving in the downloaded report. The final design added an AI assistant for revising report content, insights pulled directly from the AI Summary, and share, export, and save-as-template options.
A quiet safety rides along: , which makes experimentation safe on dashboards a whole team relies on.
Why does reporting belong in a monitoring tool?
The tool-switching problem did not end at understanding. Writing up the findings was the last forced exit, and the report drafts remove it.
The designs went through 9 evaluation sessions: 5 wireframe usability tests (1 pilot, 4 task-based) and 4 high-fidelity task-based tests. In the task-based tests, users got from raw test data to a finished report 11.5% faster with the AI-assisted dashboard.
The number is conservative. The prototype ran on simulated data with loosely connected AI, so users still reviewed and refined AI outputs manually, which capped the gain. Deeper backend integration, pattern recognition on real datasets, and stronger trust mechanisms would likely push it higher. Future work: customizable templates and traceability for enterprise users.