結論

UIの質は、最終的には次の式にかなり近いと思います。

UIの質
= 対象の捉え方の正しさ
× ユーザーの知覚への適合
× 認知モードへの適合
× 状態・操作・結果の一貫性
× 変化への耐性

一方で、実装コストはこう決まります。

実装コスト
= 知覚の多様性
× 状態の数
× 例外の数
× 品質保証すべき環境の数
× 変更頻度

共通化できている構造

つまり、UI開発が難しいのは「画面を作るから」ではありません。

本当には、人間が世界をどう知覚し、何を一つの対象として扱い、どんな状態変化を起こし、その結果をどう理解するか

を、コード・データ・UI・権限・履歴・AI処理に落とし込む必要があるからです。

ここを曖昧にしたまま画面だけを作ると、途中までは動いているように見えても、最後に破綻します。

あなたの言葉でいうなら、良いUI開発は「UIを作ること」ではなく、対象を知覚可能な単位として捉え、その単位を動く構造に接続し、人ごとの知覚に応じて投影すること

に近いです。

これが、PDD、つまり Perception Driven Development の核心だと思います。

1. UIの質は何で決まるのか

1.1 UIの質は「見た目」ではなく「対象の扱いやすさ」で決まる

UIの質というと、普通は次のようなものを想像しがちです。

• 見た目がきれい
• 配色が整っている
• 余白が気持ちいい
• アニメーションが滑らか
• コンポーネントが統一されている

もちろんこれらも重要です。

ただ、それらはUIの質の中心ではありません。

中心にあるのは、

ユーザーが対象を正しく捉えられるか

です。

たとえばToDoアプリなら、単に「タスク一覧」が見えていればよいわけではありません。

高齢者にとってのToDoは「今日忘れないための安心装置」かもしれない。子供にとってのToDoは「約束や宿題を思い出すためのもの」かもしれない。チームにとってのToDoは「責任の所在と詰まりを共有するもの」かもしれない。

同じ Todo というデータ構造でも、人によって知覚している対象が違う。

だから、良いUIとは「同じデータを表示するもの」ではなく、

その人が対象を扱える形に変換するもの

です。

1.3 良いUIは「認知モード」に合っている

ここまでの議論でかなり重要だったのは、UIパターンは実はそこまで多くない、という話です。

ただし、少ないのは「見た目の種類」ではなく、人間の認知モードです。

大きく分けると、たとえばこうです。

多くのUIがつらくなるのは、この認知モードが混ざるからです。

たとえば巨大フォームがつらいのは、UIとしては「線形完遂」を強制しているのに、ユーザーは実際には「探索編集」をしたいからです。

設定画面がつらいのも同じです。

ユーザーは「全体を見て、気になるところだけ直したい」のに、画面が「全部を順番に読め」という構造になっている。

逆に、申請やチェックアウトや問診のような場面では、探索性より完遂性が大事です。

この場合は、自由に飛び回れるUIより、一本道で抜け漏れなく進めるUIのほうがよい。

つまり、UIの質はコンポーネント選びでは決まりません。

今ユーザーはどの認知モードにいるのか

に合っているかで決まります。

1.4 情報量の問題は「密度」と「圧縮率」の問題である

情報量が多い画面と少ない画面で、毎回レイアウトを個別調整したくなる。

これはかなり自然です。

ただ、本質的には「情報量が多いから難しい」のではありません。

難しいのは、

情報量の変化に対して、UIの圧縮ルールがないこと

です。

情報量が少ないときはカードでよい。多いときは表にしたい。さらに多いとフィルタや検索や詳細ペインが必要になる。編集が入るとフォームやインライン編集が必要になる。

これを毎回画面ごとに考えると、実装も設計も破綻します。

本当は、次のような軸で扱いたい。

つまり、良いUIは「情報を全部見せる」のではなく、

その場に必要な圧縮率で情報を見せる

ものです。

この意味で、レスポンシブデザインも本当は画面幅対応ではありません。

状況に応じた情報圧縮

です。

1.5 良いUIは「状態・操作・結果」が一貫している

UIの品質を大きく左右するのが、状態です。

ボタン一つでも、実際には多くの状態があります。

