中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

在上一篇文章中，給大家講述了交互說明的基礎信息（包括元素的限制條件、狀態、操作和反饋），還沒看的同學，先去看上一篇哦~今天為大家詳細講述交互說明中那些零零散散卻又很重要的點，以及在撰寫交互說明過程中的一些注意事項。

一、交互說明包含什么？

我們先整體回顧下交互說明包含哪些內容：

二、交互說明中那些最容易遺漏的點

以下內容，是我自己實際工作中曾經遺漏過的，所以總結記錄下來，隨時提醒自己，一方面提高工作效率，另一方面保證了輸出質量。（放在其他里，是因為比較分散，不好匯總，并不是它不重要喲，這些往往是最容易遺忘的點）

接下來，逐一為大家解析：

1. 用戶身份

當某些功能并非開放給全局用戶時，需明確告知開發人員，哪些用戶有此權限。如果文檔中不注明，開發人員會默認認為該功能開放給所有用戶。所以當涉及用戶權限問題時，需明確的在交互文檔中標注清楚，哪部分用戶有權限使用。

舉例1：某些功能僅針對會員開放

如：視頻產品的去廣告功能、微博的首頁置頂、微博來源自定義、Bear的多設備同步等。

舉例2：某些功能僅針對某類身份的用戶開放

如：知乎中，開通專欄的用戶，才有權限使用專欄管理&發布文章等功能。

舉例3：某個等級以上的用戶

如：很多平臺以等級劃分權限，以此激勵用戶去不斷使用產品，去升級。最直白的例子就是游戲，不斷闖關打怪，解鎖新關卡和新技能。

2. 站內信&推送

當完成某步操作后，是否需要觸發消息（站內信&推送）通知用戶。以及通知用戶的文案寫些什么（文案一般需要運營同事來輔助，但是需要產品寫個打底文案，告知場景、目的是什么，然后由運營人員來優化話術）。

舉例1：用戶申請身份認證，當他提交審核后，會自動觸發站內信，告知用戶：信息已提交審核，審核時間多久。

舉例2：當用戶身份審核通過后，后臺觸發站內信和推送，告知用戶：審核已通過，點擊查看詳情。

注意：在寫站內信和推送時注意不要遺漏信息哦，給誰發、什么時間發、發什么。如下提供一個站內信&推送框架，供大家參考：
（1）站內信模版：發送對象+內容（xx字以內）+發送時間+（跳轉鏈接）
（2）推送模版：推送對象+標題（xx字以內）+內容（xx字以內）+推送時間+跳轉鏈接

3. 數據埋點

很多剛入行的朋友，不太注意數據埋點，這樣就會導致產品上線后，才發現想看的一些數據沒有做統計，由此導致部分初始數據的丟失，最終數據分析不夠準確。所以在功能開發時，便要進行數據埋點，為上線后數據分析提供基礎。常見的數據埋點，如：追蹤用戶的行為軌跡，查看關鍵路徑轉化率，分析某個活動對日活注冊量的影響等。常見的數據埋點方式包括：公司自己后臺做統計和借助第三方數據統計平臺（如：友盟統計、百度統計、GrowingIO、諸葛IO等）

但是也不能盲目的進行數據埋點，因為工作量不小。所以在埋點前，一定要明確埋點的目的，通過這個埋點，你想得到什么數據。

4. 首屏位置

標出首屏位置，為設計師提供設計參考。

針對較長的頁面，需要在原型圖中標注出首屏參考線，以便告知設計師，在設計時要把參考線上方的內容放在首屏。這樣可以省去一部分溝通成本，也讓設計師更理解你的原型，以保證最終輸出物與預期相符。

5. 新老版本兼容

這點有些偏技術，大部分剛入行的朋友都不太想得到。當然，這里說的新老版本兼容更偏向產品層面。比如：

舉例1：在新版本中新增加了一種內容類型（如視頻），那么該內容在老版本中如何展示？（不顯示？顯示圖片？還是…）

舉例2：當某個功能明確計劃在下版本開發，那么在設計本版本時便要考慮，老版本如何展示及提醒用戶去升級？如：之前做的一個【提現】功能，計劃在下版本開發，故在本版本設計時，做了如下處理

說到這里，想到另外一個偶爾會遇到的情況：老數據處理。

比如，你的產品最初做的時候部分字段不夠規范（均是手動錄入的自由文字），后期想進行標準化管理時，這時候就涉及到老數據的問題。對老數據規范化處理，3種解決方案：

1. 人為處理老數據進行標準化；
2. 根據規則程序去洗數據；
3. 不做處理，僅對新數據規范。

注意：對于時限性比較強的數據，在處理老數據時，一般都是有時間限制的，太久遠的數據對平臺意義不大。但還是要具體情況具體分析哦。

三. 注意事項

1. 盡量使用真實數據

使用真實數據，更有帶入感，更能還原真實場景。而且在真實場景中去設計，不會遺漏一些特殊狀態的處理。

2. 避免過長的文字說明

可以用圖片表格講清楚的內容，盡量不要使用很長的文字，因為大家沒有耐心看完。

3. 注意交互說明的排版

整體排版清晰，更有助于開發人員的閱讀。關于排版，可查看拾月之前的文章哦《什么樣的原型更受開發歡迎》。

4. 不遺漏特殊狀態的描述

再次強調，特殊狀態不要忘。很多需求的改動和增加，都是因為特殊狀態忘記了，導致最終增加開發的工作量。

5. 偶有遺漏是正常的

有同學看到這條，可能會覺得我寫的自相矛盾。一邊在強調要寫完整不要遺漏，一邊又在說偶有遺漏是正常的。
其實這條是想告訴大家，保持一個好心態！畢竟誰也不可能把所有情況都考慮到，總會有一些特殊情況，就如同程序員不可能沒有bug一樣啦。所以大家在寫交互說明時，遺漏了也不要過于糾結，及時完善，解決問題是第一位。踩過坑，我們認真記錄下來，總結分析原因，下次就會注意了。

四、總結

以上，給大家講述了交互說明中一些零碎但很重要的點，以及注意事項，希望對大家有所幫助。

本文中提到的內容僅供大家參考，還是需要活學活用，具體問題具體分析哦。至此，相信大家已經清楚的知道交互說明需要寫些什么了，希望每個人都可以建立屬于自己的交互checklist。在每次寫完文檔后，對照檢查一遍，有效防止遺漏的同時減少撕逼次數（這是我自己和開發兄弟姐妹們搞好關系的法寶，全都奉獻給大家啦）

感謝耐心閱讀，希望本文對你有所幫助。

相關閱讀

1.?一份完整的交互說明包含什么（上）

2.??什么樣的原型更受開發歡迎？

作者：拾月，4年產品交互設計經驗，微信公眾號：用戶體驗研究所（ID：PM_Cynthia）

本文由 @Cynthia拾月 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 unsplash，基于CC0協議