這篇必看：那些產品、交互新人初入職場踩過的坑

本文未經同意不得轉載，感謝鎮雷的小夥伴們。

當從象牙塔走入職場，新人們除了興奮和憧憬以外更多的還有緊張和迷茫：對龐大業務的不熟悉、對工作模式和規範的不了解、對同事和前輩的生疏，都是新人成長的必經之路。有些坑，需要我們親自踩過才能有深刻的體會，但是前車之鑒後事之師，聰明的人一樣可以從別人的錯誤中學到經驗。

這次特意邀請了七位邁入職場不久的產品經理、交互設計師同學，分享那些他們踩過的坑。話不多說，收穫有多少，就看你有多聰明啦。

交互設計師 鴻影 from 阿里巴巴

1. 無腦悶頭執行

過程描述：接到需求的時候，對方描述了一個具體的解決方案，就直接陷入這個方案里去構思細節。

原因反思：對「交互設計」的全流程認知不透徹，思考深度不夠，以為出線框出界面就是工作大頭，目標什麼的有產品經理想就夠了，而不去思考目標本身、目標和需求方描述的解決方案關聯是否合理。

如何避免：開始設計前一定要和需求方進一步溝通清楚，明確業務目標和用戶場景的合理性，並用自己的語言重新描述放在設計文檔第一頁。對需求方給出的具體解決方案，不要讓它框住自己的思路，而是反推確認方案背後的目標本質，回到目標導向設計上來。

2. 缺少全局視野

過程描述：接一個需求就加一塊內容，而不思考如何和之前已有的信息結構系統整合，久而久之變成了縫縫補補式的堆砌，產品的整體感、一致性、擴展性變差。

原因反思：沒有從系統的角度來梳理看待問題，對內容之間的關聯感知弱，只顧聚焦當前業務需求的細節，忽視了對產品整體層面的影響，或雖有意識到，但因為畏懼工作量、溝通成本等不願意推進整體角度的優化。

如何避免：提醒自己不能老摳細節，將需求們整合起來，列舉會被影響到的產品功能點，系統梳理優化信息結構，打包進一個解決方案，並在設計時考慮到未來新需求接入後的擴展性。敢於適時打破之前的框架，總是在舊方案上直接加東西，短期思考和設計的成本低了，但難以維持長久。

3. 忽視UI呈現

過程描述：覺得自己不是專業視覺設計師，交互稿不用太在意UI上的質量，隨便東拼西湊一下能表達出東西就可以了。

原因反思：對交互和視覺的分工認知太狹隘，實際上，像布局、柵格、字數限制、內容重心層次這些東西都是在交互設計階段就必須考慮和表達清楚的事情，交互設計師偷懶會導致視覺設計師受到影響（比如因為內容放不下，要完全把布局方式推翻等）。

如何避免：交互設計師必須懂得基礎UI設計原則，用高標準來對待自己的交互稿，這也是專業交互設計師和會畫原型的產品經理的區別；在很多公司里交互設計師直接出高保真是常見的現象，不要把自己的技能棧限死，這樣不利於長期發展。

4. 逃避退讓溝通

過程描述：不敢主動向合作夥伴去溝通和爭取一些事情，過於站在產品經理和開發的角度著想（這個成本會不會太高了啊我還是不考慮了吧），而缺少對產品體驗底限的強勢堅守。

原因反思：新人意識還在，臉皮不夠厚，總覺得自己資歷淺薄，在合作夥伴面前沒什麼話語權，所以還沒開始溝通就自己把自己先嚇退了。

如何避免：提醒自己已經畢業，已經是正式設計師了，要學會獨當一面，不能還用實習生的心態來對待手裡的事情。嘗試鼓起勇氣去和合作夥伴爭取，嘗試從對方的利益點來解讀自己想做的事情能帶來的幫助，給自己設一個產品體驗的底線，幾次溝通下來，你會發現對方根本沒有自己想像中那麼可怕和難說服。

交互設計師 寶玲 from eBay

我就簡單說兩個。我們公司設計部比較弱，是交互UI混在一起的，可能有些不太適合多數人：

1. 不追蹤開發效果。

