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

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

总结

我从这个项目也学到了其他东西，不过我认为以上三点显然是最重要的。总之：尽早确定结构、不断研究设计，可以“显示”出来的就不要用“说”出来。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

3 Lessons for Designing iPad Apps (When Your Engineers are Overseas)

I recently completed the user experience design of an educational iPad app for Appluza, a mobile app development firm started by a few friends and classmates in the MIT System Design & Management program. The app, entitled ZooType, provides toddlers with an interactive learning experience as they develop skills in letter recognition, typing, and spelling. The project required that I design the entire user experience for the game, from the user workflows and menu structure, to interaction design and interface design, through character development, animation, and even audio recordings! This was an excellent opportunity to “own” the entire design process – something that was challenging but absolutely rewarding. Of course, it wasn’t all on easy street as our dedicated development team was outsourced and located in India and I managed them for the final stages of the project as well. The following is a set of five lessons that I pass on from my experience designing ZooType.

1. Lock Down the Structure Earlier Than Normal

I personally like to learn by doing, so I want to explore as many concepts as possible during the design process to seek out the right one. This may drive engineers crazy at times, and I realize this, but the right answer is often impossible to arrive upon without first trudging through a sea of wrong ones. I’ve been fortunate enough to establish good working relationships with engineers over the years so we’re clear on how long I can experiment before locking in on a final product. However, this approach is significantly more difficult when outsourcing to engineers who you don’t share a personal history and familiarity with.

Constant changes will quickly lead to frustration from the hardworking engineers on your project, especially when the time differences between US and Asia result in entire days of development lost because of design iterations. My advice is to define and lock down the prominent user workflows, screen architecture, and core functionalities before beginning the development process and only deviate from it when completely necessary. Set expectations with engineers that some secondary screens and additional functionality may be added, but only when necessary and not a major impediment to the development process.

On ZooType, we had a detailed set of storyboards that included specific (and minimal) functionality and detailed interaction design. Having a structured and defined focal point reduced the early stage deviation which is common in software development.

2. Set Expectations About Design Exploration

I believe that User Experience Design requires a great deal of experimentation as a right or wrong design decision is often not clear until it has been sketched, prototyped, implemented, or shared.

In the case of ZooType, we weren’t quite sure exactly how the characters should interact with the toddler and this required significant design experimentation. For example, we had to determine how each letter should be introduced, whether it should be spoken first and then shown (or vice versa), and how the app should react when the right or wrong answer is given. This took many tries before getting it right.

We could have made decisions such as this before beginning the development of the application and it would have resulted in an adequate design. I firmly believe, however, that these types of decisions need to be pushed off until the designers and developers could work together to reach the choices that are both technical feasible and still highly engaging to the user. Because of this necessary iteration, I highly recommend setting expectations with your development team from the beginning that design-related decisions may take occur throughout the process. Because of the locked-in structure recommended in the previous tip, there should be some slack for this.

3. Be a Storyteller, Not a Painter

I think the most difficult challenge I faced was communicating to the engineers how I wanted the characters to come alive and interact. I’ve worked with international teams extensively in the past but it was on more functional projects, such as the development of financial services web applications. For  more creative projects, particularly with characters, it is much more challenging to convey qualitative aspects, like the way in which you want the character to “feel” to the toddler. Had I been able to work face-to-face with these guys, this would have been fine. However, oceans, time zones, and Skype can create some pretty significant barriers.

Attempt #1… My first attempt was to create a series of frames for each character in the game, about 30 each. Early frames conveyed positive expressions and the second half contained neutral or sad ones (used when the toddler gives a wrong answer). I then provided the engineers with audio and the art and gave instructions to randomly cycle through art frames for a character for the duration of a clip. The result? A complete disaster! I had no idea what speed the characters would move at, and the result was a bouncy, jerky mess where characters moved way too much and the voices weren’t even closely aligned.

Attempt #2.. With the threat of terrible animation looming (I used to animate professionally so this really bothered me), I created a detailed phoneme (i.e. mouth shapes that map to sounds) chart for each character and painstakingly built an art-to-audio spreadsheet of instructions for each of the four main characters. The instructions would tell the engineers where, when, and how long to display each art object, thus minimizing any variation that could occur.

This second attempt was much closer to the right choice, but it wasn’t the only solution.. and this is where my recommendation for storytelling comes in! Since I wasn’t able to do the animation myself, I decided the next best thing would be to show how I think the animation should appear. Giving qualitative commands like “make him less bouncy” over Skype would never work and likely need to frustration on both sides and lost work hours. Static screenshots also fall short when trying to convey something more kinetic, like the movement of characters or the interaction of users. Instead, I continually created short movies to communicate how I wanted the character to move. It was a good deal of extra work up front, but it ensured that my message was clear and my words would not be misinterpreted. At the end of the day, I’m not completely satisfied with the animation and art-to-audio mapping, but I think it was as good as expected considering the nature in which it was developed.

Early concept animation of Ronzi the Bear (Pre-Audio)

Mid-stage concept animation of Ronzi the Bear (with audio)

Summary

I have additional takeaways from this project, but I wanted to focus on these three as they clearly are the most significant. To wrap up: lock down structure early, explore design until late, and never “tell” when you can “show”. If you would like to see the final product, please check out ZooType in the iPad app store. I would love to get your feedback on the end results of this rewarding effort.(source:treilanderror)