エンジニアがデザイナーといい仕事ができるために頑張ったこと
この記事は下記の記事に触発されて、逆方向の「エンジニアの自分がどういうモチベーションでどうデザインの勉強をしていったか」というのを語ってみよう！という内容となっております。
あと最近よく「なんでデザインし始めたの？」「どうやって勉強してるの？」という質問をいただく機会が増えてきたので、それへのアンサーともなればなと思います。
なぜデザインを勉強し始めたのか
結論から言うと必要に駆られて勉強し始めました。
前職はスタートアップに勤めていたのですが、当時作り始めていた新規サービスに携わっている人はエンジニア2名 + デザイナー1名という少数のチームでした。
ただデザイナーともう一人のエンジニアは他のプロジェクトにかかりきり…なので一時期この新規サービスの開発は私だけという状況でした。
そこで困ったのがデザインがないこと。大まかなワイヤーフレームは握っていましたが、デザインがないのでフロントの仕事は進められませんでした。なのでバックエンドのブレなさそうなところだけ先に実装を進めていましたが、いよいよそのタスクも枯渇してきて私はこう思いました。
「これはもう、俺がデザインするしかない…！」
と。
LP などビジュアル要素が強めのところはさすがに無理かなと思いましたが、設定画面など他のサービスを参考に作れそうなところから作り始めてみました。
デザインの作りがフロントエンドの生産性にも影響大きいのでは？と気づいた
という訳で自分でデザイン作るようになって気づいたのが、「デザイン、うまく作ると実装もしやすいのでは？」ということです。
例えば Figma の Auto Layout を活用すると「display:flex と同じスタイルが撮れるやんけ！こんなん全部に使うべきやろ！」とか、デザインの段階でうまいことコンポーネントを整えておくとフロントエンドで実装する段階で設計に悩みづらくなったりなどなどです。
(この辺で感じたことは下記記事やスライドに過去にまとめました)
また、デザインのロジックで考えてフロントエンドのコードを設計するとより変化に強いものになるのではないか、というのも感じました。
例えば下記の記事では「デザイナーが余白をデザインする時は要素間の関係性に基づいて決めるはず。なので余白にはどちらかの要素に紐づくマージンではなく単独で存在する Spacer を使うべき」論を主張していますが、実際この方針で実装してみたところ大分楽に実装できていますし、変更もスムーズに行くようになった実感があります。
このような形で「デザイナーがどう考えてデザインを決めるのか」というのを理解してフロントのコードに落とせば、よりよいフロントエンドエンジニアになれるのでは！と思いました。
また、こういった”実装面で嬉しいデザインの作り方”をデザイナーにフィードバックしていくとデザイナー的にも実装とのズレが少ないデザインが作ることにも繋がって嬉しいだろう、というそこはかとない予感もあって、よりよい協業関係のためにデザインをもっと深く知ろう！と思いました。
このような思いから私のデザイン沼への旅が始まったのです。
何を学んだか
そんなこんなで「よし！デザインを勉強するぞ」となった私ですが、次に具体的にどんなことをしてたのかを語ろうと思います。
ノンデザイナーズデザインブックを読む
この本自体は新卒で勤めていた会社の課題図書として配られていたので遥か昔に読んだことがあったのですが、改めて読み直してみました。
もはや鉄板過ぎて説明不要かもしれないですが、いわゆるデザインの４原則と呼ばれる「近接、整列、強弱、反復」について学べる本です。
これを通じてデザインとは限られたスペースの中で余白や大きさ、色などのコントラストを用いて伝えたい意図に応じて情報を配置するものなんだ、というイメージがつきました。これを読むとなんとなく魔法っぽく見えるデザインという工程が思いの外ロジカルなものなんだ、という実感が得られると思います。
初学者には Must でオススメしたい一冊です。
とりあえず色んなアプリの UI を観察してみる
例えば、先ほど話したデザインをするきっかけとなった仕事では設定画面を作る必要があったので、色んなアプリの設定画面のスクショを撮って、どんな情報が存在しているのか、どうやってグルーピングしているのか、どんな UI パーツを用いているのかを観察しました。
こういっては何ですが、観察して感じることとして、昨今の UI はとてもコモディティ化しているのではないか、ということがあります。
もちろん色やタイポグラフィ、余白の使い方などには個性があるのですが、 UI パーツというレベルだと「そのアプリオリジナル」というものは中々見られません。
なので、愚直に量を積んで、UI の引き出しを増やし、色やフォントなどを決めるロジックを学べば素人の自分でも及第点のデザインは作れるようになるのではないかという実感が湧いてきました。
DailyUI をやってみる
”UI の引き出しを増やす” という文脈で「とにかく手を動かしてみたい」と思いました。「何事においても初心者の内は質より量！」という宗教に属していたため、とにかく何かしらの課題をくれるようなものが欲しかったのです。
ただ、仕事ではデザイン業も優秀なデザイナーインターン氏が入ったことから自分がやる必要も価値も無くなってきていたところでした。そんな折に知ったのが DailyUI です。
知らない方に説明すると DailyUI というのは一日一つ、お題がメールで届いて、それに即してデザインを作って公開する、というものです。
これを
とにかく手を動かしてデザインツール(Figma)に慣れる
UI の引き出しを増やす
という目的で実施していました。
ちなみにやっていた内容は note で公開しており、下記にまとまっております。(70個で更新止まっているのがお恥ずかしいですが///)
色・タイポグラフィ・レイアウトについて学ぶ
そんな感じで色々手を動かした結果思ったこととして、デザインを作るには大きく色・タイポグラフィ・レイアウトが構成要素として存在するんだな、ということが分かってきました。
他にもシャドウや角丸などの装飾に重要な要素はたくさんあるのですが、大きい要素は上記3つだろうと。
という訳でそれらの個別の要素に対して学んでみました。配色理論や Web におけるタイポグラフィのことなど。
色々読み漁りましたが特に記憶に残ったものを紹介すると下記のようなものです。
こちらは配色の教科書という本ですが、配色の歴史書と読んでも差し支えないような内容で「色」というものをどうやって表現するのがいいのかの歴史を俯瞰的に学べる良書でした。
こちらもタイポグラフィーに関して俯瞰的に学べる良書でした。読みやすさに影響を与える要素(line-height, letter-spacing, 一行あたりの文字数など)が何かだったり、フォントの分類、選び方などが学べます。
これらに対してもとにかく引き出しが大事そう
そんなこんなで一通り座学を学んでみて私はこう思いました。
「色にも配色の引き出し、タイポグラフィもフォントの引き出し、レイアウトもパターンの引き出し、経験量がとにかく物を言う世界っぽいな…？」
例えば適切なタイポグラフィを選ぶにしても、そもそもフォントの引き出し、色んなフォントを知っていないと最適なものなど選べません。
配色もたくさんの色の組み合わせを様々なものに対して実践していないと最適なものは選べないでしょう。
及第点のデザインを作る -> 人をときめかせられるようなデザインを作るにレベルアップするには数年単位の量を積む努力がどうやら必要そうだぞ…？ということに気づきました。
当たり前と言えば当たり前なのですが、それをリアリティを持って実感することができました。
そこで冷静になって考えました。
「自分は将来デザイナーとして活躍したいんだっけ？」
-> No あくまでエンジニアとして価値を出していきたい
「これ以上このビジュアル面でのデザイン力を自分が磨いてエンジニアリングとシナジーありそう？」
-> No 「デザイナーがどうやってデザインを決めるのかのロジックを知る」という目的はそこを伸ばしたところで意味がないと思う
そんな訳で私はこれ以上デザイン力(主にビジュアル面の)を磨く努力を諦めてしまいました。
そしてそこはトキメクデザインを作ってくれる最高のデザイナーと将来一緒に働けることを期待してお任せすることに決めました。まだ出会えてないですが、もし私と一緒に働く時が来ましたら一生懸命頑張るのでよろしくお願いいたします。
そうして、私のデザインの探求は終わりを迎えたのでした。
〜 完 〜
制作・著作
━━━━━
seya
View 部分のコードを書くお仕事を駆逐したい
ではなくもうちょっとだけ続くのですが、実はもう一つ自分の中で研究していたテーマがあります。
それが View、いわゆる見た目の部分のコードを自動化したい！ということです。ちなみに下記が一年半前に書いてたメモです。もはや懐かしい。
と言いますのもフロント歴も当時で3年くらいとそれなりになってきたのと、当時はとにかく静的なサイトを作る機会が多かったことがあります。コーポレートサイト、ECサイト二つ、クリニックのサイトなどなどを半年くらいの間にどんどん作っていた時期があり、とにかくフロントの実装の機会が多かった私は View のコーディングに疲れていました。
LP とかだとクリエイティブな実装もなくはないのですが、普通のページでの View の実装というのは慣れた人にとっては本当に作業です。
デザインを見ながら HTML と CSS を連打する毎日。仕事としてもそんなに面白くなかったですし、何より私の実装速度が体の限界量を超え腱鞘炎になったりもしました。
こんな仕事…駆逐してやる！という心境になって書いたのが上記の記事です。ただ当時は実現可能性低そうだな〜と思い諦めていたのですが、しばらくすると光明が指します。
そう、Figma の Auto Layout v3 です。
Auto Layout v3
具体的な時期は覚えてませんが多分去年の今くらいに Figma の Auto Layout v3 がやってきたと思います。
その変更で次のような UI になりました。
Padding が指定できて space-between とかも設定できて…
こ、これは…ほぼ display: flex やんけ！！！
厳密には flex-wrap とか表現できてなかったり全く一緒ではないですが、ほとんどのレイアウトの挙動は再現できるといって良いでしょう。
そして何より嬉しかったのがこれらのプロパティが API やプラグインを通してアクセスできることです。これによりレイアウトも含めて現実的に利用可能なコードを Figma のデザインから生成することが可能になりました。
そんな訳で自分でも Figma から React を生成するプラグインを作成し公開してみました。
それなりにいい感じには行きましたが、やはり運用で使うには課題がいくつかありました。そして、そんな課題を解くために重要になるであろうと考えた要素がデザインシステムです。
ちなみにこの辺りの「なぜデザインシステムが重要なのか」という考察は話が長くなるので省くのですが、昔こちらの記事に書き溜めたのでご興味ある方はご参照ください。
そしてデザインシステムへ…
上記の発想からデザインシステムがあるとデザインとコードが同じインターフェイス、粒度のコンポーネントやデザイントークンで作られ続ける状態を維持すればフロントの生産性もかなり上がりそうだと思いました。
(ちなみに感のいい読者の方なら気づいているかもしれないですが、デザインシステムが必要になるのはプロダクト開発フェーズの後期になるので元々の View の仕事を駆逐したいという動機からは少しずれてきています。)
また、そもそもデザインシステムは上記のような課題を解くためのものではなく(むしろこんな斜め上のところからデザインシステムに辿り着くの少数派な気がします)、調べると様々な課題を解く美しいソリューションだと気づきました。
UI の一貫性ができてユーザも Happy
デザインの意思決定も楽になり、デザイナーの作業も速くなる
エンジニアもそれなりの品質のデザインを自分で作れるようになる
実装速度も上がる
複数のプロダクトで使えばブランディングもバッチリ
これはただの流行りでは終わらん…必ずやプロダクト開発で必須の知識になるぞ。
そう強く感じました。
おわりに
そんなこんなで今に至る訳ですが、今やりたいのは次のようなことです。
デザインシステム作って運用したい
より良いデザインフローを探究したい(DesignOps と呼ばれるものかも)
その一つとしてコードをデザインに使う技術を試してみたい(これはデザインシステムあるのが前提になる)
デザインファイルの運用の仕方も工夫したい
View のコード自動化もまだ考えてる
これに関してはつい最近考察記事を書きました
UX リサーチやプロトタイピングを絡めたデザインプロセスの経験が弱いので、そこも模索したい
今はプロダクティビティの視点しか考えられていないが、より高い価値を届けるための視点を持ちたい
デザインシステムや DesignOps という概念は海外でもこの5年くらいで盛り上がってきた、まだまだ新しいフィールドなのかな〜と思います。
このフィールドで自分なりのより良いやり方を模索していけると楽しそうだなと感じているので、最高のデザイナーと共に最高のプロダクトを最高のプロセスで届ける未来を夢見て精進していきます。
それでは、長文でしたがお読みいただきありがとうございました！🚀
この記事が気に入ったらサポートをしてみませんか？