產品原型如何標註更變？

01-29

謝邀。

專業做法一般來說溝通效率不夠高。

我的做法是：

做一份全新的需求，然後跪下來求開發人員忘記之前的版本。

我一般用Axure畫原型。第一頁我會命名為『修改記錄』，此頁按日期記錄了原型文檔從誕生開始涉及到的所有修改點。其實這一頁的主要目的是為了備忘，用來跟需求方討（si）論（bi）。

既然是原型，那就是還未進行到視覺設計和開發階段，原型的修改是隨時可能發生的，沒必要標註，保證設計、開發人員拿到的是經過討論確認的版本即可。只要修改記錄里保存了相關的修改點，然後面對面溝通是最高效的。

如果說標註的話，我一般喜歡在Axure第一頁寫上版本變更信息，包括版本號，日期，變更內容，變更原因。已經養成了每天存一個版本的習慣。如果當天有重大改變還可能一天內有兩個到三個的版本號

謝邀

我一般是先更新完UI/原型/需求文檔，然後發郵件，直接在郵件里說明變更……

其實分兩種情況，一種是開發人員還沒做到這塊，那這裡只是個變更而已，他開發這塊的時候你就是變死過去，他看到的還是最終版的原型/UI/文檔，所以對他來說幾乎沒什麼影響（如果涉及後台邏輯的東西，肯定發完郵件要去當面說明）

一種是開發人員已經做完這塊，那這個就等同於新需求，我一般就是拉上測試做擋箭牌，分擔一部分火力。就這樣，具體怎麼做呢？很簡單，

我：測試爸爸，這裡需求變更了，你要按新需求來測試啊。

測試爸爸：跪下

噗通～

然後測試爸爸拉我去找開發叔叔：開發，產品又有需求變更了，我這已經過了新標準。

開發叔叔：不是吧，那你幫忙把之前打過來的BUG關掉吧

測試爸爸：好的，那我先走了。

開發叔叔殺氣騰騰地說：好的，後面那產品，你留一下，我和你明確一下需求

測試爸爸：那我也一起再確認一下吧

就這樣，我又一次因為測試爸爸壓場，所以保住了一條性命。

什麼？你問我為什麼測試不和開發一起砍我？

因為功能驗收標準是我們定啊～