这三种身份对「Blog」这项产品的需求和预期完全不同。

　　2. Functional Map

　　写了 User Story，才会知道有哪些大小功能要做。针对不同使用者的需求，从故事中挑出功能。使用者的身份不同往往影响他们能使用的功能，整理归纳出共通和差异处。

　　3. Flow Chart

　　当开发者知道使用者想要什么、也有了功能，才有办法思考「用户怎么操作功能完成他的任务或达到目的」。

　　UI 设计师常说：「配合用户的习惯与行为来设计操作流程」。就是在这一阶段规划。如果跳过 Flow Chart，只要产品功能复杂起来，你家的 RD 就会抱着头哀嚎了。

　　4. UI Flow

　　知道用户会怎么操作一项功能时，才有办法规划操作动线。UI Flow 指的是页面与页面之间的操作流程，用户想完成任务会经过多少页面之类。

　　有另一位读者传讯问道，为什么我之前的文章说不要用图片版的 UI Flow、要用文字版的呢?

　　首先，这是鸡生蛋蛋生鸡的问题。如果这个项目从零开始，把 Flow Chart 规划完后接着做 UI Flow，这时候哪来的图片版可以串 Flow?连 Wireframe 都还没开始画哩!

　　第二，当你的产品页面一多的时候…也不用太多，20页，用图片串出一个 UI Flow ，这个 Flow 图表尺寸有多大张?谁有那个心力在一张大图上用手掌工具来回移动看页面走向?

　　第三，很多人做图片版的 UI Flow 时，线条连接的是「页面」和「页面」，这时候你也只知道「喔～这一页的下一页会到这里」，但你完全不会知道为什么会到这一页。要点哪里、或是发生什么事所以跑到这里来?猜猜看啊～

　　要靠猜猜看才会看懂的文件看它(写它)干嘛?不要浪费时间啊。

　　文字版的 UI Flow 我拿来当「目录」用，对照 Wireframe 的编号，找图看细节的时候快。图片版的 UI Flow 我会用在「优化」旧产品的操作时使用，连接线会从「组件到页面」，而不是「页面到页面」，并在图片和线条旁边写上文字说明，才会知道哪个步骤可以省略或修改得更易于使用。

　　5. Wireframe

　　有画 Wireframe 不代表工程师就看得懂这要干嘛，光看脸皱成一团的表情你也不知道他是踢到脚指还是吃到酸梅。文字说明才是 Wireframe 的重点，包含触发、回馈、状态变化等等。