ポートフォリオのUXを作り直した話 — モーダル・一覧・詳細ページの役割分担

ポートフォリオサイトを作り直すにあたって、見た目を新しくするだけではなく、どうすれば見に来た人が自然に情報をたどれるかをかなり考えた。

以前のサイトは、トップページを上から下までスクロールしていく、いわゆる縦長の1ページ構成だった。これはシンプルで分かりやすい一方で、下まで読んだらそこで終わりになりやすい。少し興味を持ってくれた人が、関連する研究や制作物をさらに見ていく導線が弱かった。

そこで今回は、ポートフォリオを「情報を並べたページ」ではなく、訪問者が自分の興味に応じて深さを選べるサイトとして設計し直した。

2種類の読者を分けて考える

最初に考えたのは、ポートフォリオを見に来る人が全員同じ深さで読みに来るわけではない、ということだった。

ざっと経歴や雰囲気だけを見たい人もいる。一方で、特定の研究や制作物に興味を持ち、背景・役割・工夫・実装まで読みたい人もいる。この2種類の読者を、便宜的に次のように分けて考えた。

A層：ざっと見たい人。ホームをスクロールするだけで概観が伝わればよい。
B層：深く知りたい人。詳細ページや関連ページを気持ちよく回遊できてほしい。

ここで大事なのは、どちらか一方に寄せるのではなく、A層とB層の動線を最初から分けておくことだった。

A層に対して、いきなり詳細ページへの遷移を強制すると重い。逆に、B層に対して、ホーム上のモーダルだけで情報を閉じてしまうと浅い。だから、ホームは概観、一覧ページは回遊の入口、詳細ページは深掘り、というように、ページごとの役割を分けることにした。

負荷の正体は「ページ遷移」ではなかった

最初は、ページ遷移そのものがユーザーにとって負荷なのではないかと思っていた。

そのため、詳細情報をどう見せるかについて、モーダル、右から出てくるスライドパネル、全画面オーバーレイなど、いろいろな「遷移しない見せ方」を検討していた。しかし考えていくうちに、これらは本質的にはかなり似ていると気づいた。

どれも、固定されたホームの上に一時的なレイヤーを重ねる構造である。開いて、閉じて、また別のものを開く。見た目は違っても、回遊という意味では同じ場所を行き来しているだけになりやすい。

ここで考え直した。

ユーザーが嫌なのは、本当に「ページが変わること」なのか。
むしろ嫌なのは、ページが変わった結果として、

自分がどこにいるのか分からなくなる
さっき見ていた文脈に戻れなくなる
白画面や待ち時間で流れが切れる
スクロール位置や現在地の感覚が失われる

ことではないか。

つまり、負荷の正体は「ページ遷移」そのものではなく、ページ遷移による文脈の喪失だった。

そう考えると、目標は「ページ遷移をなくすこと」ではない。
遷移しても文脈を切らさないこと、そして遷移の体感的なジャンクを減らすことが本質だった。

この整理ができたことで、独立したURLを持つ詳細ページを作ることに前向きになれた。ページを分けること自体は悪ではなく、むしろURLとして共有でき、一覧や関連リンクからたどれるという意味では、回遊のために必要な構造でもある。

モーダルは「回遊手段」ではなく「関門」にする

最終的に、ホーム上のカードを押したときは、いきなり詳細ページへ遷移させるのではなく、まずモーダルを開く形にした。

ただし、このモーダルは詳細ページの代わりではない。役割はあくまで、軽く覗き見するための関門である。

ホームを見ている人は、まだ「詳しく読む」と決めているわけではない。少し気になったカードを押して、概要だけ見て満足するかもしれない。その人をいきなり別ページへ飛ばすと、少し重い。

そこで、ホーム上のカードではまずモーダルを出す。モーダルには、本文の要約を長々と載せるのではなく、次のような「予告編」だけを置く。

何のプロジェクト・研究か
一番伝えたい成果や数字
使用技術
代表画像
「さらに詳しく」ボタン

