Kaiir Elam 照片頁變乾淨檔案

我把 On3 的 Kaiir Elam 照片頁拆成一個可重用的球員圖庫檔案模板。

我盯這種球員頁很久了，越看越火大。它表面上是照片頁，實際上卻把招募資訊、排名、NIL、站內導覽全塞進來，最後照片反而像配角。我想看的只是球員本人、幾張圖、還有一點點上下文，結果整頁像資料庫硬塞進內容頁，什麼都給你，什麼都不乾淨。

這種頁面最煩的地方就是它不是不能用，而是太像「平台自我介紹」。你明明只是想快速確認這個人長什麼樣、在哪個學校、是什麼位置，頁面卻一直把你拉去看別的東西。我看 On3 的 Kaiir Elam photos 時，腦中一直在想：如果我要重做一個球員圖庫頁，我絕對不會把這些東西混成一鍋。

所以我把它當成模板來拆。重點不是 Kaiir Elam 本人多紅，而是這種頁面怎麼把「身份資訊」和「媒體內容」排在一起。這件事如果沒想清楚，球員頁就會變成一個很吵的卡片牆；如果想清楚，頁面就會很乾淨，讀者一眼知道自己在看什麼。

我用的原始來源是 On3，球員背景脈絡也能從它的 Rivals 區 和 database 看到。我不打算把它吹成什麼高明設計，我只是把它拆開，告訴你哪些部分值得抄，哪些部分最好直接丟掉。

這頁其實是三種頁面硬擠在一起

Rivals / Kaiir Elam / Photos

白話翻譯就是：它同時想當圖庫、球員檔案、站內入口。這就是為什麼你會覺得頁面不算亂，但就是不順。照片本身只是內容核心，周邊那些導覽和資料欄位，卻把整體重量拉得很大。

我以前幫一個學校體育網站整理相簿頁，也踩過同樣的坑。照片沒問題，問題是我一口氣加了排名、年級、地點、相關文章，結果那頁看起來像一份招募簡報，不像圖庫。使用者不是不能看，而是看起來很累。這就是模板設計最常犯的錯：把多個目的塞進同一個容器。

On3 這頁的問題不是資訊不夠，而是資訊沒有分層。身份摘要、圖庫、站內導覽、廣告骨架全在同一個視覺平面上，讀者得自己猜哪個最重要。這種頁面在資料庫產品裡很常見，因為產品團隊總想把所有訊號都放上去，結果頁面變成一個資料展示機器。

實操上，我會把這類頁面切成三層：第一層是身份，第二層是媒體，第三層是脈絡。身份只回答「這是誰」；媒體只回答「圖在哪」；脈絡才放排名、招募、相關連結。你只要把這三層分開，頁面就會立刻安靜很多。

• 身份層：姓名、學校、位置、年級
• 媒體層：圖片數、縮圖、caption
• 脈絡層：排名、NIL、相關頁、站內連結

球員卡片才是這頁真正有價值的地方

Kaiir Elam
North Palm Beach, FL · The Benjamin School
Pos CB
HT / WT 6-1.5 / 191
Class SR
NIL Valuation $95K

這段其實就是整頁最值得抄的骨架。它把你最需要的東西一次講完：人名、地點、學校、位置、身材、年級，外加 NIL。這些欄位放在一起，讀者不用翻頁就知道這是誰、什麼層級、值不值得繼續看。

也就是說，這不是在講故事，這是在做快速識別。對招募網站、球員資料庫、媒體檔案來說，這種卡片的任務只有一個：讓人兩秒內完成定位。你可以討論 NIL 要不要放進來，但整體順序是對的，先讓人認出球員，再談其他延伸資訊。

我看過太多球員頁把自我介紹寫得像新聞稿，結果第一屏先出長段落、社群連結、統計圖、推薦文章，球員名字反而被壓到下面。那種設計很像在跟使用者說：先看平台，再看人。On3 這頁至少把身份卡放在上面，這點我認為值得保留。

