Toward Human-Quantum Computer Interaction: Interface Techniques for Usable Quantum Computing

Toward Human-Quantum Computer Interaction: Interface Techniques for Usable Quantum Computing

Background and motivation

This paper develops interaction techniques for the practical workflow of gate-based quantum computing, from circuit composition and machine selection to transpilation and result interpretation. Its main concern is the gap between the concepts that developers want to express and the low-level qubits, gates, hardware properties, and bit-string counts exposed by quantum programming tools. A learner may understand the idea behind Shor's algorithm without knowing how to change its circuit for another input, while a quantum machine-learning researcher may need substantial classical code to convert images into quantum inputs and measurement results back into images. The authors also identify difficulties in inspecting alternative transpilation results, retrieving changing hardware properties, and sharing complete experimental results. These are existing usability and integration problems that the paper addresses through a coordinated set of notebook interfaces.

The authors survey ten quantum software tools and services, including Qiskit, Cirq, QuTiP, Strawberry Fields, PennyLane, Braket, CUDA-Q, Azure, qBraid, and Classiq. Their comparison is a snapshot of the ecosystem examined for this 2025 paper. They find support for circuit construction, hardware queries, and result plots, but describe substantial reliance on tutorial code, separate web dashboards, and static visualizations. Problem-oriented templates still require adaptation, hardware information is often separated from the development environment, and users must assemble their own comparisons of optimization outcomes. The survey motivates integrated interfaces with details available on demand; it is not a benchmark of the usability or performance of these tools.

Related visualization research addresses parts of this workflow. Circuit composers such as IBM Quantum Composer and Quirk support direct gate manipulation, while QuFlow, QuantumEyes, and VENUS help explain state behavior and Quantivine supports circuit abstraction. VACSEN presents hardware errors over time, and VIOLET supports analysis of quantum machine-learning results. The authors position their work as complementary to these approaches, emphasizing problem-level input and output, links between logical circuits and their physical execution, and integration into computational notebooks. This integration also draws on HCI research on data-intensive work, where notebooks combine code, documentation, and interactive widgets.

Design process and principles

The work arose from approximately three months of iterative prototyping by an HCI researcher, Hyeok Kim, and two quantum-computing researchers, Kaitlin N. Smith and Mingyoung J. Jeng. Jeng participated during the final six weeks. The team discussed designs two or three times per week through remote meetings, Slack, and GitHub issues; Kim led implementation, while Smith and Jeng applied prototypes to their use cases and supplied feedback. The resulting challenges reflect this collaboration and the literature, rather than a separate interview study with recruited participants.

Three principles organize the designs: connect conceptual ideas to quantum information, expose information at different levels of computing, and apply established usability practices to quantum tools. These principles respond to differences between application developers, architecture researchers, and beginners without assuming that their needs remain fixed. For example, a researcher may initially care about image-processing results and later need pulse or transpilation details. Notebook integration and explanations placed directly in the interface support all four task areas, reducing the need to switch between code, documentation, and hardware dashboards.

Figure 3 is an annotated overview of the proposed interaction techniques, including schematic interface elements and example representations. It maps techniques to design principles and likely beginner or expert audiences; the later use-case figures show the functioning notebook prototypes.

Circuit composition and machine exploration

The circuit writer lets developers choose supported problem types and supply meaningful inputs such as integers, image files, or logical expressions. It incorporates existing quantum methods for these problems rather than introducing new quantum algorithms. As inputs change, it checks constraints such as required parameters and valid qubit assignments, and it can automatically determine the necessary qubits and classical bits. Users can disable automatic selection when they need manual control. The writer exports Python circuit code and provides access to QASM, linking graphical authoring to subsequent programming. Its verification supports the constraints of the provided authoring workflow; the paper does not establish a general proof system for arbitrary quantum programs.

The machine explorer combines overview visualizations with detailed tables and pop-up information. Its chip view places qubit properties in their hardware connectivity context, while distribution views summarize properties such as gate errors. Users can inspect individual qubits and gates, select reference dates to see historical property values, and generate reusable code to retrieve selected properties from other machines. Figure 9 illustrates this workflow with a chip diagram, property distributions, a table of qubit data, and exported code used to produce comparable plots for candidate simulators. The technique therefore connects visual exploration to repeatable programmatic data access, rather than automating the entire machine-selection decision.

Comparing circuits and physical execution

The circuit viewer juxtaposes a logical circuit with one or more transpiled physical circuits. Selecting a logical gate highlights corresponding physical gates, helping explain how a compact operation expands into machine-supported gates. A summary table compares optimization outcomes through quantities such as gate count, number of layers, duration, and estimated success probability. The implementation uses a greedy matching approach to associate logical and physical operations; the authors describe this as a practical alternative to exhaustive matching, not a guaranteed perfect correspondence.

A linked hardware view places the currently inspected operations on the processor's qubits and connections. Users can step through layers or play an animation whose timing is proportional to gate-operation duration, slowed down enough to perceive and adjustable in speed. Inactive qubits can be filtered or visually de-emphasized. This view depicts the scheduled use of hardware and its associated error estimates, rather than displaying measured intermediate quantum states. On-demand panels expose additional gate and qubit properties, with pulse information discussed as a detail of interest to more advanced users.

