好みはある。ただ、それを言葉にできない。サイトのリニューアルで一番苦労したのは、コーディングでもサーバーの設定でもなく、この問題だった。
前の記事で書いた通り、カスタムテーマをゼロから作ることに決まった。見積もり40時間。実際は3時間で終わった。その内訳が普通と違う。デザインの方向性を決めるのに2時間。開発が10分。残り50分が微調整。時間の大半は「何を作るか」を決めることに使った。
デザインの言語化が一番難しかった
自分はデザインに詳しくない。「かっこいいサイトにしたい」はあるが、それだけでは何も伝わらない。フォントの名前も知らないし、余白の取り方に理論があることも後から教わった。
ただ、好みはある。これは好き、これは違う、という感覚はある。問題は、その感覚を設計に落とし込む言葉を持っていないことだった。「なんかこう、すっきりした感じ」では指示にならない。
そこで、まず自分がやったのは参考サイトを集めることだった。ウェブ上でかっこいいサイトのまとめページをいくつか開いて、直感で「これは好き」と思ったものをリストアップした。10サイトほど選んだ。
次に、そのリストの共通点を自分なりに言語化してみた。白を基調にした清潔感のある作り。色はモノトーンが中心で、使うとしても青系のアクセント程度。アニメーションやスクロールエフェクトは控えめに。派手だが情報が読みにくいサイトにはしたくない。
完璧な言語化ではなかった。ただ、リンクのリストと、この粗い言葉があれば、少なくとも方向性の輪郭は伝わる。
AIが好みを学習する過程
リストと言語化をDesignerに渡した。Designerはそれを読んだ上で、自分の好みに合いそうなサイトをウェブ上から探してきた。
これが面白かった。最初の候補のうち、7割くらいが的を射ていた。自分が選んだサイトの傾向を、かなり正確に読み取っている。残りの3割は「方向は合っているが、これではない」という微妙なずれだった。
そのずれに対して個別にコメントを返した。このサイトは余白の使い方が好きだが、フォントが軽すぎる。こっちは色のトーンがいいが、情報の密度が高すぎる。こういう粒度のフィードバックを返すと、次に探してくる候補のヒット率が上がった。
やっていることは、デザインの要件定義だ。ただし仕様書を書くのではなく、「好き・嫌い」の判断を繰り返すことで、言語化できなかった好みが設計に変換されていく。自分がやるのは見て、感じて、反応を返すこと。それだけだった。
要望が1分でブラウザに出る
感覚がすり合った段階で、Designerがモックの制作に入った。
最初に出てきたのは、トップページの全体像だった。白い背景に、薄い青のヒーローセクション。テキストは黒に近いグレー。見出しと本文でフォントが違う。参考サイトの議論で固まった方向性が、そのまま画面になっていた。
ここからの調整が速かった。「見出しの色をもう少し濃くしたい」と言えば、1分もしないうちに修正されたページがブラウザに表示される。「最初に目に入るセクションの背景を、もう少し青みがかった白にしたい」と言えば、すぐに反映される。
このスピードが何を変えるか。試行回数が上がる。従来なら「まあこれでいいか」と妥協していた部分を、「もう一案見たい」と言える。言えば出てくる。出てきたものを見て、また調整する。このサイクルが数十秒単位で回った。
納得するまで調整した後、サイトリニューアルの議論に参加した他のエージェントにもレビューを回した。前回の議論で決めた方向性と矛盾がないか。ターゲットに対して適切な印象を与えるか。デザインの好みだけでなく、戦略との整合性を複数の視点で確認した。
参考サイトの収集からここまで、2時間弱だった。
開発は10分で終わった
デザインが固まった後、開発の担当に仕様を渡した。ページの構成、色、フォント、レイアウト。モックで確認済みの内容をそのまま実装に移す作業だ。
テーマの骨格ができるまで、約10分。品質の確認まで含めてその時間だった。
その後の50分弱は、実際に動くサイトを見ながらの微調整に使った。モバイルで見たときのメニューの位置。画像のサイズ。フォームの接続。一つ確認して、一つ直す。途中で自分が「やっぱりここはこうしたい」と要望を変えた部分もあった。それも含めて50分だった。
合計3時間。見積もりの40時間に対して、10分の1以下で終わった。
時間の使い方が逆転した
3時間の内訳を振り返ると、配分が通常のサイト制作と逆転している。
普通、制作の大半はコーディングと実装に費やされる。デザインの議論は最初の打ち合わせで済ませて、残りは手を動かす時間だ。今回は逆だった。3時間のうち2時間がデザインの議論。開発は10分。調整が50分。時間の7割を「何を作るか」に使い、「作ること」自体はほとんど時間がかかっていない。
この配分は、おそらく正しい。サイトの出来を決めるのは、コードの量ではなく、設計の判断だ。どの色を使うか。余白をどれだけ取るか。最初に目に入る要素を何にするか。こうした判断一つ一つが、訪問者の印象を決める。そこに時間を使えたのは、実装のコストがほぼ消えたからだ。
前の記事で、チームメイトの見積もりが人間エンジニア基準だった話を書いた。もう一つ、見積もりが見落としていたことがある。デザインの言語化という、本来一番手間のかかる工程を、参考サイトの往復という方法で短縮できたことだ。言葉にできない好みを、好き嫌いの反復で伝える。この方法は、相手が何度でも即座に候補を出せるから成立する。
制作の本質は判断だった。判断以外の全てが加速したとき、残るのは「自分は何が好きで、何を作りたいのか」という問いだけだった。