Information Visualization Design

Business Challenge

Six information views displayed simultaneously, all linked together. By navigating through any view, the others updated accordingly.

How to enter a mature market (serial protocol analysis) owned by an entrenched competitor?

The competitor’s UX, considered industry-standard, was not capable of handling the latest emerging hi-speed serial protocol (PCIE3)

Our system was the most accurate and least invasive of any on the planet, but its user experience was awful.

The instrument's accuracy forced engineers to look at 1GB of data practically one bit at a time.

The business believed with our superior hardware and an improved UX, we could take significant market share from the competition. The only question was, “How?”

Results

Screen capture of Bird's Eye View (BEV) latency information. The time between a request for a packet and its ultimate delivery indicates the performance of the circuit. This display renders latency as small colored dots (red exceeds a threshold) along with size (larger dots indicate greater latency).

BEV Latency display: Each lane of traffic indicates how long a packet request took to be fulfilled. Red exceeds a threshold, indicating potential latency issues.

Screen capture of Bird's Eye View (BEV) LTSSM visualization. As two end points in a serial circuit "train" they pass through an agreed-upon set of states. This view displays the state changes.

BEV LTSSM display: PCIE3 circuits "train up" determining what bandwidth they can operate at. The endpoints move through a series of states, prescribed by the protocol. Failure states can be easily seen in the colored bands.

Screen capture of Bird's Eye View (BEV) rollover, showing additional data at the cursor.

BEV detail view. Each pixel in the BEV represents as much as 1Mb of data. Grazing over the BEV reveals specific data elements within that sliver of time.

Screen capture of Bird's Eye View (BEV) error visualization. Errors, represented by different shapes are positioned in time, earlier at the top, most recent at the bottom.

BEV Error display: Things go wrong all the time in a PCIE3 circuit. This customizable display shows errors as symbols, placed in time and channels.

Screen capture of Bird's Eye View (BEV) flow control visualization. Flow control, the way circuits negotiate the flow of serial data, is represented as a set of blue and red lines. Thin blue means the flow is in spec, thick blue means the flow is approaching a threshold and red means the threshold has been crossed.

BEV Flow control display: PCIE3 circuits constantly monitor the receiver's ability to accept more data. When the display shows thickening or red lines, the engineer can zoom in to see why data isn't flowing smoothly.

BEV Flow control display detail.

We designed an information visualization offering multiple views into the same data acquisition.

This approach offered validation engineers a variety of ways to view the problem, without risking another data capture.

For example, the summary display (shown above), renders six separate views, all linked together in a “zoomable” interface.

One revolutionary approach was a “bird’s eye view” (the BEV): in a 100 pixel-wide container displaying five selectable visualizations. With the BEV, the debug engineer could quickly view important attributes of data sets as large as 16GBs!

Drawing of TSA front panel showing LED arrangements, sockets, ports and connectors.

Specification image of actual front panel showing LEDs that correspond to configuration screen elements.

Screen capture of the TSA front panel, configuration screen.

Software front panel configuration screen showing 16 channels, 8 up and 8 down.

Software front panel configuration screen showing 8 lanes, 4 up and 4 down.
Note how the TSA permits non-standard routing from the physical probe to the logical lane.

Screen capture of the TSA front panel self-calibration process. The instrument ran through a series of tests on the target circuit to determine how best to acquire good signals.

Software front panel configuration screen showing self calibration and configuration.

Equally revolutionary was the front panel itself and its configuration screen. Our design for the software interface mimicked the physical front panel, but the visualization simultaneously provided status and configuration.

Debug engineers never simply "configured" test equipment. Instead, they perfomed a set of experiments to confirm the configuration was working. The display combined configuration with status, permitting the engineer to quickly determine the status of the configuration without having to suffer time-consuming data captures.

Process

Photo of sticky notes arranged on hand drawn screens indicating desired features and relative relationship of data elements.

Participatory design artifact. Participants were asked to sketch a desired analysis screen using sticky notes and markers.

Photo of lab bench with multiple monitors, keyboards, mice and machines, cables dangling everywhere.

In-situ observations. Typical test bench environment.

Image of multiple screens showing circuit undergoing training. As the two end points learn more about each other, higher resolution of information is rendered on the screens.

Presumptive design prototype: animated sequences (in PowerPoint) rendered PCIE streams as they trained.

Image of protocol packets on sketched screen. Packets enter from right of screen - they are ornamented with specific icons indicating their type.

Presumptive design prototype: animated sequences (in PowerPoint) rendered PCIE packets as icons marching across the screen.

