Skip to content

Instantly share code, notes, and snippets.

@yangshaoshun

yangshaoshun/process_00_DesignProcess.md

Last active October 3, 2016 04:04
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save yangshaoshun/b87b6bb19d892ef312273f6a93f26be9 to your computer and use it in GitHub Desktop.
Save yangshaoshun/b87b6bb19d892ef312273f6a93f26be9 to your computer and use it in GitHub Desktop.
Download ZIP
产品设计流程
Raw
process_00_DesignProcess.md

開發流程

讀者來信：UI 設計流程 · 嫁給 RD 的 UI Designer

基本上我自己在開發產品的流程大致上不會脫離這張圖太遠。

  1. User Story
  2. Functional Map
  3. Flow Chart
  4. UI Flow
  5. Wireframe
  6. Mockup
  7. Prototype

使用者要什麼？ > 從需求中整理出功能 > 使用者怎麼操作這些功能？ > 操作的過程需要哪些頁面？ > 頁面要放什麼內容/元件？怎麼被操作？ > 使用者看到的頁面長什麼樣子？

各家有各家的作法，沒有標準或正確一定要這樣做的流程，但我在做自己的玩具時都會這樣幹。

有 UX 團隊的大公司會把上述流程拆的更細，還會做使用者研究之類；一人 UI/UX 通包的小型團隊…這 7 項是最低一定要產出的文件，依個人想偷懶的慘痛經驗，再刪除精簡化就會在執行專案的過程中漏東漏西，之後補洞反而花更多時間和心力。

Functional Map > UI Flow > Wireframe > Mockup > Prototype 之間的差異 – cultivate-my-design-insight – Medium

Raw
process_01_UserStory.md

1. User Story

功能怎麼來的？從「使用者要什麼」或「客戶預期使用者想要什麼」開始。 依使用者的身份不同，想要的功能也會不同，完成的任務不一樣嘛。

比如「Blog」：

我是讀者，我要看到這位作者寫的所有文章。 我是作者，我要撰寫並發佈文章。 我是平台提供商，我要看到所有會員身份和繳費狀態。

這三種身份對「Blog」這項產品的需求和預期完全不同。

Raw
process_02_FunctionalMap.md

2. Functional Map

寫了 User Story，才會知道有哪些大小功能要做。針對不同使用者的需求，從故事中挑出功能。使用者的身份不同往往影響他們能使用的功能，整理歸納出共通和差異處。

Raw
process_03_FlowChart.md

3. Flow Chart

當開發者知道使用者想要什麼、也有了功能，才有辦法思考「使用者怎麼操作功能完成他的任務或達到目的」。

UI 設計師常說：「配合使用者的習慣與行為來設計操作流程」。就是在這一階段規劃。如果跳過 Flow Chart，只要產品功能複雜起來，你家的 RD 就會抱著頭哀嚎了。

Raw
process_04_UIFlow.md

4. UI Flow

知道使用者會怎麼操作一項功能時，才有辦法規劃操作動線。UI Flow 指的是頁面與頁面之間的操作流程，使用者想完成任務會經過多少頁面之類。

有另一位讀者傳訊問道，為什麼我之前的文章說不要用圖片版的 UI Flow、要用文字版的呢？

首先，這是雞生蛋蛋生雞的問題。如果這個專案從零開始，把 Flow Chart 規劃完後接著做 UI Flow，這時候哪來的圖片版可以串 Flow？連 Wireframe 都還沒開始畫哩！

第二，當你的產品頁面一多的時候…也不用太多，20頁，用圖片串出一個 UI Flow ，這個 Flow 圖表尺寸有多大張？誰有那個心力在一張大圖上用手掌工具來回移動看頁面走向？

第三，很多人做圖片版的 UI Flow 時，線條連接的是「頁面」和「頁面」，這時候你也只知道「喔～這一頁的下一頁會到這裡」，但你完全不會知道為什麼會到這一頁。要點哪裡、或是發生什麼事所以跑到這裡來？猜猜看啊～

要靠猜猜看才會看懂的文件看它（寫它）幹嘛？不要浪費時間啊。

文字版的 UI Flow 我拿來當「目錄」用，對照 Wireframe 的編號，找圖看細節的時候快。 圖片版的 UI Flow 我會用在「優化」舊產品的操作時使用，連接線會從「元件到頁面」，而不是「頁面到頁面」，並在圖片和線條旁邊寫上文字說明，才會知道哪個步驟可以省略或修改得更易於使用。

Raw
process_06_Mockup.md

6. Mockup

視覺稿…照 Grid 和 Guideline 做吧，之後還有切圖和標示文件要弄。

好處是切圖和標示文件都有外掛工具可以代勞，甚至設計師只要顧好原始檔、切圖和標示文件都用 Avocode 或 Zeplin 解決。

Raw
process_07_Prototype.md

7. Prototype

那位讀者問另外問了關於 Prototype 的問題：

高保真Prototyple是在切圖給RD之後製作，那做出來的用意是在RD程式還沒完成前再次確定操作上有無任何問題嗎? 那高保真Prototyple就是跟成品長的一樣還可以操作囉??

做 Prototype 的目的通常是測試和驗證，不管是給使用者操作看看、觀察使用者操作狀況做使用者測試；還是工程師套完程式上線前先測看看有沒有蟲或哪邊爆炸了。所以它一定要可以被操作，不能被實際操作是要怎麼測試？腦內補完？

Prototype 要可以被操作！ Prototype 要可以被操作！ Prototype 要可以被操作！

不能被操作的都不是 Prototype。

Wireframe 可以做 Prototype，低保真原型。 Mockup 可以做 Prototype，高保真原型。 切圖叫工程師寫程式套版做一個，高保真原型。

我自己大多做完 Mockup 後才會出 Prototype 測試。 因為，Wireframe 做的低保真原型一般使用者看不懂也沒感覺，沒辦法做使用者測試 =_=

Wireframe 做的 Prototype 頂多內部測試吧，但內部測試常常不太准，工程師和設計師的思維和一般人不一樣，測一測重點常常歪掉…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment