Posted by Eric Mills on Sun, Jul 19, 2009 @ 02:38 PM
After seeing my twitter post about the reviews our Pace Race game was getting, Trent Thurman contacted me and we did a quick question and answer. Trent is the director of the Texas Evening MBA program at the University of Texas, where I proudly attended. Trent's blog post was immediately picked up by the McCombs blog. Pretty cool. Check it out.
Posted by Eric Mills on Mon, Jul 06, 2009 @ 09:55 PM
After hearing another horror story from a customer who came to us after a bad experience with another iPhone App Developer, I felt the need to offer up some advice on how to avoid a failed project. Here is the golden rule: Do not start coding until the app has been completely designed. Build the user interface and work backward. Don't even talk to any programmers for a few weeks during design. Don't just pencil and paper or whiteboard the user interface. Build the final user interface and use that as an asset to convey the scope of the project to the programmers. Once the user interface is exactly like you want it, only then should you consider writing code.
See, the amazing thing about a user interface is that everybody has an opinion about it. Nobody (except the programmer) is going to be worrying about what internal data structures are used, but every person involved in the app planning process will have "valuable input" on the layout and colors of the user interface. Get all of this controversy out of the way before engaging a programmer. Programmers hate redoing work because of user interface changes. It sucks the life out of them. A programmer wants to know the technical requirements of the project and be left alone to create the most efficient solution to the problem at hand.
At the end of the design process, create a design document. This is the single system of record for what is going to be created. this doesn't need to be a tome of formal terms that nobody will ever read. The design document should contain the following information:
- The goal of the application: Are we trying to create a fun game of solitaire, an ebook reader, or a mapping application? Should the main focus be on usability, speed of use, speed of development, or performance?
- All final user interface screen with descriptions. Don't skimp on the descriptions. Describe any non-trivial function of the app.
- Functional specification: This needs to be nothing more than an outline of the app and what every button and control should do.
- Schedule: How long should the development effort take? Ask the programmers, don't tell them. You convincing them it won't take that long will not reduce development time.
- How much will it cost? Translate the hours to dollars.
- Acceptance: A simple signature for client and developer to sign indicating acceptance of the design, schedule, and associated price.
This may sound like a lot of work, but once you start doing things this way, you will wonder how you ever got along without it. Get everybody on the same page from the beginning. Manage expectations through out this process and your app will succeed. Don't be lazy. Do this work and you won't regret it.