起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識在畫原型之前，請先擬好“流程圖”和“信息結構”
上一篇《做交互，別急著畫原型》中說到畫原型前先要理解功能，并且從用戶角度思考如何繪制適合用戶的流程圖。而今天將和大家講講，畫原型圖前比較重要的兩個因素：“流程圖”與“信息結構”。
首先，當拿到一個功能需求時，需要大致知道這個功能是干什么的：哪些角色有需求要通過這個功能來完成什么目標（具體的用戶需求不細說）。如果這個整體方向都不能確定，那這個需求要么是不完整的要么是不成立的。在這種不確定需求的情況下畫原型，過程肯定是磕磕絆絆甚至是無用功的。
（所以，如果設計師接到的是這種不確定的需求時，要么說明原因選擇不做，要么在有足夠多時間的情況下自己去分析需求。）
我們先假設有這么一個功能：大致是給團隊的成員協調配合完成任務的那么一個功能，其中任務需要被發起，被完成和被批閱。而且它有可能存在以下兩種情況：
情況1：
只涉及到兩種角色，“角色A”既是任務的發起者也是任務的批閱者，“角色B”是任務完成人員。屬于來往關系。
情況2：
涉及到三種角色，“角色A”只是任務發起者，由“角色B”來完成，進行批閱需要通過“角色C”，屬于上級關系。
所以，在設計開始前必須確定該功能是情況1呢還是情況2呢甚至還有情況N，不同的情況會導致我們的流程圖的方向有所不一樣，最終導致原型圖的不一樣，因此整體方向很重要。
這里我們不糾結哪個情況是對的，我們選擇情況2，并且進行簡單細化：
- 角色A：簡單地發起任務
- 角色B：可以拒絕任務，也可以接受任務
- 角色C：批閱任務是否完成
整理而得的流程圖如下：
通過這個流程圖，就可以比較清晰的知道各個角色之間的關系，然后對每個角色涉及到的操作進行“加工”：
- 用戶A布置任務可能包括：任務標題、任務內容、任務時間等等
- 用戶B的任務涵蓋任務標題、任務內容和任務時間等等，并且對任務有一定的操作
- 用戶C等到任務完成后批閱任務是否通過，如果不通過原因是什么
- 以及等等（冥想中~）
更加可視化可以整理出信息結構（以用戶A為例）：
通過這么一簡單整理，每個流程步驟可能涉及的頁面或者是內容就都有了。
那為什么要搞出個這么一個所謂“腦圖”的東西呢？
我們在做原型時，肯定是通過流程來確定頁面，但是流程上并沒有說角色發起任務需要填寫哪些信息，需要包含哪些內容，就算我們腦子里有這些信息，但是我們也有可能會遺漏，所以在做原型前更好地是思考用戶操作會涉及哪幾個頁面，頁面里有哪些信息，哪些操作是如何跳轉的，而信息結構圖能很好的解決這一點：頁面結構，頁面內容，頁面關系和頁面狀態等。
剩下的就看把流程和內容應用到原型上的功力了。做原型時更多的從用戶角度思考，并且參考一些交互原則，同時平時可以多觀察觀察其他app，不斷積累。不過也別想一次性就把所有細節都考慮到，大體方向確定了，后面的細節可以慢慢補充，慢慢完善。
總結
拿到功能先要理解功能，理解用戶在用這個功能時會是怎么操作的，用戶之間的關系又是怎么樣的，也許腦子里有大概的流程，但是更好的辦法是把流程畫出來，畫出流程后，對每個流程中可能涉及到的操作和內容進行整理，將這些內容合理的整理到直觀的信息結構中，然后在帶入到具體的頁面，并且不斷思考流程和改進細節。
先有方向才有框架，有了框架才能填入內容，有了內容才能不斷進行更細致的調整和修改。
本文由 @交互の故事 原創發布于人人都是產品經理。未經許可，禁止轉載
提問：文章中流程圖之前的是什么圖呢？
大部分產品經理的基礎技能不扎實，產品做出來了但是方法論基本功并不扎實，很多都是借鑒參考。
產品從需求開始，功能是用來滿足需求的，而業務流程又是對功能的具體落實。
信息是指實現功能需要具備的元素是什么，需要什么信息、什么操作，將這些信息、操作進行系統化的、結構化的整理就是信息架構了。
最后再把這些信息、操作使用元件、控件布局到頁面上，就形成了產品原型。
一般順序是
需求列表——功能列表——業務流程圖——信息架構圖——頁面流程圖——原型——UI設計稿——產品（代碼實現）
前輩，從0到1時是先畫任務流程圖還是先設計原型？請您幫我解惑呢
一般大部分產品經理都是先原型后流程圖，因為往往都是找競品參考、修改的，你懂的，這樣做產品往往都是先做原型再畫任務流程圖，畫圖的目的是為了寫產品文檔
如果你真的是0-1沒有啥參考借鑒的，你肯定是得先搞清需求是什么，然后用何種功能滿足需求，這個功能是具體如何實現和展開的，這就是流程圖
為了實現這個功能，用戶需要依據什么信息做判斷和操作，對這些信息進行結構化系統化的整理，這就是信息架構了
最后才是根據信息確定具體的頁面元素，畫原型
非常棒 產品經理越早跨越畫圖成長越快 微信hengshuivick。學習溝通
來過、受教、感謝
在梳理最初的任務流程后開始整理分析了流程中的結構內容元素，可以在分析整理結構元素后在補畫一個頁面流程圖，這樣在進行原型制作時可能會更清晰。
又讀理一遍想問腦圖是什么？
請問拿到一份用戶的需求大雜燴，應該如和梳理呢（多角色的后臺管理系統）。頁面流程圖、業務流程圖、功能結構圖、需求列表、功能列表、邏輯流程圖應該先畫哪個。。。
這些相關的邏輯梳理工具，在實踐中的使用順序，個人一般如此處理：
1.需求列表 2.業務流程圖 3.功能列表 4.功能結構圖 5.頁面流程圖 6.邏輯流程圖
1、2、3、4一般是產品經理用得多，5是交互設計師用得多，6是程序員用得多。如果能全部使用并展開，是可以的。
最后看到個人功力的時候就泄氣了，請問您知道怎么提高個人的功力嗎（特別是初稿的設計能力）
沒有明確的答案吧。具體涉及在原型設計的時候我認為更多的是項目積累 不斷研究其他產品吧，然后畫原型多考慮用戶的使用習慣以及哪些內容是側重點等。我現在也是在需要不斷充實和提高的一個階段
我現在剛接觸穿品，所以在看其他產品的時候，看的角度還是在表面上，而不是設計者得角度去評論，所以甚是苦惱
作者的基本功還是不扎實，其實邏輯就是：
功能決定于需求，流程是對功能的具體描述，信息、操作是實現功能所需要的材料，這些材料必須要先用腦圖進行結構化的整理。最后這些信息再根據場景、用戶使用習慣等轉化成具體的頁面元素（控件）布局到頁面上。
在畫原型之前有個頁面流程圖，就是打個草稿，將頁面的大概內容分布在不同頁面上并且確定每個頁面的業務目標，這樣級就可以做個頁面流轉路徑的整理，給原型打個框架
所謂的功力就是你從抽象到具體的能力，有些產品經理也沒有去分析如何從0-1的一步步的實現過程，但是他做多了，功力深，一個需求出來，流程圖、信息架構都沒做，就直接從抽象到具體了
有些功力淺的就要一步步從需求慢慢的具象化，并且還要不斷反復打磨
90%的產品經理其實都是抄襲嘛，很少有人研究這些
所謂的功力有兩種
第一種，有意識的不斷訓練自己的產品思維，不斷訓練從0-1做產品的思路歷程
第二種，看得多了，做得多了，自然就快了，你問他怎么從0-1，他也說不清，反正就是會搞，這是無意識的
我在工作中發現大部分產品經理對于信息架構都是不擅長的
思路很重要
還不錯，雖然簡單，但是重要的是思路
想請問有了框架，頁面的內容怎么來確定呢？
內容一部分來這后面不斷的完善，更大一部分來自前期需求分析總結而來
好的，謝謝
有了框架以后，就去逐項的完成具體內容，想象自己是最終用戶，描述每一步的具體操作及交互響應。雖然在很多的需求指導文章里說過，不能給研發做功能的限制，只要描述需要實現的功能即可。但以我的經驗來說，如果你不把交互這的需求寫細了，攻城獅們很可能就會把這功能做的不倫不類，甚至反人類。。。
恩～
感謝
邏輯縝密，不錯的干貨！
厲害了，這才是應有的思路
很實用的文章
??