別のプロジェクトのDesign Tokensが交じることで、開発メンバーに混乱とコストをもたらす
※1. 以降の、課題感や分析や実装担当者と実装レビュワー担当者の感想が多いので、デザイン担当者の課題や意見ももらいつつ、ブラッシュアップしていきたいです
※2. あくまで実装者視点の意見や解決策案なので、一方向的な思考です🙏
※3. この課題は特定個人でなく、チーム全体、組織全体の課題です。課題を整理して、原因を発見し、よりより解決策を考えるために書きます。
課題整理のMotivation
実装者だけでなく、レビュワーからも課題感を感じると意見をもらった
確認コストが日に日に増えていて不毛で、みんなHappyじゃない。
Figmaのコメントが沢山になって、大事なコメントがあふれる
確認スコープが増えて、集中すべき事に対する集中力が奪われる
正直、デザインリソースの少なさや実装を最終デザインする方針であれば一定許容できるし、今のデザインリソース的に妥当だねと思っていた。ただ、思った以上にコミュニケーションコストが発生したりシステム側に誤差が発生したりしていて、FE側のコストが増えているし、デザイン修正コストも増えていそうなので、全体感で見ても、課題を整理したり、解決策としてcomponent化の工数を取るのが良いよねとFEメンバーで結論が出た
課題
混乱原因のデザインフロー
ただし、その修正をデザイナーが忘れることが、かなり頻発している。
実装者がデザインを実装する時
そのページや機能限定で、埋め込んで定義して実装
上記のような、何度も確認行為が発生することで、実装者における渡されたデザインに対する信頼性が下がり、以降、Web側のDesign Tokensレベルのミクロなデザインレビューにレビュースコープが広がる。 不毛な指摘コメントもたくさんする必要になる。
上記の実装者の混乱が、実装のレビュワーでも再発する。
シンプルに２度手間
レビュワー視点だと、実装者が気づいて無いようにも見えるので、実装者/デザイン作成者に対する信頼を失うと共に以降のレビューScopeがミクロな範囲にまで広がる
上記の課題から生まれるマイナスコストを整理する。
実装時
実装者
実装者がデザイン作成者に対して確認するコスト
デザイン作成者
デザイン作成者が実装者に返信するコスト
デザイン修正コスト
※されない場合もあって、以降のコストが発生する場合も多い。
レビュー時
実装のレビュワー
レビュワーが実装者及びデザイン作成者に対して確認するコスト
実装者
実装者がレビュワーに返信するコスト
Fimgaにおけるコスト
指摘/確認コメントで溢れて、大事なコメントが分からなくなる情報の信頼性のコスト
課題の原因分析
ここが根本原因なら辞める？
物理的コピペを辞めたところで、視覚的コピペを行うので、意味ない。
それなら、物理的コピペして修正したほうが作業効率が高い。
以上から、物理的コピペしても修正していれば問題無い。
ただし、その修正をデザイナーが忘れることが、かなり頻発している。
エンジニアが気づけて、デザイナーが気づけていない理由
デザインを見直していない。
見直す必要性は感じているが、時間が無い。
逆になぜ、エンジニアは気づくのか？
視覚的違和感に気づく。
※全てのエンジニアが気づくわけでなくて、そのProjectに長らくいるエンジニアは気づくけど、入ったばかりのエンジニアが気づかなくてそのまま実装している例もある。
結果、実装側の誤差が広がる
反映されない理由
反映する必要性は感じていない。
あくまで実装が最終的な正で、デザインはその仮定という方針
反映する必要性は感じているが、時間が無い。
指摘箇所しか修正していなく、同じデザインの他の箇所(PCや隣のページ、別パターン)が指摘前のデザインである。
真の原因: そもそも、該当デザイン箇所が、component化されていれば、一箇所の修正で直るのだが、component化されていないと同じデザインをすべて、手作業で修正する必要がある。
? なぜ、component化されていないのか？2箇所以上、利用するならば、後の修正面倒なので、component化すれば良いのでは？
実はcomponent化する方法が分からない。
componentでいろんなパターンを作る方法が分からない。
Responsiveにcomponent化する方法がわからない。
component化する必要性を感じていない。
そのデザインを再利用することや最終デザインをデザインデータに反映することは考えていないし、実際、実装者がいい感じで汲み取ってくれるので、Figmaに最終デザインを反映することを考えていない。
惰性的にcomponent化していない。
デザインをブラッシュアップしている時に、component化する発想に至らない/出来ないので、各フレームの塊をコピペして流用しがち。
? なぜ、デザイン側はこの実装側の負担やコスト感が理解出来ていないのか？
思考
主なコストが実装側に寄っていて、課題が見えていない。
実装担当者が、この課題感をデザイン作成者に伝えられていない。
結論
伝えましょう。
解決策を考える
案1. 方針で運用(失敗)
弊チームでは、一旦、以下の結論を下し、暫定対応していた
暫定対応
デザイナーは、見直して直す、指摘されたら直す。
エンジニアは、気づいたら指摘/確認して直してもらう。
恒久対応
もう少し後で、考える。
上記の暫定対応したが、あまり解決していなかった。
デザイナーは、見直して直す、指摘されたら直す。
これが全然出来ていない。
エンジニアは、気づいたら指摘/確認して直してもらう。
エンジニアとしても、指摘量がすごくて、疲弊している。デザイナーも同じはず。
「指摘されたら直す。」が出来ていないので、上述した実装レビュワーの課題は一切、解決していない。
案2: デザインfixしてエンジニアに渡す前に、デザインのcomponent化や見直し、工数を用意する。
フロー変更イメージ
Before
PDMからの要件→デザインでいくつかのパターン提案→PDM/デザイナー/エンジニアでブラッシュアップ→一旦デザイン確定→エンジニア要件整理→実際に実装→(偶にデザイン側のcomponent化後からする)
After
PDMからの要件→デザインでいくつかのパターン提案→PDM/デザイナー/エンジニアでブラッシュアップ→デザインのcomponent化や見直しをして、デザインfix→エンジニア要件整理→実際に実装
※ 別に、component化自身は、いくつかのパターン提案時やブラッシュアップ時に行っても良いとも思う。
意見
課題で上げたコスト感に関係者が納得すれば、「デザインのcomponent化や見直しをして、デザインfix」の工数を取ることは難しくないと思っている。
デザイン部分の作業工数が増えてしまうように見えるが、デザイナーやエンジニアの見えない工数が発生しているより、見積もりやすくなるし、コミュニケーションコスト減るし良いと思っている。
Q/A
そもそも、デザインリソースが足りないのに、新しくデザイン工数増やして大丈夫ですか？
全体観でいうと、デザイン工数も減ると思っています。
具体的には以下の工数が減ります。
デザイン作成者が実装者に返信するコスト
デザイン修正コスト
また、上記のコストを減らして、デザインのcomponent化や見直しをする工数として視覚化することで、デザイン工数を視覚化しやすくする効能があります。
ふわっとした、実装側の指摘対応といった、見積もりしにくく、視覚化しにくいコストが減ります。
デザインに対する信頼性、再利用性が上がることで以下のメリットもあります。
component化されているので、追加修正に対応しやすい。
後で、デザインデータを確認/参照した時に、正しいデザインであることを保証して利用できる。
その他、よりよくしていくための活動案
デザイン担当者と実装担当者で、デザイン↔実装における課題感や理想のデザインシステムといったことを議論できる、定期的な 1on1のような場所を設ける。
フロー的に、デザインシステムについて話せる場を設ける。
デザインシステムchを用意して、各自発信や話題提供、コミュニケーションを行う
Appのデザインシステム、Webのデザインシステム、デザイントークンの役割を正しく言語化する。
実装担当者が、Figmaデザインデータを直せるようにする。
Component化の粒度感や命名、デザインと実装の構造や意匠の一致を極力頑張るといったことも実装担当者にも求める。
実際、週末にFigmaでコンポーネント作成の理想例を作るべく練習して提案したのが良かった。
デザイナーもそれを見て勉強してきてくれた
おわり。
hr.icon
後日
案2の進捗次第で何かあれば書く。