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.

Product page is here: http://itunes.apple.com/app/id507987104

If you don't have an iPad, here's a video of the app...

http://www.youtube.com/watch?v=w0Dqu_svEOI&list=UUF3B3HGWgCuzjZDxVBTaDXQ&index=1&feature=plcp