實操寫法很簡單：卡片欄位不要超過一屏，欄位順序要按讀者價值排，不要照資料庫欄位順序排。最先放姓名和學校，再來是位置和身材，最後才是年級、NIL、排名。你要的是快速辨識，不是把所有欄位一次丟給人看。

• 先放讀者最在意的欄位
• 把編輯欄位和 scouting 欄位分開
• 進階資訊用「更多」折疊，不要硬塞同一塊

排名數字有用，但它不是主角

Industry Rating 95.69
48 Natl
6 Pos
8 St

這些數字很容易讓頁面看起來「很專業」，因為它們立刻建立階級感。但問題也在這裡：數字太搶戲的時候，頁面就會從球員頁變成榜單頁。On3 把 rating 和 rank 放進 profile 區塊，對它的受眾來說合理，可是如果你照抄，最後很容易做出一個只會炫數字、不會講人的頁面。

翻譯一下就是，排名應該幫助理解球員，而不是跟球員搶版面。使用者多半已經知道自己在看招募頁了，他們需要的是「這個人目前在哪個層級」的快速訊號，然後馬上回到照片。排名要有，但不能像頭條。

我做過一個內部名單頁，當時把分數徽章做得太大，結果大家一進頁面先看分數，完全沒看人名。這種設計看起來很會做 dashboard，實際上很不會做內容。分數、排名、rating 都是 metadata，只是它們穿了行銷外套，所以很容易讓人誤以為那就是內容本身。

實操上，我會把 rank 資訊降級成次要字級，縮小間距，只保留一層最重要的排名。如果整頁主題是照片，就不要把排名做成第一視覺焦點。你要的是「補充判斷」，不是「搶走閱讀路線」。

還有一個很實際的判斷方式：這個數字是幫使用者挑照片，還是只是讓頁面看起來更官方？如果答案是後者，通常就該往下放，甚至乾脆移到側欄。

一張圖也能叫圖庫，但你得把狀態設計好

Photos Gallery · 1 image

這裡最有意思。頁面叫照片庫，但來源只顯示一張圖。也就是說，這個 gallery 不是「很多圖的集合」，而是「可擴充的媒體容器」。它現在很薄，但模板已經先把位置留好了。

白話講，這不是壞事，反而是設計上比較成熟的地方。因為很多頁面死在內容稀疏時的樣子：一張圖也要撐成大圖庫，結果看起來像沒載完。On3 至少有把 gallery 的外殼先搭好，哪怕內容只有一張，也不至於整頁崩掉。

我以前在 CMS 裡做活動相簿，也遇過這種情況。活動還沒補齊照片，頁面先上線。如果你沒設計 0、1、many 三種狀態，使用者只會懷疑系統壞了，不會覺得內容少。頁面不是越滿越好，重點是每種內容量都要看起來像有意識地設計過。

實操寫法：圖庫元件一定要支援零張、一張、多張。零張時顯示 placeholder 和說明；一張時用 hero 圖加 metadata；多張時再開 grid 或 carousel。不要讓一張圖看起來像漏掉其他圖，也不要讓空狀態像系統錯誤。

• 0 張：顯示說明與回到 profile 的入口
• 1 張：用 hero image + caption
• 多張：縮圖網格或輪播，但標籤一致

站內外殼要退場，不要一直搶戲

這種體育站頁面常見的毛病，就是外殼比內容還吵。導覽列、登入提示、相關分類、頁尾連結、廣告版位，全部都在提醒你「你在某個平台上」。我知道啦，我已經看到了，不用每一屏都再講一次。

也就是說，如果頁面主體是照片，外殼就應該退後。導覽可以在，但不能像內容一樣大聲；廣告可以有，但要跟內容區塊切開；相關連結可以放，但不要把主視覺壓扁。這不是反對站內功能，而是反對功能搶走內容的注意力。

