UIコンポーネント作成のリードタイムを短縮する工夫
CrowdWorks.jpのデザイナーのksmです。
10月からデザイン基盤チームで専任デザイナーとして活動しています。
10月くらいまではFigmaでデザインを作成する業務が多かったのですが、デザイン領域とエンジニア領域を反復横とびしながらVue.jsでUIを実装をメインに活動しています。
この記事ではデザイン基盤チームで、デザインシステムのひとつであるコンポーネントライブラリ構築するにあたって、冗長化していたUIコンポーネントのデザイン決定までのリードタイムを短縮する取り組みをご紹介したいと思います。
なにをしたのか
忙しい人のために、先に要点からご紹介させていただきます。
デザイン要件を決める前のPOからのヒアリングで「要望」と「要件」という言葉の違いを、メンバーで認識を揃えた
デザイン要件策定したあとの要件レビューやデザインレビューでも、論点がブレずに進められた
ひとつのコンポーネントに複数の機能が要求されたら、機能ごとにコンポーネントを分割するようにした
難しいことを考えなくてすむようになった（機能の複雑性が下がった）
機能がシンプルにすることで、デザインレビューのコストも抑えられた
以上の認識を揃えたとコンポーネントを分割するようにした話を具体的に書いていきたいと思います。
大きいものは小さくする
議論の題材が複数あると、ついつい話が脱線し「あれ？何の話をしていたっけ？」ということになるのはよくある話だと思います。
そういった混乱を避けるには考えることを少なくするというのが一番取り組みやすい手段だと思います。ですから、ここではなるべく論点は絞って、考えることも絞るという工夫をしてみました。
プログラミングでも、新しい機能を実装するとき「なるべく小さなプログラムを作って、それを組み合わせて1つの機能にする」みたいな考え方をします。その考え方を議論にも活かしてみようという発想です。
そのUIコンポーネント、なにをするの？を話すようにする
弊チームでは、UIコンポーネントを作るときは
POから機能の要望をヒアリングする
要望をもとにデザイナーが要件を策定していく
策定された要件を複数人でレビュー
デザイナーがUIコンポーネントのデザインをFigmaで作る
作られたデザインを複数人でレビューする
という流れになります。
デザインが完了するまでに長い期間向き合うことになるので、なるべく決めるべきことは短期で決めて、手戻りは最小限にする必要があります。
なぜならば、長期戦になればなるほど作業者（担当者）がいつになっても完了しないタスクに疲弊してモチベーションが下がってしまうからです。
順調に進めても長期戦で疲弊してしまうのに、手戻りが発生してしまうとメンタルの消耗が激しく燃え尽きてしまいます 。
デザインシステムの構築は長期間の取り組みになるので、心身の健康のためにもこのあたりは大事にしておきたいところです。
要望をヒアリングする前に、要望出しルールを決める
POから要望ヒアリングを行う前に「『要望』と『要件』は別もの」であると認識を合わせる
要望は、MUST、WANT、NO NEEDで分類分けし、「なぜそれが必要 or 不要なのか」をあとから見返せるように付箋に書き出す
ワイヤーフレーム、あるいは既存ページのキャプチャを張り出すときはグレースケールの画像で用意
色がついていると、どうしてもそちらに目が言ってしまって、スタイリング的な話をしてしまうので、それを防ぐ
上記の工夫で議論の脱線を防ぎ、「〇〇したい」という抽象度の高い要望を聞き出せました。
もちろん、POのほかにマーケティングを担当している人から要望が来るケースや、別のチームのPOからの要望が飛び出てくることもあるので、すべてに対応できているとは思いません。しかし 「なんとなく長時間使って話したけど、まとまらない」 みたいなことにはなりませんでした。
同じ見た目でも複数のユースケースがあるコンポーネント
DropdownのようなUIで以下のような例があります。
formの中につかわれているselectとしての機能
selectでoptionを選択すると、選択したページへ遷移（リクエスト）する機能
selectでoptionを選択すると、CSVやPDFなど特定のファイルダウンロード処理を実行する機能
selectでoptionを選択すると、表示されている一覧がoptionの条件でソーティングされる
これがユースケースを洗い出すのも大変でしたが、コンポーネントの要望出しをするのも大変でした。
それよりももっと大変だったのが、複数の機能（やりたいこと）があるのに、ひとつのコンポーネントとして要件を考えることです。
ユースケースから考えると、使っている画面によって求められる機能が違う
1つのコンポーネントとして作ろうと思うと、要件も複雑になるが、なにより実装が「これ、本当に作れるの？」という心配が脳裏をよぎる
デザインも機能別で考える必要がある
考えることがたくさんあり、画面によって求められる機能が違います。
ぐるぐるといろいろ考えをこねくり回した結果「いっそ別のコンポーネントとして分割して進めたほうが楽に進められるかも？」という仮説が出てきました。
そこで「まずは一覧をソーティングするだけのFilterコンポーネントの要件だけ考えよう」という方針で進めてみました。
すると、他のコンポーネントでは要望出し→要件策定→デザイン決定まで11週間かかっていましたが、Filterコンポーネントは5週間でデザイン決定まで進めることができました。
コンポーネントごとに難易度は変わるので単純比較では説明不足のところもあります。
しかし、体感的なところで「ソーティングするための機能に必要なデザイン要件を考える」ことに集中できたというのは心理的負担が軽減に繋がりました。
また「もし△△という条件が出てきたときは」みたいなoptionalを考える必要もなくなったので、考慮漏れなどを心配することも少なかったです。
気づき
言葉の意味は人数が多くなると曖昧になるので、認識を揃えることが大事
議論をはじめる前に「この場では、これについて議論します。あれについては議論しません」という目的を選手宣誓することで、脱線を防げる
全部は無理。ここではなるべく脱線しないように……くらいの心がけでいいと思う
大きなものを作ろうとすると長期戦になり心理的につらくなるので、対象を小さくして短期決戦を繰り返し「進捗、ヨシッ（現場ネコ）」という状態にすることでモチベーション維持につなげる事ができる
特別なことはしていませんが、ちょっとした工夫で「モチベーションを維持しながら、進捗を意識できるようになる」状態にもっていけるのだな、という知見を得られたように思います。
これまで思っててもなかなかできないことだったので、やり切れたことは自分としても良い成功体験でした。
🍙
シンプルイズベスト。 単純明快は正義。
気楽にデザインシステム構築を進めていける取り組みはなんぼあってもいいですからね。
この記事が気に入ったらサポートをしてみませんか？