刀光劍影！那些年射雞師與程序猿的「鬥爭史」

這篇文章是台灣UI設計師@Akane Lee 寫的，恰好她的老公是程序員（什麼？程序員居然能找到女朋友？），這位非常有趣的設計師痛訴當年與程序員的「鬥爭史」，總結了很多實用的「勝利經驗」，還有她反擊程序員喊她作美工的光榮事迹，童鞋們必須新技能get√ 起來！

妹子博客：blog.akanelee

攝於師大青田巷

妹子的好文：

幾乎每個面試官都會問我：「你和RD的溝通情況如何？」我通常會反問：「都嫁給 RD 了，你覺得我和 RD 溝通情況怎麼樣？」不管是在家或是在工作，我整天都和 RD 相處啊！但即使和老公很有默契，遇到夫妻吵架，還是會大喊：「RD 的腦袋真不知道在裝什麼。」

職場上遇到不會擋客戶需求的決策單位也不知道他們在想什麼，客戶提什麼需求都說好…反正痛在 RD 身上，和 UI 設計師關連不太大。我一直覺得就某方面來說， RD 是種好可憐的職業，在開發流程上他們需要最多的工時、最麻煩的工作內容、卻排在流程較後期才開工。常常發生所有規格都定版、RD 都快完工了，客戶臨時看到某隻 APP 好炫好漂亮、硬要塞功能進去；或是前期耗掉太多時間導致他們後期天天加班趕工；遇到神級的 UI 設計師，做出可以看不能用的設計又擺高姿態一副凡夫俗子哪懂此等境界的表情還不能掐死同事…等等。之前就遇到這種神人，開口跟他說 Guidelne 上不建議這樣做，神人回一句「那是賈伯斯訂的又不是我、Guideline 太死板那是初學者在看的，我覺得就是應該～！＠＃＄…」 實現這個 UI 是 RD 的工作，老天保佑他們。

之前看過 RD 對 UI 嗆聲，UI 開口閉門就是「我覺得」，然後被 RD 酸到淚奔（不是我）。這時候就是 Guideline 出場的最佳時機，如果可以請把 Guideline 看得比 RD 熟，當然在設計開發上也以 Guideline 優先。不只是給自己一個背書、一條退路，面對和自己意見不同的場合，可以大聲且理所當然的說：「這是遵守 Guideline 所做的設計。」對付 RD 就是要佔盡「理」這個字，比他們講道理就贏了！（和老公吵架的心得）

當然也是有客戶/RD/PM 反問：「你怎麼沒有自己的意見？」這時候可以秒回：「Guideline 是多少高人組成的團隊做了無數實驗訂定的精華，同時也是使用者最熟悉的操作方式，我能做的就是基於 Guideline 之上將功能化為可操作的介面。」如果對方還啰嗦、就說好啊我改，可是要加時間（加錢）喔。加錢加時間是大絕，客戶怕加錢、PM 怕加時間、RD 也怕加時間 XD

我很堅持「不該只是使用者覺得好用，連 RD 都該覺得好寫才稱得上是好 UI」。簡單的 UI 不只使用者容易上手，通常邏輯也簡單，邏輯簡單表示 RD 也會輕鬆點、較不易出錯，QA 也不用一測再測。時程壓力小、PM 也不會天天被客戶追殺。有能力設計出大家都開心、大家都滿意的 UI，就不要為難同事了吧，大家都是出來混口飯吃的。

即使台灣這個大環境不重視設計，也不能因此覺得自己不重要。UI 設計包含的層面太多，要學習研究的範圍也太廣。胡搞一通就是害到工作流程排在你後面的 RD，好人 RD會含淚加班搞定你捅出來的邏輯不通大洞，資深的 RD 會拿著 Wireframe 和 Flow 把你罵到淚奔。 因為現在不是你（UI）哭、等客戶確認一切定案后就換他（RD）哭了。

受邀去某公司介紹 UI時，有遇過開口閉口都喊我「美工」的 RD 。一時沒反應過來很順的反問：「打字工你在叫我嗎？」（嫁給RD的壞處之一：整天都在嘴炮練得牙尖嘴利）這 RD 一定沒吃過UI的苦頭，百分百是剛出社會的小雛鳥。UI 要整 RD 是很簡單的事，來幾個炫麗繁複的過場特效、實時運算邏輯複雜的動畫等等，就夠 RD 整顆頭抱著燒了。開發時程不能延，就在前期規劃大幅提升他們的開發難度吧。

基本上 RD 都是些不錯的好人，通常單純好騙不善鬥爭、也不太會抱怨（至少我遇到的RD大部份都是這種類型），偶爾缺根筋在奇怪的地方出糗這樣（我老公腦袋一定被門夾過）。看在 UI 設計不佳是由他們來收拾善後，設計師們請對工程師好一些吧。