This effort built on the work I had already done for the Logic Analyzer product line. Because our target users were exactly the same as for the prior instrument, we could re-use the Personas, work models and experience schematics.

But protocol analysis is not at all like logic analysis, and the incumbent competitor had the benchmark user experience against which every other was measured. We had to design a completely different and more compelling experience if our prospects would even consider our solution.

Discover

I began with a series of in-situ interviews accompanied by participatory design exercises to tease out what was compelling about the competition's application and where it was weak. In addition, I performed an expert review of the competitor's application to identify key usability weaknesses.

In addition, I fielded a series of Presumptive Designs to test ideas about graphical representations of serial protocol information. (From those, I was able to file and be awarded several patents.)

Photo of screen of data organized in columns and rows, with colored bands distinguishing one type of data from another.

Our best effort at displaying protocol information, circa 2009.

Photo of screen showing "box car" diagram - rows of colored rectangles indicating packet structures.

Competitor's "benchmark" display of protocol information, circa 2009.

A sketch of an affinity or prioritization table cross-correlating PCIE variables with potential applications.

Analysis of PCIE variables against potential applications of software.

Image of a network node diagram or state diagram showing multiple states (nodes) and how they relate to one another (connecting lines). Overlaid in color are the potential rendering options.

Analysis of PCIE state diagram.

Image of InfoVis mapping criteria showing types of information, types of numeric representation and potential rendering alternatives.

Analysis of PCIE variables against Infovis data types and rendering guidelines.

Define

From those engagements, we captured several key findings:

The competitor's representation of "time" was confusing at best and wrong at times!
Their acquisition performance was terrible: large acquisitions took 10-15 minutes unless users chose to throw key data away.
An "end-to-end" view of the data was critical; debug engineers needed to see the complete acquisition, even if it meant rendering 16GB of data.
Errors could occur at any point in the protocol, from a single bit to a malformed transaction sequence. Engineers needed to navigate up and down the stack.

Photo of notebook page containing thumbnail sketches of screen layouts for protocol displays.

Early sketch of multi-window analysis system.

Screen capture of proposed Summary Window showing a table layout. Rows are specific packet types, columns are quantities of packets and overall sparklines for up and down lanes.

Early rendering of Summary Window based on Participatory Design sessions.

Image of multiple lanes of traffic rendered as a schematic drawing.

Evolution of protocol rendering: schematic view of end-to-end packets and transactions.

Design

Armed with these and many other insights, I quickly landed on Tufte's "sparklines" as one way to render end-to-end acquisitions in a tight space. Partnering with a lighthouse customer, the hardware and software teams iterated through an agile approach, rapidly developing the "Summary Statistics" screen. (See my CHI2011 Honorable Mention paper for the details on this entire process).

The Summary Statistics screen was just the first step. We knew we had to show the entire protocol stack, not just the aggregate statistics. My strategy going forward was to eliminate separate reporting screens, whenever possible, and instead integrate visualizations directly into configuration and management tasks. This design strategy completely revolutionized the product line's approach to screen development. It was an opportune time to undertake this work, as the underlying architecture of the machine was also undergoing significant refactoring to address the new serial analysis application.

Image of marked-up visual design for rollover data element for BEV, including "redlined" callouts for placement of various elements.

Excerpt from Bird's Eye View specification showing position and layout specs.

Image of marked-up visual design for BEV, including "redlined" callouts for placement of various elements.

Excerpt from Bird's Eye View specification showing position and layout specs.

Image of specifications for laying out the schematic view. Three drafted drawings of rectangle "trains" rendering protocol packets and transactions.

Excerpt from Schematic View specification showing several different forms of the schematic representation.

Deliver

By the time the I had completed designs for the Bird's Eye View, the product line's software engineering teams had become fully agile. As a result, we were able to quickly iterate on initial design offerings, adding features and capabilities with each release (as opposed to delivering a monolithic release one time per year).

In addition to specifications for details on the visualization, I crafted prototypes in Processing to help me refine my designs, test them with users and communicate them with engineering team members.

Collaboration | Contributions

Screen capture of BEV as progress indicator is moving along the BEV plot area.

To improve perceived performance, the BEV reveals the acquisition data over time, beginning with the most important data: the trigger.

A project of this magnitude takes multiple teams. I was the lead UX researcher, designer and architect throughout this multi-year effort.

I brought in senior UX designers to assist on specific initiatives: early prototyping sessions and analysis of PCIE as well as late-stage design development of the schematic view.

I worked closely with both hardware and software engineering teams to confirm I wasn't violating laws of physics, or creating a software stack that was unaffordable.

Finally, I partnered closely with Product Management and Sales to get in front of the right customers and help move our go-to-market plans forward.