• 通常
• hover
• focus
• active
• disabled
• loading
• success
• error
• permission denied
• optimistic update
• retry

UIが複雑になる理由は、見た目の数ではなく状態の数です。

React公式ドキュメントでも、アプリが大きくなるほど状態の構造とデータフローを意図的に設計する必要があり、重複した状態はバグの原因になりやすいと説明されています。

良いUIでは、ユーザーがこう理解できます。

今、何が起きているのか

自分は何を操作できるのか

操作すると何が変わるのか

結果はどこに反映されたのか

失敗した場合にどう戻れるのか

ここが弱いUIは、見た目がきれいでも使いづらい。

逆に、見た目が素朴でも、状態と操作と結果の対応が明快なUIは強いです。

1.6 アクセシビリティは「追加品質」ではなくUI品質の中心である

UIの質を考えるとき、アクセシビリティは別枠ではありません。

アクセシビリティとは、単に障害のある人に対応することではなく、

異なる身体、認知、環境、年齢、状況でも対象を扱えるようにすること

です。

これはあなたのPDDの考え方ともかなり近いです。

つまり、

同じ対象でも、人によって知覚の仕方が違う

という前提に立つなら、アクセシビリティは後付け対応ではなく、最初から設計原理になります。

1.5 UIとは何を指すのか。

UIは「人間とシステムの境界面」である

UIは、単なる画面ではありません。

UIは、

人間の知覚

行動

判断

不安

記憶

注意

と、

データ

状態

処理

権限

履歴

通信

の境界面です。

この境界面がうまく設計されていると、ユーザーは自然に対象を扱えます。

逆に、境界面が悪いと、システムとしては正しくても、人間にとっては意味不明になります。

たとえば会計データが正しくても、経営者が「今どこまで使っていいのか」を判断できなければ、そのUIは目的に対して不十分です。

業務フローが保存されていても、現場の人が「次に何を見て、どこを判断し、何を残せばよいか」を理解できなければ、それは実行可能な構造になっていません。

UIの質は、データの正しさだけでは決まりません。

その人が判断可能になるかで決まります。

少なくとも三つの目的層がある

UIという言葉は、実際にはかなり異なるものを同時に指しています。

例えば、次のようなものは全て「UI」と呼ばれます。

• 何を一つの対象として認識できるか
• どこを押せると感じるか
• 何が編集可能だと理解できるか
• どういう順番で操作すればよいか
• どこに注意を向ければよいか
• 情報がどうまとまって見えるか

一方で、同じUIという言葉の中には、

• ぬるっとしたアニメーション
• 余白
• 色
• タイポグラフィ
• hover
• transition
• shadow
• micro interaction

のようなものも含まれています。

これらはどちらもUIです。

しかし、同じ層の問題ではありません。

ここを分けて考えることは、UIを理解する上でかなり重要です。

1.認識形成（Perceptual Framing）

一つ目の層は、

「これは何なのか」

「どういう世界なのか」

「何が起きているのか」

を理解させる層です。

これは単なる見た目ではありません。

より根本的には、

• 何が一つの対象として見えるか
• どこまでがまとまりとして感じられるか
• どの操作が可能だと理解できるか
• どの順番で行動すべきか
• 何が危険で、何が安全か
• 何が保存され、何が一時状態か
• 今どの状態にいるのか

といった、対象理解と世界理解の問題です。

ここでは、構造や表示そのものが、人間の認識を形成しています。

例えば、動いているエスカレーターは、

「これは乗ると運ばれるもの」

という認識を先に形成しています。

だから人は自然に足を預けます。

一方、止まっているエスカレーターは、階段として知覚されやすく、同じ構造でも身体の反応が変わります。

これは「操作説明不足」ではありません。

階段に見えているため、対象認識そのものが違う。

UIでも同じです。

• 保存済みなのか
• 一時入力なのか
• 編集可能なのか
• 比較する画面なのか
• 承認する画面なのか
• 探索する画面なのか

によって、人はまったく違う世界として知覚します。

PDDが扱おうとしているのは、まずこの層です。

2.行動誘導（Behavioral Guidance）

二つ目の層は、「次に何をすればよいか」を自然に導く層です。