過程描述：許多設計師在完成了一個模塊的設計之後就進入下一個模塊的設計，永遠處於設計的狀態，而不去追蹤設計效果的開發實現。實際上，開發結果和設計效果往往會有出入，特別是設計師不管開發效果的時候，不少前端會自作主張或者錯誤理解設計稿，最終開發出不盡如人意的產品。

原因反思：設計師往往認為設計過程是最重要的，提交了設計稿之後自己的任務就完成了，接下來的開發環節不歸自己管了，應屬開發和產品經理來負責，如果開發不理解設計稿也肯定來問設計師的，設計師只管等著被問就好了。而實際上，人都有惰性，開發也會碰到問題不來問，寧願自作主張的。產品經理也會更注重大局，而忽視交互視覺上的小瑕疵。將設計稿完美地開發出來需要設計師對後續開發的跟進和反饋。

如何避免：首先在提交設計稿時就應按照開發寫代碼的方式將設計稿標註好，如果標註的字太小，也可以在郵件里再寫一遍，以便開發能有明確的參考。其次，將設計稿提交之後隨時跟進開發進度，對於開發結果出現的諸如沒對齊、沒有邊界線、padding大小不對等等細節進行反饋請求修改。

2. 不懂技術。

在國內，不懂技術對於設計師來說似乎無可厚非，許多公司的招聘廣告里絲毫不要求設計師懂技術。然而懂一點前端開發是你的設計可以被完美開發還原的基礎。懂前端可以讓你以開發想要的方式來標註你的設計稿，降低了設計師和前端之間的溝通成本，有時甚至可以幫前端改一些他懶得改的細節代碼，以使開發作品更符合自己的設計原型。

原因反思：許多公司招聘設計師不要求設計師懂技術，面試時也不會涉及任何技術問題；設計師理所當然地認為技術屬於開發的管理範疇，自己只要能設計出來的，開發一定有辦法開發出來；犯難情緒，覺得技術難懂，不想學。

如何避免：我提倡設計師去接觸一些前端知識，即使自己一行代碼都不寫，不練習寫代碼，但至少也要看看前端代碼是如何構造而產生界面的。推薦http://w3school.com這個網站，能系統地學到許多前端知識。

交互設計師（實習）Thor from 網易遊戲

想提一點我自身感覺特別深，就是在進行討論時，要懂得始終讓討論在同一個維度上，說白了就是討論的是同一個問題。

說兩個案例：

1、在前一份燃健身實習時，boss是大熊，前美麗說副總裁，性格非常直爽的一個人。有一種很明顯的體會就是，大熊參加的會議，討論產品的效率會提升不少。因為每次在討論某個問題的時候，參與的人可能會從不同的角度去分析或則思考，得出的結論也會不一樣。大熊往往會出來控場，每次的控場都非常的果斷，只要有其他緯度的延伸，就會及時的遏制住，確保當前緯度的問題可以更好的進行下去。

2、第二個案例說一說最近的，目前在網易遊戲實習，在這份實習過程中，同樣經常需要參加評審以及討論。有一次在和導師討論我的設計方案時，導師提出了我方案中做的不好的地方，並具體說明了理由，但當時我並沒有就這個角度去回應，而是自己從其他角度進行了更多的解釋。不得已導師又繼續重複了一遍，並順便指出了我所提出的角度存在的問題，這才讓我兩的溝通更加順暢。

分析：這兩個案例都說明了討論在一個維度上的重要性，不管是參與評審還是1對1的討論，假如各方之間的觀點並不在一個維度上，是無法達成一個共識的，因為不同的理由只能對應於不同的維度，當維度相同時，各方之間才能夠正面的進行碰撞。

小菜，Flyme Research & Design Center，准交互設計師

1. 在進入產品形態發展較為成熟的公司時，常會設計出違背設計守則的設計。（尤其在手機廠商，設計 ROM 時有著非常多的設計規範。）

踩坑過程：在入職一周後便進行了 Flyme 某應用的概念設計，在設計時我嘗試了很多新穎的交互和視覺，甚至有過顛覆 Flyme 的天真想法。但由於對 ROM 設計規範了解不透徹，以及不夠重視 ROM 一致性，最後被同事噴了「真?概念」。

