UIの色を変えただけで大量のクレームを頂戴してしまった話
Webプロダクト開発をしていると様々な諸事情によりUI構成を変えたり機能を増やしたり減らしたりすることが多々あると思います。そんな時に避けられない事態として「UI変更に対するお怒りがユーザーからわんさか届いてしまう」ということがあります。今回はUI上の１要素の色を変えただけで虎の尾を盛大に踏んでしまった事件の話をしようと思います。差し当たりどういうUIをどう変えたのかを明示しておきます。変える前がこちら↓↓
ほんで変わった後がこちら↓↓
ご覧の通り「作業カード」と呼ばれるコンポーネントの色を「緑＆黄」から「緑塗り＆緑枠線」に変更しました。「え、それだけ？」という声が聞こえてきそうですがそうなんです。それだけなのです。しかしここはレガシードメインのtoB SaaS。toB SaaSではUIの変更がユーザー業務への影響に直結するので軽微な変更を加えるのもハードルが高い、ということについてはこれを読んでるみなさんも想像に難くないと思います。Vertical SaaSは特にその傾向が顕著です。我々、運営も一定のクレームをいただくことはある程度想定していました。が、見込みが甘すぎた。ということでこの記事ではバーティカルドメインでUIの変更をするとユーザーがどういう反応をするのか、その現実を生々しく書いていこうと思います。
なぜUIを変える必要があったのか
そもそもなぜ色を変える必要があったのかについて軽く説明しておきます。どうでもいい方にとってはどうでもいいセクションになるかと思うのでどうでもいい方は読み飛ばしてください。
まず記事冒頭のUIはMOVO Berthという物流センター向けのトラック予約管理システムのとある画面になります。この画面ではその日の作業予定を一覧で見ることができるのですが、グーグルカレンダー同様に確定している予定と確定していない予定を識別する必要があります。それがこれですね。
確定している作業が緑、確定していない作業が黄色で表示されています。こちらの見方としては「１時から２時にABC物流の作業をすることが確定している」ということになります。「確定と未確定を識別することが目的なら緑と黄色のままでもいんじゃね？見た目綺麗にしたかっただけちゃうんけ。」と思ったそこのあなた。決してデザイナーである私が己のエゴを貫くべくプロダクトを芸術の対象とみなしたUI作品にしたかったわけではないので余計な勘繰りをするのはやめていただきたい😡黄色と緑からfillとoutlineに変えた明確な理由があるのです。
物流センターでは日夜多くの荷物を積んだトラックが出入りしているのですが、そのトラックが持ってきた荷物を効率よく捌くために物流センターの担当者は予定の確定、未確定以外の情報を多く必要としているわけです。例えば出荷なのか入荷なのかや、どんな荷物を持ってきたのか、どこから持ってきたのか等々ですね。この情報がパッとわかることで次にどのトラックを呼ぶべきか、どういう準備をすればいいのかがサッとわかるようになるわけですね。そこでバース表をザッと見るだけでどの作業カードがどういう情報を持っているかをガッと判断できるようにするべく作業カードに色をつけたいという要望がユーザーから多く寄せられていたため、作業カードのデフォルトの色を変える必要があったのです。
当然ながら作業カードの色そのものを変更する以外の解決策はたくさんあると思います。実は私がジョインする前のデザイナーも一度この要件について揉んでいたようでその痕跡が残っていました。
他にも「ドッグイヤーをつける」「縦幅を増やして文字情報を増やす」「右上のバッジを増やす」などなどいろいろなアイディアがありましたが「足し算で解決するのは無理が出るだろうな」という予感がしていたので引き算で解決することにしました。ということで確定と未確定を塗りと枠線で識別するUIに変更。みなさんお馴染みのｸﾞｰｶﾚと同じ在り方ですね。
これでカードの色そのものを変更できるようにしてしまえば「出荷なら緑、入荷なら青」といった具合に確定・未確定の識別を可能にしたままユーザー任意の情報で他の識別要素を付与できるようになりました。ﾒﾃﾞﾀｼﾒﾃﾞﾀｼ!!
押し寄せるユーザーの憤怒
上記のUIをリリースするまでに何社かユーザーヒアリングをかけたりCSなどのbiz側メンバーとも何度も方向性確認を行いながら「このUIであれば概ね大丈夫そうだよね」となっていましたがそうは問屋が卸さないのが世の常である。「これでユーザーの長きにわたる要望を実現するための一歩を踏み出したぜ」というお気持ちの我々ではありましたがリリース直後からクレームの嵐に見舞われました。届いた苦情抜粋↓
白抜き文字がチカチカして見にくい
白抜き文字がチカチカして見にくい！！
白抜き文字がチカチカして見にくい！！！！
他にも「バッジも含むと色が多い」や「整った環境で作られる際には問題なかったのかもしれませんが、温度も変わり日差しも差し込む現場には合いません」といった厳しいお言葉を頂戴したりもしました。が正直、ｸﾞｰｶﾚに慣れ親しんでいる我々からすると「白抜き文字が見にくい」という反応が来たのは完全に想定外。当然QAも挟んでいるしCSメンバーや数社と言えどヒアリングも経ているUIです。リリースするまで「白抜き文字が見にくい」という意見は１度も出ていなかったのにも関わらず同じ趣旨の苦情が50件以上届きました。ｸﾞｰｶﾚに限らず白抜き文字はあらゆるシーン・媒体で目にするものなので有効な代案も全く思いつきません。いやはや。
不安になるエンジニア、取り乱すPdM
作業カードの色を変えたことに付随する修正タスクを積まれている中、ユーザーからの不満がばんばん飛んでくる状況だったのでエンジニアもついに「手戻りに絶対ならなさそうな開発しかしたくないです」モードに突入。モードに突入したというか直接言っていた気がします。こうなるとPdMとしてはユーザーと対峙する中、開発からの支援が得られなくなり孤軍奮闘状態。表には出さないですが思考がどんどん弱気になっていました。その証拠↓↓
こういう時、デザイナーは比較的ニュートラルなポジションにいるのでPdMを支えてあげることが重要です。現状維持バイアスにより大企業がロゴを変えた時同様、何かを変えると必ず批判はくるものなので「そのうちユーザーも慣れてきますって！」とか「今後を考えると絶対必要な変更なので強く行きましょ！」とかなんとか言いながら励ますワシ。とはいえPdMに比べたらカスみたいな責任しか負っていないデザイナーは安易と軽口を叩けますが、この時のPdMには非PdMの想像を絶するほどの心理的負荷がかかっていたと思います。普段開発している時にはあまり意識しないですがMOVO Berthはトラック予約システムシェア１位のサービス。「自分の意思決定ミスで大量チャーンが発生して失墜したら」「自分の判断で顧客の業務が止まってしまったら」「CSのクレーム対応負荷が上がりすぎてCSとdevの関係が悪化したら」等々、不安要素を上げ出したらきりがありません。そんな中で開発陣から「開発したくありません」なんて言われたらもうハシゴを外されるに等しいのです。これを読んでるみなさんも頑張ってるPdMには優しくしましょう。
このDM以外にもハドル等で話し合ったりしていたんですが、リリース数日経ってついに「戻した方がいいのかなぁ、、、」って言い出した時は自身のゆるキャラ垢が炎上しても一切動じないことで有名なさすがのワイも「やっべぇぞ！！」ってなりましたね、エェ。みなさんもご想像の通りここで戻す判断をすると「PdMと開発陣の関係性が完膚なきまでにぶち壊れる」というリスクが高すぎるので、具体として何を言ったかは覚えていませんがあーだこーだ言って頑張って励ました気がします笑
UIに変更を加える時はやり抜く勇気が必要
そんなこんなでなんやかんやばたばたしてましたが、１ヶ月も経てば「戻してほしい」の声はほとんど聞かなくなったのでやはり慣れが解決してくれたようです。直後に追加実装された「作業カードの色変更機能」も順当に使われており、各物流拠点でその拠点に合った設定ができるようになったのも大きい模様。そうはいってもVertical SaaS。UIの変更難易度が高いという我々のイメージはしっかり現実を伴っていたようで、予想の５倍ぐらいの反応が返ってきました。もちろん渦中にいる時はその後がどう転ぶかなんてのは全く見えないわけですがそれでも「変更した方が後々のためになる」と思えるUI変更は途中で何を言われようともやりきった方がいいと思います。やり抜く勇気大事。仮に途中でやっぱりやめる選択を取っていたらそれこそ開発チームが壊れ、CSはもとに戻すための周知対応に追われ、新しいUIを指向するユーザーの不信感も高まってしまう割に開発コストも無駄になるし利益もなにも出ないわけで、それはそれで地獄のような状況が爆誕してしまいます。ユーザーがまぁまぁいるプロダクトのUIに変更を加える際は相当の覚悟をもって臨むのがよさそう。とはいえ「ユーザーが全く受け入れてくれないからVertical SaaSでUI変更はできない」というわけではなさそうです。もちろん程度にもよるとは思いますが。同じ轍を踏む開発チームが少しでも減るといいなという理由で考えられる対策を書いておきます。
事前の丁寧な周知超重要
業務に支障が出る変更をいきなり加えられるとそのUIがいかに優れていても「急に変えんなよ」のお気持ちが強まり、UIがどうであれ元に戻す力が強烈に働くようです。「UI変えますよ〜」という事前周知は丁寧に行うようにしましょう。
移行期間を設けるとユーザーの心理負荷を軽減できそう
これもよく使われる手段ですが移行期間中は新旧両方のUIを使えるようにしておくことで事前認知を取りやすくするのも有効そうです。今回の作業カード色変更は色が変わるだけで操作フローに変化はないため「たぶんイケる」と思っていましたが全然イケなかったので安牌を取る努力を怠ってはイケない。そしてたぶん設けたところでゼロにできるわけではないということも認識しておくべし。
関係者全員に不満の声は絶対にくることを伝えておく
我々は想定外の事態や事前に知らされていないことで自分にとって嬉しくない状況に陥った時、必要以上にてんぱったり怒りを覚えがちな生き物です。なんなら「思ってる５倍ぐらいは批判がくる」ぐらいの勢いで伝えてしまってもいいかもしれません。今回はPdMがCSへ丁寧に伝えていたこともあり、CSの方々は淡々と対応していただいていた印象。これが仮に、CSも「ユーザーから色々言われるので元に戻してください」というムードになっていたらPdMの心は完全に折れていた気がします。
最後に
筆者はこれまで５年ほど本業・複業通してずっとVerticalドメインを主戦場としてUIデザイナーをやってきているわけですが、これほどのプロダクト規模でこれほどユーザー業務に影響を与えうるUI変更のリリースをやったのは今回が初めてです。多くのtoB Verticalな開発会社はクレームを恐れるがあまりプロダクトの諸問題を足し算で解決してしまい、機能やUIの複雑性が高まってその後の開発がのっぴきならなくなる傾向にあります。そんなのっぴきならなくなるプロダクト開発をしがちな会社やPdMが多い中、ユーザー業務の根幹に関わる変更をPdM裁量で実行できる会社組織もすごいし、自分ひとりの責任でやると決めたPdMには盛大な拍手を送りたいお気持ち👏👏👏いや、「この意思決定できるのはまじすごいっす」っていう話はPdM本人にもずっとしていたんですが。まじすごい。これを読んでる方は「色変える程度でおおげさなぁ」と思ってるかもしれないですが、たぶん自分が同じ状況で同じ立場に立ったら大半の人は何もできなくなると思います。偉大なPdMって偉大だよナ！！
また開発チームが最悪の状態にならずにプロジェクトを完遂できたのは心強いCSﾒﾝが心強く淡々と顧客対応をしてくださっていたおかげだと思うので心強いCSﾒﾝには頭が上がらないです。いつもありがとうございます😌そして当然のことながらPdMとデザイナーだけでは動くものは何も作れないので紆余曲折ありながらも開発をやりきってくださったエンジニア、QAメンバーにも感謝です！！我々企画サイドの人間はいろんな人の協力があってはじめてユーザーの役に立てるので、今後もいろんな人に対するありがとうのお気持ちをたずさえてプロダクトデザインしていきたいお気持ち。
この記事が気に入ったらサポートをしてみませんか？