分享手机应用屏幕VS流程的设计方法.pdfVIP

分享手机应用屏幕 VS 流程的设计方法 依流程所设计的手机游戏涉及到映射出用户可在游戏中点触整个屏幕设置的 概念：用户流。虽然像 Zynga 和 GREE 等许多大型手机游戏工作室通常是依流 程而设计 UI/UX ，但有不少手机应用设计师仍然是根据功能来设计各个屏幕。 在本文我将描述两个内容： 1.屏幕 vs 流程概念：设计屏幕 vs 流程的概念，以及流程在手机游戏设计中 的重要性。 2.优先方法：一种我认为优于当前许多工作室现成方法的格式和工具(使用 Google Docs Drawings)。 mobile UI deisgn 1.屏幕 vs 流程 在过去几年与大量不同游戏设计师共事的过程中，我发现许多设计师仍在根 据屏幕设计手机游戏。为什么我要这么说呢? 我认为传统过程是从列出组成游戏的一系列功能的游戏设计文件入手。之 后，将这些功能进行划分，再由设计师和 UI 美术人员为每个功能分配一个游戏 屏幕。这个方法在小型工作室，尤其是来自主机/PC 领域的游戏设计师当中似乎 甚为普遍。主机/PC 设计师通常并不是很习惯那些嵌在手机应用内部的大量屏 幕。在《使命召唤》的“核心循环”中，游戏究竟向用户展示了多少个屏幕? 基于 UI 的屏幕 这是一个极为简化论(vs 整体性)的游戏设计方法。它忽略了用户如何真正与 游戏，以及所有的路径、用户流等组成整体用户体验的元素互动。 一个更好的方法是考虑用户在游戏中的路径，以及用户如何在所有屏幕间切 换，并以此来设计手机应用。 流程 UI 设计 游戏和 UI 设计师可从这个方法中获得两大好处： 1.对用户体验的理解：它更易于形象化和展示用户将如何体验你的手机应 用。 2.避免功能爆炸：通过绘制出所有流程(并不停留于屏幕层面) ，游戏设计师 就不会因为自己没有预料到的新功能和事件而意外。 从我个人经验来看，不事先绘制出所有流程常会导致出现没有预料的事件以 及额外需求功能这种情况。一个简单的问题：“如果有人点触了 X 会发生什么 情况?”每个按钮和可点触图标几乎都会出现一些需要支持的未预料功能。 在许多情况下，我们可能会预计功能 X 需要 10 天的开发时间，但由于它出 现未预料的功能，我们可能就需要将原来的时间安排再扩展 5 天。如果我们还要 算上美术和额外 UI 等会拖延开发进程的因素，这种延时情况就更严重了。 基于流程的设计方法通常有助于我们更准确地估算开发时间。 2.优先方法：“The Kim 方法” 依我个人经验来看，设计应用流程通常可用以下两种方法之一来处理： 1.大型 AI 文件：在这种方法中，UI 美术人员(通常使用 Adobe Illustrator) 来绘制完整的屏幕集合与流程。结果就会产生甚至多达 30 个以上屏幕，到处标 注着箭头和注解的超大图像。你也可以根据功能来划分，但你通常还是会有大量 屏幕，并且难以获得超过一个以上的特定功能预览图。 2.紧凑预览：另一个方法就是以一种顺序来拼凑所有屏幕，例如在一个网页 或 JPG 上放置 3-4 个屏幕。它是一种预览屏幕和总体流程感的紧凑方法。 这两种方法都有以下一些劣势： *大型 AI 文件： 你很难在这样一张大图中看出游戏操作情况，很容易在这样的大图中忽略细 节。 *紧凑预览： 难以改变/调整，并且在网页格式中通常缺乏流程注角和箭头。 *两种方法： ·缺乏独立和群体安全性 ·无法支持多名同时负责流程文件的用户之间的共享与合作、访问 ·极难以添加和共享评论 ·没有修订记录的版本控制 ·缺乏轻松编辑/图像插入、复制等关键功能 有什么更好的解决方法? 我在上面所描述的多数情况是用 Google Docs 创建的!因此，我们可以使用 一个 Google Docs Drawing 格式但添加了注解和箭头，支持用户合作，并使用 了所有由谷歌创建的优良功能的 3 栏紧凑预览的变体。 在这种解决方法中： 1.工具