ここでは、

• affordance
• hierarchy
• CTA
• focus
• hover
• cursor
• feedback
• animation

などが重要になります。

例えば、

• 押せそう
• 編集できそう
• 開けそう
• 次へ進めそう
• ドラッグできそう

といった、行動可能性を感じさせること。

つまりこれは、どう行動すればよいかを設計する層です。

エスカレーターで言えば、

• 黄色ライン
• 手すり
• ステップ形状
• 流れ方向

などは、身体に対して「どう動けばよいか」を教えています。

3.操作触感（Operational Feeling）

三つ目の層は、「操作した時にどう感じるか」です。

例えば、

• 気持ちいい
• 軽い
• 重い
• 怖い
• 安心する
• 緊張する
• 急かされる
• 疲れる
• 信頼できる
• 高級感がある

といったものです。

これは、

• animation
• easing
• latency
• spacing
• typography
• color
• sound
• haptic
• transition timing

などによって作られます。

ここは、身体感覚としてのUIに近い。

例えば銀行UIは、構造も操作も理解できるが、怖いことがあります。

逆にNotionは、自由に触ってよいという触感をかなり強く持っています。

これは意味理解ではなく、操作触感の問題です。

三つは別だが、相互に影響する

重要なのは、この三つは別物だが、完全には分離できないということです。

例えばhoverは、

• 押せることを伝える
• 注意を向けさせる
• 軽さや気持ちよさを作る

を同時に行っています。

つまり、

認識形成

行動誘導

操作触感

は相互に支え合っている。

ただし、分けて考えることで、UIの問題をかなり整理できます。

例えば、

となります。

現代UIは「操作触感」に偏ることがある

近年のUIデザインでは、

• 美しいmotion
• 滑らかなtransition
• 洗練された余白
• micro interaction
• ガラス風表現

のような、

触り心地

への注目が強くなることがあります。

もちろんこれは重要です。

しかし、それだけでは、

人が対象をどう理解しているか

までは扱えません。

そのため、

触り心地は良いが、

何をどう扱えばよいかわからないUI

が生まれることがあります。

逆に業務システムでは、

構造だけが強く、

身体負荷が高い

ことがある。

つまり、本来のUI設計は、

認識形成

+

行動誘導

+

操作触感

を同時に扱う必要があります。

2. 実装コストは何で決まるのか

実装コストは「画面数」ではなく「差分の数」で決まる

実装コストは、単純に画面数で決まるわけではありません。

本当に効くのは差分です。

誰にとって

どの対象を

どの認知モードで

どの状態まで

どの環境で

どの品質で

扱えるようにするか

この差分が増えるほど、コストが増えます。

たとえば同じ一覧画面でも、次の違いがあるだけで別物になります。

• 閲覧だけか、編集もするか
• 少量データか、大量データか
• 比較が必要か、詳細確認が必要か
• 権限によって見えるものが変わるか
• 履歴や監査ログが必要か
• モバイルでも同等に使う必要があるか
• AIが同じ構造を読める必要があるか

つまり、実装コストは「UIの量」ではなく、

状態空間の広さ

で決まります。

コストを増やす最大要因は「曖昧な単位」である

もっとも危険なのは、対象の単位が曖昧なまま実装することです。

• 何を一つの単位として扱うのか
• 何が状態なのか
• 何が一時的な入力なのか
• 何を保存すべきなのか
• 操作によって何が変化するのか
• 履歴として残すべきものは何か
• 権限の対象はどこか

ここが曖昧だと、UIは途中までは動きます。

しかし、後から必ず破綻します。

たとえば「申請」という対象が曖昧なまま実装すると、後からこうなります。

• 下書きとは何か
• 提出済みとは何か
• 差し戻しとは何か
• 承認後に編集できるのか
• 誰がどの時点で見られるのか
• 履歴はどの粒度で残すのか
• AIが代筆した場合、責任はどこにあるのか

こうした問いに答えずに画面だけ作ると、あとで条件分岐が爆発します。

だから、実装コストを下げる最初の仕事は、コンポーネントを増やすことではありません。

対象の境界を決めることです。

