見出し画像

デザインシステム勉強会「ds.t Episode V: atama plus」での質問に答えます

こんにちは。atama plusのヌマタです。
先日1/16に勉強会「designsystems.tokyo Episode V: atama plus」を開催しました。来場いただいた方々ありがとうございました!

designsystems.tokyoとは、デザインシステムに取り組む各社が知見や学びを共有するガチな勉強会です。その第5回目としてatama plusのデザインシステムの1年間についてお話ししました。

イベントでの反響はtogetterにまとめております!


今回は、当日hands up!で募集していた質問のうち、答えきれなかったものにお答えしたいと思います。

デザイン原則の浸透のさせ方

Q. デザイン原則を浸透させるためにどんなことをしていますか?

A. デザイン原則を印刷して、社内の壁に貼っています。また、入社時のオンボーディングで全社員に紹介しています。こつこつ地道な活動ですね。

画像1

デザイナー以外のデザイン原則浸透具合

Q. 社内でデザイン原則はデザイナー以外にどこまで浸透していますか?

A. 先日嬉しかったのが、塾での講座設計などを担当しているCSメンバーが「僕デザイン原則をスマホの壁紙にしています!」と伝えてきてくれたことです。(衝撃が走りました) 浸透は継続してやっていく必要がありまだまだこれからの側面もありますが、会社のMVとの位置づけを明確にし、社内に広く掲示している効果は一定あるかなと思っています。

デザイン原則の解釈について

Q.「そのデザインがデザイン原則に合っているかどうか」がデザイナー間で判断がブレることはありませんか?

A. 検討の時点でぶれない表現になることを意識はしました。曖昧性をなくし、むしろ迷ったときの判断の軸になるように考慮して整理しています。
その結果か、特にぶれているといった話はなく、むしろ判断に役立っているなという認識です。オンボーディングなどでニュアンス含め認識を揃えている効果かもしれません。

開発以外のメンバーをどのように説得したか

Q. ビジネスサイドなど開発以外のメンバーを説得するのに定性理由で納得してもらえたのでしょうか?どうしても費用対効果やリソースの心配ばかりされて、実行GOが出されず悩んでいます…

A. プロダクトのフェーズや状況によって判断は変わり得ますが、弊社の場合は、デザイナーやプロダクトに関わる人数が増える中で、今からデザインシステムに取り組んだ未来と取り組まなかった未来がどうなるのかを伝えました。事例ベースで伝えることを意識しています。
また、デザインシステムも技術的負債同様にUXUIの負債の解消という側面があるので、技術的負債に取り組む文脈で伝えると理解を得やすいかもしれません。

デザインシステムの適用を目的に開発したのか

Q. 「1ページずつ機能パターンを適用してアップデートする」のは、何かの開発に合わせてついでにアップデートしていったのか、アップデート自体を目的にした開発を行ったのか、どちらでしょうか?

A. デザインシステムをプロダクトに当てることは、それ単体で1チケットとして作業が切られています。「uniform対応をXXページに行う」のようなチケットです。
ですが、機能追加や改善が確定しているページがあるとき、uniform対応を後に回すと技術負債が貯まるので、機能追加と一緒にやる場合もあります。

デザインレビューはやっているか

Q. 実際にデザインをプロダクトにあてていった後、デザインレビューのようなものはやっているんでしょうか?(開発フローどんな感じなのかなと)

A. デザインレビューは行っています。以下、開発フローに交えてお答えします。
前提として、アジャイル開発を導入しており、1スプリントごとにスプリント内に行ったチケットのレビューを行っています。レビューは以下の3種類があります。
①デザイナーの設計をチーム(デザイナー・エンジニア・エリアプロダクトオーナー・QA)で確認するレビュー
②実装されたものをチームで確認するレビュー
③ビジネス・コーポレート系の職種も含めた全体レビュー

まず①の段階でuniformに照らしてパターンの使い方を確認します。uniformは「載っていないパターン使用禁止」のような厳しい基準としていません。新しいパターンは許容して複数回使われ出した時に整理してドキュメント化しています。
次に②で、エンジニアが実装したものをデザイナーが確認します。今は既存のページに新しいパターンを作りながら当てていく作業が多く、エンジニア・デザイナー間で細かく確認しながら進めています。

ちなみに、プロダクトに反映したときの違和感・考慮漏れ等をuniformにフィードバックすることも行っています。ここでは、新たなパターンとして定義するか、ドキュメントにどんなことを追記するかなどのことを主に議論しています。レビューの結果、そのページ特有のコンポーネントなのでuniformには反映しないなどの結論が出たりします。


このように、質疑応答も活発に行われたイベントでした。atama plus側から来場者へ質問することもでき、学びが多かったです!知見を交換したいな、今後のイベント参加したいなと思う方はdesignsystems.tokyoのtwitterconnpassをチェックしてみてください。(一般参加枠がない場合もあります)

また、atama plusがデザインシステムをどのように作っているかについてnoteにまとめていっております。こちらもぜひご覧ください!


atama plusについてもっと知りたい方はこちら!


この記事が気に入ったらサポートをしてみませんか?