なんとなくでUIをAIに実装させない
UI における、「描くデザイン」のコストは下がりました。shadcn のようなデフォルトデザインシステム、つまりコンポーネントとデザイントークンを包括的に扱えるライブラリが登場して成熟しています。その土台で AI エージェントが自由にプリコラージュすることで人の手を介さずにUIが実装されていきます。
エンジニアリングにおいて、プログラミングがアセンブリ言語からより高レイヤーな言語へ移り、プログラミング言語そのものも現代的に洗練されてきたように、UI 実装もまた抽象度の高いレイヤーへ移りつつあります。コーディング作業の一部が AI に置き換わっていくのと同じように、UI をどう作るべきかを定義することの比重が高まっています。
つまり、目的や導線、優先順位、判断基準を言語化する「考える作業」が、これからの UI 実装ではより重要になります。
一方で、AI に曖昧な指示を出すと、破綻していないだけの UI ができあがります。
- 「信頼感のある SaaS っぽい画面にして」
- 「モダンで使いやすく」
- 「いい感じのダッシュボードにして」
こうした指示でも、見た目として無難なものは作れます。しかし、無難であることは目的に適していることの同義ではありません。
見た目が整っていても、目的までの導線が分かりにくかったり、情報に適切な優先順位がついていなかったり、情報量に過不足があったりすれば、UI として十分に機能しているとは言えません。作り手の頭にはプロダクトの全体像が入っているため簡単に使えるように見えても、初めて触れるユーザーにとっては認知負荷が高い、ということも起こります。
では、その一歩先にある「機能する UI」は、どのように考え、作ればよいのでしょうか。本稿では、UI を描く技術ではなく、その前段にある、目的やユーザー行動を整理し、AI に渡せる形まで言語化するための考え方について整理していきます。
UIを実装する前に考えること
UI を実装させる前に、何を考えるべきでしょうか。完成した画面の見た目ではなく、まずユーザーの課題を理解し、それを UI でどのように解決するかを考える必要があります。
特に重要となる、導線・フィードバック・状態・優先順位について考えていきます。
導線設計
ユーザーがどのような課題を持ち、何を見て、どの操作を通じて目的を達成するのかを考えます。
画面上に必要な機能をすべて詰め込んだとしても、それだけではユーザーは次に何をすべきか判断できません。目的を達成するまでの操作を自然に導き、迷いを減らせることが、よい UI の重要な要素です。
導線設計では単に操作できる場所をわかりやすくするだけでなく、どのような順番で情報を見せて何を判断させるのか、それをもとにどの行動に進んでもらうかを考える必要があります。ユーザーが目的にたどり着くまでの流れを設計します。
PC やスマートフォンが十分に普及した現在では、ユーザーが身につけている操作の慣習をある程度前提にできます。たとえば、視覚的な強弱で情報の重要性を判別したり、ボタンは操作可能であること、スクロールやスワイプで続きや次のコンテンツがあることを期待したりします。
こうした既存の慣習を利用しながら、ユーザーが次の操作を自然に予測できるように情報と操作を配置します。すべてを一から説明するのではなく、ユーザーが期待する場所にその動作を配置して、どうすれば良いかが自然にわかるように設計する必要があります。
優先順位設計
すべて必要な情報であっても、ユーザーがそのタイミングで必要としている情報にはズレがあります。また、一度に理解できる情報量にも限りはあります。
そのため、1つの画面に存在する情報や操作を同じ強さで並べるのではなく、何から認識して欲しいか、何を補助するための情報として扱うかを考える必要があります。
例えば、サービスを初めて使うユーザーには概要や料金、メリットが重要でも、すでに利用しているユーザーには直近の状態や次に行う操作の方が重要です。同じ入り口であってもユーザーの状況によって重要度が異なります。
また、管理画面で「新規作成」が主要な操作であれば、そのボタンを最も認識しやすくし、「エクスポート」や「設定」のような補助的な操作は相対的に弱く見せます。
重要なのは、情報を単純に減らすことではありません。ユーザーがその時点で判断するために必要な情報を過不足なく提示して重要なものから認識できる状態をつくることです。
何を見せるかだけでなく、今は何を強く見せないかを決めることも優先順位設計に含まれます。
フィードバック・状態設計
ユーザーのインタラクションに適切なフィードバックを返すことも重要です。
例えば、送信ボタンをクリックしたらボタンは非活性で、送信中であることを示すべきです。送信が成功したら成功を、失敗したら失敗を、ユーザーに対して伝えてボタンの状態を切り替える必要があります。リンクをクリックした場合も、画面遷移や読み込みが進んでいることが分かる状態にしておく必要があります。
操作に対する反応が何もなければ、ユーザーは処理が実行されたのか判断できず、同じ操作を繰り返したり、不安を感じたりします。UI は単に操作を受け取るだけではなく、「いま何が起きているのか」「操作の結果どうなったのか」を継続的に伝える必要があります。
そのため、通常時の画面だけでなく、ローディング中、成功、失敗、操作不可といった状態まで含めて設計することが重要です。状態ごとにユーザーが次に何をすべきか判断できるようにすることも、UI の役割のひとつです。
考えを構造化して言語にする
「信頼感がある」「モダン」「使いやすい」といった言葉だけでは、破綻しないデザインを作ることはできても、ユーザーの課題をピンポイントで解決する UI を作るには不十分です。
もちろん、こうした感覚的な言葉そのものを否定する必要はありません。むしろ、デザインを考える出発点であり、最終的にユーザーが受け取る印象という意味では終着点にもなります。必要なのは、その感覚をそのまま扱うのではなく、「誰に」「なぜ」その印象を与えたいのか、その結果としてどのような行動につなげたいのかまで分解することです。
たとえば「赤を使う」という判断だけを見れば、赤は UI を構成する表現にすぎません。しかし、「危険な操作であることを認識させ、誤操作を防ぎたい」と考えれば表現と目的の間に理由が生まれます。
タイポグラフィや余白、角丸、コンポーネント配置についても同様です。「高級感を出したい」「未来的な印象を与えたい」という感覚があるなら、その印象を誰に与えたいのか、なぜ必要なのか、それによってどのような判断や行動を期待するのかまで考えます。
重要なのは、どのような表現にするかを細かく指定することではなく、何のためにその表現が必要なのかを言葉にすることです。具体的にどのタイポグラフィや余白、コンポーネントを使うかは AI に判断させるとしても、その判断に必要な前提は人間側で与える必要があります。
ユーザーの課題や事業上の目的から、期待する判断や行動を整理し、その理由を UI 表現へつなげていく。感覚的な言葉をそのまま AI に渡すのではなく、目的と表現の間にある理由を言語化することが重要です。
さいごに
AI によって UI を描くコストは下がりました。これまでよりも多くの人が、簡単に一定水準の UI を作れるようになっています。その中で、より重要になるのは「なぜこの UI なのか」を説明できることです。
描くデザインと考えるデザインのレイヤーを分けて捉えることで、どこまでを AI に任せられるのか、反対に人間はどこに注力すべきなのかも見えやすくなります。AI に UI を作ってもらうこと自体ではなく、その前提となる目的や判断基準を考え、出てきたものを評価できることが、これからの UI 実装では重要になると考えています。
この記事では、あえて「デザイン」全体ではなく、UI 実装に範囲を限定しました。デザインという言葉が指すものはあまりにも広く、その境界を明確に定義すること自体が難しいからです。
パスカルの著書であるパンセから一節引いて、自然をデザインに置き換えても成立するくらいの概念だと思っています。
自然とは、中心がどこにでもあり、円周がどこにもない無限の球体である
だからこそ今回はそのすべてを語ろうとせず、AI コーディングにおける UI 実装という限られた範囲から、「考えるデザイン」について整理しました。