如何避免問題再次發生：在進入一家公司時，先不著急接手設計項目，或者利用接手項目前的時間，深度體驗公司的產品，並且將規範整理和記憶。

2. 前輩的指導看作是真理。

踩坑過程：剛入職場時，每次評審面對一群 boss 時都會提心弔膽，boss 也會對自己的設計稿提出各種建議。頂著壓力之下和對前輩的認可，往往 boss 說什麼都沒經過多思考就點頭認可，但回頭自己一想卻四處有問題。

如何避免問題再次發生：評審實際上也是一場討論會，經驗再豐富的前輩也會判斷不準確，更何況他們僅僅是評審時才進入思考模式，多表達自己觀點和設計時的思考。但更為重要的是，培養獨立思考能力。

3. 和同事討論關於過於激烈而最後引發爭吵。

踩坑過程：當時做了一項新功能，就是否需要新手引導的問題和我的導師討論了起來。我們各自表達了加入新手引導的利弊，但又各持態度，最後誰也不讓誰而引發了爭吵。過後導師還向自己道了歉，我為此非常愧疚。

如何避免問題再次發生：當討論時雙方各持態度時，多一些人加入討論會產生不一樣的觀點，或許能成為矛盾下的「潤滑劑」，也或許會得出更好的結論。

匿名，Microsoft Research Asia，UX 設計實習生

作為職場新人，除了錘鍊專業技能，工作中的「性格」表現也應當注意。

踩坑過程：剛開始工作時，常把一些學校的習慣代入到公司中，例如在工作中過多的曝露自己的私人生活與喜好。這樣的行事方式容易給周邊的同事留下一個在你意料之外的標籤，如「愛打遊戲」「宅男」「養貓人士」。我就是因此常被不熟悉的同事誤認為工作不夠飽和，貪玩。或許這樣能給大家留下一個有趣，容易相處的好印象，但是在工作場合，讓人想起你的第一件事更應該是「專業」而不是其他東西，這樣才能體現出你在公司的價值和重要性。

如何避免問題再次發生：工作外的事情在工作場合以外和好友同事分享便已足夠。「你有看過你的老闆跟你分享他的私生活嗎？」

from 卿詞 聚划算 產品經理（實習）

問題點：初入大公司陷入「螺絲釘」情緒，拘泥於產品細節和功能體驗。

描述：上一份工作是在一個創業公司兼任產品與交互設計，更多的強調快速迭代拿到結果的執行力和產品體驗上的細節雕琢能力，工作效率和用戶體驗設計是我的核心競爭力。但是到了阿里後，我的工作職能調整成為了進口業務的產品經理。這是一個更前台化，業務化的崗位。初期在慣性下，我仍然過多的拘泥於單點的執行和前台玩法的視覺優化上，在業務層面的思考不夠全面也不夠深入，沒有在一個大的業務方向下去進行長線的規劃。一方面，我沒有意識和主動承擔我對業務的決策能力，另一方面，基於業務淺層的功能設計也很難給我帶來提高。

而當我逐漸意識到這個問題後，我開始花更多的時間去了解行業特點，對待競品更多的從業務上的競爭力（貨品結構、銷售模式、目標人群、運營策略等）而非功能設計和視覺展現去分析，積極地約運營和UED同學探討業務的現狀和未來發展，我把自己更多的放在了一個業務經理的位置，愈發的意識到產品只是業務執行中的一種工具和手段。只有基於業務層面的分析和決策才是決定業務未來發展的核心點，而產品設計和體驗設計，更像是業務實現目標的一種表現形式，決定了業務達到「天花板」的速度。

結論：

1. 在大公司不要局限於所處業務和團隊，將自己束縛於「螺絲釘」的定位中。在產品執行之外，主動承擔業務的思考和決策工作，積極的進行跨類目、行業、bu的溝通與合作。雖然每個人負責的業務可能很有限，但是，能夠對接的業務確是無限的。

2. 產品設計本身沒有好壞，只看是否能表達這個業務的運營策略。在我看來，做的好（產品執行、問題解決）的同時，更要想清楚（對於業務核心和下階段重點的判斷），前者是職業能力的體現和獲取信任的基礎，而後者才決定了能在當前位置和業務上走的高度。

