design trendsJune 27, 20268 min read

従来のデザインケーススタディは死にかけている

47画面の肥大化したケーススタディは、1セッションでリリースされた動くアプリに負けている。何が変わったのか、ポートフォリオはどうあるべきか、そして思考がまだ重要な理由。

By Boone
XLinkedIn
design case study is dying

肥大化したデザインケーススタディは死にかけている。ケーススタディそのものではない。

その区別がすべての主張だ。しっかり覚えておいてほしい。6週間分のプロセスドキュメントを含む47画面のデッキは、誰かが1セッションで作った動くプロダクトの3分間のLoomに、場を奪われつつある。採用担当者が10秒でライブURLをクリックできるとき、あなたのダブルダイヤモンドのウォークスルーは、彼らに宿題を課しているように感じさせ始める。

これは思考への死亡通知ではない。証明の場所が移ったという通知だ。成果物が議論そのものになり、成果物を説明するスライドデッキはオプションになりつつある。

デザイナーのTwitterを二分したスレッド

デザイナーの@andrewkが従来のケーススタディはもう時代遅れかと問うスレッドを投稿したとき、この議論は公になった。約9,800リポストと400件以上の返信を集め、デザイナーたちは真っ二つに分かれた。

その分裂こそがシグナルだ。半分はケーススタディが神聖な技芸だと主張した。もう半分は自分たちのライブデモを指差し、プロダクトがそこにあるのになぜデッキが必要なのかと問うた。

どちらも間違っていない。だからこそ広まった。この対立はデザイナーが考えるべきかどうかについてではない。リリースがほぼ無料になった今、その思考の証拠がどこにあるべきかについてだ。

実際に何が変わったのか(1セッション、本物の認証、本物の決済、当日リリース)

1回の長時間セッションで構築された完全なアプリを表示するCursor IDE。
1回の長時間セッションで構築された完全なアプリを表示するCursor IDE。

cursor.comでライブを見る

変わったのは、動く成果物のコストが崩壊したことだ。インディーデザイナーや創業者たちは今、認証、決済、リアルなデータフローを備えた完全に機能するアプリを、1回の長時間セッションで生成し当日リリースした状態で投稿している。

ツールがこれを急速に信頼できるものにした。Claude CodeやCursorでの長時間ビルドは、3ファイル目で崩壊する代わりに、セッション全体を通じてコヒーレントなプランを保てるようになった。Fable 5の長期的な信頼性と最近のCursorBenchでの勝利が、「ワンテイク」がデモの小技から火曜日の普通の作業のように聞こえるようになった理由だ。

だから計算式が逆転した。旧来のケーススタディが存在したのは、本物を作ることが高価で、遅くて、エンジニアリングの壁に阻まれていたからだ。プロセスを文書化したのは、実際に見せられる作業のほとんどがプロセスだったからだ。

今や本物を作ることは安くなった。その日のうちにライブURLを渡せるなら、どのように作ったかの静的な再構成は、すでに持っている証拠の劣化版として読まれてしまう。

旧来の成果物 vs 動く成果物(正直な比較表)

これを具体的にする比較がここにある。これはハイプではなく、各フォーマットがあなたを評価する人に実際に何をするかの違いだ。

評価軸旧来のケーススタディ成果物動く成果物
フォーマット30〜50枚の静的画面、ナレーション付きプロセスライブURLと短いウォークスルー
何を証明するかメソッドを説明できること動くものをリリースできること
評価にかかる時間8〜15分の読書クリックまで10秒、感じるまで3分
隠せるものそれが実際に機能したかどうかほぼ何も隠せない、動くか動かないかだ
よくある失敗プロセスシアター、実質より磨きスリークな表面の裏の薄い思考
レビュアーが覚えること雰囲気といくつかのスクリーンショットプロダクトが何かをした瞬間

「隠せるもの」の行を二度読んでほしい。静的なケーススタディは、そのデザインがリアルなデータ、リアルな状態、リアルなバックエンドとの接触を生き延びられなかったことを隠せる。動く成果物はそれを隠せない。レビュアーがその中に立っているからだ。

だから成果物は信頼において勝つ。動くものを偽造する方が、レンダリングされたものを偽造するより難しい。

肥大化したケーススタディデッキとライブの動く成果物を対比するボクセル図。
肥大化したケーススタディデッキとライブの動く成果物を対比するボクセル図。

ケーススタディは死んでいない、肥大化したものが死ぬのだ

正直な反論を述べよう。この見解の死亡通知版は怠慢だから。

ライブデモは表面が機能することを証明する。それだけでは、問題を理解したこと、トレードオフを検討したこと、3つの劣った選択肢よりこの形を選んだことを証明しない。間違った問題を解く美しいアプリは、より速くリリースされた間違った問題のままだ。

これが「ケーススタディは死んだ」の罠だ。人々はそれを聞いて、スライドの膨張と一緒に思考まで削除してしまう。それらは同じものではない。膨張とは、誰も求めていなかったペルソナの引用12枚とムードボードのことだ。思考とは、実際にプロダクトを形作った2つの決断のことだ。

だから動きは「作業の説明をやめる」ではない。「詰め物をやめる」だ。判断を残し、シアターを削れ。背後にストーリーのない動く成果物は「プロンプトで来ました」と読まれかねず、シニアポジションではそれは本物のリスクだ。

従来のデザインプロセスを置き換える合理化されたワンテイクパイプラインのボクセルイラスト。
従来のデザインプロセスを置き換える合理化されたワンテイクパイプラインのボクセルイラスト。

