やらなきゃ損する!? デザイナーが出来る、プロジェクトを高速化するエンジニアとの連携術。

長らく、あることがUIデザインやWEBデザインについて実しやかに言われています。

それは、次のような意見です。

「デザインの能力や経験がない人とデザインの議論をする時、必ず具体的なビジュアルやその案を見せながら話そう。そうでなければ生産的な話は出来ない」

しかし、それは本当なのでしょうか？

ある会話

デザイナー
「あー、じゃあこのAのプロパティはBooleanの方がいいかもしれないですね」

エンジニア
「そうっすね。で、A’っていうプロパティを別途作って、そっちはstringにしましょう」

デ「いや、A’がstringだと紐づいてる情報の中身が引用されなくなるので、jsonでいいんじゃないですかね。もしくは別テーブルからリレーションして引っ張ってくるか」

エ「あー、じゃあA’はstringで置いておいて、引っ張ってくる用のA’’っていうプロパティ作ればいいんじゃないですかね？」

…これは、ある時私がエンジニアと交わしたUIデザイナーとしての会話の一部です。

ある新機能に使うUIコンポーネントをエンジニアと一緒に定義しているシーンで、部分的にDBの内容や構成にも触れています。

2人の目の前には、対象物がどんな見た目かが分かるデザイン資料はなく、NotionのDBテーブルに書いたプロパティ表だけがありました。

そしてさらに重要なことに、この会話はデザイン過程の中盤や後半ではなく、序盤に行われました。

見た目も何も見ていない上にプロジェクトの序盤なのに、その議論内容はまるで既に具体像が見えているかのようです。

これは、冒頭に述べた「具体的なビジュアルやその案を見せながら話そう」という原則(?)に反していますよね。にも関わらず、生産的に議論しているように見えます。

なぜ、そんなことが可能だったのでしょうか？

プロダクトデザインのルーティン

プロダクトや機能を設計する職業をプロダクトデザイナーと言います。設計することが仕事の彼らは、どういう風にプロダクトを作るかを毎回ゼロから考えているわけではありません。

きちんと進行できる型・開発できる型を持っていて、これによって設計の妥当性やスムーズな進行を再現しています。

長らくプロダクトデザインをやってきた人間として、私も例に漏れずプロダクトや機能を設計する際に必ず行うルーティンがいくつかあります。

その内の1つが、画面やコンポーネントを作り始める前にオブジェクトとそのプロパティを定義することです。

オブジェクトのモデリング例（引用元：OOUX(OOUI)を知らなかったらタスクベースのUIを設計していた話）

先にオブジェクトとプロパティと定義するアプローチは、あることを解決します。

例えば、こんなこと、経験ありませんか？

「Figmaにあるデザインは画面ベースで作ってあって、画面に起こされてない細かな事柄が設計されていない」

「画面だけあるけど、全然情報が網羅されてないんですよね。早くデザイン完成しないと、開発進められないですよ」

課題

デザイン待ちのエンジニア

上記のようにデザインツールで作った画面以外に情報が無い/少ない時、そのプロジェクトのエンジニアリングはそこで一度停滞します。

また、デザインが終わるまで何も出来ないというのは、そこだけ見ると伝統的なウォーターフォールでありデリバリーの速度を落とすことになります。

実質的な歩留まり

プロジェクトが停滞してしまっても、エンジニアがすぐに着手できる別のタスクがある場合は開発リソースが完全に歩留まってしまうわけではありません。

ですが、もし会社やプロジェクトにとって超重要な機能や開発項目であれば、これに着手できない状態は歩留まりと実質的に同義です。

ソリューション

プロパティを画面より先に設計する

こういったデザイン待ちによるデリバリー速度の低下は、デザインにおいてある工夫をすることで、ある程度緩和することができます。

ニュースレターでは続きが無料！！！！！