iOS

Napkin doodles are the cornerstone of your next great mobile app

Keeping your project within the original boundaries and reducing or eliminating scope creep requires more diligence in the "planning" stages.

Hundreds of eighth-grade science teachers have quoted "speed equals distance over time." In mobile application development, speed to market is affected by the amount of deviation from the original idea over time. Project divergence over time equates to more overtime to meet an inflexible launch date. Given the aggressive development life cycle of most mobile applications, it is reasonable to assume that scope creep (PDF) is the single biggest challenge. Keeping your project within the original boundaries - and reducing or eliminating scope creep - requires more diligence in the "planning" stage of the standard development life cycle (SDLC).

The power of the napkin

Better planning will result in less coding. Not necessarily fewer lines, but less time translating requirements into a marketable mobile app. Regardless the SDLC model, requirements and architecture are the crucial building blocks for all mobile apps. The requirements define exactly what the app is going to do, while the architecture outlines how it's going to do it. No matter the level of complexity of your app, requirements should always be clear and concise. The most popular iOS apps most likely evolved from napkin doodles (Figure A).

Figure A

Napkin Doodles

Napkin doodles, loose notes, and random thoughts are the cornerstone of your next great mobile app. Take some time to organize your thoughts and create sketches of the interface, navigation, and program flow. A simple wireframe can reveal problems and thwart issues before the first line of code is written. Use case outlines and diagrams are an integral part of the requirements gathering process. All of the information - formally documented or loosely defined - fuel the blueprint and define the architecture of an iOS app.

If project requirements are the building blocks of an iOS app, then project architecture is the definition of how the blocks are to be positioned or stacked. The iOS App Store is hosting many apps with similar functionality. These apps are differentiated by the various approaches each developer used to translate requirements into architecture. In traditional software development, architecture is the process of designing a system that satisfies the requirements. This effort is greatly reduced if the requirements are thorough, descriptive, and well documented.

Three steps

Going from napkin doodles to application architecture and design can be less daunting if you follow this three-step process:

  • Identify and list the functional requirements. Using the "right-to-passage" Hello World app as an example, functional requirements might include:

· Must capture user name.

· Must support device rotation.

· Must display user name with welcome message.

  • Create a list of non-functional requirements. Non-functional requirements would include anything that is not a task performed by the mobile app. For example:

· Must be fast.

· Must be released in time for the holidays.

  • Create a UML use case diagram and present it - along with supporting documentation - to the project stakeholders (Figure B).

Figure B

Use case diagram

With everyone in agreement - and a clear understanding of what the app is going to do - you can move to the architecture and design phase with less risk of scope creep. If a new OS is announced during the development of your app, a decision needs to be made as to whether or not to leverage any new capability or functionality. Depending on the SDLC methodology, it might make more sense to continue with the current release and start planning your next release to incorporate the new system or device capabilities.

More often than not, apps fail because there is not enough planning before code writing. Other development efforts fall short because there is no structure or methodology applied after the requirements have been gathered and documented. Of the eight mainstream SDLC models - Agile, Evolutionary, Rapid Prototype, Slamdunk, Spiral, Stage Gate, Sync-Stable, and Waterfall - we hear the most buzz surrounding Agile and Waterfall.

Agile and Waterfall

Traditionalists like the organization and thorough documentation required for a Waterfall project (Figure C). A Waterfall project is synchronous. For example, one completed phase cascades into the next. However, the Waterfall method does not align well with the speed at which mobile technology and innovation moves.

Figure C

Waterfall project

The SDLC Agile method, on the other hand, lends itself to the fast-paced and ever-changing mobile environment. The iterative process of the Agile method satisfies the need to remain nimble and sensitive to changes in the technology throughout the lifecycle of a project. The Agile method for software development is a "plan as you go" approach that welcomes change throughout the process (Figure D).

Figure D

Agile method

The iterative process of the Agile method is more receptive to a napkin doodle as input than the rigid procedural process of the Waterfall method. Great ideas can come at any time. Grab the closest writable surface - such as a drink coaster or napkin - and sketch a quick proof-of-concept. Few projects start as a detailed set of schematics, but rather as a collection of unorganized random thoughts, notes, and illustrations. Your next great iOS mobile app can originate from a simple set of napkin doodles.

Also read:

About

Gregory Dean is the CTO for the Wilen Group. He has spent the past 25 years in C-level positions setting the tone and direction of technology-driven services organizations. Gregory is constantly researching technologies and developing capabilities to...

4 comments
Blackberryparts
Blackberryparts

Project ideas on Napkin!! Do you have any suggestion? You are talking from technical point of view or just in general. Because I don't think napkin is having any relation with technology.

Mark W. Kaelin
Mark W. Kaelin

Do you find yourself developing project ideas on a napkin or other unconventional method?

HAL 9000
HAL 9000

You are in the wrong field of endeavour. Colin Chapman designed the Mini on a Table Napkin over lunch one day and look where that went. I do not believe that it was implied that you get a finished polished product from what you draw on a Napkin but you will get the start of a product when you are not really trying to design something. However different people work in different ways I personally prefer to Sleep on a Major Problem and when I wake up I have the solution to what I was not able to solve previously. Sitting inside an office trying to design something isn't always the best way to start or even work most times. It's only necessary to be there when you don't need the distractions that may very well give you great ideas. ;) Col

gregorydean
gregorydean

To your point, you cannot dictate innovation. In other words, there is no guarantee that the ideas will come while we sit in our cubicles between 9 and 5. Thanks for the comments.

Editor's Picks