而貓是貓奴的神
RD 是偉大的，是神聖的。當 RD 往會議投影螢幕瞄了一眼設計圖，所有人最害怕聽到四個字：
這不能做。
彷彿宣告整個專案的諸神黃昏。PO 忙著跟業務解釋因為這樣那樣所以有困難、UI 忙著想怎麼改才能讓 RD 大大滿意、SA 忙著跟 RD 了解架構困難在哪邊。
所有人不約而同想到一件事：「OMG 死線怎麼辦！」
阿就說不行啊
再問一次，真的不能做嗎？
RD 是神，所以 RD 說不能做，就是不能做。
但真的如此嗎？
很多時候的「不能做」可能包含許許多多的一言難盡：
- 時間太趕了，所以不能做；
- 之前的程式找不到怎麼改，所以不能做；
- 這個資料拿不到，所以不能做；
- 效能限制，會讓頁面跑很久，所以不能做；
- 資料庫要調整，怕影響到其他程式，所以不能做；
- 資料必須跨部門請求，沒有開放 API，所以不能做；
- 還有很多很多⋯⋯，所以不能做。
通常後面的一言難盡，最後都會變成「時間不夠不能做」。
看出竅門了嗎？
喔～喔喔喔喔喔喔！
時間夠資源也夠，能不能做？
拿香蕉只能請到猴子，同樣的，資源完整時間充裕的狀況下，很多事情不是「做不到」，而是「比較麻煩（但做得到）」。
這個時候團隊的每個人就要搞清楚，所謂「不能做」的瓶頸在哪，而能透過協調得到共識，比方說MVP、分批交付，來達成最終的目的。
我一個畫 UI 的，能幫上什麼忙？
我常覺得 UI 設計其實跟萬事屋沒兩樣。如果團隊所有成員相關的知識都懂一點，就不容易設計出讓人一秒想逃避的介面。
- 設計前花一點時間閱讀 PRD 和 API 文件
- 稍微了解一點專案的架構
- 研究一下之前專案的文件
- 知道哪些資料是由資料庫取得、哪些要計算、哪些是寫死的
- 了解需要載入的資料，是否很吃效能：時間短就補上載入狀態，時間長就要考慮是否分批載入，資料切多少合理？用分頁還是 lazyload？
- 舊專案改版有一些技術債，現在配合的 RD 有辦法解決嗎？如果有時間壓力，哪些可以先沿用舊功能 / UI，哪些比較緊急的可以先做，然後請 PO 決策
- 不要在例行會議中討論，而是去找負責的成員請教；問問題之前先研究一遍相關文件（比方說過去的規格書），把問題寫下來，再跟協作夥伴約時間有效率地問完。
而當你累積了一定量相關的知識，當會議時被問到「這個資料要從哪裡來」，你可以當場回答出「就我所知目前我們資料庫沒有這些資料，但我有問到我們可以向 OO 部申請，定期批次匯入我們的資料庫，就可以跟專案的資料庫關聯 ，結合成我們所要提供給 user 的內容」。
喔吼，你蠻聰明的嘛
當你可以解釋出你的每個 UI 設計都是有考慮過團隊每個角色的 solution 時，即便最後沒有採納你的建議，團隊夥伴們也會知道，「這個 UI 很清楚他在做什麼」，而被秒拒的機會也會少很多。
但切記，不要說「這很簡單」。
打乎哩死！
這是全世界 RD 禁忌的咒語，一講出來 RD 會現場化身魔暴龍。
Nice team, happy Designer!
