分享与海外团队合作开发iPad应用的3个经验

作者：Todd Reily

我最近刚为一家手机游戏开发公司Appluza完成了一款iPad教学软件的用户体验设计。那家公司是由几个朋友和MIT系统设计和管理课程的同学创办的。这款名为《ZooType》的软件为幼儿提供了一种交互式学习体验，用于帮助其认识和拼写字母。项目要求我为游戏设计整套用户体验，从用户的工作流程和菜单结构，到交互设计和界面设计，再到角色设计、动画和甚至录音!这真是一个学习完整的设计过程的绝好机会，虽然颇有难度，但完全值得。当然，因为我们敬业的开发团队是外包的，位于印度，且我在项目后期才管理他们，所以工作并不方便。以下是我从设计《ZooType》中学习到的经验。

1、尽早确定结构


Appluza_Bear(from treilanderror)

我个人喜欢通过实践来学习，所以在开发过程中，我想研究尽可能多的概念直到找到最合适的一个。我知道有时这会让工程师很崩溃，但不穿越错误的海洋，如何能抵达真理的彼岸呢？幸运的是，我和工程师有多年的交情，所以我们很清楚在确定最终产品以前，我需要实验多久。但是，如果外包工程师和你并不熟，你也不了解他们的个人背景，这个方法就不非常不管用了。

频繁的变更会让辛劳工作的工程师们很受挫，特别是当美国和亚洲的时间差会让整个工作日都浪费掉。我的建议是，在启动开发进程以前就确定重要的用户工作流程、画面结构和核心功能，除非完全必要，否则不要脱离开发进程。和工程师一起预测某些次级画面和额外的功能，但必须保证不会干扰开发进度。

我们给《ZooType》制定了详细的脚本，包括特定的（和最小的）功能和详尽的交互设计。结构良好的、重点突出的结构可以减少软件开发早期普遍出现的误差。

2、预测设计

我认为用户体验设计需要大量实验，因为正确或错误的设计决定往往直到已经完成草图、首个原型、安装或共享时才被发现。


Appluza_Dino(from treilanderror)

设计《ZooType》时，我们并不十分确定角色应该怎么与儿童互动，这需要经过设计实验。比如，我们必须确定如何引入各个字母、是否应该先发声再显形（或相反）、当用户给出正确或错误的答案时，软件应该如何反应。在正确执行以前，我们做了许多尝试。

我们本应该在开始开发软件以前就做好这些决定，本可以完成足够的设计。我坚信，这类决策必须推迟到游戏设计师和开发商在技术可行性和用户适用度上达成共识。因为这个必要的重复，我强烈推荐设计师从一开始就和开发团队一起确定预期目标，因为设计相关的决定可能贯穿整个开发过程。因为在第一条中已经建议先确定结构，所以这应该会轻松一些。

3、讲故事而不是画画

我认为我遇到的难度最大的挑战是和工程师阐明我希望角色如何活动和反应。过去我经常和国际团队合作，但那些都是比较功能性的项目，比如开发一个金融服务网站程序。而对于更具创造性的项目，特别是角色，要传达品质方面的信息就困难多了。比如，如何让角色“感知”幼儿玩家。如果我能够面对面地与工程师们合作，这个问题也不难解决。但是，地域、时差和网络电话都会造成相当多的困扰。


Appluza_Dog(from treilanderror)

尝试1：我的第一个尝试是给各个游戏角色制作一系列画面，每个角色大约有30个。前半部分的画面表现的是积极的表情，而后半部分的则是中性或消极的表情（当小玩家给出错误的回答时使用）。之后我给工程师提供了音频和美术设定，说在整个片断中随便循环各个角色的画面帧。彻底的悲剧！我不知道角色移动的速度，所以结果是一团糟，角色的活动超前，声音无法同步。


Appluza_Dog(from treilanderror)

尝试2：随着可怕的3d动画工作逼近（我曾经专职干过动画，动画真让我烦恼），我给各个角角制作了详细的音位图（如指导发声的口型），并且煞费苦心地给四个主要3d游戏角色制作了画面对应声音的说明表格。这些说明表格会告诉工程师在什么时候地方、什么时候、各个物体出现多久，这样就将误差大大减小了。

第二个尝试更成功，但仍然不是唯一的方案。针对脚本，我想提一下我的建议。因为我不能自己完成动画，所以我认为退一步方案是，向工程师们阐明动画应该如何呈现。用网络电话告诉工程师“不要让他太活泼”从来就行不通，倒是有可能让双方都很受挫，并且浪费时间。当要表现某些动态物品，如角色的活动或用户的反应，静态画面是不管用的。所以，我只能不断制作短篇来说明我认为角色应该如何移动。这很费功夫，但可以保证工程师清楚我的意思，不产生误解。虽然直到最后一天，我也不完全满意动画和声音的映射效果，但考虑到开发性质，我认为已经达到期望了。

总结

我从这个项目也学到了其他东西，不过我认为以上三点显然是最重要的。总之：尽早确定结构、不断研究设计，可以“显示”出来的就不要用“说”出来。文章转自gamerboom