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

不管是前臺產品經理還是后臺產品經理，都離不開原型設計，原型是各個崗位之間協同溝通的重要文檔之一。那么該如何繪制原型設計，做到提效呢？作者從繪制原型及說明標注的提效小技巧進行分享，希望對你有所幫助。

不管是前臺PM還是后臺PM，在工作中或多或少都要進行原型設計。原型可以說是產品、開發、測試之間進行交流溝通最重要的文檔之一，那么怎么把原型畫得又快又好呢？

從設計流程上看，原型設計節點包括但不限于梳理需求大綱、規劃頁面結構、完善信息結構、繪制原型及進行說明標注。前面三個節點個人有個人的方法，今天主要想和大家分享一下后兩個——繪制原型及說明標注的提效小技巧，希望對你有幫助。

一、制作全局說明

通俗地說，全局說明就是那些你懶得寫第二次的東西。比如說網絡異常/加載失敗/沒有數據，這些這是任意頁面都可能會碰出現的情況，如果分開寫，每個頁面都要寫一次，改的話得同時改很多地方，費事費力而且不利于需求的統一管理。所有，把這些通用性的東西寫在一個地方，既可以簡潔原型文檔，降低開發、測試、設計等人員的閱讀成本，又可以少寫點字，何樂不為呢？

全局說明可以是適用于全文檔的，也可以是適用于某個迭代的。像是一些和迭代相關度高的名詞解釋。寫在全文檔性的說明里就有些冗余，寫在迭代內全局說明中就剛剛好（個人見解）。

根據通用性，可以將全局說明分成兩種：通用說明和業務說明。通用說明是在大多數產品/頁面內都可以通用的，比如頁面狀態、加載狀態、通用手勢、彈窗遮罩等；而業務說明則不同，這類說明和業務高度相關，相同內容在不同業務間有較大差異，比如時間展示規則、昵稱長度等。下面給大家舉幾個栗子：

1. 通用說明

移動端全局說明具體可見浪子寫的文章，很詳細：https://zhuanlan.zhihu.com/p/22270169

2. 業務說明

最近一條消息時間展示規則：

圖中是微信的展示規則。手動試出來的，不對的地方歡迎指正。

最近一條消息展示規則：

圖中微信的展示規則。手動試出來的，不對的地方歡迎指正。

產品上架/下架/瀏覽時間展示規則：

第一版設計的規則里跨年時間也是帶「時時:分分」的，后來因為產品列表地皮實在放不下，就把后面的具體時間砍掉了（都跨年了，具體時間沒那么重要了叭）。所以具體的展示規則是和實際系統密切相關的。

二、建立字段說明表

可以把用到的數據用表格的形式羅列出來，清晰且一目了然。

三、取用元件庫進行原型繪制

在繪制原型時，有一些控件會被經常用到。如果每次用到都重新制作，不僅無法保證交互效果的統一性，而且會占用很多工作時間。為了咱岌岌可危的發際線，我向大家使用Axure元件庫功能。

什么，你說Axure自帶的元件庫丑？

網上有不少大公司的設計的元件庫，找個你喜歡的導入就行。比如螞蟻金服、餓了么、有贊等。

什么，你說懶得找？

那我這給大家推薦幾個。

1. Vant 移動端組件庫

非常全面的一個組件庫，自帶交互。除了通用組件，還有帶有電商業務組件，用來繪制移動端原型很方便。

設計網站：Zan Design

資源下載：Zan Design 移動端元件庫

2. Ant Design 移動端組件庫

支付寶風格的組件庫，組件沒有Vant那么多，但是通用性強。

設計網站：Ant Design

資源下載：Ant Design 移動端元件庫

3. Ant Design 后臺組件庫

這個不用多說了吧，后臺產品必備。UI 樣式可配置，拓展性強，大多數產品風格都能輕松適應。

設計網站：Ant Design

資源下載：Ant Design 移動端元件庫

大廠設計的組件庫當然不錯，但是用起來也會碰到一些問題。比如和自己的設計風格不一致呀，有無用的組件呀，部分組件需要微調等等。所以建議每個PM都自己積累元件并長期更新。不用一次完成，平時工作中碰到新的就維護進去，這樣不會占用很多時間，而且可以保證原型整體的視覺統一。

我司后臺部分用的是螞蟻金服組件庫，基本不用修改，所以沒有制作元件庫。APP端因為有些特殊組件，通用組件庫里沒有就積累了一些，基本是Ant Design 和Vant 的混合版，這里就不獻丑了……

四、建立交互需求說明庫

如果系統用的是某個開源的UI項目的話，組件的交互基本都是確定好了的，交互說明文檔可以少些甚至不用寫。如果沒有用開源項目，所有的輪子都是百度或者自己造的話，那交互說明文檔就必不可少了。碰到一些常見、使用頻率高的組件，可以建立一個“交互說明庫”，用到的時候貼一個鏈接或者copy一下，可以減少開發的理解成本。

PM或多或少會碰到被開發圍攻的情況，大部分情形可能都是因為需求描述不準確導致的。如果有一個規則模板參考，是不是就可以減少遺漏的情況呢？

需求說明基本分為三個部分：需求說明、交互說明、交互預覽。

1. 需求說明一般包含：前置事件、后置事件、初始化、加載/分頁、排序、正常和異常結果等，具體看組件類型；
2. 交互說明一般包含：不同組件的說明會有較大差異，如果想描述得很詳細，可以參考開源項目的API文檔；
3. 交互預覽一般包含：輸入狀態/選中狀態/聚焦狀態、禁止狀態、加載狀態等等。

五、進行交互自查

輸出完后先對照交互自查表把每個細節梳理一遍，讓原型更加更加全面和縝密。

自查表是之前存的，忘記是哪篇文章了。如果你知道的話歡迎補充～

好了，以上就是個人平時畫原型積累的一些技巧和感悟，完全是出于個人習慣和主觀經驗得來的，歡迎評論區一起探討。

參考文章：

1、浪子，善用Axure寫PRD，全局規范一個都不能少

2、交互設計自查表