Overview

LEAPS-Softwareは「考えさせないUI 」を軸に「迷わない導線」を提供することを目標に設計している。利用者は、データセットのアップロードから結果の確認までの一方向の流れをたどるだけで完結し、途中で手順に迷う場面を発生させない。一般的に、テキストボックスを用いたUI は自由度が高く柔軟である一方で、私たちが想定するユースケースでは手順の逸脱が品質低下に直結する。そこでLEAPS-Softwareでは、ステップフォームを用いたシンプルなUIを採用し、**「いま何をすれば良いか」**が一目でわかるようになっている。

このステップフォームは、**段階的開示（Progressive Disclosure）**の考え方に基づいて設計した。段階的開示とは、情報を段階的に表示して、ユーザーが必要な時に必要な情報を入力できるようにする手法である。入力すべき項目は、つねに 5W1H（Why / Where / What / When / Who / How）の観点で取捨選択した。

具体的には以下の考え方である。

• Why

その入力がなぜ必要なのかを明確にする。ヒックの法則に基づきに、コンポーネントの配置や画面遷移などを定量化し、判断の回数を最小にする。

• Where

その入力がどこに必要なのかを明確にする。ゲシュタルト近接の原則に基づき、コンポーネントを適切にグルーピングし、視覚的な手がかりを強化する。

• What

その入力が何を必要なのかを明確にする。KISS原則に基づいて必要とする項目のみ提示し、迷いと誤入力を抑制する。

• When

その入力が「いつ」必要なのかを明確にする。ドハーティのしきい値に基づいて、入力の要求は即応できる状態でのみ提示し、処理が重い場合はスケルトンを利用する。

• Who

その入力がだれが必要なのかを明確にする。最小権限の原則に基づいて各モジュール別に項目を分岐し、不要な操作を排除する。

• How

その入力がどのように必要なのかを明確にする。ニールセンの一貫性と標準に基づいてパターンと文言を統一し、学習コストを低減する。

このように、LEAPS-Softwareのフォームは**「考えさせないUI」**を設計の原則とし、迷わない導線を人間工学の知見で具体化している。

Site Design

LEAPS-Softwareの画面設計は**「迷わせない導線」を成立させる情報設計**に基づいている。アコーディオンを用いたUIでステップごとに情報を分離し、各ステップに必要な入力・フィードバックだけを提示する。これは、認知にかかる負荷の低減と進捗の直感的な理解を同時に達成する。

また、以下のような工夫もある。

• 状態の可視化

実行したタスクの状態には「保留 / 実行中 / 成功 / 失敗 / 中断」が存在する。これを直感的に表現するために、アイコンと色を用いて即時に伝達する。経過時間を提示して、長い処理がかかるタスクが、どれくらい進行しているかを一目で把握できる。

• 入力の支援

入力すべき項目には、複雑な条件が科されるものがある。例えば、データセットの入力には、CSVやTSVといった形式のバリデーションや列数と行数のバリデーションなどがある。これらを適切に支援するために、即時フィードバックを実装している。

• 入力の一貫性

入力すべき項目には、見た目（デザイン）・意味（セマンティクス）・振る舞い（インタラクション）の観点で揃える方針を採用している**。shadcnはTailwindのデザイントークンとRadix Primitives **を土台に、コンポーネントレベルで規格化できるため、一貫性を組織的に担保する。

Build

LEAPS-Softwareは当初、対話型のUIも検討した。これは、LLM (Large Language Model)を用いて、ユーザーと対話を重ねることで、LEAPS-Softwareをセットアップするものである。しかし、モデルへの自由な入力は手順の逸脱と再現性の低下を招きやすく、ユースケースとの相性が悪くなってしまう。そこで段階的開示に基づいたステップフォームを採用している。技術的には、Next.jsをベースに Server Componentsで初回のレンダリングを高速化し、Client Componentsでインタラクションを担当させている。

Ingenuity

私たちは「うまく動くか」ではなく、「迷わず意図どおりに使えるか」を基準に、実ユースケースで何度も検証を重ねた。まず、仮説をもとにプロトタイプを作成し、実際のシナリオを模したタスクを用意した。そして、ハイウェイテストとして身近な非エンジニアによる評価を実施した。これにより、実行までの時間を計測し、改善のループを短いサイクルで回した。

評価にはニールセンの10原則に基づいて行った。結果として、フォームのインラインのバリデーション、色とアイコンによる表現、コンポーネントの配置と画面遷移の最適化など、認知にかかる負荷を下げる変更を継続的に取り込んだ。

加えて、アクセシビリティなどの環境に起因する問題も想定し、ドハーティのしきい値を満たすフィードバックにスケルトンやトーストを採用した。一貫したデザインとインタラクションを手に入れることで、LEAPS-Softwareは短い期間で高い操作性を実現した。

以下は実際に取り入れた工夫である。

• エラーの表示

Before: 送信後にまとめてエラーをダイアログで通知していた。

After: 各フィールドでインラインのバリデーションを実施するようにした。

これにより、修正すべき箇所が文脈で分かり、往復が減る。

• グルーピングの最適化

Before: 1つのページに多数のテキストボックスが連続して配置されていた。

After: 意味のある単位ごとにフォームをダイアログに集約した。

これにより、ユーザーは一度に保持すべき情報を小さく保てるため、認知にかかる負荷が減る。

Input and Output Method

LEAPS-Softwareの入力と出力は、目的を達成するために必要な情報のみを扱う設計になっている。入力は、配列と各ラベルからなるデータセットと最適化の方向のみに絞った。まず、データセットは、LEAPS-Softwareが想定するユーザーにとって必要な項目である。また、最適化の方向は、LEAPS-Softwareが想定するユーザーにとって重要な項目である。

出力は、生成された配列と各予測値だけでなく、我々が独自に作成した毒性タンパク質データベースから検索した結果も表示している。アラートによる疲れを避けるため、1つのタンパク質に提示される毒性タンパク質は1件に絞り、該当しないときには沈黙する。人間の注意は強いシグナルに引き寄せられますが、頻発すると鈍ってしまうため、適度なアラートにすることで、判断の質を上げる狙いがある。

Build

実装では、入力と出力のどちらも「迷わず一度で決められる」ことを最優先にしている。データセットはテキストをそのまま受け付けるだけでなく、区切り文字を自動判定して即座に表形式でプレビューする。ヘッダーの意味（id・sequence・各ラベル）は読み込み時に検査し、不整合や欠損はテキストボックス直下に静かに示す。誤りをまとめて後出ししないことで、視線移動と往復回数を減らし、短い思考で修正できるようにしている。最適化の方向は、単位と範囲のヒントを併記したフィールドで最小限に指定でき、詳細な調整は折りたたみの「高度な設定」を開いたときだけ現れる。既定値を強くすることで、多くの利用者はそのまま進められるようにしている。

出力は、まず生成配列と各予測値を遅延なく一覧として提示し、根拠やログは行の展開後に表示する。処理中はスケルトンで体感を切らさず、完了・失敗のみトーストで知らせる。毒性チェックは独自データベースと照合し、該当がある場合のみ UniProt ID を一件だけ明示する（該当なしのときは沈黙します）。アラートを節約することで注意の質を保ち、次の判断（保存・再実行・設定の見直し）に迷わず進める導線にしている。再現性のために、実行時の設定スナップショットとデータセットのハッシュを結果に添えており、同じ前提で同じ結論に戻れるようにしている。