資料夾很適合交件，但不一定適合找照片

資料夾一直都是很好的交件工具。它有清楚的位置、既有權限、容易整包下載，也很適合公司沿用原本的雲端與備份流程。

所以問題不是「資料夾過時了嗎」。真正值得拆開的是另一件事：

完整交件，和從大量照片裡找到某一張，並不是同一個任務。

前者在確認檔案有沒有完整送到；後者在處理一個人怎麼從自己的線索出發，走到需要的畫面。

整理者知道流程，找照片的人不一定知道

攝影師或窗口整理照片時，很自然會沿著活動本身的結構命名：

• 01_報到與空景
• 02_開幕致詞
• 03_論壇
• 04_頒獎
• 05_交流與合照

這樣的結構對歸檔很好，因為它把一場活動重新放回時間與流程裡。

但另一個使用者找照片時，腦中的線索可能完全不同。

他想的是「我跟董事長在攤位前的那張」、「講者拿著獎牌的照片」，或「那張可以放簡報封面的橫圖」。這些線索可能是人物、用途、地點、物件，未必是流程名稱。

於是同一個資料夾結構，對整理者是清楚的，對使用者卻可能要求他先猜：「我想找的東西，當初被分到哪一類？」

這不是誰整理錯了，而是兩個人的分類方式本來就不一樣。

找圖問題，常常是資訊架構問題

資訊架構的分類沒有一個放諸四海皆準的答案。Nielsen Norman Group 在介紹 tree testing 時，直接把它定義為一種以任務測試階層分類的方法：給使用者一個要找的東西，看他是否能沿著現有分類找到正確位置。文章也提醒，即使遵循一般設計原則，仍不能只靠設計者自己判斷分類與標籤是否對使用者有意義。來源：NN/g，Tree Testing

把這個觀念放進活動照片很直觀。

如果窗口平常都是依 rundown 工作，「論壇 → Panel 2 → Q&A」可能一眼就懂；但第一次收到照片的來賓，只知道「下午跟某個人合照」。兩個人需要的不是同一條導航路徑。

因此，真正要測的不是「資料夾分得整不整齊」，而是：目標使用者拿著自己的線索進來時，能不能走到需要的照片。

資料夾本身也可以很好找

這裡也不需要把資料夾和搜尋功能畫成敵人。

以 Google Drive 為例，官方目前就提供搜尋列，以及依檔案類型、人物、修改日期與 Drive 位置等條件篩選檔案的方式。來源：Google Drive Help

所以「用資料夾交件」不等於「只能一層一層點進去」，更不代表一定需要換成另一套工具。

如果使用者本來就熟悉共享雲端、知道關鍵字，或公司有既定的資料管理規則，原本的資料夾可能已經非常夠用。

問題應該改成：現在這批照片最常被怎麼找？既有入口有沒有支援那些線索？

先做低成本的改善，通常比較合理

如果找圖只是偶爾卡住，我會先改交付方式，不會直接增加一個新系統。

例如把最常用的照片另外整理成精選子資料夾；最上層改用「講者／頒獎／品牌／合照」這類接近使用任務的名稱；保留能快速瀏覽的縮圖；必要時用明確檔名或一份簡單索引，告訴窗口各類照片大概在哪裡。

這和〈影像策略 06：素材包要怎麼整理才不會造成窗口困擾？〉談的是同一個方向：整理方式不只要服務保存，也要服務下一個人的使用。

做完這些之後，再觀察問題還剩多少。因為每增加一個入口，也會增加另一種成本：有人要維護、有人要知道去哪裡、權限要重新確認，窗口還可能多一件需要解釋的事。

漂亮的新介面不是效率提升的證據；它只有在解掉原本的工作摩擦時才有價值。

什麼時候，另一種找圖入口才開始有意義？

當需求從「窗口收一整包照片」變成「很多不同的人，各自來找不同照片」，資料夾的優勢就可能不再等於使用者的優勢。

尤其當幾個條件反覆出現：找照片的人不熟悉活動流程、同一批影像有很多不同用途、窗口開始頻繁代找與轉傳，或使用者每次都從不同線索開始尋找。這時候，專門的照片瀏覽與搜尋入口才值得被評估。

注意，是值得評估，不是必然要導入。

相反地，如果需求是完整歸檔、固定窗口接收、公司既有權限政策，或之後會把整包素材移進自己的雲端，資料夾往往仍是更直接、維護成本更低的做法。

工具應該跟著任務，而不是反過來

上一篇〈600 張照片交出去之後，真正的問題才剛開始〉先把「檔案已存在」和「需要的人能找到」拆開。這一篇再往前一步：同一批檔案可以用不同方式被組織，而組織方式是否有效，要看它服務的是交件、歸檔，還是找圖。

資料夾是很好的交付容器，但容器的結構不一定就是每一位使用者的尋路方式。

如果資料夾已經能完成任務，就沒有必要多造一個系統；如果真正的瓶頸是找圖，就應該先從使用者實際帶著什麼線索進來開始處理，而不是先問哪一套工具看起來比較新。

---

本文提供一般性的攝影規劃與影像使用參考。實際執行方式會因活動形式、場地條件、時程與個別需求而有所不同，內容不構成服務範圍、報價、交付規格或合作承諾。實際合作內容以雙方確認的提案、報價或合約為準。