レスポンシブ対応のコストは「画面幅」ではなく「文脈差」で決まる

レスポンシブ対応がつらい理由も、単にCSSが難しいからではありません。

本当には、

同じUIが置かれる文脈が増えすぎる

からです。

• PCのメイン領域
• スマホ
• サイドバー
• モーダル
• 埋め込み
• 分割ビュー
• 高齢者向け大きめ表示
• アクセシビリティ拡大
• 多言語
• 入力中のキーボード表示

これらを全部、画面ごとのmedia queryで調整すると破綻します。

そこで近年は、viewportではなくコンポーネントが置かれた親コンテナのサイズに応じてスタイルを変えるcontainer queryが重要になっています。

これは単なるCSS機能ではなく、考え方の変化です。

ページ単位の調整

↓

コンポーネント単位の自己適応

へ移っている。

つまり、実装コストを下げる方向は、「全画面を個別に調整する」ことではなく、

置かれた文脈に応じて自然に縮退する部品を作ること

です。

実装コストを下げるには「UI」ではなく「ルール」を作る必要がある

コストを下げるために必要なのは、単にコンポーネントライブラリを作ることではありません。

必要なのは、次のようなルールです。

強いチームは、毎回画面を頑張って作っているのではなく、

画面が自然に生成・調整される制約

を作っています。

3. これまで社会は何をしてきたのか

3.1 第一段階: HTMLとCSSで文書を画面化した

最初のWebは、基本的には文書の世界でした。

HTMLは文書構造を表すために非常に強い。

• 見出し
• 段落
• リンク
• リスト
• フォーム
• 表

これらは今でもWebの基盤です。

ただ、現代の多くのWebアプリは文書ではありません。

• 業務システム
• ダッシュボード
• 共同編集
• デザインツール
• チャット
• 動画編集
• 会計
• AIエージェント操作

つまり、文書システムの上でアプリケーション、場合によってはOSに近いものを作っている。

ここに大きな無理がある。

3.2 第二段階: コンポーネント化した

その後、ReactやVueやSvelteのようなコンポーネント指向が広がりました。

これは大きな進歩でした。

画面をHTMLファイルとしてではなく、

状態からUIを生成する部品の集合

として扱えるようになったからです。

ただし、React的なコンポーネント化でも、まだ多くの場合は低レベルです。

実際にはまだ、

• Card
• Table
• Modal
• Form
• Button
• Tabs

のような見た目・UI部品中心の抽象化です。

これは必要ですが、それだけでは「なぜこのUIなのか」までは扱えません。

本当はその手前に、

• 探索する
• 比較する
• 完遂する
• 承認する
• 思考する
• 監視する
• 共有する
• 安心させる

といった、人間の行為や認知モードの抽象化が必要になります。

3.3 第三段階: デザインシステム化した

次に、多くの組織がデザインシステムへ向かいました。

デザインシステムは、色やボタンの統一だけではありません。

本質的には、

UI判断を毎回やらなくて済むようにする仕組み

です。

• spacing
• typography
• color
• elevation
• component
• pattern
• guideline
• accessibility
• motion
• content tone

これらを共通化することで、実装コストと品質ばらつきを下げる。

ただし、デザインシステムにも限界があります。

多くのデザインシステムは、

見た目の一貫性

には強いが、

対象の知覚差

にはまだ弱い。

つまり、高齢者にとってのToDo、子供にとってのToDo、専門職にとってのToDoをどう分岐させるかまでは扱いきれない。

3.4 第四段階: CMS化・ノーコード化・ローコード化した

次に起きたのが、CMS化、ノーコード、ローコードです。

これは「コードを書かない」という話だけではありません。

より本質的には、

UIや業務構造を編集可能なものにする

という流れです。

WordPress、Webflow、Framer、Notion、Airtable、Retool、kintone、Shopify、Contentful、Sanityなどは、それぞれ違う領域で「コードを書く前の構造編集」を可能にしてきました。

ただし、ここにも限界があります。

多くのノーコード・ローコードは、

作れる人を増やす

ことには成功しました。

しかし、

良いものを作れる人を大きく増やす

ところではまだ不十分です。

なぜなら、良いものを作るには、画面を配置する能力だけでは足りないからです。