3. 產品經理是一個很大的籮筐，具體到某一公司某一行業的產品經理，其職業發展和能力修鍊和方向都是非常不一樣的，一定要迅速找准當前業務的重點，明晰自身定位，做到工作效能最大化。

4. 在我的問題中其實還隱藏了一點，為什麼我會拘泥於產品體驗和淺層執行上，我認為，恰恰是我對自身能力的不夠自信（hold住業務，說服大家），所以才選擇了一條更加封閉和短期就看得見反饋的體驗優化之路。結論就是，不要用戰術（產品執行、功能設計）上的勤奮來掩蓋戰略（業務規劃、團隊領導）上的懶惰。

form 寶鵬 阿里巴巴 產品經理

不要過度關注於產品本身，避免成為工具人。

工具人： 消耗絕大部分精相對比較確認要做的事情中，而欠缺對於全局、業務或者對於自身的考慮，導致自己成為了公司的「螺絲釘」，可替代性強，就像工具一樣，公司用你就用，不用可以隨時裁掉。

在阿里巴巴等偏重業務導向的公司中，「產品」僅僅是業務或者需求落地的抽象工具，因此「產品」並不代表了業務的所有。在這種境況中「產品」實現或者是說放大了業務的價值，是業務價值的主要承載體。

我認為沒有任何業務場景更準確的說沒有應用場景的「產品」是沒有存在必要的。即便是在因緣際會下某些「產品」進入了大眾視野，我相信這類「產品」也很容易死掉。因此不要認為「產品」只要做的足夠好，體驗足夠極致，那麼就一定會有可觀的用戶和可觀的流量。

案例：在做無線產品的時候（支付寶-首頁下拉更多-雲市場），接到一個任務是使用支付寶的掃碼支付來提供一個在B2B線下掃碼下單（讀者請注意，這裡是掃碼下單並非是走直接轉賬哈）的功能。我認為保證用戶的點擊、掃碼體驗以及功能性是比較重要的，因而花了大量的精力在控制項優化和掃碼性能、功能的提升上。誠然，這些東西無論在何時何地都是十分重要的。然而在線下推廣我們業務的初期，發現了一些問題：

1、不少用戶連支付寶都沒有用過，更不用說掃碼；

2、掃碼支付存在用支付寶賬號免登陸到1688的邏輯，然而由於歷史原因淘寶-支付寶-1688的賬號並不是一一對應的，導致登陸失敗；

3、下單過程實際上是一個掃碼到店鋪頁面，並點擊向檔口付款來進行支付，存在用戶的跳失。

因此實際上我要做的並不是一個功能，而是一個場景：用戶在線下的登陸-掃碼查看店鋪-向店鋪支付-支付寶支付成功，而並非掃碼本身，並且還需要從業務角度考慮如何讓沒有用過支付寶的人進入到這個場景中，以及如何讓用過支付寶但是只習慣掃碼轉賬的人使用掃碼下單而不再用掃碼轉賬才是應該考慮的問題。

歸納：產品設計和實現過程中要使用全局業務思考原則和優先順序判定原則來解決上述問題。在如上的場景中，需要利用全局業務思考原則來進行「產品」的判定，我做的到底是功能還是場景，如果是做功能那需要聚焦的是哪方面，如果是要做場景則要保證怎樣的業務閉環。

根據全局思考的原則，我們再回來查看以上場景中的問題。

1、用戶沒有用過支付寶，則需要通過線下運營的方式來考慮這個問題。因此需要向老闆提出配備運營團隊或者同支付寶來合作來進行共同地推裝機，這個不是產品所能夠解決的問題。

2、首先理清楚賬號對應邏輯，能夠對應的做到無感登陸；對應關係無法查到的則給予提示告訴用戶你目前的賬號狀態，要如何操作才能夠繼續接下來的功能。

3、下單跳失這個問題同樣不是產品能夠解決的問題，因為掃碼支付同直接轉賬的方式並沒有任何的優勢，反而操作多了一點點的成本，再次，即便是用戶付現金也沒有任何差別。那麼需要通過確認使用如何的運營策略來勾住用戶（比如紅包、滿減、積分等方式）。

從如上來看，掃碼下單流程的「產品」功能本身反而是次要的了。

推薦閱讀：