規(guī)范性的指南在指導(dǎo)設(shè)計與開發(fā)的交接時很容易遵循與修改，但是這些具體的操作指南是否能跟得上未來新工具的更迭？

人們都喜歡步驟型的教學(xué)內(nèi)容。我作為設(shè)計刊物的編輯，經(jīng)常會見到許多類似于“10步完美與開發(fā)人員對接”或是“整理設(shè)計文件時的禁忌”，他們會吸引許多在執(zhí)行日常工作前需要尋找指導(dǎo)的設(shè)計師。這些指南大多數(shù)都是一些策略性的小技巧，例如標(biāo)注設(shè)計文件、整理文件夾，或是同類文件整理的最佳案例，這些小技巧被證明可以應(yīng)用到工作中的各個方面。

規(guī)范性的指南在指導(dǎo)設(shè)計與開發(fā)的交接時很容易遵循與修改，但是這些具體的操作指南是否能跟得上未來新工具的更迭？

事實(shí)上有許多種方法可以整理文件，命名文件夾或是多版本管理。如果只是提供一種方法，那么設(shè)計者就沒有考慮到每個團(tuán)隊的需求與執(zhí)行方式都是不同的。

我們使用的工具會經(jīng)常變化。設(shè)計師們處于各行各業(yè)，設(shè)計類型與所處團(tuán)隊規(guī)模都有差異，而且每家公司都有自己的組織影響設(shè)計師的工作流程，工具使用與執(zhí)行。甚至在同一個團(tuán)隊中，由于時間與合作人數(shù)的變化，設(shè)計的具體流程也會發(fā)生較大的變化。

好的合作方式是提供原則指導(dǎo)，而不是具體策略

我工作了15年，見過許多迭代版本的設(shè)計師與開發(fā)人員的交接流程。甚至在我剛開始從事設(shè)計工作時，我們將設(shè)計文件存儲在本地然后直接扔給開發(fā)人員，他們帶入自己的主觀審美將設(shè)計稿轉(zhuǎn)化為代碼實(shí)現(xiàn)。

經(jīng)過多年來的發(fā)展，設(shè)計師與開發(fā)者的合作方式已經(jīng)經(jīng)歷了許多變化。一些方法已經(jīng)通過實(shí)踐驗證效果較好—但是在不同的項目中，也許某種方法很適合與這個項目，但是對另一個項目而言使用起來卻很糟糕。如果我要撰寫具體的合作指南，那可能我每隔一段時間都要重新撰寫——所以我選擇了聚焦于設(shè)計原則。原則不僅可以經(jīng)歷時間的磨礪，適用的設(shè)計師類型以及團(tuán)隊規(guī)模也更廣。

下面的列表列出了我個人提出的合作原則，作為一名設(shè)計師，我每天至少花三分之一的時間與產(chǎn)品經(jīng)理和實(shí)現(xiàn)設(shè)計的開發(fā)人員一起工作。雖然多年來具體的方法和技術(shù)已經(jīng)發(fā)生了很大的變化，但這些原則仍然能夠抵抗時間的挑戰(zhàn)。

1. 開發(fā)人員是您的用戶

如果我們像關(guān)注用戶一樣關(guān)注開發(fā)人員如何使用我們的設(shè)計（和設(shè)計文檔）呢？

作為設(shè)計師，我們在思考產(chǎn)品帶給用戶的體驗時，總是考慮用戶的需求和痛點(diǎn)。除非你自己開發(fā)，否則最終用戶永遠(yuǎn)不會與我們的設(shè)計互動，他們將與開發(fā)人員基于我們的設(shè)計文檔構(gòu)建的最終產(chǎn)品進(jìn)行交互。這意味著我們在項目的這個階段所交付給的真正用戶是開發(fā)人員。

一旦我們將這個概念融入到我們的實(shí)踐中，關(guān)于我們工作流程的每一個決定都是以開發(fā)人員為中心開始的。與我們對最終用戶進(jìn)行研究的方式類似，我們可以在項目開始時與工程團(tuán)隊進(jìn)行面談，以了解他們的偏好、過程和痛點(diǎn)，并提出滿足他們需求的工作模型。

