問題に対して共通言語を持つ

問題に対して共通言語を持つ

ドッグフーディングやユーザビリティテストを行うと、これでもかってくらい問題が見つかる(ですよね?)。分かっていたものもあれば、想定の斜め上をいくものも。よし、この問題はまずいから真っ先にやるぞ!ときっと誰かが言う。でも立場によって問題に対する認識度というか重要度って結構異なるわけで、デザイナーからしたらありえない!と思っていても、エンジニアにしてみりゃどっちでもええやん。。もあるし、プロマネが必死でこれやらないと死ぬ!なんていっても、デザイナーには全然響かないケースもある。

こういう場合問題なのは、共通認識というか共通言語がないからだと思うんだよね。つまりは尺度がバラバラな状態。そりゃまとまるはずねーわなって話なわけで、問題の重要度ってのもちゃんと客観的に決められるべき。リソースが潤沢にあるならもちろん全部やればいいんだけど、その場合においても優先順位は大事なはず。見つかった問題たちを机の上に並べたあと、どれから片付けていけばいいか迷わなくなるために役立つかもしれない話。

そもそも問題ってなんだ

ユーザビリティ上の問題というのは「タスクのゴールを妨げるもの」である。例えばこういうの。

気付くべきものに気付かない
判断に迷う
間違っているのに正しいと思い込む
エラーを引き起こす

 
例えばボタンの配置とキャプションが微妙っていう問題があると、これらすべてに当てはまる可能性がある。予想される場所に配置されてないからまず気付かない。画面上をくまなく探して気付いたものの、キャプションが微妙なため押すべきかどうか悩む。悩んだ結果、あっちのボタンが正しかったんだ!と思い込み押してみたら、それは今できないからまず○○をしろ!と怒られる。

これらの問題は、少し迷わせる・不安にさせるだけならまだしも、タスクのゴールに辿り着けない状態を引き起こしてしまう可能性すらある。インパクトのレベルはこんな感じ。

0 ちょっと悩むしイライラするけどタスクの完了には影響がない
1 タスクを失敗させる可能性があるが、別の手段によって完了できる
2 これが起きたらもうタスクは完了できない


重要な観点としては「その問題がタスクにどういう影響を及ぼすか」を気にすること。ちょっとしたUI上の不備だからこれは軽度だよねーとはせず、起こり得るインパクトまでちゃんと考えましょうねの話。

起こり得る頻度

年に1回使うか使わないかの機能ならぶっちゃけどうでもいい。いや、どうでもいいってのは言いすぎだけど、これを改善するくらいなら他にもっとやるべきことがある。複数のペルソナによって毎日何回も使われるような機能のほうが当然優先度は上がるはずで、ただし、ここでいう頻度というのはその機能が使われる頻度ではなく、問題が起こり得る頻度。利用頻度に比例するので目安にはしてもいいが、本来測定すべきなのはその問題が機能単位やアプリ全体としてどれくらい起こっているか。こっちのほうがよっぽど大事。

例えば、ブラウザのスクロール位置が微妙なところで止まっちゃう問題があったとして、それ自体は全然軽度(に見える)だけど、それが毎日何十回、どのタスクを行なった時でも起こっちゃうようなら話は別。

サービスの特性

インパクトを考える際に最後に気にしておくべきは、サービス全体でみたときに重要かどうか。そのサービスで求められる目標やゴールによって、問題のインパクトは結構変わる。例えば、銀行のATMでお金を引き出す機能、飲食店で予約情報を登録する機能、エンドユーザーが自身の予定をスケジューラーに登録する機能、の3つに対し、「ゴールにたどりつくまでのステップ数が多い問題」を当てはめたとする。結果はどうだろう。スケジューラーにとっては深刻なユーザー離れを引き起こす可能性があるが、銀行のATMでは大した問題にならない。それよりもウィザードに従っていれば確実にゴールへ辿り着けるという安心感や確実性のほうがよっぽど大事になるはず。

まとめると、問題の優先順位というのはこの3つで相対的に決まる。

インパクト × 頻度 × 特性

言い換えると、これが共通認識・共通言語。デザイナーもエンジニアもプロマネも、みんなこの軸で話をすればたぶんケンカにならないんじゃないかな笑。チームのベクトルを合わせる際に是非基準にしてもらいたい。