デザインの前にハンドオフしたら、プロジェクトが加速した話。

ある方法を始めてエンジニアとの摩擦が激減しました。デザインはビジュアルを見せながら話すべき はウソでした。画面やコンポーネントの前にあることを行うと、見た目が分かるデザイン資料を作る前からハンドオフできます。エンジニアのため、チームのため、プロジェクトのためにデザイナーがやるべき”プロパティ術”を公開！

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

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

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

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

ある会話

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

課題

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

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

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

実質的な歩留まり

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

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

ソリューション

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

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

その工夫が、オブジェクトのプロパティを画面やコンポーネントよりも先に作り、ドキュメントにすることです。

ドキュメントの例。Googleスライドの”テキスト要素”のプロパティを分解した表。テキストだけでこれだけある(右側)。これだけのバリエーションを最初からコンポーネントや画面単位で作ると膨大な時間が必要になる。

画面が無いと実装が進まない は嘘

上記のようにプロパティを先に設計しドキュメント化しておけば、「FigmaのUIデザインは画面単位で作ってあって、情報が網羅されてない」なんてことは無くなります。

エンジニアがすべてのバリエーションを把握でき、コンポーネント開発やDB設計に活かすことが出来るからです。

もちろん初稿の段階では考慮漏れがあるものですが、それについても早い時点で複数人のレビュー、特にエンジニアのレビューが入れることは大きな副産物です。

画面が無くてもプロジェクトは進む

ちなみにこのようなプロパティを作っている作業の中で解像度は上がっていき、プロダクトデザイナーの脳内ではおおよそのUI像が見えます（少なくとも私はそう）。

その全てをFigmaやコードといった誰でも見える形にするには時間がかかりますが、作り終えてから共有するのではプロジェクト進行は遅くなります。

だからこうやって、作る前から情報を共有することで進行を早めるのです。

プロパティ設計から連なるスイムレーン。このように早い段階からエンジニアも動くことが出来る。

テンプレート

正直なところ、手法についてこれ以上言えることはもうありません。より詳細なことは、具体的な実践になります。

そこでここでは、プロパティを設計するにあたりいつも自分のやっている方法をテンプレート化しておくことにしました。

Notionユーザーであれば誰でも今すぐ使い始めることが出来ます。下記からコピーして覗いてみてください。また、ご興味があれば、ご自身のお仕事で軽くワークをしてみてください。

• ダウンロード：オブジェクトプロパティテンプレート

• 見方や使い方：同ドキュメント内に簡易な説明を記載しました

注意点

完全なソリューションではない

ただこの話には、1つ続きがあります。重要な注意点です。

それは、この方法だけでは完全なソリューションにはならないということです。

早い段階でプロパティが揃うことは、それだけでプロジェクト進行を何倍も早めるわけではありません。

より具体的に進行したり本番の開発を完了することは、やはり仕様やUIデザインが完成していなければ難しいからです。

設計のレビューやコンポーネント開発、DB設計への着手は早くなりますが、結局のところ仕様やUIデザインがFixしていない状態ではエンジニアはブロックされます。

さらに言えば、ハンドオフが早まった結果むしろブロックされるタイミングも早く訪れることになります。

よって、このドキュメントがあればUIデザインはのんびりやっていても良いというわけではありません。

UIデザインや仕様策定（赤線部）も速めなければ、やはりデリバリーはブロックされる。せっかく前半部分を速くしたなら、ここも高速化したい。

実はこの課題については個人的な解答があるのですが、まだ確かめられておらず無責任に誰にでも言うのは憚られるため、コミュニティのChatsにのみ書くことにします。

気になる方はSubstackを開いて、Chatからご覧ください。↓

また、同じくSubstackのアプリからご覧の方は、下部のRestackボタンから、「わかりやすい」「ここが面白かった」といった感想をNotesでシェアして教えてください。

今後もこのような情報をTwitterやニュースレターで発信していきます。興味がある方は、私のTwitterもフォローしてくださいね🙏

コメント欄について

本ニュースレターは、各記事の配下にあるコメント欄も積極的に活用しています。Twitterでは言いにくい、DMするほどでもない、質問したいこと, 誰かの意見を聞きたいことはありませんか？ぜひコメントしてみてくださいね。

1. 【会話】
記述しているA, A’, A’’は、実際の会話ではプロパティ名です。

2. 【そこだけ見ると伝統的なウォーターフォール】
ウォーターフォールに見えるものでも、デザインの中で仮説検証が行われてユーザー行動やインサイト、ユーザビリティについて学習が進んでいることがあり、この場合、リリースするまで何も学習することをしないウォーターフォールとは本質的に状況が異なります。

ただ、その価値を無視したり内情を見ずに外から眺めた場合、デリバリーが無い事実からその形はウォーターフォールです。