• 開發(fā)人員希望如何接收文檔？多長時間？通過什么渠道？
• 細(xì)節(jié)越多越好？書面文檔和可視化文檔之間的正確平衡是什么？
• 對于特定的開發(fā)人員來說，如何使用系統(tǒng)里怎么去工作的非可視規(guī)則的最有效方法是什么？這如何與產(chǎn)品的其他部分和組織內(nèi)的其他組織相結(jié)合?

團(tuán)隊可能為了方便協(xié)作會為項目建立一個維基百科文檔；也許這個維基文檔只是一個每周兩次的會議記錄，其功能更多的是作為記載會議的問答對話而無法形成具體的規(guī)范。有一些團(tuán)隊習(xí)慣在整理好所有設(shè)計文件后才會著手開發(fā)；還有一些團(tuán)隊比較靈活，會在開發(fā)迭代和實(shí)驗中不斷的完善規(guī)范。

既然我們在設(shè)計過程中要根據(jù)用戶的需求調(diào)整我們的設(shè)計解決方案，同理我們也應(yīng)該調(diào)整我們的設(shè)計工作流程，以適應(yīng)我們的開發(fā)合作伙伴的需求。

2.?唯一能確定的是：改變始終存在

設(shè)計師需要靈活處理項目，我們不僅要調(diào)整我們的流程以適應(yīng)不同的團(tuán)隊配置，而且還要隨著項目的展開調(diào)整我們的工作流。

除了極少數(shù)案例外，我們每次啟動新項目時都必須調(diào)整文檔和工作流。隨著經(jīng)驗的積累，我們總結(jié)形成了自己撰寫文檔的模版，這種模版在特定的環(huán)境下可能會很好用，但不一定在所有環(huán)境下都完全適用。一個模版不是處理每個團(tuán)隊的設(shè)計文檔和協(xié)作的好方法。

其次每個開發(fā)人員的習(xí)慣不同，有些開發(fā)人員喜歡和設(shè)計師面對面交流處理具體問題，還有一些開發(fā)人員可能更喜歡通過線上消息溝通或是投票表決來解決問題。

不是所有的事情都可以在設(shè)計師的掌控中，設(shè)計師唯一確定的是：每個項目都會存在變話。

有時候一些客觀的因素會影響你的工作，例如新同事加入團(tuán)隊，發(fā)布日期的突然調(diào)整，不可預(yù)見的平臺或網(wǎng)絡(luò)技術(shù)的約束。學(xué)習(xí)識別團(tuán)隊中無形的協(xié)作機(jī)制并讓自己做好快速調(diào)整工作流程的準(zhǔn)備，這也許不能在短期內(nèi)避免挫折，但是會讓你變得更好。

3. 設(shè)計永遠(yuǎn)不會終結(jié)

當(dāng)我們完成一個項目的設(shè)計時，其實(shí)我們只完成了一半的工作。

特別是在瀑布式開發(fā)的項目中，或是敏捷性開發(fā)的初級階段，有一種常見的誤解：即設(shè)計師的工作就是將所有屏幕顯示需要的圖繪制出來就完成了所有工作，例如設(shè)計產(chǎn)品模型或原型，會讓人誤以為設(shè)計師的職責(zé)僅僅是滿足開發(fā)要求設(shè)計師做的每個網(wǎng)頁圖片。但實(shí)際上設(shè)計師應(yīng)該不僅應(yīng)該考慮屏幕上顯示的頁面圖片，還需要分析背后的功能。

真正的挑戰(zhàn)開始于開發(fā)人員開始四處尋找關(guān)于我們設(shè)計的問題以及測試人員分析出設(shè)計師沒能預(yù)見的用例。添加的限制和規(guī)則越多，我們就越難在這些條條框框容納新的需求，并同時保持體驗的簡潔與明晰。那就是關(guān)鍵時刻：大多數(shù)團(tuán)隊能畫出合格與優(yōu)秀設(shè)計師之間的那條線。

