SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

デザインに貢献できる開発者になろう! Figmaを通じたデザインの始め方

日々の仕事でデザインに興味を持ってみよう!──エンジニアがデザインを学ぶ3つのメリット

デザインに貢献できる開発者になろう! Figmaを通じたデザインの始め方 第1回

デザインを学ぶメリットその1:デザインからコーディングの品質・速度の向上

 まず分かりやすいのがデザインからフロントエンドの見た目の部分を実装する時のスピードを上げること、またはよりデザイナーの意図を汲んだコーディングができるようになることがあげられます。

 Figmaなどのデザインツールの見方や扱い方を学ぶことにより、コーディングに必要な情報が素早く得られるようになります。見た目の部分のコーディングは思いの外単純作業で、量が多いと私は中々精神的にも疲れますし、なんなら腱鞘炎になったこともあります。そこに対して情報の取得の容易性の向上や、デザインツールからのコピペやコード生成などで高速化、及び打鍵量の低下に繋げることができます。

 また、デザインファイルからよりデザイナーの意図が汲み取れるようになり、デザイン通りの見た目を作れるようになります。例えば、ちょっと極端な例かもしれないですが、フロントエンドの実装の経験がそんなにない方だと基本的なプロパティ(色、タイポグラフィ、余白)などの値が間違っていることはありますし、そういった見た目に映るところだけでなくレイヤーとコードの構造を揃えておくと後々の変更の容易性が上がることがあります。

デザインを学ぶメリットその2:デザインプロセス全体への貢献

 また、コーディングというエンジニアに閉じた作業だけではなく、デザインに早期にエンジニアの目線(主に実現可能性と実装コスト)をいれることによってプロダクト開発全体のスピードを向上させることもできます。

 デザインと一口に言ってもいくつかのレイヤーがあります。有名なのは「Five Elements of UX Design」というもので、次のように戦略、要件、構造、骨格、表層の5レイヤーに分類されています。

Five Elements of  UX Designの図
Five Elements of UX Designの図(出典:「Five Elements of UX Design」)

 エンジニアが特にデザインに関与しない場合は、デザイナーが表層の部分まで作ってくれるまでデザインを見ることはありません。しかし、できればもっと上のレイヤーの段階でエンジニアの目線でフィードバックができるとプロダクト開発全体のプロセスを改善することができます。

 表層のレイヤーまで作られてからフィードバックして要件など上位のレイヤーが変わると、それまでの苦労が水の泡になってしまいます。ただ、実際はひっくり返すことはそこまで多くなく、そのまま実装に反映されることも少なくないのではないかと思います。そうなるとデザインのみならず実装の複雑性にも繋がり、長期的なプロダクトの開発速度の低下につながる可能性があります。

 より確度の高い実装コストを考えられるのは、やはり具体の実装をしているエンジニアです。デザインプロセスにガンガン関与していけるとより良い意思決定に貢献できるのかなと思います。

デザインを学ぶメリットその3:デザインをメンテナブルに作ることに対する貢献

 また、デザインをメンテナブルに作っていくことに対してもエンジニアの力は活きます。

 組織が小さい内はそこまで問題になりませんが、人が増えてきたり、プロダクトの数が増えてきたりするとデザインにも「スケーラビリティ」が求められてくるようになります。

 デザインにもある程度の構造や統一した規則を設けないと、人やチームによって違う体験やlook & feelをユーザに提供してしまったり、既に作ったものをうまく活かせなかったりするとデザイン及びそのデザインの実装に対する余分な仕事が産まれてしまいます。

 そういった課題に対する打ち手の一つとして大きいものがデザインシステムなのですが、そこに対してはエンジニアの貢献が非常に重要になってきます。

 まずデザインシステムで具体として定義されるもののうち、コンポーネントやデザイントークンなどがありますが、これは実際のプロダクトに反映されていないと絵に描いた餅です。デザインとコードを同期していくためにはエンジニアの協力が不可欠です。

 また、デザイン自体のメンテナビリティにもさまざまな角度から貢献することができます。デザインシステムを作っていく時に、Figmaなどでコンポーネントやデザイントークンなどを設計していく必要があるのですが、もはやこの設計はデザインを構成する要素を抽象化して名前付けしていくようなもので「デザインというものを対象にプログラミングしている」ような感覚があります。ここに関してもエンジニアが普段しているような思考が活きるでしょうし、もっと具体的にデザインツール上での作り方の補助などの手助けもできます。

 デザインシステムには、一度は作られたもののプロダクトに反映されなかったり運用が続けられず活用されなくなる「デザインシステム墓場」なる現象がよく起きます。

 それはそもそも組織やプロダクトに対してまだカッチリしたデザインシステムが不要だった場合もあるとは思いますが、運用が回るまで続けられなかった側面も大きいとは思い、そこに対して強い意志と知見を持ったエンジニアが増えていくといいのかなと感じております。

まとめ

 以上、初回の記事としてエンジニアがなぜデザインを学ぶのかを掘り下げていきました。

 次回以降は代表的なデザインツールであるFigmaの基本的な使い方から、プログラミングを通じたデザインデータの扱い方などより高度なものまで解説していきます。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
デザインに貢献できる開発者になろう! Figmaを通じたデザインの始め方連載記事一覧

もっと読む

この記事の著者

seya(セヤ)

 Figma に詳しいフロントエンドエンジニア。NY州立大学 Stony Brook Computer Science 科卒業後、ソフトウェアエンジニアとして働き始める。フロントエンドエンジニアとして働く傍ら、エンジニアにとってもあらゆるメリットを持つ Figma に魅せられ、エンジニア目線でデザインプロセスの改善やデザインからコードへの自動化などを手がける。<Figma 公式グローバルカンファレンス「Figma Config 2022」登壇。Comm...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/17940 2023/07/18 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー