組織の評価軸が不要な機能を生む話
こんにちは。IT企業でデザイナーをしているharahiro (@harahiro_d) です。
会社はデザイナーが全体の0.5割しかいないエンジニア主体の企業で、BtoB, BtoC, BtoG向けサービスを展開している事業会社です。
自分が数年UIデザイナーとして企業に勤め、感じた組織の評価軸とアウトプットの関係について、自分の頭の整理を含めまとめたいと思います。
”Just In Case” 問題
以前からユーザー中心設計、UI, UXなどのキーワードをよく聞きますが、ユーザーのレビューや評価などの声を気にするあまり、不要な機能を取り入れてしまうことがよくあると感じています。
特にあるのはUI, UXデザインの阻害要員として、”Just In Case”の機能を多く盛り込んでしまうことです。
”Just In Case”とは、その名の通り「何かあった時用」という意味で「もしかしたらこういうこともあるかもしれないから、念のために...。」といった補助的なシーンのことを示します。
”Just In Case”の機能は、一見便利に見えますが主導線の補助となる機能なので、増やしすぎるとユーザーフローの妨げとなり、アプリやWebのUI, UXの品質低下につながる恐れがあります。
※ ”Just In Case”の機能による問題は下記のインタビューでも言及されています。
”Just In Case”の機能が一度リリースされてしまうと、大規模なサービスの場合「使ってる人がいるから…。」と後から消すことが難しくなります。
また、新機能はお客様に使って欲しいから目立たせたいという思いが先行しやすいため、主導線と同等レベルの位置や強調具合で配置したいという勢力が現れます。
それを許容した結果、一時的な利用者が増えてさらに消せない状況となります。
問題は組織の評価軸
これを止められない要因の一つとして、組織のKGI, KPIなどの目標が売上や施行回数などの数値としてのみ存在していることが考えられます。
そういった組織環境の中では、直近の成果を定期的な報告会、面談で求められるため、よほどPM（プロジェクトマネージャー）に理解がないと「本当にこれいるのかな？」という機能がとりあえず様子見でリリースされ、消せない負のスパイラルに入ります。
特にこのパターンは、最終的なKGIが売り上げの場合に多いと感じます。
「やらないよりやった方がいいよね。」で動き始めてしまい、そもそも熱量のない案件のため、結果のウォッチもなされないので何となく残り続けてしまう。報告するために何かをやる必要がある。
そこに目的はなく、本来必要とされるはずの「サービスの質を向上させる」という思想が抜けがちになります。
たまにですが、既にある程度の仕様が決まり開発がスタートしている案件を共有され、もう仕様の変更や機能自体の必要性について見直しができないことがあります。
後から仕様変更することは多くのコストがかかること、これまでかけた工数への「もったいない。」精神と「やらないよりやった方がいい。」の典型的なパターンです。
私は、やったことを評価することはとても大切だと思いますが、それと同じぐらいやらなかったことを評価する必要があると思います。
問題はそれが評価しづらいということですが。。
改善はワークフローから
根本的に環境の改善を図るなら組織の意識を変えることが必要だと思いますが、いくつか実践して改善されたと思うワークフローにおける対処法を記載します。
① 案件が発生する場合は出来るだけ上流で関われるように立ち回る
受動的ではなく能動的に案件を拾いに行くことで、早い段階での対処が可能です。コストがかかる前に軌道修正できる可能性があります。
② リリースする際は事前にその機能を評価する指標を定めて、定期的に機能見直しを図るよう約束事を決めておく
事前に判断軸を決めておくことで、リリース後の判断基準を明確にすることができます。また、改善の話題を持ちかけやすくなります。
③ 改善点が見つかった場合には、チーム全体に共有する前にPMのような影響力のある人に直接話しを通す
同じ言葉でもそれが誰の口から伝えられるのか、誰が賛同しているのかで意見の重さ、価値は変わってきます。例え狭義のデザインに対する意見であっても、チームに信頼されているデザイナーよりも機能の開発担当者を直接評価する人の言葉には敵わないことも多いと感じます。
意識の改善は一苦労
デザインが理解される環境に身を置くためには、以下が考えられると思います。
a. 所属組織の意識を改善する
b. 既に環境が整っている組織に異動する
aの場合は、チームや個人の意識を改善するために先ずは上長またはPMのような影響力をもつ人の意識を変えるよう働きかけることがことが重要だと考えています。
先述したように、同じ言葉でもそれが誰の口から伝えられるのか、誰が賛同しているのかで意見の重さ、価値は変わるためです。
ただ最初からある程度の理解がある相手でないと説得は容易ではないため、多くの場合、bの方がコストをかけずに求める環境に身を置くことができると考えています。
デザインの効果を明確に説明できれば、より説得力が増し環境改善につながるとは思いますが、デザインを数値化すること、説明の材料を用意すること自体にコストがかかりますし、そもそもデザインは長期的に観測しないと効果を実感しにくいものが多いので、短期的に説明しようとするとCTR, CVR, 離脱率など、グロース的な要素に偏りがちです。
現状の環境に満足できないデザイナーがそこをクリアできずに転職に流れることがとても多いと感じています。
私の周りの先輩、友人でもそういったケースで転職された方を何人か見ています。
まとめ
組織のKGI, KPIなどの目標が売上や施行回数などの数値としてのみ存在していることが、”Just In Case”の機能を生む要因の一つになる。
”Just In Case”の機能を防ぐためには、影響力をもつ人にデザインに対する理解を深めてもらう必要がある。
ただ、デザイン自体が明確に効果を説明することに向いていないので、かなりの根気やある程度の実力がないと難しい。
意識や環境の改善が難しい場合は、もともとデザインに対する理解がある環境に身を置くことが求める環境への近道。
最後までお読みいただきありがとうございました！本まとめが何かしらのお役に立てましたら幸いです。
デザインや普段気になったことについてつぶやいていますので、よろしければご覧ください！
最後までお読みいただきありがとうございます！ もし気に入っていただけましたら、スキやSNSでのシェアもよろしくお願いします！