モックアップ内のボタンは通常、デフォルトの 1 つの状態を示します。実際の製品では、同じボタンがホバーされ、キーボードでフォーカスされ、押され、フォームが不完全な間は無効になり、リクエストの送信中にロードされます。これらはそれぞれ UI 状態であり、それぞれにデザインが必要です。
2 つのグループを分けるのに役立ちます。インタラクション状態は、ホバー、フォーカス、押下、無効などのユーザーから取得されます。データの状態はシステムから取得されます (読み込み中、空、部分データ、エラー、成功)。たとえば、リスト画面には、読み込み中、アイテムがないとき、アイテムが 1 つあるとき、アイテムが数百あるとき、およびリクエストが失敗したときのデザインが必要です。
フォーカス状態には特別な注意が必要です。キーボードやスイッチ デバイスを使用する人は、自分の位置を知るために目に見えるフォーカス インジケーターを頼りにしています。ブラウザーのフォーカス アウトラインを置き換えずに削除することは、最も一般的なアクセシビリティの問題の 1 つです。
状態間の変化も設計の一部です。デフォルトから押下状態への短く明確な遷移により、タップが確認されます。読み込み状態がスムーズに成功に変わると、人々は自分のアクションがうまくいったことを伝えます。突然のジャンプやアニメーションが遅すぎると、インターフェイスの信頼性が低く感じられます。
状態の欠落を回避する実際的な方法は、設計前にコンポーネントごとに状態のリストを作成するか、コンポーネントをステート マシン (状態のセットと状態間を移動するイベント) としてモデル化することです。私たちが作ったExodeUIはこのように動作します。各状態とそれらの間の遷移を 1 つのファイルで設計し、コードによって実際のアプリで状態を切り替えるイベントを送信します。