利用者が「ん？」と思って問い合わせてくるというのは、システム屋をやっていたらちょいちょいある。
そういう時、現象の確認だけして、
「あー、それ、仕様ですねぇ」
って返してイッパシの技術者、POを気取る人がいる。
「いや、だって、利用者にはシステムの仕様が理解できない人が多いですからねー」
おいおいおいおい。
理解できないのはイッパシの技術者、PO気取りでドヤ顔のオノレの頭や。
システムは、利用者が、利用する。
ここ、大事。
そのシステムはどういう人が利用するのか？
当たり前だろうって？
それを当たり前だと言いながら、「利用者にはシステムの仕様が理解できない人が多い」という認識を持っているのなら、「仕様を理解しないと使えないシステム」「おや？と思った時に仕様と睨めっこしなければならないシステム」を構築するのは、そもそも矛盾している、間違えているとは考えられないのだろうか？
利用者が「ん？」と思って問い合わせてきた内容は「バグか仕様通りか」が大事なのではなく、「なぜ『ん？』と思ったか、その運用するときの思考の流れにささくれができる」という事実が大事なのだ。
と、駆け出しの頃、先方の偉い人に教わった。
そこにそのプログラム(サービス)の改善ポイントが転がっているんだ。
と。
これもUXの要素の一つ。
利用者の認知負荷を下げるのは、道具として使ってもらうなら当然のことなのだ。
これを教わった案件とその後の案件は、極力マニュアルなしでも使えるように設計している。
ボタンを押しまくれば何でもできる万能十徳ナイフみたいなツールではなく、その仕事に必要な最小限の、でも必須な機能が一目でわかるように削ぎ落としたアプリにしている。
ちょうど、初代iPodのデザインのように。
「それは仕様です」と口走る前に、確認しなきゃならないことがある。
ということ。