対象の単位、状態、操作、履歴、権限、知覚差を捉える必要がある。

3.5 第五段階: AIによる生成が始まった

現在は、AIによってコードやUIを生成する流れが急速に進んでいます。

自然言語で仕様を伝え、AIがコード、画面、データ構造、テスト、ドキュメントを補助する。

これは大きな変化です。

ただし、AI生成にも同じ限界があります。

AIは「それっぽい画面」や「動くコード」は作れる。

しかし、ユーザーが対象をどう知覚しているか、何を状態として扱うべきか、どの操作を保存すべきか、どの履歴が必要か、誰にとってそのUIが自然なのか、という部分が曖昧なままだと、AIも曖昧なものを生成します。

つまり、AI時代に重要になるのは、プロンプトの上手さだけではありません。

対象を構造化して知覚可能にする力

です。

4. 社会はどこへ向かっているのか

「画面を作る」から「構造を投影する」へ

社会全体の流れを一言でいうと、

画面を作る

↓

コンポーネントを組む

↓

構造を編集する

↓

知覚に応じて投影する

へ進んでいます。

昔はHTMLを書いていました。

次にReactコンポーネントを書きました。

次にデザインシステムやCMSやノーコードで、画面を構成可能にしました。

そして今後は、より上位のものを扱うようになるはずです。

それは、

対象

状態

操作

関係

権限

履歴

判断

知覚

です。

つまり、UIは完成物ではなく、

安定した構造から生成される投影

になっていく。

「一つのUIを全員に使わせる」から「知覚ごとにUIを分ける」へ

これまでのプロダクト開発では、多くの場合、一つのプロダクトに一つの主要UIがありました。

しかし、あなたが書いていた通り、一つのUIは必ず誰かを選別します。

専門職にとって効率的なUIは、高齢者には厳しいかもしれない。

子供にとって安心できるUIは、業務担当者には遅すぎるかもしれない。

経営者が見たいお金の流れと、会計担当者が見たいお金の流れは違う。

現場が必要とする業務手順と、AIが処理する構造も違う。

だから今後の方向は、

一つの安定した構造

+

複数の知覚に合わせたUI

です。

あなたの言葉でいえば、Holon Frameが扱おうとしているのはまさにここです。

同じデータ構造や通信を保ちながら、高齢者向けUI、子供向けUI、専門職向けUI、管理者向けUI、AI向け構造を分ける。

これは単なる着せ替えではありません。

同じ対象を、異なる知覚に合わせて再投影する

ことです。

4.3 「UIコンポーネント」から「認知操作プリミティブ」へ

今後のUI開発では、Card、Table、Form、Modalのような部品だけでは足りなくなります。

それらは低レイヤーの部品です。

より上位には、次のようなプリミティブが必要になる。

これらは、UIコンポーネントではありません。

人間の行為の単位です。

この単位からUIを生成・選択できるようになると、実装コストは大きく下がります。

なぜなら、画面ごとに考える必要が減るからです。

4.4 「人間だけのUI」から「人間とAIが共有する構造」へ

今後は、UIは人間のためだけのものではなくなります。

AIが処理できる構造も必要になります。

たとえばHolon Worksで書かれていたように、業務では次のようなことが重要になります。

• 何を見るのか
• 何を入力するのか
• どう判断するのか
• どう計算するのか
• 何を成果物として残すのか
• どこで人間が判断するのか
• どこをAIに任せるのか
• どの履歴を残すのか

これは単なるUIではありません。

人間とAIが同じ業務プロセスを再現するための実行構造

です。

今後の強いプロダクトは、見た目のUIだけでなく、この実行構造を持つはずです。

5. なぜ「良いものを作ること」は民主化しきらないのか

5.1 画面生成が民主化しても、対象把握は民主化しない

AIやノーコードによって、画面を作ることはかなり民主化されます。

すでに、簡単なLP、フォーム、管理画面、ToDoアプリ、社内ツールはかなり作りやすくなっています。

しかし、良いものを作ることは別です。

なぜなら、良いものを作るには、次の力が必要だからです。

