最近我在帶實習生開始接手資訊架構的工作，相對於用戶研究的工作，資訊架構的設計規劃工作可以說是新人殺手。
我聽過剛入行的設計師困惑的跟我說：「wireframe 不就是沒上色的介面設計嗎？」
殊不知，許多剛入行設計師規劃的介面與流程被工程師刁難、被 PM 亂改、魔改了十幾個版本之後才發現沒辦法開發，原因或許都跟缺乏資訊架構設計的過程有關。所以我想寫給我們家實習生一篇文章，聊一下為什麼資訊架構設計是他今後成為產品設計師的路上，一個需要埋頭苦練的基本功。
資訊架構這個技能，是許多設計師既熟係又陌生的一門領域，其實只要參與產品開發，資訊架構的問題幾乎如影隨形出現在產品的方方面面上，但真的要定義這是一份什麼工作，卻又難以回答。
當一個軟體需求被確認之後，呃，我知道這不容易，而且隨時會翻船，但我們假設你得到了一份邏輯清楚、可信度靠譜而且確定要執行的需求描述之後，資訊架構的工作就隨之展開了。
就好像搬家，你有對於生活情境的想像，也有一些自己的家具，然後你要觀察即將搬進去的房間格局，思考你的生活動線，這個居住空間會有哪些使用情境，然後把家具試著擺放進去，再測試看看是否如你預期，然後還要決定這麼多衣服、書本、雜物要如何收納進這整個空間。
換到軟體開發的資訊架構設計工作也是一樣的，當你接手軟體的需求之後，首先要確認的是什麼角色？因為什麼原因？要做哪些事情？會使用到什麼機制功能？需要哪些資訊？
角色、原因、做哪些事，這要透過需求訪談來處理，我們先不提經常需要你觀落陰的情況。
會使用到什麼機制功能，這需要去跟技術開發者或者 PM 確認，整理出系統機制的功能性流程圖來定案，再次聲明，我們先不討論需要你觀落陰的情況。
經過這樣東市買駿馬、西市買長鞭的拼湊一個軟體需求所影響的每一個要素，你才有辦法著手資訊架構設計的工作。
但如果你以為這樣就可以開始進行 sitemap、wireframe 這些一般常見的工作，嗯，想得美。
在打開設計軟體畫圖之前，你還要整理資訊的來源、結構與格局這塊工作要處理，就像炒菜之前你得要備料一樣。
假設你這次要處理的流程，三個步驟裡面需要五種資訊才能幫助使用者抵達流程的終點，就像訂單成交，你需要使用者資訊、購物清單、金流資訊、物流資訊等等等。
你找出系統裡面有某些其他現存的機制，已經具備一部分使用者在這個需求中需要的資訊，太棒了，不需要憑空規劃，那剩下的資訊怎麼辦呢？
可以要求使用者自己輸入嗎？有沒有第三方系統可以提供？A 使用者需要取用的資訊，會不會連動到 B 使用者呢？這些資訊取用的過程，系統會延遲或者需要驗證什麼嗎？
當然你也可以認為這是工程師或是 PM 該做的事情，但那就不要抱怨被當做美工或者人形滑鼠使用，因為整理並確認這些素材，可以確保你最後規劃的介面與流程是經過大家確認具備開發上的可行性。
負責「設計」流程的人，如果沒有整理以上資訊的能力，就像廚師沒有能力對食材調味，也辨識不出什麼樣的食材搭配在一起是能夠吃的。
處理資訊架構的過程繁雜，每個階段的產出不太具體，許多開發團隊也沒有意識到要規劃對應的溝通時間。
這些事情 UX 設計師不處理，其他對這類問題有意識的人也會察覺問題，這也是每個人都會來嘴一遍你設計的介面與流程有問題，然後你很難過為什麼不早點告訴你這些問題的原因。
但如果你有資訊架構的問題意識，並且挑起擔子主動出擊，或許我不是工程師啦，但有這樣的設計師夥伴聽起來挺不錯的，不是嗎？
