続・デザイナーが実装できれば中間成果物としてのデザインはいらないのか

一年半前にこんな記事を書きました。

結論を簡潔に書くと

- デザインは仮説検証とそれの打ち手をゴニョゴニョ考える活動も含まれるので、それに対してコーディングは生産性が低くなるので中間成果物としてのデザインは依然として必要

というもので、今もこの考え方は変わっていません。
ですが、この「ゴニョゴニョ考える活動」をもっといい感じに表現する方法を先日の Figma が開催した Schema 2021 で手に入れたのでそれを元に徒然に語るのがこの記事です。

早速ですがその方法とはこちらの図です。

「ゴニョゴニョ考える活動」とはこの図における Freeform Design に当てはまります。今度からは私も「Freeform のデザインが必要だからいきなりコーディングでデザインは違うと思うんだよね〜」と語ることにしようと思います。そっちの方が "ゴニョゴニョ" よりかっこいいですもの。

Figma はなぜ成功したのか

この Freeform の部分も Structured Design の部分も高品質に実現できているのが理由なんじゃないかと思いました。

Figma はペイントよろしく自由にお絵描きできます。かなりフリーダムに作れるので私もクソコラ作成などに重宝しています。

ただ、フリーダムに作った後に、それを"構造化"することができます。
例えば テキストや色のスタイルを定義したり、Auto Layout で CSS の display: flex さながらの挙動をデザインに付与できたり、コンポーネントを定義することによる再利用を可能になったからです。

私はデザインを作る目的は大きく二つあると思っています。
- デザイナーが自分のアイデアを具現化するため(仮説検証などに用いるため)
- デザイナーがエンジニアに自分の UI デザインの意図を伝えるため

この異なる二つの目的を Figma は前者は Freeform で自由に考えるフェーズと Structured なデザインで生産性を上げることで達成し、後者を Structured なデザインによってほぼ Web やアプリと同じ構造で表現されることによって実現したと考えています。

なので一つの成果物で二つの目的をストレスなく実現できるところが他のデザインツールと比べて Figma が優れた点だったのかなと思います。(ただどちらかと言うと、とにかく"コラボレーションをちゃんとしたい"デザイナーにとって嬉しい機能を追加していったら結果的にエンジニアにとっても嬉しいものになっていたという気もしますが)

コードからデザインする可能性について

私が最近注目しているのがデザインシステムです。
上記図の Code と Structured Design を繋げるものをデザインシステムとして表現していました。個人的にはこの考え方はしっくりきます。

具体的には下記の記事に書いたのですが、How としてデザインシステムを導入するとデザインとコードの構造はかなり近づきます。

なので、最初に「Freeform なデザインのために必要」と言っていましたが、開発が進んで Freeform でデザインする必要が減ってきた(ほぼ全てのデザインが Structured Design になってデザインシステムがコードとデザインを繋ぐ)プロダクトに関しては、もしかしたらコードでデザインする可能性も出てくるのではないかと考えるようになりました。

私をそんな気持ちにさせたのがこの UXPin Merge です。(唐突に宣伝くさくなりましたが特にお金はもらっていません。)

Merge by UXPin

Merge では React で書いたコンポーネントをそのままデザインツールの中で使えます。なのである意味 "コードでデザイン" しているようなものです。
そしてそういったスタイルをとっていると成果物はデザインしたものがそのままプロダクションレディなコードになるのでそのまま使えますし、アイデアの具現化も Figma 同様の感覚で行えます。

Freeform の部分に関しては正直 Figma の方が痒いところに手が届く感覚がありますが、プロダクトのフェーズに応じてこういったツールを活用して「コードでデザイン」して開発を加速させていく選択肢はあるのかもなぁと最近感じています。

もしこのツールをガンガン使いこなせるような状態になったら爆速で改善していけそうですごくワクワクします。そうなれるように頑張ろうと思ったのでした。

完