ここで満足した人は閉じればいい。もっと知りたい人だけが、「さらに詳しく」を押して詳細ページへ進む。

重要なのは、モーダルと詳細ページに同じ文章を書かないことだと思っている。モーダルにページ冒頭の縮小版を書いてしまうと、詳細ページへ進んだ人が同じ情報をもう一度読むことになる。モーダルはフック、詳細ページは背景・過程・工夫・関連情報を書く場所、と役割を分ける必要がある。

一覧ページからは直接詳細へ進ませる

一方で、Projects一覧やResearch一覧では、カードを押したらモーダルを挟まずに直接詳細ページへ遷移するようにした。

同じカードでも、ホームにあるときと一覧ページにあるときでは、ユーザーの状態が違う。

ホームのユーザーは、まだざっと眺めている段階かもしれない。だからモーダルでワンクッション置く。
しかし一覧ページに来ているユーザーは、すでに「もう少し見よう」と思っている可能性が高い。そこでもう一度モーダルを挟むと、むしろ余計なクリックになる。

そのため、次のように動線を分けた。

ホームのカード：モーダルを開く
一覧ページのカード：詳細ページへ直接移動する

これにより、ライトに見たい人には軽さを残しつつ、深く見たい人には余計なステップを挟まないようにした。

独立ページを「孤児」にしない

詳細ページを作ると、別の問題が出てくる。
そのページが、サイト全体の中でどこに属しているのか分かりにくくなることだ。

以前のサイトでは、グローバルナビが #projects や #research のようにホーム内アンカーへ向いていた。1ページ構成ならそれでよいが、独立した詳細ページを作ると、そのナビゲーションでは現在地を示せない。

詳細ページを開いた瞬間に、「このページはProjectsの中なのか、Researchの中なのか」「一覧へ戻れるのか」「隣には何があるのか」が分からなくなる。これは回遊性としてかなり悪い。詳細ページが、地図のない島のようになってしまう。

そこで、構造を次のように整理した。

Home：厳選したハイライトを見せる場所
Projects / Research / Achievements の一覧ページ：全件を見られる入口
詳細ページ：背景・過程・工夫まで読む場所

それに合わせて、グローバルナビもホーム内アンカー中心ではなく、一覧ページへのリンクを基本にした。詳細ページにはパンくずを置き、ページ下部には前後ナビや一覧への導線を置いた。

たとえば、詳細ページでは次のように現在地が分かる。

Home > Projects > Portfolio Site

これだけでも、「自分はいまProjectsの中にいる」という感覚がかなり持ちやすくなる。

「もどる」の意味を流入元によって変える

詳細ページの下部には、「もどる」「一覧へ」「前後の項目へ」といった導線を置いた。ここで意外と難しかったのが、「もどる」という言葉の扱いだった。

ホームのモーダルから詳細ページに来た人にとって、自然な戻り先はホームの該当セクションである。たとえば、ホームのProjectsセクションでカードを開き、そこから詳細ページに進んだなら、「もどる」で /#projects に戻るのが直感的だと思う。

一方で、Projects一覧ページから詳細ページに来た人にとっては、戻り先は一覧ページである。この場合、「もどる」がホームへ飛んでしまうと違和感がある。

さらに、詳細ページ下部の「前へ」「次へ」から別の詳細ページに移動した場合、「もどる」と書かれているのに実際には前の詳細ページではなくホームへ飛ぶ、という状態も避けたい。

そこで、document.referrer を使って流入元を判定し、ボタンの文言と優先度を変えることにした。

ホームから来た場合：主ボタンを「もどる」にし、該当セクションのアンカーへ戻す
一覧ページから来た場合：「一覧へ」を主ボタンにし、ホームへのボタンは「ホームへ」にする
詳細ページ間を移動してきた場合：「もどる」ではなく「ホームへ」と表示する

細かい調整だが、ユーザーがボタンを押す前に期待する挙動と、実際の遷移先を一致させるためには必要だった。

細かい違和感を潰す

今回の改修では、派手な演出よりも、触っていて引っかかる細かい違和感を潰すことを重視した。

