這個必須收!如何讓開發人員按照UI標注還原設計?
當一個開發工程師屢次發問「這里讓我移1px有什么意義,我為什么要浪費時間這么做」且拒絕修改時,如何讓這位開發理解、認識到修改的重要性?
首先回答問題,程序員不配合,90%以上的情況是需求人員工作不到位。 目錄 產品人員,一定要了解1個像素在不同情況下,重要程度是不同的,這是你是否要去找程序員修改的大前提。比如 1,產品戰略層面是否重視體驗? 公司是技術驅動,設計驅動還是市場驅動?這款產品是面向什么用戶的?這直接決定了細節在產品中的重要程度。不知道題主所在公司情況,就直接告訴題主“體驗為王”或“設計師工作是可選的”,這樣真的好嗎? 于UI\UE的重要程度,絕大多數情況下,企業軟件<專業工具<大眾產品。 舉個例子,我老東家金山的后臺管理系統,爛的簡直讓人發指,別說易用了,連能用都達不到,不讓你撤銷重填就算謝天謝地了,可用了多年也沒換過。你說1像素重要嗎?對于很多企業用戶來說,企業軟件最重要的是安全、易于部署、維護和擴展,而不是UI是否好看/UE是否完美。所以如果你是做這種產品的UI設計師,長時間糾結1像素被鄙視也是稀松平常的。 而對于像Zaker這樣的大眾產品,在底層技術能夠到位的情況下,用戶體驗就成了極其重要的一環。任何UI無法對齊、圖標大了4個像素、出現“iphone”這樣的文字、配色有些爛俗的情況,都會讓用戶認為“這個產品比較山寨”,“用著有點別扭”的感覺,直接會造成流失/評價下跌。我想,用過知乎iPhone和安卓客戶端的人一定深有體會。 2,細節在應用層面的重要程度如何? 同樣是1個像素,在不同地方是有不同效果的,不能直接就說重要還是不重要。舉個例子 【我的收藏】前面的圖標,如果往左挪1個像素,你覺得怎么樣? 我的頭像這張圖和名字,如果整體往左挪1個像素,你覺得怎么樣? 我想,大多數人都會同意,第一條更不能忍。也就是說同樣的細節,是否重要一定要看它所處的環境,必須具體問題具體分析。對于任何提需求的人,都要自己先搞清楚,再灌輸給制作的人,不能一股腦全都丟過去。 3,項目進度和優先級是否允許? 一根筋,是絕大多數新的策劃\產品\設計人員最常犯的毛病。他們分不清楚輕重緩急,總是抱著“我是為產品好”的想法去做不合適的事。 舉個例子,一個游戲出現刷錢的嚴重bug,運營要求1小時必須解決。在你的眼里,順便調整1像素,也就是調一下坐標的事,沒什么難的。但在程序員眼里,這代表著要重新編譯、打包上傳,會極大增加出問題的風險。哪怕前端程序員沒有工作,你也不能去找他改這1像素。這個時候,1像素絕對是無足輕重的。 而當你記下這個需求,等發版以后,程序們有時間開發時再提交,這1像素就有可能重要了。 這一點上,我要為程序員們喊冤。絕大多數情況下,都是需求提供人員自己本身沒有做到位(大部分情況是極不到位)。包括但不限于以下情況: …… 程序員們,大多數都是非常單純的人,沒有那么多花花腸子,很少有故意給你臉色、撂挑子的情況。只是有些時候他們會一根筋,只要你足夠專業,勤于溝通,一般都沒有問題。所以是因為設計師不懂代碼?部分技術人員的審美意識?還是大廠心態或者其他什么原因?這種狀況怎么解決?到什么時代或是契機才能夠被解決? 這種抱怨的話少提,與人方便自己方便,自己既然是提需求的人,就要多為對方考慮。 假設真的出了問題,我們該如何面對?首先要尋找原因,是自己沒做到位,還是對方沒理解你的想法,還是單純瞅你不順眼?假設是1和2,那我們要做到: 1,先搞清產品戰略。 自己弄明白這1像素細節是否對產品有足夠的重要性。如果不重要,那請把工作中心轉移到重要的事情上。 2,絕對自己把該做的事情先做好。 這里邊包括自己先弄明白修改的意義,畫好標注色值、像素的示意圖和文檔,做好產品原型等任何能讓對方不需糾結,直接可以上手的工作。自己的專業、努力是贏得程序員尊重的前提,贏得他們的尊重你才能順利開展工作。 我以前給策劃審文檔,一個3頁的doc我打回去過7遍,改了幾天,最后才到程序員那里開始執行。雖然還是有些問題,但至少程序看到了這個策劃的努力。你想想一下,如果不審核就發給程序,程序會不會拿刀砍人? 3,弄清進度和優先級,弄清對方手頭工作 在搞清楚產品進度、優先級的情況下,尤其要注意一點:“絕對不要想到一個需求就跑過去要求程序改!” 程序也是人,很可能正在苦思一個重要問題時,你跑過來打斷他的思路,還是用在他看來毫無價值的需求,更糟糕的是你直接要求他放下自己的工作,立即修改,是個程序員都會爆掉的。別說是程序員,要你你也受不了。 好的方法是記錄所有需求,自己標記優先級,定期(每天定時)跟程序員溝通,跟他一起制定解決方案和時間。記住不要替他做主!他不是你的下級!他是幫助你的伙伴! 4,私下給老板和程序員不斷灌輸用戶體驗的重要性 這是很多人經常疏漏的地方。每個人的思維模式都不同,你不能要求別人也按照你的思維模式來看待問題。想要讓大家認同你的看法,就要在平常不斷的潛移默化影響別人。比如沒事多跟公司其他人聊產品,聊體驗,聊感受,慢慢給他們灌輸體驗的重要性。只要你的話題有趣,人有趣,沒有人會拒絕跟你聊,時間長了,整個團隊的思路就會有所轉變。 說個小技巧。程序員大多比較孤高,如果你想讓他改什么,你可以有意無意的跟他說,你覺得某個跟你們很像的產品某個體驗做的很好,你不知道怎么實現的,一定要擺出一臉羨慕的樣子,說他們太牛逼了。你們程序員一定會一臉鄙夷的看著你,說這破玩意有啥難的?老子半天搞定,絕對比他強百倍。多吹捧吹捧,你的目的就達到了,你倆都挺爽,是不是不錯? 5,搞好同事關系 程序員加班多,偶爾在他們加班時買瓶可樂,裝作一臉坦然的放到他桌子上,他就算嘴上不說,心里也會感激你的。這不是歪門邪道,而是人之常情。社會上你上哪去找一瓶可樂就可以買通的朋友去? 如果還不管用,請用這張圖詛咒他 如果你都做好上面5點,對方還無理由拒絕,那問題就不在你這邊,也不是你一個人能解決的了。請找你們共同的主管(比如項目經理),三人一起當面溝通,為什么會出現類似的情況,要有不解決我就拉你們住在會議室的決心。絕大多數情況下,你是能聽到程序員告訴你為什么他會不配合的。 切忌私下找對方上級。職場上任何時候,都要做到我對你說的話,對別人都敢說,千萬不要做背后議論,抱怨,捅刀子的人。 如果你已經做到位,還是無法解決,那不是這個程序員的問題,就是你們主管的問題,請考慮換工作吧。 這一條是我看了排名第一CTO的同學,有感而發。同樣作為管理人員,我堅信沒有任何一個工種是“可選”的。絕大多數產品,無法單靠某一類人就能做到100%的極致,再好的產品也有改進空間。而這個改進空間,無法靠設計者自己解決,需要借助外力。所以我不認為產品人員不給力,就可以把他們邊緣化。 我自己是策劃出身,如果我是這個公司的CTO的話,我想我會從下面幾個角度讓程序和產品人員更好合作。 1,不斷給團隊灌輸產品為先。 我們每一個人,都是為了這款產品的成功而努力。在這里面,每個人的工作都是為了產品成功負責,而不是誰是做什么的,誰專業不專業。只要能夠讓產品質量提高,任何提出的方案、修改都是可以討論的,即使進度不允許,也可以記錄下來。 讓團隊每一個人不再關注自己的角色(策劃、程序、美術)、職位,改為關注產品本身,是我的職責所在。 2,抓好培訓。提供工具。 抓好培訓:為程序人員培訓產品的意識。為產品人員培訓開發的流程與經驗。不求互相替代,只要能兩撥人能互相理解,能從對方角度考慮問題就夠了。 提供工具:為產品人員提供更好的開發、設計工具,能夠讓需求從設計者到開發者之間,盡量少出現因溝通產生的歧義。 3, 制定規范和流程 包括需求制作規范、文檔規范、開發流程、需求變更規范等等,減少項目中因人的因素帶來的不可控。 4,搞好團隊建設和人際關系,盡早解決問題。 打破工種的圈子,一起出去吃個飯,打個球,其樂融融多好。 總結一下吧,程序員不配合,不用找那么多理由,大多數情況是需求人員沒做到位,請繼續修煉自己的專業能力和人際關系。 作者:@逍遙老李 來源:優設網
一、像素這樣的細節是否重要?
二、為什么程序員不愿意修改?
三、產品人員該如何解決?
四、程序主管應該做什么?
太偏向程序員了,實際工作中,有些開發自己不耐心看文檔看需求,開會的時候不走心,說了多次,最后還是能給犯下很無語的錯誤。
產品需求寫的越來越細,不厭其煩多次溝通,產品也是人,也會累呀。
我的覺得說的有道理,像程序猿他們真的還是很好講話的。首先曉之以理,如果 講不好,說明自己的道理沒打動人。不行的話還可以動之以情啊,拜托一下對方修改,求求人家都是可以的。不過真的要找對時間,寫代碼一個邏輯性的事情,你過來講事情的時候,真的會打斷別人思路的,很令人討厭。除非重要bug,不然最好挑人家寫完一段 代碼的時間去說。
哈哈哈哈哈哈,有理!
確實應該這樣,產品經理考慮一個點子可能只要一分鐘,但要把這個點子實現,開發可能需要一天。點子的考慮要慎重。
有點偏袒程序員。
寫得挺好的,謝謝分享~
做項目管理久的人的通病,偏向開發
如果更進一步的說,應該是建立團隊文化
看完非常受益,另外那張詛咒圖太有意思了,哈哈
??