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

工欲善其事，必先利其器，在產品工作中，我所理解的具象的“器”便是原型、需求文檔、各類圖表等，雖然這些交付物只是輔助、起著最基本的作用，但必要的總結和思考可以把這幾把“器”磨的更鋒利，在戰（ping）場（shen）上（hui）高效取勝、減少傷（si）亡（bi）。

原型圖

主要交付對象：開發、測試、UI設計師

繪制注意點：

1. 中、低保真的原型，配色以黑灰白為主。超鏈接、按鈕、其他需著重突出的元素可適當用紅或藍色。以免顏色過多干擾UI設計師發揮，給其他人員演示原型時也不會因色塊過而顯得重點分散，減輕查看者的理解成本。
2. 控件規范使用。該用什么控件就用什么，避免UI誤解，便于開發和測試理解，降低理解成本。例如按鈕習慣用圓角長方形，若突然換成直角，則在特殊場景下，UI可能會誤解為標簽；單選應該用Radio button，多選應用checkbox，亂用兩者可能導致功能點被開發錯。
3. 涉及頁面都顯示出來，盡量不用動態面板隱藏彈層及頁面。我目前是連提醒彈框都會單獨開一個頁面（允悲臉），并不是因為懶或者不精通動效，而是這樣開發、UI、測試查看時才不會漏頁面。雖然頁面增多了，動效也不炫酷了，但疏漏少了。畢竟技能要分場景使用才能錦上添花（比如你要演示給boss看時……）
4. 頁面之間加跳轉鏈接。上一條說的是頁面內動效盡量少，為的是降低出錯率。這一條說的是頁面間的跳轉鏈接一定要加上，為的是減少溝通成本。
5. 頁面上盡量模擬真實場景下的字段和數據。例如，我在做產品初期就出過這樣的烏龍，由于在設計原型時很不過腦的用“xxx企業”當占位字段，因為字數少，當時在有限的寬度內放置了三個也排列的很清爽。UI那關也沒攔住，直接按我原型排列了。結果可想而知，一般企業名十幾個字都很常見，一行放不下三個企業名，前端哥哥很負責任的自動折行顯示了，導致產品驗收的時候才丑拒提了bug，如果當時畫原型時把自己置入實際場景，就會少了后面這些不必要的改動。

原型舉例（隨手YY的）:

*功能設計碎碎念：這條其實算不上注意點，而是自己畫原型時的小套路。在設計功能時，一般我會遵循畫縱向形成閉環+橫向盡量延伸。

縱向操作閉環指的是除了考慮某一操作本身的設計（操作起始點——操作結束點間各個節點），還要考慮改操作會輻射到的其他元素。比如某toB產品新增了附件上傳需求，那么除了在相關頁面加好上傳功能、上傳成功／失敗的顯示、刪除／重傳的交互等基本點以外，還要考慮上傳完，其他協作用戶（非上傳者）是否也可以看到，要在頁面哪個位置看到。

橫向盡量延伸指的是對縱向梳理的每個節點進行窮舉。例如上傳功能這個節點，還要考慮上傳附件的格式規定、上傳附件的數量規定、上傳完文件名稱顯示是要直接提取文件名，還是統一顯示成某個字段、上傳成功／失敗的顯示、刪除／重傳的交互；查看附件這個節點，是要預覽查看，還是下載查看等等。

流程圖

在工作中，我一般用流程圖來闡明系統邏輯或功能操作邏輯。其中又因描述粒度的不同，而分為系統流程圖和功能操作流程圖。

1. 主流程圖

（1）主要交付對象

開發／測試／運營／業務／UI

（2）特點

偏重描述大邏輯，不需要拘小細節，一般用于初次系統講解或次相關人員培訓。

粒度很粗，偏重描述大邏輯，不需要拘小細節，其中大多數節點可細化出一個功能流程圖。下面以某外賣從選擇商家到下單完成的流程來舉個栗子：

例如：

只描述最主要的步驟，將系統中某個環節概述清楚即可。

2. 操作流程圖

（1）主要交付對象

開發／測試

（2）特點

粒度細，至少描述完全實現功能所需的每步操作，根據需要也可細化到異常狀態處理操作。

以上圖中對應功能操作流程圖為例：

因未從事過外賣產品，并且為了方便舉例，粒度也沒有特別細，只包含了基本操作，根據公司文檔交付習慣不同，若粒度需更細，也可加入操作異?；蚴。╡g：網絡中斷反饋；下載失敗處理；未保存輸入內容里開頁面等）流程。

繪制tip：可在流程圖節點旁邊適當添加注解，尤其是系統流程圖，這樣有助于查看者理解。

個人感覺，查看流程圖時比查看原型圖更容易在腦中建立整體回路，而在重要節點旁加上注釋或其他信息，就更方便查看者聯系前后節點場景進行理解，也更加會留下印象。

泳道圖

特點：

• 流程中涉及2個及以上角色；
• 多個系統階段；
• 多用于描述業務流程

在流程圖中劃分用戶角色或系統階段時，會加入泳道，即繪制成泳道圖。

