（b）行ごとに保存ボタン

行ごとに保存ボタンを置くことの利点は，（a）のように自動的に保存されるわけでもなく（c）のようにすべて保存するわけではない，必要に応じてこまめに保存できるという点があります。行ごとの保存であるため，一連の作業が行ごとに行われることが想定できる場合に効果的です。

図4の赤い枠が行ごと，緑の枠は列ごとの囲みです。今回の例で想定できることとして，特定のスタッフの情報を更新するようなケースであれば，行ごとに保存するボタンがあることが有効です。しかし，全スタッフの報酬をバランスをとりながら変更するといったケースでは，行ごとではなく列ごとでの保存ができることが有効です。しかし，どちらにも保存ボタンを付けると画面が煩雑になってしまいます。それであれば，後述する（c）のようにすべて保存するようにしたほうがシンプルになります。

また，いろいろな部分を変更していると，どこを保存していて，どこを保存していないかわからなくなってしまう可能性もあります。ユーザーの行動を想像して，タイミング良く保存できるように意識してください。TwitterのPC画面では，ツイートを途中まで書いた状態で別の画面へ移動しようとすると，図5のようなダイアログが表示されます。ユーザーが情報を書き換えて保存せずに別の画面へ移動する場合，変更が破棄されることを伝えると丁寧になるでしょう。

（c）すべて保存ボタン

すべて保存するボタンを置くことの利点は，画面に配置されている項目全体を配慮しながら保存できる点にあります。（b）のように行単位で毎回保存していくわけではなく，保存ボタンを押すのは一度でよいため，シンプルで作業が楽というメリ ットもあります。また，全体をすべて保存できることで保存したという実感も得られやすいです。

しかし，すべて保存するボタンを置く場合でも，ページをまたいでの保存には注意が必要です。一覧編集画面のようなケ ースでは，図6のように複数の画面に項目がまたがりページャが付く場合もあります。ほかのページも含めてユーザーに保存 させる場合，何が変更されたかわからなくなるリスクが伴います。1つのページで保存が完結するように設計しましょう。

また，先の状態が想像できないような変更を行う場合は，（a）のような自動保存ではなく（b）（c）のように保存ボタンをちゃんと設けましょう。図7はGmailのテーマ変更ダイアログです。デザイン変更などは，「⁠実際にどういったデザインになるかのプレビューを確認してから保存したい」と思うケースがほとんどです。すぐに変更が確定される自動保存ではなく，確認できる状態を作ったうえで，キャンセルまたは変更を保存できるよう注意しましょう。

このように，1つの画面でもさまざまな保存のUIが考えられます。どれが正解というわけではありませんが，今回のスタッフ管理アプリケーションのケースであれば，以下のように筆者は考えます。

• じっくり考えながら行う操作や突然変更されると良くないケースが含まれていることから，（a）の自動保存は不向き
• 行ごとだけでなく列ごとに思考する可能性があるため，（b）の場合ユーザーの思考とずれるのと，保存回数が多くなる可能性があるため不向き
• 全体を見渡しながら，ユーザーが思ったときにまとめて保存ができる。保存前に何度も値を調整できることからが（c）向いている

今回は「保存」をテーマに最適なUI はどれか検証してみましたが，複数のデザインが考えられるケースは多くあります。そのため，最適なUIを生み出せるよう，ユーザーの行動を想像して考えるプロセスが大切です。