状況
以下のようなものを見た。
- スーパーに設置されている装置
- 鍵がささったまま
- 装置の傍に人はいない
- 装置は一般客が通る通路に置かれている
- スーパーに来る人には一定の割合で「親切な」人がいる
「鍵がささってますよ。大丈夫ですか？」という質問が離れたところにいる店員に行く(N回)。
明示的でない事柄
店員に声をかけたところ、以下のことだと分かった。
- 装置の特定処理中には鍵を「ぬけない」仕組みになっている
- 処理中に限り、鍵を盗難される心配はない
失敗と思う点
- 鍵が見える状況にある
- 鍵の仕組み(特定動作中に着脱できない)が明示的ではない
- 人が傍らにいない
失敗のUIの結果
- 装置利用者: 親切な人の声かけが発生する (N回)
- 装置販売者(営業): 仕組みの説明が必要 (M回)
- 装置販売者(設計): 営業への周知が必要 (L回)
一つのUIの失敗により、上記のように関係者の時間を奪い続ける。
改善案
装置そのものに対する改善点はないだろうか。
- 状況の明示化
- 例: 「XXX動作中は鍵は抜けません」というステッカー
- 隠す
- 例: 鍵が見えないように隠すデザインにする
備考
失敗のUIでは口頭での詳細説明を必要とする。それは関係者の時間を奪い続けるという認識を持つのがいいと思う。
口頭での詳細説明を必要とするUIにはどこかに問題がある、とも思われる。
引用
@ プログラマが知るべき97のこと by Kevlin Henney
コードは生涯サポートするつもりで書く by Yuriy Zubarev
「どういう理由でこういうコードを書いたのか説明してくれ」と言われても文句は言えないとしたら。そう考えれば、自然に、そんな問い合わせを受けないですむようにしたい、と思うでしょう。そのために、技術力を少しずつでも高めようとし、変数名やメソッド名の付け方にも注意するようになります。
他の本にも「同僚にコードのことで尋ねられたら、口頭で説明をするのではなく、同僚が分かるコードにしてチェックインして、”チェックインしたよ”というようにした方が良い」ということが記載されていた。
同意する。