In this series, I will document my strategy and progress as I attempt to launch an app by myself in one week. I will discuss my strategic thought-process and attempt to justify most of my design decisions. Although some of the posts in this series will be technical in nature, no programming experience is required to follow along.
“Finish” will be a game in which users must guess the last word of the most recent Tweets in their Twitter timeline. So, the basic idea is for a user to open the app, login with Twitter, and then “finish” their friend’s Tweets. The app will display the entire tweet except for the last word. If the users “finishes” the Tweet by correctly guessing the final word, they will gain a point. If they are unsuccessful, they will lose a point.
I would like to take it a step further and allow users to gain a point if someone else “finishes” their tweet incorrectly, and vice-versa. That way, every time someone gains a point, someone else loses a point. That would give the app a more competitive edge, but it will also be more difficult to develop.
I have an idea for a game, and a basic vision of how it should operate. However, my goal is to have a completely finished app in one week, so I don’t have time to research and test every possible development method. Whatever route I choose will not be perfect, and I will make mistakes, and I will take shortcuts. I will be forced to sacrifice quality for the sake of completeness. But I think it will be fun, and to that end, I will begin with the most creative task of the entire process: the user-experience design.
After I have laid out the ground-rules for the user-experience, I will then design a basic information architecture for the app by choosing appropriate front-end and back-end technologies. Next, I will write the code and get the app itself working. Finally, I will use any remaining time to make the app look “pretty” and refine the interface as best I can. It is important to note that although refining the user-interface (UI) comes last, I am defining the user-experience (UX) first. This is an important distinction, and it is worth Googling if you are confused by it.
Marketing. I will not actually advertise this app outside of this blog, but again, it’s a topic worth Googling if you’re interested.
Support. It has been said that most of the development work on an app comes in the form of updates after the initial launch. My support plan is simple: if the app breaks, maybe I’ll fix it.
Review-time. This will be a native iOS app, so it must go through Apple’s review process before it can be downloaded from the iTunes App Store. This usually causes around one week of delay, and I’m obviously not accounting for that in my project deadline. I plan to submit my app one week from today, but it’s actual launch date will be some time later.
It is also important to note that I will be doing all of the design work and coding myself. I have a degree in Computer Engineering, and I have a basic knowledge of photo-editing software such as Illustrator and Photoshop. However, anyone capable of defining a UX and an information architecture can, with a little patience, outsource the implementation to someone else. So, this series should be entertaining whether you plan to act upon your strategy yourself or to enlist help from others (or to do nothing at all).
This is not intended as a general strategy-guide for app development. Every app has a different purpose, and this one is intended as a fun project for myself. I will not be setting strict requirements or writing test-cases, but I will be discussing my basic design strategies and reporting on my progress in real-time. I’ll try to keep it interesting!