Muhit：インターフェースの一貫性は何から生まれるのか

色とコンポーネントから始まり、振る舞い、文脈、信頼へと広がるデザインシステムについて。

作業用の表を思い浮かべてみる。レコードを絞り込み、いくつかの行を選び、詳細を確かめるために別の画面へ移る。戻ってきたときには、検索条件や選択、作業していた位置が保たれていることを期待する。

この期待を、私たちはあまりデザインの一部とは呼ばない。けれども、インターフェースとの関係の多くはここで形づくられる。操作に対して何が起こるのか。システムは何を覚えているのか。処理が完了しなかったとき、それをどう知るのか。

Muhitに取り組むなかで、私が考えたのはこの問いだった。インターフェースを構成する異なる部分は、利用者にどうすれば共通した振る舞いを提供できるのだろうか。

一貫性はどこから始まるのか

デザインシステムの目に見える部分は説明しやすい。書体、色、余白、ボタン、カード、表が組み合わさり、ページのあいだに見慣れたリズムが生まれる。

しかし、同じように見える二つのボタンが、異なる期待を生むこともある。一方は操作をすぐに完了し、もう一方は確認ダイアログを開く。あるフォームは該当する入力欄のそばにエラーを示し、別のフォームは短い通知だけを出す。ある表は絞り込み条件を保ち、別の表は更新のたびに最初の状態へ戻る。

そのような画面では、見た目を知っていても、利用者は振る舞いを学び直さなければならない。

Muhitの出発点には、Nevmosのインターフェース制作で生まれた部品を、独立したライブラリにするという考えがあった。切り分けるためには、どの判断が特定の製品に属し、どの判断なら別の制作にも持ち運べるのかを問う必要があった。

製品のロゴやコンテンツは、その製品の文脈に属する。一方、見えるキーボードフォーカス、理解できる状態ラベル、エラー後に再試行できること、操作結果を知らせることには、より広い用途がある。

Muhitは、こうした共通の判断をまとめて保とうとしている。その名前が連想させる環境や近隣という意味も、ここで大切になると思う。それぞれの部品には役割があり、それらが一緒につくる場は理解しやすいものである必要がある。

共通の言葉、異なる条件

その環境が、どのプロジェクトでも同じ姿をしている必要はない。

研究のための道具なら、長い文章や参考資料のために場所を用意できる。頻繁に使う管理画面なら、より密度の高い配置が必要かもしれない。別の制作では、落ち着いた面とゆったりした余白を選べる。

Muhitのテーマは、こうした違いから考えている。色、タイポグラフィ、密度、境界、動きの設定をまとめて変えられる。その変化の下には、文字、背景、強調、状態、フォーカスといった、定義された役割がある。

だからテーマを変えたときには、さらに問う必要がある。文字はまだ読めるか。選択された状態が伝わるか。キーボードで移動する人は、自分の位置を確認できるか。コンパクトな表示でも、タッチ操作に必要な範囲は確保されているか。

同じような確認は、ページの異なる状態にも現れる。

コンテンツで満たされた画面は、デザインの一つの瞬間を示している。その画面には、データを待つとき、まだレコードがないとき、リクエストが失敗したとき、アクセス権が必要なときにも、それぞれ考えられた状態が必要になる。

「まだレコードがない」と「レコードを読み込めなかった」は、異なる状況だ。利用者の次の行動も変わりうる。前者なら新しいレコードをつくることに意味があり、後者なら再試行が必要かもしれない。

Muhitのページ構成例でこれらの状態も扱うことで、通常の流れから外れたときの振る舞いまでデザインに含めている。

コンポーネントをアプリケーションにつなぐときにも、同じ注意が続く。参照用の統合例では、言語変更時にフォームの下書きを保つことや、表を再構築するときにフィルターと選択状態を引き継ぐことが重要になる。利用者が直前にしたことが、次の一歩の文脈をつくる。

インターフェースが約束を守ること

この考え方は、エージェントがインターフェースを提案するときにも意味を持つ。

モデルは、表示する情報や提供する操作を、構造化された定義として提案できる。その定義をどのコンポーネントに変換できるか、どの範囲にとどめるべきかは、あらかじめ定められる。

Muhitのエージェントアダプターが働くのはこの部分だ。定義を検証し、許可されたコンポーネントで表示を組み立てる。利用者が操作を選ぶと、その選択をアプリケーションに伝える。データの保存、リクエストの送信、必要な権限の確認は、アプリケーションが担う。

この区別は、利用者にも明確でなければならない。画面に「保存」ボタンがあることは、保存が成功したことを意味しない。インターフェースのフィードバックは、その背後にある処理の実際の状態に基づく必要がある。

Muhitのデザインで、私が大切にしている考えはここに集まる。インターフェースが約束することと、システムが実際に行うことは、対応していなければならない。

これは、これからも確かめ続ける必要がある領域だ。Muhit 0.15.0には、コンポーネント、ページの状態、テーマの選択肢、統合例に対する自動チェックがある。実機での利用やスクリーンリーダーによる評価も、引き続き取り組む課題に含まれている。

デザインシステムは、発展するにつれて新しいコンポーネントを得る。それとともに、利用者にどれほど新しい学習を求めているかにも目を向けたい。

一度覚えた振る舞いが別のページでも意味を保ち、自分の選択が次の段階に引き継がれ、予想外の状況でもシステムが理解できる道を示すなら、共通の言葉が生まれ始める。

私はMuhitを、その言葉のなかで異なる制作がそれぞれの個性を保ちながら居場所を持てる環境として育てている。

---

異なる形、共通のリズム。表紙のイラストは、この記事のためにAIで生成しました。

資料: Muhitのソースコード · Muhit 0.15.0のドキュメント

関連する文章：制約された視覚言語は何を可能にするのか

Atlasの概念: 設計 · ソフトウェア · 文脈 · システム