2025-03 · Lead Product Designer

UX デザイン基盤

Funda の人主体「資料作成講座」を、AS IS / SHOULD BE 解体からアプリ体験へ翻訳した立ち上げ期の UX 設計。

アプリに置き換えると決まった瞬間、最初にやったのは画面を描くことではなく、人がやっていた体験を全部解体することだった。

スライドアカデミーの前身は、Funda で数年運営していた人主体の短期集中講座「資料作成講座」だった。Discord でコミュニケーション、Notion で教材、Zoom で勉強会という構成で、参加者のリアルな悩みも蓄積されていた。「いつでもどこでも学習できる学習アプリにしよう」という意思決定が降りてきたのが 2025 年 3 月。別プロジェクトと並行しながら、約 1 ヶ月でデザイン基盤を完成させる必要があった。

タイトな制約下で、まず決めたのは「何をやらないか」だった。

デザイン原則

画面化する前に、体験を解体する

最初にやるべきことは画面を描くことではなく、Funda で動いていた「人主体の体験」を要素分解することだった。Discord での質問のされ方、Notion で教材を読む流れ、Zoom 勉強会の盛り上がりポイント — 講座の体験は何枚もの薄い体験の積層でできている。これを画面構造に変換する前に、いったん完全に分解する必要があった。

そのうえで AS IS（人が運営していた体験）と SHOULD BE（アプリで再現したい体験）を並べて書き出した。「そのまま画面化する」のではなく「アプリならではの形で翻訳する」と決めた。例えば Zoom 勉強会のリアルタイム性は、アプリ内では「ライブ通知 + アーカイブ即時公開 + コメント」という別の形に置き換えた。

構造が見えるまで、絵を描かない

サイトマップ → タスクフロー → ユーザーフロー → ペルソナ → ワイヤー、の順で進めた。意識的にワイヤーを最後に置いた。絵から入るとその絵に引きずられて構造が歪むからだ。

サイトマップは Home / 勉強会 / 学習コンテンツ / トレーニング / 実践課題 / Q&A の 6 タブに整理した。タスクフローでは「新規登録」「オリエンテーション参加」「学習コンテンツ閲覧」「トレーニング挑戦」「課題提出」「Q&A 投稿」など、講座体験のすべてのタスクをユーザー視点で分解。ユーザーフローでは各タスクの分岐・エラー処理・終了条件まで降ろした。

ペルソナは 3 タイプを置いた。包括的にスキルアップしたい中堅営業マン（A）、情報設計を学びたい IT 企業 PM（B）、副業・フリーランス志向の資料作成スキル拡張層（C）。各画面で「誰のための機能か」を毎回確認するための土台になった。

ワイヤーフレームはこの 4 層が固まったあとで、初めて描いた。

やらないことを最初に決める

1 ヶ月という制約のもとで、何を捨てるかを最初に決めた。捨てたのは「世界観の構築」と「独自のビジュアル言語の整備」。アプリ体験が成立するかどうかも検証できていない段階で、ブランディングにリソースを大きく投下するのは順番が違うと判断した。

代わりに、Funda にすでに整っていたデザインスタイルをそのまま流用することにした。世界観を持たないシンプルな UI を前提に、まずは「体験が成立するか」だけを検証範囲にした。後から世界観を載せるほうが、検証なしで全部いっぺんに作るより速い。

どうやって進めたか

別プロジェクトと並行しながらの 1 ヶ月。各工程の所要時間を逆算して、AS IS / SHOULD BE 整理 → IA → タスクフロー → ユーザーフロー → ペルソナ → ワイヤー、の順序で配分した。PdM とエンジニアには各層が固まる節目で判断を見せて、巻き戻りを最小化する運用にした。

道具立てもシンプルにした。Figma で IA・フロー・ワイヤーを 1 ファイルにまとめ、ペルソナだけ別ファイルに切った。複雑なツール構成は組まなかった。これも「やらないことを最初に決める」の一部だった。

これから先

立ち上げ期の「世界観を持たない」判断は、半年後のリブランディングで意図通り効いた。アプリ体験が成立することを確認してから、2025-09 に「資料作成の Duolingo」というコンセプトに振り切って世界観を載せ直した。最初から世界観を作っていたら、振り切る判断はもっと遅くなっていた。

「やらない」を早く決めると、後から「やる」を強く決められる。