Contributors
LEAPS-Software is designed around the principle of a “don’t make me think” UI, aiming to provide “intuitive navigation” without confusion. Users can complete their workflow through a unidirectional flow from dataset upload to result verification, eliminating any points where they might become uncertain about the procedure. While text box-based UIs generally offer high flexibility and freedom, in our anticipated use cases, procedural deviations directly lead to quality degradation. Therefore, LEAPS-Software adopts a simple UI using a step-form approach, making it immediately clear “what needs to be done now”.
This step-form is designed based on the concept of Progressive Disclosure, a technique that displays information incrementally, allowing users to input necessary information when needed. The items requiring input are consistently selected from the perspective of the 5W1H framework (Why / Where / What / When / Who / How).
Specifically, the design follows these principles:
We clarify why each input is necessary. Based on Hick’s Law, we quantify component placement and screen transitions to minimize the number of decisions required.
We clarify where each input is needed. Based on the Gestalt principle of proximity, we appropriately group components to enhance visual cues.
We clarify what each input requires. Following the KISS principle, we present only necessary items to suppress confusion and input errors.
We clarify when each input is needed. Based on Doherty’s threshold, input requests are presented only when the system can respond immediately, and skeletons are used when processing is heavy.
We clarify who needs each input. Based on the principle of least privilege, we branch items by module to eliminate unnecessary operations.
We clarify how each input is needed. Based on Nielsen’s consistency and standards, we unify patterns and terminology to reduce learning costs.
Thus, the LEAPS-Software form adopts the “don’t make me think” UI as a design principle, concretizing intuitive navigation through human factors engineering insights.
The screen design of LEAPS-Software is based on information architecture that establishes “navigation without confusion”. Using an accordion-based UI, information is separated by steps, presenting only the necessary input and feedback for each step. This simultaneously achieves reduced cognitive load and intuitive understanding of progress.
Additional design considerations include:
Executed tasks have states: “pending / running / succeeded / failed / canceled”. To express these intuitively, we use icons and colors for immediate communication. Elapsed time is displayed so users can understand at a glance how far a lengthy task has progressed.
Some input fields have complex requirements. For example, dataset input requires validation of formats such as CSV or TSV, as well as validation of column and row numbers. To properly support these requirements, we implement immediate feedback.
For input fields, we adopt a policy of alignment in terms of appearance (design), meaning (semantics), and behavior (interaction). shadcn, built on Tailwind design tokens and Radix Primitives, enables standardization at the component level, systematically ensuring consistency.
LEAPS-Software initially considered an interactive UI that would use an LLM (Large Language Model) to set up LEAPS-Software through repeated dialogue with users. However, free-form input to the model tends to cause procedural deviations and reduced reproducibility, making it incompatible with our use cases. Therefore, we adopted a step-form based on progressive disclosure. Technically, we use Next.js as the foundation, accelerating initial rendering with Server Components while handling interactions with Client Components.
Rather than simply asking “does it work well?”, we used the criterion “can it be used as intended without confusion?” and conducted repeated validation in real use cases. First, we created prototypes based on hypotheses and prepared tasks simulating actual scenarios. We then conducted highway testing with nearby non-engineers for evaluation. This allowed us to measure time to execution and iterate improvements in short cycles.
Evaluation was conducted based on Nielsen’s 10 heuristics. As a result, we continuously incorporated changes that reduce cognitive load, including inline validation in forms, expression through colors and icons, and optimization of component placement and screen transitions.
Additionally, anticipating environment-related issues such as accessibility, we adopted skeletons and toasts for feedback that meets Doherty’s threshold. By obtaining consistent design and interaction, LEAPS-Software achieved high operability in a short period.
Below are the specific improvements we implemented:
Before: Errors were collectively notified in a dialog after submission.
After: Inline validation is performed for each field.
This allows users to understand which areas need correction in context, reducing back-and-forth.
Before: Numerous text boxes were consecutively arranged on a single page.
After: Forms were consolidated into dialogs by meaningful units.
This reduces cognitive load by allowing users to maintain smaller amounts of information at once.
The input and output of LEAPS-Software are designed to handle only the information necessary to achieve objectives. Input is limited to datasets consisting of sequences and their labels, and the optimization direction. First, the dataset represents items necessary for users anticipated by LEAPS-Software. Additionally, the optimization direction represents items important to users anticipated by LEAPS-Software.
Output displays not only generated sequences and their predicted values but also search results from our proprietary toxic protein database. To avoid alert fatigue, only one toxic protein is presented per protein, and the system remains silent when no matches are found. Human attention is drawn to strong signals, but becomes dulled with frequent occurrence; therefore, we aim to improve judgment quality through moderate alerting.
In implementation, we prioritize “deciding without confusion in one attempt” for both input and output. Datasets accept not only raw text but also automatically detect delimiters and immediately preview data in tabular format. The meaning of headers (id, sequence, and each label) is validated upon loading, and inconsistencies or missing data are quietly indicated directly below the text box. By not presenting errors collectively afterward, we reduce eye movement and the number of round trips, enabling corrections with minimal thought. The optimization direction can be minimally specified in fields that include hints about units and ranges, with detailed adjustments appearing only when the “advanced settings” accordion is expanded. Strong default values allow most users to proceed without modification.
Output first presents generated sequences and their predicted values as a list without delay, with supporting evidence and logs displayed after row expansion. During processing, skeletons maintain engagement, and only completion or failure is notified via toast. Toxicity checks are cross-referenced with our proprietary database, displaying only one UniProt ID when matches exist (remaining silent when no matches are found). By conserving alerts, we maintain attention quality and enable navigation without confusion to the next decision (save, re-run, or review settings). For reproducibility, we attach a snapshot of execution settings and dataset hash to results, allowing users to return to the same conclusions from the same premises.
© 2025 - Content on this site is licensed under a Creative Commons Attribution 4.0 International license
The repository used to create this website is available at gitlab.igem.org/2025/tsukuba.
