どのレベルのコードを書くと効果的であるか
自分だけでコーディングできる必要はありませんが、デザイナーがまったくコードを書かなくて良いチームも少ないのではないでしょうか。
私がよく聞かれる質問のひとつに「デザイナーはどこまでコードを書けると良いのでしょうか」というものがあります。身も蓋もないのですが、これに対しては「チームによる」がその答えです。
フロントエンドが強い方が複数いれば、デザイナーとフロントエンドエンジニアできっちり分業した方が効果的です。この場合はHTMLとCSSさえ書ければ良いでしょう。逆にバックエンドやインフラ出身の方が多いのであれば、デザイナーがフロントエンドをカバーする動きも必要です。ビュー側で行うちょっとした条件分岐などであれば、デザイナーが実装できた方がきっと事業のスピードは上がります。
また、新規に作成するプロダクトにデザイナーがイチから加わるケースでは、データベースのカラム名の命名などにもデザイナーが入り、UIモックアップやマークアップでも同じ名前を使うようにする、といった関わりかたもできるでしょう。
「コードを書く」とは少し違いますが、デザイナーがどう関わるのが今後の制作にとっていちばん良い影響を及ぼせるのかを考えることが大切です。
大切なのは「触って操作できるもの」を制作できること
コードを書くにしても、完全に本番投入できるクオリティで書くことがすべてではありません。それは下記のような理由からです。
- FigmaやSketchで作るものよりも、もう少し高精度なプロトタイプで検証したい目的であれば、HTMLとCSSだけで作ったページでも問題はない。
- ダミーのデータを用意してローカルで動くものを作るだけでも「実際に近い操作感」で動的なページ変化の操作を検証できる。
- たとえばTypeScriptを扱う現場であっても、デザイナーが書く場所はanyを使ってもOK、とすればまったく触れないことはないはず（※）。
※デザイナーだけでルールを決めず、引き継ぎ方などを含めてエンジニアと話し合うのが前提です。anyの多用されたコードそのものを許容する意味ではありません。
UIツール上で「静的なモックアップ」だけを作成するか、コードを書いて「触って操作できるもの」を作るかでは雲泥の差があります。
また、実際の制作はモックアップ作成をしたあとにコードでの実装にうつる、というように、きれいに線形に進むものでもありません。いざコードで書いてみたら操作感が悪く、モックアップに手を入れて……と、行ったり来たりしながら完成に向かうことは問題ありません。
まったくコードが理解できていないと、モックアップを実装者にパスする、やり直しが発生したらデザイナーへ戻す、また修正して実装者にパスとなってしまい、時間がかかってしまいがちです。そういう現象を回避するためにも、UIモックアップ作成と並行して、基本的なコードを書けるようにしておくと良いのではないでしょうか。
まとめ
- デジタルプロダクトに関わるデザイナーは自分だけでコーディングできる必要はないが、理解は必須。
- チームのエンジニアの得意な領域によって「デザイナーが書くと効果的なコードのレベル」は変わるため、デザイナー単体としてではなく、チーム全体の総合力としてどこまでのレベルに到達できると良いかを考えていくのが良い。
- 完全に静的なUIモックアップ作成だけに終始せず、ある程度触って動かせるものまで作れる状態が大切。
