江湖笑，恩怨了；人過招，笑藏刀…
江湖笑，愛逍遙；琴或簫，酒來倒…

相信大家此刻一定輕聲哼起了周華健的《江湖笑》，哈哈！日出東方，唯我不敗！

有人的地方就有江湖，有江湖的地方的就會有恩怨。在產品的江湖中，“產品”、“設計”、“開發(fā)”這三大門派常常是刀光劍影，血流成河。作為一名設計師，如何才能練就“御劍之術”，行走江湖來去自如？

一、江湖背景

一般性的互聯網公司，一條產品線大概能有20人左右的團隊。主要由“產品”、“設計”、“開發(fā)”三大塊組成（運營和銷售暫不談），詳細的工種配置可參考下圖。

產品線工種配置

二、恩怨情仇

產品開發(fā)通常的工作流程為：產品經理和產品設計師確定“產品功能需求”并輸出“產品需求文檔”。交互設計師接過文檔，根據其內容進行框架結構的設計，對于文檔中不合理的內容或可進一步優(yōu)化的點，會及時反饋給產品人員，經商討確認后，交互需調整設計方案，并最終輸出“交互設計文檔”（Demo）。

產品開發(fā)工作流程

• 由于業(yè)務上的要求，需要增加新的功能；
• 產品人員發(fā)現漏掉了一些東西；
• 前端人員說這個交互樣式實現不了；
• 開發(fā)人員找到邏輯漏洞；

面對這些問題，產品人員需要調整需求文檔，交互稿也會隨之進行調整，調整后會及時的發(fā)布出來（發(fā)布到公司的交互原型庫中）。這時，矛盾產生了：

1. 交互稿內容調整了，下游同事不知道

下游同事不知道交互稿調整內容，將會導致已做完的工作進行返工，增加工作量。產生這種情況，主要有以下幾個方面的原因：

• “產品評審會”結束后，產品和交互馬上開始新的產品任務，工作時間上排的很緊；
• 對開發(fā)的分工并不是很了解，無法判定某個內容的調整會涉及到哪些開發(fā)人員；
• 一天下來，五六個“間斷性”的調整內容如果通過即時通訊工具或郵件告知下游的十幾個同事，中間再產生往來交流，將花費近?的工作時間；
• 大大增加了溝通成本，降低了工作效率，長此以往對設計師來說也是一種傷害。

2. 需求文檔與交互稿內容有偏差

在產品開發(fā)中，開發(fā)人員通過交互稿來確認產品功能的框架結構，而詳細的功能規(guī)則通過查看需求文檔來完成。在這一過程中，開發(fā)人員常常發(fā)現需求文檔與交互稿存在不一致的地方，不知道以哪個為準。每次都要去問交互或產品，很麻煩，也很惱火，主要是因為產品與交互之間沒有協調好。

• 產品人員調整了需求文檔，忘記告知交互；
• 產品人員調整了需求文檔，告知交互，交互忘記改了；
• 交互與產品商討確認后，交互改了，產品忘記調整需求文檔；
• ……

三、冤家宜解不宜結

在嘗試了多種方法之后，終于摸索出了一條可行的解決方案：

解決方案

Step1：

產品人員對需求文檔進行了變更，將變更內容告知交互設計。

Step2：

交互設計根據需求文檔的變更，對交互稿作相應的調整。將每次的調整內容進行記錄（包括時間、內容、變更人等）。一天下來，將記錄的內容進行匯總，發(fā)布變更群郵件，且對交互稿進行更新。

記錄匯總模板

Step3：

相關涉及人員查看后，一方面知曉最新變更內容，另一方面發(fā)現有錯誤或遺漏的地方也能夠及時的反饋給產品人員和交互人員。

Step4：

當變更內容比較多時，需要在交互稿的頂部新增一個“交互變更記錄”的頁面，用于存放每日的交互變更記錄，方便項目相關人員的查閱。例如：

交互更新記錄