UIデザイン使用性チェックリストの基準充足とメンバーの感想
こんにちは、オオカワラ（@o_kwr）です。暑さがとても厳しい今日この頃ですね。
UIデザイン使用性チェックリストの基準充足に取り組みました
SmartHRのプロダクトデザイン本部では、今年の頭から6月末の上期にかけて、メンバー全員でSmartHR Design Systemにおける「UIデザイン使用性チェックリスト」を運用できる状態にするために、必要なコンポーネントやデザインパターンとしての基準の充足を行ないました。この基準充足とは、コンポーネントやデザインパターンにおけるルールや、使用の際の判断基準を追加・アップデートすることを指しています。
なぜ、この基準充足をメンバー全員で行なったかというと、2024年1月時点ではこのチェックリストにおける判断基準はまだ充足できていない部分があり、そのままでは十分な運用ができない状態でした。しかし、このままではSmartHRのプロダクトデザイナーのパーパス（存在意義）でもある「プロダクトの使用性を担保する開発者」であることが達成できないため、そのケイパビリティを高める一環として取り組みました。
UIデザイン使用性チェックリストに関しては、versionfiveさんが以前書いた記事を読むとより詳しいことが書いてありますので是非あわせて読んでみてください。
SmartHR Design SystemはGitHub上でパブリックリポジトリで運用されているため、マージされたPull Requestを覗いてみるとわかるのですが、例えばアプリケーション内で存在しうるページレイアウトに関するルールをゼロから追加したり、今まで利用場面やルールが曖昧だったコンポーネントに対して定義を与えたりしました。
これにより、UIデザイン使用性チェックリストは、プロダクトデザイナーがお互いにインターフェースのレビューを行う際に議論するための共通言語として、どういったコンポーネントやデザインパターンを選ぶべきか判断コストを削減するといった効果が出始めています。
基準充足の取り組みについてメンバーにアンケートしてみました
そして今回は、この基準充足の活動が一段落した今、実際に取り組んだメンバーにアンケートを取ってみて、どんな感想だったかなと調査してみたのでその内訳をご紹介します。
「どうしてこの取り組みの感想なんか聞いてみるんだ...？」とお思いのそこのあなた。わかります。実際に取り組んだ人でないと正直あまり興味ないですよね。ですが、私もこの基準充足に取り組んだ一人として言わせていただくと、ほんっと〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜に大変だったんですこの基準充足！
普段、暗黙的に理由付けして使っていたコンポーネントをどういうときにどういうルールで使用すべきかについて一般化・言語化して、プロダクトデザイナー全員で認識を揃えるという一連の流れが思っている以上に難しいんです。（ちなみに、この半年で53項目の内容について基準充足を取り組みました。個々の具体的なものに関してはX（旧Twitter）にて追うこともできます。）
そんなわけで、基準充足に取り組んだ他のメンバーもきっといろいろ大変さや感じたことがあるに違いない、そして軽く振り返ってみることで気付きがあると思い、アンケートで聞いてみました。普段プロダクトデザインに取り組んでいる方にも何かしら示唆があるのではないかと思います。抜粋しつつ見ていきましょう。
Q1. 基準充足を取り組むにあたり、良かったことがあれば教えてください
コンポーネントの使い方やレイアウトにおける基準を「自分で言語化」できたのはいい経験だったと思います。人から聞いたり既存のガイドラインを読んだりすることで理解した気になっていたことも、いざ自分で言語化しようとするととても難しい一方で、レビューを頂きながらなんとか自分で言語化したものは自分の血となり肉となった感覚があり、開発時にUIの理由などを明瞭に説明できるようになりました。
わかる。言語化がやってみると意外と難しいんですよね〜。
ほしかった基準、不要だと思っていた基準を自らの手で加筆修正できた。
そうそう。改めて見てみるとこの基準不要だよねというものもありました。
基準を書くためにそもそもHTMLの規格がどうなっているのか？やSmartHRの画面がどうなっているかを調べるところから始めたので、どちらの理解も深まったと思っています。
「そもそも」の部分から情報を洗い出して全体を俯瞰して考えるというのが多かったですね。
ひとまず「プロデザの現時点のメンバー・構成において」、迷っていたことをはじめとした「"言語化できる・すべき範囲"での言語化」が一定つくれたことで、デザインの品質の最低ラインが新たに更新されたと思っています。
プロデザ全員がデザインシステムにコミットできたこと・できる状態になったこと、これはマジででかいと思います。プロダクトデザイン組織でデザイナー「全員」が「GitHubを中心とした開発環境を整え」、「Pull Requestを作成して」、「デザインシステムに基準を生んだ」、こんな組織ありますかね？ないと思います！！
大臣（自分が担当した基準の解像度が高い状態）が生まれたことは嬉しい誤算でした。得意なものを各自もっていることはいいことです。
この基準に沿っていれば一定ラインの品質が担保されるようになった、という状態になったのは偉業ですね！そしてそこにプロダクトデザイナー全員でコミットできているのも改めてすごいな〜と思っています！
ちなみに私は基準充足を通じていろいろありましたがSegmentedControl大臣になりました。
自分が書いたコンポーネントについては自信をもって使い、レビュー時に使用できるようになった
プロダクトデザイン本部では、週2回各1時間でレビュー&モブデザ会というメンバー全員が揃って開発中のUIをレビューする場があるのですが、このときに迷わずに使用基準を議論できるようになりましたね〜。
Q2. 基準充足を取り組むにあたり、難しかったことや困ったことがあれば教えてください。
「SmartHRではどうするか」だけでなく、「一般的にはどうすべきか」も伝えなければならないこともあり、他社のガイドラインなど様々な文献を参考にしたことが大変でした。
（たとえば、余白は一般的にはどうなっているべきかを、人間の認知に関する法則をもとにまとめたり）
ある程度普遍的な範囲まで考慮しなくてはいけないのは大変でしたね。
新しく書く基準において「求められているものが何なのか」を見出すのが難しかった。
使い方がそもそもあんまり決まっていないものの、使い方を決めることが難しかった。（明文化されていないけど暗黙的に「こういうものだよね」というものは、どう分かりやすく説明するか、だけを考えればよかったので）
ゼロベースからだとそもそもどういった基準が必要なのか、メンバーから意見を吸い上げることもありました。難しかったですね。
議論の範囲をどこまでにすべきか、は一定の課題が残ったと思います。たくさんの人数で議論すると一向にまとまりませんが、一方で少ないと基準ができたあとに「そういう認識じゃなかった」が生まれることもあります。これは一定受け入れて、適宜「あとから見直す」という運用する体制を整えることが重要だと思います。
私個人的な話として、すべてのPRの基準をレビューするのは頭が爆発するかと思いました。特に最後の1ヶ月くらいの負荷が異常だったので、若干「もう二度と御免」感があるのでサステナブルに続けたい。。
たくさんの人数で議論すると本当に発散しまくって収拾するのに大変でしたね。私もPull Requestのレビューをもらって「え、これどうやってまとめよう......」と悩んだことが何度かありました。
そして基準のレビュー本当にお疲れさまでした......。
パターンの説明をゼロから書くため、「モード」という概念そのものや、まだ社内で誰も明確に言語化できていない分類や使い分けを定義する必要があり、その部分が特に難しかった。
また「ダイアログ」の基準を書くにあたり、「ダイアログとは何か」という今さらな説明を書くのにも意外と苦労した。
モードやダイアログあたりに関しては、他社の開発組織でもここまでちゃんと言語化できていないんじゃないかと思うほど充実して偉業だと思います。
Q3. 基準充足を取り組むにあたり、気付きがあれば教えてください。
一人ではできない。
他の人に相談し、レビューしてもらい、一緒に悩み、議論してようやく一つの知見となることがわかりました（わかってはいたけれど、よりそう思った）
レビューと議論を通じて、次々とまとまっていくという感覚でした。
普段何気なく使っていたデザインパターンに、すべて理由があるということを改めて認識できた。
プロダクトデザイナーという職域で避けては通れない、デザインに対する説明責任をコンポーネントやデザインパターンに対して全て言語化して果たしていく、みたいな取り組みでしたね〜。
基準を作った人が一番基準に詳しくなるのでレビュー会とかでもその人がいたら意見を聞けるし、デザインシステムに加筆するときもレビュワーとして呼ばれたりしてその基準においては進みが良くなるという副次効果があるなと思っています。
上述していた「大臣」効果ですよね〜。ちゃんと基準が自分の中にあるからスラスラと答えられるようになりましたね。
自分が書いたところ・レビューしたところの解像度はとても上がるが、他はなかなか上がらないなと思っていた。読み合わせ会があるのは非常に助かる。
基準が追加されたところは順次全員でその内容を確認する「読み合わせ会」がありましたが、これのおかげでちゃんとキャッチアップできています。
Q4. 基準充足がなされてきて、今現在まででその恩恵を受けた場面はありますか？
自分自身がUIを設計する際に迷うことが少なくなった気がします。悩んだらすぐデザインシステムで検索して、そうそうこれこれ、みたいな感じ。
あとはプロダクトエンジニアの方から「充実してわかりやすくなった」という声ももらっています。もうデザインシステムがあれば自分が不在でも開発が進むのでは、と思ったりもしています。
デザインシステムをソースとして貼り付ける機会が増えた気がします!
これまでだと実装されているものを参考にしてたけど、基準がリファレンスになるので基準にそうことができる。
また、デザイナー以外とのコミュニケーションでデザインシステムを参照するようにURLを貼れるのでデザインの理解関心に一役買っているのでイネイブリングが捗る感じがしています。
私自身も、開発チームの中で議論していてこういうときどうするといいんだっけ？となって、デザインシステムをそのまま参照して答えを出せたりしています。ありがたい。
余計なことで悩むことが減った気がする。余白を設定するときにこの余白にした理由って何だっけ…や、InformationPanelを使うときにこれって使っていい場面だっけ… 他にも似たようなのがあった気がするけど… のような余計な悩みが減り、プロダクトに大事な悩み事に時間を使えるようになった気がする。
プロダクトにおいてより時間をかけたい部分にリソースを集中できるようになったのはありますよね〜。
自分が担当したコンポーネントに関しては、使い方に迷いがかなり減った。
感覚的な判断が減り、理由やロジックを明確に説明できるようになった。（ここは基準がある、もしくは理由があって基準には合わせずに対応している、など）
説明責任を果たす、という部分に寄与していますね。
基準充足ができたここからがスタートライン
というわけで、メンバーの感想や意見を見てみましたが、
基準の言語化は難しかったが、設計時の迷いがなくなったり説明責任を果たす土台ができた
開発ステークホルダーへの説明やリファレンスとして強化できた
あたりが大きな部分として得ることができました。
しかしながら、この基準充足はあくまでもスタートラインに立ったに過ぎません。UIデザイン使用性チェックリストがプロダクトの使用性や品質を担保し、議論するための共通言語となった今、その次はそれをどう開発の中に浸透させていくか、そしてその結果プロダクトがユーザーへもたらす価値に対して今以上にコミットしていくにはどうしたらいいかが次の課題となっています。
そして、今回取り組んだ基準充足ももちろんこれで終わりではありません。プロダクトを開発していく中で、こういう場合はどうしたらいいだろう、こんな基準も追加すべきなのではないか、というのは引き続き出てきます。SmartHR Design Systemは、比較的完成されたものだと思われることもあるのですが全くそんなことはなく、今回の基準充足のように引き続きアップデートしていくつもりです。
最後に
SmartHRのプロダクトデザイン本部では、今回の基準充足のように自らの武器であるSmartHR Design Systemをアップデートしつづけ、その先のプロダクトの使用性やユーザーにもたらす価値を追求していく環境で活躍していきたいデザイナーを本当に心から待っています。
もしSmartHRのプロダクトデザイナーに興味をお持ちいただけましたら、積極的にカジュアル面談や採用をしていますので、以下の申し込みページからお気軽にお申し込みください！
この記事が気に入ったらサポートをしてみませんか？