我見過太多設(shè)計師推卸責(zé)任——這絕不是一件好事。如果最終的體驗沒有按照我們的設(shè)想實(shí)現(xiàn)，那么這就是包括我們設(shè)計師在內(nèi)所有人的責(zé)任。我們的角色是創(chuàng)造易于使用的體驗方案，而不是看上去漂亮的界面。這意味著我們需要為團(tuán)隊實(shí)現(xiàn)的最終產(chǎn)品負(fù)責(zé)。

4. 少一點(diǎn)，但更好

當(dāng)產(chǎn)品經(jīng)理砍掉產(chǎn)品某些功能來得到一個最小可行性產(chǎn)品時，設(shè)計師并不會感到沮喪，而是將它變?yōu)樘嵘延泄δ芗蟽?nèi)體驗的機(jī)會。

富有遠(yuǎn)見的德國設(shè)計師Dieter Rams時二十世紀(jì)最受認(rèn)可和最具影響力的設(shè)計師之一。作為功能主義的堅定信仰者，他對設(shè)計的理性認(rèn)識可以概括為他的著名短語：“少一點(diǎn)，但更好?！彪m然他當(dāng)時顯然是針對工業(yè)設(shè)計，但這一概念對于我們當(dāng)今創(chuàng)造的數(shù)字產(chǎn)品和服務(wù)仍然適用。

隨著設(shè)計的發(fā)展，產(chǎn)品經(jīng)理開始優(yōu)先考慮功能，這時設(shè)計師會發(fā)現(xiàn)他們的許多工作都被縮水為最小可行性產(chǎn)品，包括他們對產(chǎn)品的最初設(shè)想和經(jīng)驗，這會令人感到沮喪。而我所知道的最優(yōu)秀的設(shè)計師會將這種沮喪轉(zhuǎn)變?yōu)闄C(jī)會，他們知道提供更少的功能是完全可以的，只要能提升體驗即可。

對于我們設(shè)計師而言，需要設(shè)計的功能變少意味著：

• 我們能將更多的時間花在更少的設(shè)計方案上使其更好：例如過場，狀態(tài)，動畫，復(fù)制。
• 我們能更緊密地和開發(fā)人員合作以保證我們正確傳達(dá)了初始設(shè)想。

5.?激情具有感染力

在一些公司中，開發(fā)人員不參與早期的構(gòu)思、設(shè)計探索和產(chǎn)品經(jīng)理的戰(zhàn)略層次討論。我們?nèi)绾尾拍軒椭麄兝斫夂皖I(lǐng)會，從而真正了解正在開發(fā)的功能?

設(shè)計師代表了團(tuán)隊中用戶的聲音。我們常常理所當(dāng)然地認(rèn)為，我們有能力設(shè)身處地為用戶著想，而忘記了我們可以在團(tuán)隊中傳播這種觀點(diǎn)和看法?？梢允俏覀冊谘芯窟^程中從用戶那里聽到的一個小故事；或者是某個人的個人故事，因為我們所創(chuàng)造的產(chǎn)品改變了他的生活方式。

我們的同理心，對用戶的關(guān)注以及我們的熱情—這些都是寶貴的資源，我們可以用來啟發(fā)開發(fā)人員，幫助他們理解某個特定功能應(yīng)該如何工作，并且了解它將如何影響人們的生活。

設(shè)計是一項團(tuán)隊活動

（謝天謝地）“搖滾明星設(shè)計師”的舊模式正在消失。隨著數(shù)字團(tuán)隊的增長與項目變得更加復(fù)雜，設(shè)計師因其協(xié)作技能和團(tuán)隊支持而受到重視，而不是僅僅繪制具體的交付物。定義團(tuán)隊之間的合作原則才是我們執(zhí)行具體工作的第一步。

原文地址：https://uxdesign.cc/5-principles-for-better-designer-developer-collaboration-36b4094887db

本文由 @喵吉斯蒂 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議