• 対象を命名する力
• 境界を決める力
• 状態を見抜く力
• 操作と結果を対応づける力
• 人による知覚差を想像する力
• 例外を構造化する力
• どこを保存し、どこを一時入力にするか決める力
• 人間とAIの分担を決める力
• 変更に耐える構造を作る力

これは、単なる実装スキルではありません。

かなり根源的には、

世界を分節する力

です。

ここが民主化されない限り、良いものづくりは民主化しません。

5.2 UIの民主化が途中で止まる理由

良いUIづくりが民主化しきらない理由は、主に三つあります。

1. 人は対象をうまく言語化できない

多くの場合、ユーザーも作り手も、自分が扱いたい対象を明確に言語化できません。

「在庫管理したい」 「タスク管理したい」 「お金を見える化したい」 「業務を効率化したい」

と言うことはできる。

しかし、その中にある本当の単位は曖昧です。

• 在庫とは何か
• 発注判断とは何か
• タスクとは何か
• 完了とは何か
• 売上とは何か
• 使っていいお金とは何か
• 業務が終わったとは何か

ここが曖昧なままUIを作ると、最後に破綻します。

2. 生成ツールは「見えているもの」を作りがち

ノーコードやAIは、ユーザーが言語化したものを作ります。

しかし、ユーザーが言語化できていない構造は作れません。

そのため、生成ツールはしばしば、

それっぽい画面

を作ります。

でも本当に必要なのは、

その人が対象を扱える構造

です。

この差は大きい。

3. 良いUIには「削る判断」が必要

良いUIは、機能を増やせばできるものではありません。

むしろ、多くの場合は削る必要があります。

• 何を見せないか
• 何を後回しにするか
• 何を自動化するか
• 何を一本道にするか
• 何を自由にするか
• どの知覚を優先するか
• 誰を対象外にするか

これは価値判断です。

ツールが自動で決めにくい。

だから、良いものづくりは完全には自動化されにくい。

5.3 民主化に必要なのは「生成」ではなく「知覚の足場」である

良いものづくりを本当に民主化するには、画面生成ツールだけでは足りません。

必要なのは、

対象を捉えるための足場

です。

たとえば、作り手が次の問いに自然に答えられる必要があります。

この問いに答えられるようにすることが、本当の民主化です。

6. PDDは何を言っているのか

PDDは「知覚をものづくりの出発点にする」考え方である

PDD、Perception Driven Development は、かなり端的に言えばこうです。

ものづくりを、技術・画面・DBから始めるのではなく、対象が誰にどう知覚されるかから始める

DDDはドメインモデルを中心にします。

それは非常に重要です。

ただし、PDDはさらに手前を見ている。

同じドメインでも、見る人によって知覚が違う。

同じお金の流れでも、会計担当者、創業者、現場責任者、AIでは見ているものが違う。

同じ業務でも、マネージャー、作業者、AI、顧客では必要な構造が違う。

だからPDDは、ドメインそのものではなく、そのドメインを誰がどう見るのかを出発点にします。

7. 最終的に、良いものづくりはどう変わるのか

開発者の役割は「画面実装者」から「構造設計者」へ移る

今後、単純な画面実装の価値は相対的に下がります。

AIやノーコードが、一定のUIやコードを作れるようになるからです。

しかし、開発者や設計者の価値がなくなるわけではありません。

むしろ、より上流に移ります。

これから重要になるのは、

何を対象として扱うか

どの状態を持たせるか

どの操作を許すか

どの履歴を残すか

誰の知覚に合わせるか

AIにどこを任せるか

を設計することです。

つまり、開発者は「画面を作る人」から、

人間とシステムの間にある意味構造を設計する人

になっていく。

ユーザーの役割も「使う人」から「構造を編集する人」へ移る

ユーザーも変わります。

従来のユーザーは、完成されたUIを使う人でした。

しかし今後は、ユーザー自身が業務構造や情報構造を編集するようになります。

Notion、Airtable、kintone、Retool、Webflow、Framer、AIエージェントなどはすでにその方向にあります。

ただし、ここで必要なのは、自由な編集権限だけではありません。

自由すぎると、すぐに壊れます。

必要なのは、

制約付き編集可能性

です。