今ポートフォリオが証明しなければならないこと(センス、判断力、問題フレーミング)

リリースがほぼ無料になると、希少なのはアウトプットではない。ワンショットアプリが単独では証明できない3つのことだ。

センス。 誰でも及第点のインターフェースを生成できるとき、及第点と正解の差が仕事のすべてだ。センスとはモデルが代わりにやってくれない千の小さな決断だ。何を削るか、何を遅らせるか、どこに意図的に摩擦を加えるか。

判断力。 分岐点を見せろ。ボツにしたバージョンと、ボツにした理由を1文で見せろ。「Xを試したが、チェックアウトで信頼を損なったのでYにした」という一例は、分岐のない40枚スライドのナラティブより多くを証明する。

問題フレーミング。 デモは「作ったか」に答える。フレーミングは「これは存在すべきだったか、この形で」に答える。その問いこそシニアデザイナーがタイトルを稼ぐ場所であり、モデルが最も苦手とする部分だ。

これらのどれも50画面を必要としないことに気づいてほしい。動くものと、作る際に下した判断についての正直な数文が必要なだけだ。

今月ポートフォリオを再構築する方法(動くものを先頭に、短い決断ログを保持する)

最初のプロンプトからリリースされたアプリまでの完全なプロダクトビルドを示すCursorセッションログ。
最初のプロンプトからリリースされたアプリまでの完全なプロダクトビルドを示すCursorセッションログ。

cursor.comでライブを見る

持っているものを燃やすことなく、1ヶ月でこれを再構築できる。形はシンプルだ。成果物を先頭に、判断で裏付け、残りを削る。

  1. 動くものを先頭に。 すべてのプロジェクトの最初の画面は、クリックできるURLか60〜90秒のプロダクトの動作ウォークスルーだ。ヒーローショットではなく、実際のプロダクト。レビュアーは一言読む前に本物に触れるべきだ。

  2. 短い決断ログを保持する。 プロジェクトごとに3〜5の決断、それぞれ1行。決断、却下した代替案、理由。これがデモ単独では担えない判断の証拠だ。

  3. プロジェクトごとに分岐を1つ見せる。 リリースしなかったバージョンとその理由。これが、ただ生成していたのではなく考えていたことを証明する最速の方法だ。

  4. プロセスシアターを削る。 ペルソナスライド、使わなかったエンパシーマップ、ムードボード、「アイデエーション」画面を削除しろ。プロダクトを変えなかったなら、スペースを稼げない。

  5. リリース日を記載する。 「アイデアから1セッションでライブ」または「週末にリリース」は今や資格だ。2026年における実際の作業スピードで動けることを示すシグナルだ。

これが移行のすべてだ。成果物を先頭に、判断を5行で証明し、常に詰め物だったものを捨てる。

よくある質問

デザインケーススタディは完全に死んだのか?

いいえ。肥大化したプロセス重視のケーススタディがデフォルトとして死にかけているだけだ。それが証明しようとしたもの、考えてリリースできること、は今や動く成果物と短い決断ログの中により良く存在する。

説明なしで動くプロトタイプをただ投稿すればいいのか?

いいえ、これが最もよくある過剰修正だ。ストーリーのないデモは「プロンプトで来ました」と読まれ、シニアポジションでは不利になる。ライブ成果物と3〜5の1行決断と、却下した分岐を1つ組み合わせろ。

ワンショットアプリとは正確には何か?

Claude CodeやCursorのようなツールで1回の長時間セッションで構築され、当日リリースされた完全に機能するプロダクトで、多くの場合認証、決済、リアルなデータを備える。人間の判断はまだ関わっている。崩壊したのはアイデアから動くものまでの距離だ。

これはジュニアデザイナーが危機に瀕しているということか?

バーは「メソッドを説明できるか」から「リリースしてそれを守れるか」に移った。それは作れる人すべてを助ける、なぜならクリックできる成果物はデッキより正直だからだ。リスクは、プロセススライドの裏に薄い実質を隠したポートフォリオにある。

ケーススタディがなければ、どうやって思考を証明するのか?

思考を証明するのに長文のケーススタディは必要ない。短い決断ログを使え。下した判断、却下した選択肢、1文の理由。それを3〜5個、ライブ成果物の横に置けば、40画面のナラティブより多くの判断力を証明する。

ワンショットにできない複雑なエンタープライズやシステム作業はどうするのか?

その場合、成果物は異なるが原則は同じだ。動くスライスや機能するコンポーネントを見せ、決断ログを添付しろ。シフトは「本物でクリックできるものを先頭に」であり、「週末でSaaS全体を再構築しろ」ではない。

まとめ(成果物が議論だ)

成果物が今や議論そのものだ。動くものを渡せるとき、どのように作ったかを説明するデッキは、すでに持っている証拠の劣化コピーになる。

@andrewkのスレッドが約9,800リポストと400件以上の返信でデザイナーを二分したのは、両方の陣営が真実を守っていたからだ。一方は思考を守り、他方は証明を守った。解決策は、証明が動くものの中に移り、思考がその横の5行の正直な言葉に移ったことだ。

だからケーススタディを悼むな。肥大化したものを引退させ、判断を残し、動くものを先頭に立てろ。プロセスアウト、プロダクトイン。

2026年に部屋を制するデザイナーは、最も厚いデッキを持つ者ではない。「これをクリックして」と言い、その後5行で、それがなぜそういう形なのかを正確に説明できる者だ。

Want a portfolio that ships working product, not slide decks? Let's build it.

Get Started

More from Brainy Papers

Keep reading