サイボウズでプロダクトデザイナーをしている @kochitaku です。
Garoonという大規模組織まで使える情報共有の製品を担当しています。
今回は、数年前に行ったデザイン変更のプロセスを紹介します。
ユーザーの業務に影響があるB向け製品のデザイン変更は慎重さがとても大事ですが、慎重になりすぎてプロジェクトが冗長になったりコストが膨らんで取集がつかなくなるリスクもあります。なので「石橋を高速で叩く」ようなイメージで進めた当時のことをまとめました。
動き出したのは、社内外からの見た目に関する声が多くなってきたタイミングでした。
社内からは「古い」「今のサイボウズのイメージと違う」といった声があり、社外からも「見づらい」など視認性に関する要望がありました。自分が担当したデザインだったので、かなり厳しい声も遠慮なく関係者への提案資料に盛り込みました。
アクセシビリティ向上や他サイボウズ製品との親和性も軸として加え、よりUIをモダンにしていく「More Modern活動」と名付けてスタートしました。
PMの同意も得てリニューアルを進めていくわけですが、開発前に新デザインの価値をできるだけ速くリアルに体感できる方法を模索しました。デザインプロトではなく、普段業務で使っている環境で体感できると強いと考えました。
※サイボウズは自社製品を自分達の実務で利用
そこで、CSSを上書きできるChrome拡張を使って、実務環境で試すことをやってみました。対象がWEBアプリだったこと、当時の開発の状況的にCSSと画像の変更レベルがメインになると想像できた背景もあります。
Stylusなどの拡張がありますが、今ならChromeのCSSのオーバーライド機能でも同様のことができそうです。
毎日実務で使いながら手元で改善を繰り返し、なかなかの手ごたえを感じていました。振り返ってみるとここが大きなポイントだったと思います。
PMと共有してある程度納得いくものができた段階で、多様な部署のメンバーに新デザインの適用をお願いしました。ユーザーテストと同時に共感者を増やすという2つの目的を兼ねた社内運用です。Chrome拡張の適用方法のマニュアルをつくったりできるだけ試してもらえる工夫をしました。
運用中にもらったフィードバックの一部：
Good
- 会議で新デザインをモニタに映すと、「かっこいい」という反応がある
- 圧迫感が緩和された。UIの間隔が気持ち良い
- ボタンが大きくなったて押しやすい
- ヘッダーの操作感が他製品と同じになって使いやすい
No Good/イマイチ
- ヘッダーの各UIの位置に違和感がある
- 小さい部分のアイコンもフラットデザインにして欲しい
- もっと他製品と同じUIにして欲しい
全体ではポジティブなフィードバックが多く、チームで大きな手ごたえを得て本開発に入っていきました。
社外には、まず任意で設定できるお試し版としてリリースしました。いきなりUIが変わることの影響を考慮して、フィードバックを得てから正式なデフォルトデザインとしてリリースする計画でした。
ただしフィードバックが少ないと今後の判断が難しくなるため、「試してもらう」「新デザインの意図を知ってもらう」「フィードバックしてもらう」をできるだけ多くのユーザーに協力していただく必要がありました。チーム一丸となってその施策に注力しました。
ヘッダーの下に目立つように新デザインお試しのお知らせを表示しました。製品内でこのようなお知らせUIは初だったので、より注目していただいたと思います。余談ですがこの施策の反応により、チーム内では「製品内導線最強説」が生まれました。
新デザインの理解を深めていただくため、プロモーションチームと連携して新デザイン専用サイトを用意し、製品からもアクセスしやすいようにしました。
フィードバックフォームもアクセスしやすいようにして、フィードバックしやすいよう入力項目も最小限にしました。
社内運用での手ごたえはありましたが、経験上デザイン変更はネガティブ意見が多い印象を持ってましたので、リリース後の出社時は覚悟してました。
「1番つらいのは無関心」と自分に言い聞かせながら、新デザイン化をともにやって来たPMに挨拶すると「”気に入っている”が結構来てますよ！」と言ったのでびっくりしました。
全体としては「気に入っている」が多く、チームでさらに手ごたえを得ました。いただいたフィードバックを吟味して改善を行い、予定通り次のバージョンアップでデフォルトデザインとして無事リリースすることができました。フィードバックをしていただいた全ての方に感謝します。
自分も「良い！」と思った時はちゃんとフィードバックしようと心に刻みました。
UIのリニューアルや大幅なアップデートは、常に批判や反対がついてまわり、慎重にならざるを得ないものです。一方で時間も限られていた今回は「石橋を叩いて渡る」のではなく「石橋を高速で叩いて渡る」ことが求められていました。
慎重さとスピード感を両立させるために、開発前に自分の環境で素早く確度の高い検証を行うことは1つの方法でしたが、既存のフローに縛られず状況に合わせて常に知恵を絞ることが大事だと最近特に実感しています。
また、社外リリース時にお試し期間の担保があったことでチーム全体のチャレンジが促進され意思決定のスピードも上がったと思います。
ここまで読んでいただきありがとうございました。
他にも聞いてみたいトピックがあれば、ぜひこちら (ページ下部) からお寄せください。