The paper uses estimated success probability, or ESP, to summarize gate-error information:

$$\operatorname{ESP}(G)=\prod_{g\in G}(1-e_g),$$

where $e_g$ is the reported error rate of gate $g$ and $G$ is the set of gates being summarized. The viewer shows ESP for individual layers, cumulative ESP through each layer, and cumulative ESP for each qubit. In Figure 3, paired bars aligned with circuit layers distinguish layer and cumulative values, while qubit colors in the chip view encode cumulative ESP on a green-to-red scale. Figure 10 shows these elements within the implemented comparison dashboard, alongside cross-highlighting and a summary table. ESP is a product-based estimate derived from gate errors, so comparisons based on it should not be read as direct measurements of output-state fidelity.

Interpreting, transferring, and sharing results

The result viewer presents measurement counts together with their logical circuit, physical circuit, job metadata, and relevant machine properties. Because $n$ measured qubits permit up to $2^n$ distinct bit strings, transferring the complete result into a browser can become a practical obstacle. The prototype divides and streams output data to avoid sending one large object to the notebook interface. This is a data-transfer technique; it does not remove the underlying exponential number of possible outcomes.

Problem-specific views translate bit strings and counts into forms appropriate to the application. Figure 4 shows a natural-number plot, a truth table with count bars, an image reconstructed from measurement results, and a contingency table that users configure by selecting bits. The image view exposes rendering parameters such as width, height, ordering, and zoom. These views change how users inspect the same result data, allowing numerical patterns, logical assignments, image structure, or selected-bit relationships to become visible.

The paper also introduces hypothetical error adjustment using Monte Carlo simulation to express uncertainty associated with gate errors. Figure 5 compares measured-count ticks, simulated adjusted-count means, and black intervals described as 95% confidence intervals for the hypothetical adjusted counts. The examples illustrate clearly separated outcomes, less reliable separation, and counts for which more shots may be needed. The procedure tends to move counts toward the uniform level, decreasing large counts and increasing small ones. It is presented as an exploratory uncertainty aid, and the paper does not validate it as a recovery of the ideal distribution or compare it against established error-mitigation methods.

For collaboration, APIs package logical and physical circuits, counts, and machine properties into an object that can be saved and retrieved from a shared file. The retrieved object can reopen result views and create a simulator using the stored hardware properties, helping reproduce the conditions associated with an earlier job even after a provider updates its calibration information. This is implemented job-data support within the prototype, while a broader interoperable standard remains a future research direction.

Implementation and demonstration findings

The authors implement four high-fidelity interfaces: a circuit writer, machine explorer, circuit viewer, and result viewer. They use Svelte and embed the interfaces in Jupyter Notebook through AnyWidget, releasing the prototypes and demonstration notebooks as Patoka. The implementation is mainly built around Qiskit. The paper demonstrates three scenarios reflecting the team's prior uses and challenges; the named characters are pseudonyms rather than evidence of a separate participant evaluation.

The Shor's-algorithm scenario uses the circuit writer to configure an example, generate code, first test a simulator, and then submit a job to IBM's cloud hardware. Figures 6 and 7 show authoring constraints, generated code, saved job data, numerical result views, and historical machine properties. For the reported 39.4 MB result, the authors state that their interface displayed data that Qiskit's online platform failed to show. This is a concrete demonstration of the streaming approach in that case, rather than a systematic browser-performance study.

The quantum machine-learning scenario applies an image-convolution subroutine on a simulator. The writer accepts an image, color dimension, and filter choice, while the result viewer converts measurements back to an image and allows zooming, as shown in Figure 8. The example demonstrates a connected authoring and interpretation workflow; it does not evaluate machine-learning accuracy or compare learning outcomes for users.

The optimization scenario compares four strategies for a Toffoli circuit using simulated hardware properties. Figures 9 through 11 show machine exploration, synchronized circuit comparisons, and hypothetical error-adjusted result plots for Vigo and Bogota simulators. In this example, strategy 2 improves the reported ESP by about 9% relative to the zero-optimization case and has a shorter duration than the other optimized cases, despite a slightly higher gate count. These observations illustrate how the interface exposes tradeoffs among metrics. They do not establish a generally superior optimizer, and the displayed simulator comparison is not a hardware experiment.

Contributions, limitations, and future work

The main contribution is a workflow-spanning design proposal supported by functioning notebook prototypes and realistic examples. It combines problem-oriented authoring, hardware exploration, linked logical and physical circuit views, application-specific result representations, and transferable job data under three usability principles. Its evidence establishes feasibility and illustrates possible uses, while gains in task completion, understanding, error reduction, or collaboration remain unmeasured by an independent user study. The authors explicitly call for evaluations of individual interfaces and techniques.

The prototypes' Qiskit focus limits demonstrated portability to other toolchains, and analog quantum computing is identified as future work. The authors also propose more robust programming-language semantics and types that reflect how users conceptualize quantum inputs and outputs, interoperable representations suited both to storage and interface interaction, and domain-specific environments for areas such as chemistry and physical simulation. They emphasize that graphical manipulation alone can become cumbersome for large problems, motivating combinations of visual interfaces and concise textual expressions. For evaluation, they suggest carefully scoped tutorials, longer-term observation of tool communities, and classroom deployment to accommodate users who lack extensive quantum-computing backgrounds.