たとえば、モーダルを開いたときに背景のスクロールバーが消えると、ページ全体の横幅が変わり、コンテンツが少し右にずれることがある。これは一瞬でもかなり気になる。そこで、スクロールバーの幅を動的に測り、その分だけ body や固定ナビに padding-right を加えて補正した。

また、モーダルを開くときに背景のぼかしが急にかかると、画面がガクッと変わったように感じる。そのため、バックドロップは少し時間をかけてフェードインし、モーダル本体は少し遅れて表示するようにした。

一覧ページも、Projects / Research / Achievements で構造が似ているため、完全に同じ見た目にすると現在地が分かりにくい。そこで、Researchは青、Projectsは緑、Achievementsは金系の淡いグラデーションにして、統一感を保ちつつページごとの差を出した。

モバイルでは、ハンバーガーメニューを開いたらアイコンがバツに変わり、そのバツを押せば閉じられるようにした。ユーザーが自然に期待する挙動に合わせるためである。

また、YouTubeを埋め込んだモーダルでは、閉じた後も動画の音声が残り続ける問題があった。これは、モーダルを閉じるタイミングで中身のHTMLを空にし、iframe自体をDOMから消すことで止めるようにした。

どれも一つひとつは小さい。しかし、こういう細かい違和感が積み重なると、サイト全体の印象が落ちる。逆に言えば、違和感を一つずつ潰していくことが、UXを作る上でかなり大事だと感じた。

AIエージェントへの指示の出し方

今回の実装は、かなりの部分をAIコーディングエージェントと相談しながら進めた。ただ、単に「こういう機能を実装して」と投げたわけではない。

むしろ大事だったのは、自分が何に違和感を持っているのかを言語化して渡すことだった。

たとえば、回遊性の問題については、最初から「一覧ページを作って」とだけ指示したわけではない。まず、

独立ページを開いても、そのページがどこに所属しているのか、どうたどり着けるもので、他のページとはどういう位置関係なのかが全く見えない。回遊性としてはかなり悪い。

というように、問題の構造を説明した。その上で、

だから、一覧ページを作って、ホームには最近のものだけを出して、メニューは一覧ページへのリンクにする、みたいな工夫が必要かもしれない。ただし、これはあくまで例であって、この通りにすべきと言っているわけではない。

と伝えた。

この「あくまで例」という言い方はかなり重要だった。こちらが解決策を断定しすぎると、AIはその案をそのまま実装しようとする。しかし、問題と意図を渡しつつ、解決策には余白を残すと、AI側からよりよい整理や代替案が返ってくることがある。

また、AIの提案もそのまま受け入れるのではなく、一度原理に戻って疑うようにした。

たとえば、右から出てくるパネル案が出たときには、

右からパネルが滑り込むのと、モーダルウィンドウって、UX的に大差なくない？

と問い返した。これによって、「見た目の違い」ではなく、「それは本当に回遊性を改善しているのか」という論点に戻ることができた。

AIを、答えを出す装置としてではなく、設計を詰めるための壁打ち相手として使う。今回のUX改修では、その感覚がかなり大きかった。

まとめ

今回のポートフォリオ改修で意識したのは、派手な演出を増やすことではない。

大事にしたのは、次の3つだった。

軽く見たい人が、ホームだけで概観をつかめること
深く知りたい人が、一覧や詳細ページを自然に回遊できること
どのページにいても、現在地と次の行き先を見失わないこと

そのために、モーダル、一覧ページ、詳細ページ、パンくず、戻るボタン、モバイルメニューといった要素の役割を一つずつ整理した。

作ってみて感じたのは、UX設計は「どのコンポーネントを使うか」ではなく、ユーザーがどの状態で、何を期待していて、次にどこへ行きたいのかを考えることだということだった。

そしてAIエージェントに実装してもらうときも、最終的に効くのはプロンプトの技巧そのものではなく、こちら側の問題設定の解像度だった。
AIは設計思想を増幅する。だからこそ、何を作るかの前に、なぜそう作るのかを言語化しておくことが大事だと思っている。