我現在做編輯頁面或內部工具時，最在意的就是 chrome 的音量。使用者打開頁面後，應該先知道自己在哪，再把注意力交給內容。不是每次滑動都要跟 header 打架。當頁面高度有一半都在講平台，內容自然就被擠成背景。

實操上，我會用三段式優先級：大的是身份卡，中的是圖庫標題，小的是工具列和站內導覽。只要 header 比內容預覽還高，你就該重做。頁面不是越像首頁越好，尤其是圖庫頁，越像內容頁越對。

真正值得抄的是資訊順序，不是長相

我最後得到的結論很直接：這頁最有價值的不是它長什麼樣，而是它把哪些資訊先給你。先身份、再圖庫、再脈絡，這個順序是對的。你如果要做球員相簿、校隊檔案、媒體資料庫、 alumni gallery，都可以沿用這個順序。

白話翻譯就是，不要抄 On3 的視覺噪音，要抄它的資訊排序。這個頁面真正能遷移到別的產品上的，是「先讓人認人，再讓人看圖，最後才補背景」。這比任何花俏版型都更有用，因為它直接對應到閱讀行為。

我自己在重做這類頁面時，會先問三個問題：這頁是給誰看、他第一眼要看什麼、哪些東西可以晚一點再出現。只要這三個問題回答清楚，版面通常就不會亂。反過來說，如果你先做視覺，再補內容，最後一定會把頁面做成一包很吵的卡片。

實操寫法：把頁面拆成四區，標題區、身份區、圖庫區、延伸區。每一區只做一件事，別偷渡。這樣你就能保留資訊密度，又不會讓頁面像資料表。

可抄的模板

# Athlete Photo Gallery Template（可直接改成你的 CMS 區塊）

## 1. 頁首標題
- {Player Name} Photos
- {Hometown, State} · {School}

## 2. 身份卡
- Pos: {Position}
- HT / WT: {Height} / {Weight}
- Class: {Class Year}
- Optional: {NIL Valuation}
- Optional: {Industry Rating} / {National Rank} / {Position Rank}

## 3. 圖庫摘要
- Gallery title: Photos Gallery
- Image count: {0|1|many}
- Short note: {這批照片的來源或事件}

## 4. 圖庫區
- Hero image or thumbnail
- Grid / carousel for more images
- Captions with event, date, or location
- Alt text for every image

## 5. 脈絡區
- Recruiting profile: {link}
- Team page: {link}
- Related coverage: {link}
- Verification note: official or approved imagery only

## 6. 顯示規則
- 先顯示姓名與學校，再顯示圖庫
- 排名字級要小於姓名與位置
- 圖庫要能正常處理 0、1、many 張圖
- 導覽列與廣告不要壓過內容
- 若只有 1 張圖，仍要看起來像完整頁面

## 7. 可直接貼進頁面的 skeleton
# {Player Name} Photos

**{Hometown, State} · {School}**  
**Pos** {Position}  
**HT / WT** {Height} / {Weight}  
**Class** {Class Year}  
**NIL Valuation** {Optional Value}

## Photos Gallery
{Image count} image{plural}

![{Alt text}]({image-url})

## More About {Player Name}
- Recruiting profile: {link}
- Team page: {link}
- Related coverage: {link}

## Notes
- Official or verified imagery only
- Caption should identify event, location, or context
- Update image count whenever photos are added

這版我會直接丟給編輯或前端。它保留了 On3 那種「先識別、再看圖、最後補背景」的順序，但把最吵的東西都拿掉了。你如果要做自己的球員圖庫頁，先別急著選版型，先把資訊層級排好，頁面自然會安靜很多。

原始來源是 On3 的 Kaiir Elam photos 頁，平台主站在 On3。我這篇的拆解是原創的，但頁面事實與結構都來自公開來源；如果你想對照球員脈絡，可以再看 Rivals on On3 和 On3 database。