作者：Joseph Kim

依流程所设计的手机游戏涉及到映射出用户可在游戏中点触整个屏幕设置的概念：用户流。虽然像Zynga和GREE等许多大型手机游戏工作室通常是依流程而设计UI/UX，但有不少手机应用设计师仍然是根据功能来设计各个屏幕。

在本文我将描述两个内容：

1.屏幕vs流程概念：设计屏幕vs流程的概念，以及流程在手机游戏设计中的重要性。

2.优先方法：一种我认为优于当前许多工作室现成方法的格式和工具（使用Google Docs Drawings）。

mobile UI deisgn(from coroflot.com)

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.工具：进入Google Docs并创建一个Google Docs Drawing

1）点击文件->页面设置并将宽度更改为12，并根据你所需设计的屏幕数量更改长度。

2）点击视图->100%

3）点击视图->对齐到->网格

2.组织：横向并列你的3个屏幕（每个屏幕宽度要小于4）

3.拖放：将最终画面拖放到相应位置

4.注解和箭头：合理添加注解和画面字幕。使用箭头显示按钮应该引向何处或者屏幕的流程。

5.占位符：以必要的画面绘制每个流程，如果你还没有设计该屏幕在相应位置用占位符屏幕代替。保持一切内容的更新！

6.安全性与协作：设置你的安全权限，并与其他相关人员共享这一权限。你也可以在此添加注解。

最后，我认为我们都应该感谢谷歌提供了如此出色的资源，不但支持分享、协作、评论、修订记录、拷贝（便于你创建模版）、编辑/图像插入（只要拖放即可）等功能，而且还是免费的！（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Mobile UI and Game Design: Screens vs. Flows

by Joseph Kim

Context:

Mobile game design by flows refers to the concept of mapping out the entire set of screens a user can tap through in a mobile game: the user flows. While many of the larger mobile game studios such as Zynga or GREE routinely design UI/UX by flows, many mobile application designers are still designing individual screens by feature.

In this blog post I describe:

Screens vs. Flows Concept: The concept of designing screens vs. flows and why flows are critical in mobile game design

Preferred Approach: A format and tool (using Google Docs Drawings) that I believe is superior to existing approaches found in many of the studios today

1. Screens vs. Flows

In the past few years, having had the opportunity to work with and collaborate with a number of different game designers I’ve noticed that many designers are still designing mobile games via Screens. What do I mean by this?

A typical process I see is to initially start with a game design document that lists a set of features that comprise the game. After that, the features are broken down and then a game screen for each feature is designed by game designers and UI artists. This approach seems generally true in small studios and especially with game designers coming from the console/PC space. Console/PC designers generally aren’t used to a bunch of screens that is more typical within mobile applications. How many screens is a user presented with in the “core loop” of Call of Duty?

screens based UI

This is a very reductionist (vs. holistic) approach to game design. This ignores how users actually interact with the game and all of the paths, the user flows, that comprise the overall user experience.

A better approach is to design your mobile application considering the user’s path within your game and how the user will actually traverse all of the screens.

Flow UI design

Game and UI designers get 2 primary advantages from this approach:

User Experience Understanding: It becomes much easier to visualize and walk through just how a user will experience your mobile application

Avoiding Feature Explosion: By mapping all of the flows (and not stopping at the screen level) game designers don’t become surprised with new features and contingencies they didn’t expect

I can speak from personal experience in saying that there have been numerous occasions where not mapping out all of the flows has led to unforeseen contingencies and additional required functionality. The simple question: “What happens when someone taps on X?” for every single button and tappable icon will almost always reveal unforeseen functionality that will need to be supported.

In many cases, we may have estimated say a 10 day development schedule for feature X but then due to unforeseen functionality it turns out we now need to expand the schedule by another 5 days (for example). This is even further compounded when we also need art and additional UI which bottlenecks development.

A Flows based design approach will often lead to much more accurate estimates of development schedule.

2. Preferred Approach: “The Kim Method”

In my experience, designing application flows is typically handled in one of 2 ways:

Big Ass AI File: In this approach, a UI artist will (often using Adobe Illustrator) draw out the full set of screens and flows. The end result is a really large image with even up to 30+ screens in some cases with arrows and notes all over the place. It’s also possible to breakdown by feature, but you typically still have a lot of screens and it’s difficult to get more than a specific feature view in that case.

Compact Overview:  Another approach is to just stick all of the screens in an ordered way e.g., 3-4 screens across on a website or JPG. This approach gives a very compact way of viewing the screens and a general sense of flow.

Both of these approaches, however, suffer from some major disadvantages as follows:

Big Ass AI File:

Too difficult to easily see what’s going on with such a big ass picture. It’s easy to get lost in the details of a really big image.

Compact Overview:

Difficult to change/modify and in website form often lacks notes and arrows for flows
Both Methods:

Lack of individual and group security

Inability to share and collaborate and give access to multiple users who can work on the flows document simultaneously

Very difficult to add and share comments

No version control with revision history

Lack of other key features such as easy editing/image insertion, copying, etc.

So what is a better solution?

Well much of what I describe above comes built in with Google Docs! Hence, we can just adopt a variation of the 3 column compact overview method using a Google Docs Drawing format but add notes and arrows, enable collaboration, and use all of the nifty features built in by Google.

Let me show you a simple example from a partial game design I worked on for fun last year (Click View->100% for better viewing):

Fantasy Alliance Flows Design Example

In this solution:

Tool: Go to Google Docs and create a Google Docs Drawing

Click File->Page Setup and change the width to about 12″ and the length according to how many screens you will design

Click View->100%

Click View->Snap To->Grid (I find it easier to align my wires this way to the grid boundaries)

Organization: Organize your screens 3 screens across (hence each screen should take up slightly less than 4″ width)

Drag and Drop: Take any wires or final screens and just drag and drop them into place

Notes and Arrows: Add notes and screen titles as appropriate. Use arrows to show where buttons should lead or screens should flow

Placeholders: Map every flow with the necessary screens and just put placeholder screens where you haven’t designed that screen yet. Keep everything up to date!

Security and Collaboration: Set your security permissions and share with the other folks who should be able to collaborate with you. You can leave notes here as well.

Finally I think we should all thank Google. Thanks Google for providing a great resource which has all of those great features like sharing, collaboration, commenting, revision history, copying (so you can create templates), great editing/image insertion (just drag and drop), etc.! Oh, and it’s free.（source：quarterview）