Notionが強いのは、何でもできそうに見えて、実際には block という強い制約があるからです。

Holon的にも、おそらく重要なのはここです。

ユーザーに完全な自由を与えるのではなく、

対象を扱える単位に分け、

安全に構造化できる編集環境を与える

こと。

「良いものを作る民主化」は、UI生成ではなくPDDの民主化で起きる

最終的に、良いものをみんなが作れるようになるには、単にAIがコードを書けるだけでは足りません。

必要なのは、PDD的な思考がツールに埋め込まれることです。

つまり、ユーザーが自然に次の順で考えられるようにする。

誰にとっての対象か

↓

どう知覚されているか

↓

何を一単位とするか

↓

何が状態か

↓

何が操作か

↓

どの認知モードで使うか

↓

どんなUIに投影するか

↓

どの構造を保存するか

↓

AIや外部SaaSとどう接続するか

この流れが支援されると、ものづくりはかなり民主化します。

ただし、それでも完全には自動化されません。

なぜなら、最終的には人間が、

何を大事にするか

誰に合わせるか

何を削るか

どの知覚を優先するか

を決める必要があるからです。

8. まとめ

UIの質は、見た目の美しさだけで決まりません。

これまで社会は、HTML、コンポーネント、デザインシステム、CMS、ノーコード、AI生成へと進んできました。

しかし、その多くはまだ「画面を作りやすくする」方向でした。

これから必要になるのは、対象を知覚可能な単位として捉え、その単位を安定した構造に接続し、人や状況ごとにUIとして投影する方向です。

良いものづくりが民主化しきらない理由は、実装が難しいからだけではありません。

もっと手前で、人が対象を自分の言葉で捉えられていないからです。

だから本当に民主化すべきなのは、コードを書く力だけではなく、世界を分節し、名前を与え、状態と操作に落とし、知覚ごとに扱える形へ変換する力です。

そこまで支援できたとき、UI開発は「画面づくり」ではなくなります。

それは、人間が世界を扱えるようにするための構造設計になります。

あとがき

最終的な実装はAIとやるより、良いGUIプラットフォームと解像度がある人間の方が全然強そう

デザインシステムなりdb1こで100個の事業と1000uiつくりたおす前提でちまちま積み上げてるけど級数的に実装コスト下がっていきそうな感じする。

1. 本人の持つ着想や視点の深掘りと構造化
2. 本人や顧客の解像度の深掘りと構造化
3. 体験への仮説の具体化
4. 試作品をみてさらに欲しいプロダクトを言語化する
5. バックエンドや演算やファイル処理をロジックの言葉をコードに変換する

ここらへんはAI超活躍しそうというかめちゃめちゃ使うけど、アプリそのものの実装は整備された制約とGUIで自分で作る方が早いし意図通りに動くっていう世界観の方が正しい気がするなー。

グラフィックデザイナーの延長にも、AI開発の延長にも作り切れるUIデザイナーはいなさそう。

そもそもの成果構造を特定するスキルは描画ではない。

バナー職人がマーケ出来ないのと似てる。

webプロダクトがまだ飽和してないってのと、UIの質ではなくて会社の資産や運用機能やバックエンドを顧客は買ってるプロダクトしか日本にはほぼない。ってのもあって描画されてて動けばいい。ってのは、そうだけど。

その時代が終わるから、なんだろうな。お皿とか家とかと同じように使い勝手の良いプロダクトに辿り着いた人に客がつくドメインがどんどん増える気がする。

その活動な伴奏者はバイブコーダーでもバイブコーディングでもなさそう。

自然言語処理AIが、人間の目と手よりも本人が感じる知覚を把握できて当てれる世界観がきたら、そこもいけそうだけど、LLMはそういう道具ではない。

派生

DBとかスキームの設計も構図がこれとすごい似てるんだよなー。

まあ作ってみれたからこそ触ってもらえるから、最終的に機能するプロダクトに辿り着く確率は今でも確実に数倍上がっている気はするんだけど、0.1%が0.5%になった感じというか。

この手の触るほどに構造違和感と修理したくなる専光がtinkerさんなんだなー。社会とか価値じゃなくて気持ち悪いから泣かせるようにしたい。って感じ。