最初の状態、状態の変化
さて、多くのモバイル端末やデスクトップ端末上のアプリケーション、ウェブサービスなどでは、まず起動、アクセスされたシステムが何らかの情報をユーザーに提示している状態から始まる（常に起動されていてユーザーの無意識の動作を記録したりするようなタイプのシステムはここではおいておく）。
「状態」と書いたが、インタラクションはひとつひとつの（ある程度まとまった） やりとりによって、システムの（ユーザーに対して、どういう入力を受け付けるかなどの）状態が移り変わっていく。場合によっては何もしなくとも時間の経過によって、状態が変わる。
このため、ユーザーが「システムは今、どういう状態であるのか」を容易に、かつ間違いなく認識できるようになっていることが重要になる。また、前回説明したレイアウトの反復の原則と同様、状態が変わっても情報提示に関して統一的なルールが保たれていることも大事である。
状態がわからない、判別に時間がかかるというのは、ユーザーにとっては道に迷っているのと同じなので、安心やスムーズさを損ない、UXを著しく悪化させる。
そして、状態を勘違いしやすい場合は、ミスが生じる可能性も上がる。ウェブのフォームを埋めて書類などを提出したつもりが、実はその後にもう一段「確認」の画面があって提出されていなかった、というような経験はないだろうか。
入力に対するフィードバック
ユーザーの入力に対するシステムの、ユーザーに判る反応を「フィードバック」と呼ぶ。ユーザーにとっては、まず「入力が受け付けられたか」がわかることが第一であり、そして「意図通りに入力されたか」が続く。アプリケーションやウェブサービスなどの設計において、これらのフィードバックが適切にデザインされていないと、ユーザーは安心して入力ができない。
文字入力やボタンを押すという操作自体、画面のスクロールなどの入力と、それに対するフィードバックなど基本的な入出力に関しては通常、OSやブラウザなどが扱うので、その上で動くアプリケーションやサービスを作る側は気にしなくてもよい。
むしろ、それらに関しては他のアプリケーションまで含めたプラットフォーム全体のUXに関わるので、個々のアプリケーションの都合でむやみに変えるわけにはいかない。
それよりも大きな粒度の、ボタンが押された結果何が起こっている・起こったかなどは、アプリケーションやサービス側でしっかりとフィードバックしなければならない。
特に、操作の結果が得られるまでに時間が掛かるような場合は、「処理が進行している」ことを伝えるフィードバックを用意しておくとよい。場合によっては適切なフィードバックによって、ユーザーが「感じる」遅さを軽減することもできる。
すぐに結果が出て表示が変化するような場合も、変化したことを強調するとよい場合も多い。
空白だったところに何かが表示されるというような変化は、比較的わかりやすいのだが、文字AがBに一瞬で変わったなどの変化は、特にユーザーの視線から外れたところでの場合は意外とわかりづらい。もちろん、変化する部分が多かったりすると強調は埋もれてしまったり、うっとうしくなってしまったりするので、加減が必要である。