繪制tip：一般我在繪制時用橫向劃分角色，縱向按時間順序劃分業務或操作階段。若泳道長度較長，可給不同角色使用不同顏色，以便于下拉至看不到泳道標頭的時候快速區分對象。

例如：（下圖中對涉及商業信息的字段模糊描述）

?產品設計說明書

1、交付對象

開發、測試

2、特點

產品講解從粗到細，快速建立產品概念

其實平時工作中不常寫產品說明書，之前接觸過的的產品說明書更像是先于PRD交付給開發人員查看的的產品講解物。拿我們的2B產品設計說明書為例，一般包含：

1. 文檔概述
2. 業務場景描述：場景圖、文字
3. 系統流程描述：系統流程圖、流程節點表
4. 系統邏輯描述：改動邏輯整理表（若有）、新增邏輯整理表及描述、其他補充邏輯
5. 產品規則：編碼規則（例如合同編碼規則、訂單編碼規則）+費用計算規則+其他規則
6. 主界面設計說明：主要界面原型圖、對應原型界面描述

個人覺得產品設計說明書就像是各種產品說明的大雜燴，用于先為查看者（特別是初次接觸該產品者）建立產品概念，之后由粗（業務場景）到細（界面說明）逐步推進，使查看者可以快速進入產品狀態，說明書中要放什么內容，則要視部門合作習慣等因素而定。

系統操作手冊

交付對象：運營人員、業務人員、用戶

在toB產品中，由于流程復雜、參與角色眾多，編寫不同角色對應的系統操作手冊能夠幫助其快速掌握操作流程。下面是筆者慣用的編寫步驟：

1、編寫文檔概述（非必寫）

文檔概述一般包括網站背景、系統簡介、手冊應用對象、專業名詞及縮寫解釋、軟硬件環境、版權聲明等。

2、 撰寫操作說明

（1）拆分流程

按照主流程進行順序，依次劃分出若干個子模塊。例如注冊登錄流程、認證開戶流程、資產登記流程等等，至于異常情況處理可單獨匯總為一個模塊，好處是方便查找，也可視情況分布在其他流程中，融合到實際操作場景里。

（2）分解功能點

對子模塊按照操作順序拆分出主要功能點。

（3）配圖及文字說明

• 配圖：截取流程中依次會跳轉到的頁面（重要的提示彈框也可以截?。?，將該頁需操作的區域或元件用紅框框出。在同一頁面不同位置進行連續操作，可用箭頭指引。截取的圖最好進行圖注，一是可以讓使用者查找時快速定位，而是方便理解當前頁面用途。
• 文字說明：寫清楚當前處于哪個頁面，需要進行哪個（些）操作（若需更詳細也可對該操作要求進行講解，例如必填／非必填等），操作完成后相關流程會進入什么狀態，接下來會進入哪個頁面。重要提示可用醒目的紅字標出。

例如：

UI驗收圖

交付對象：開發、測試

通常UI設計師們按照產品原型給出效果圖后，產品要進行驗收，驗收后才能交付給開發及測試人員。

驗收注意事項

個人總結UI驗收主要需注意以下幾點：

1. 元素是否畫全，字段是否正確
2. 元素間“組”的關系是否保留：相關的元素要相近，有時UI為了整體布局美觀會將某些元素均勻分布，但忽略了它們間的相關性。
3. 頁面中重點是否突出：或弱化的元素是否達到效果：頁面中第一眼望上去應該被關注的模塊或元素是否在視覺上被突出了？有沒有產生喧賓奪主的不佳情況？
4. 頁面中需弱化的元素是否達到效果：不希望用戶注意到或使用率很低的元素（例如舉報按鈕）是否被弱化？
5. 設計是否符合用戶操作習慣：這里指的主要是B端用戶，因為對于大部分此類用戶，習慣性的操作可以讓效率更高，或者線下的相關操作長期遵循某一模式，線上用同樣方式可以降低理解成本，便于快速上手。此時在審查UI圖時，美觀就不是放在第一位的，而應更側重于用戶習慣。比如合同的相關信息展示就最好按照紙質合同來布局。

為了避免驗收出現上述問題，可以在交付給UI原型中加以特別標注，或者UI設計的過程中緊迫盯人、加以提醒（微笑），當然最好的方式是在產品UI設計前期培訓設計師們，為其講清楚場景或業務需求，這樣設計師童鞋們在設計的過程中自然會更佳貼近需求。

其他交付物

當然根據產品類型、公司規程、合作習慣的不同，還存在著許多其他交付物。例如業務節點表（適合匯總對比業務各階段的狀態、相關要素的增減情況）、字段訂正表（金融等相關產品頁面上的字段都需要風控過審）、場景演示圖（用人-人／人-物等模型演示產品場景，適合做產品初級培訓）……不過所有交付物的作用其實都是更好的傳達自己的想法或需求，所以交付物的形式也不必拘泥于形式，畢竟黑喵白喵，抓到老鼠的就是好喵～～～

最后，以上僅為個人工作中對交付物的小總結，未考慮全面的地方希望大家指導溝通，本文也應該會在未來有所更新。

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