Blueprint for Building Native Apps

How should companies build native mobile apps? I've thought a lot about this very question. It's a very different problem than web development, where you can push code 24/7 and bugs are cheap to fix. On mobile, you've got one shot to get it right and make a great first impression.

(I'd probably augment this advice for larger teams, so apply this only to smaller startups)

The first step is, as a team, step-through all the screens in your app. Start with the question, "What is the very first thing the user sees when they download the app?", and then explore what happens when they tap each button or perform all of the possible actions. Repeat exhaustively for each screen and be thorough. This needn't be a 100% final UI mockup, just a bunch of boxes with arrows between them. This should give enough information for the engineers to start building a working "skeleton" of the app.

Then fill in the screens with basic UI elements. Where are all the buttons, text-boxes, or switches on each of them? Engineering can start coding with the normal looking UI elements which ship with the operating system.

After you figure out the screens, list every piece of information you need on each of those screens. Have a screen that lists books? What about them, their title, author, ISBN? Have a screen that shows details about a book? Do you show comments, reviews, ratings, or what? Even list what instructional or marketing copy is needed for different screens. Engineers can fill in those bare screens with working (but unstyled) data.

While the engineers are filling in the bare-bones app with data and normal UI elements, your designers should start finalizing UI designs. It's basically taking your skeletons and doing this:

This is where the designers and engineers really need to collaborate. Your designer should supply specially formatted images for customizing buttons, navigation bars, tab bars, and other stock controls. The engineers should read up on Apple and Google's docs on what the dimensions these need to be, but they should never have to open Photoshop and do it themselves. (I can tell you from personal experience, a coder playing with someone else's design will probably screw it up anyway ;) ).

Both iOS and Android support types of "stretchable" images (specified in code on iOS, as 9-patch PNGs on Android), which coders should familiarize your designer with. Also make sure all of the elements come prepared for multiple densities (so @2x on iOS, l/m/h/xh-DPI on Android).

On mobile, it's incredibly important to not only consider how something looks in a static photoshop file, but also how it looks in motion. Do elements animate? How should those animations behave, can they be prototyped by the designer to show to engineers? What do different buttons look like when they're tapped or disabled? What do you show while images or data is loading from the server?

My theory is that by the time UI styling and animations hit engineering, the design shouldn't be changing much before launch. If you're unsure about a design, try to prototype and get it in your hands somehow (Keynote, quick web demo, anything) before you resort to just trying it out using real Android or iOS code. In a perfect world, the designer would drop all of the specially sized UI elements in a Dropbox folder and the developers would be good-to-go.

By the same token, designers should keep tabs on how well engineering is implementing their work. Blurry graphics? Mis-aligned elements? Wrong fonts? These should all be called to attention and fixed.

If you can't tell by the body of this message, but in my experience that step takes 70-80% of the time. A good engineer can whip up a working prototype pretty quick, but sweating the details and getting the UI right takes a lot of time. If anyone has found a better way for a custom-looking app, I'd love to hear about it!

The last thing you need to do is test, test, test. I'd try to get it in the hands of a small beta group (~30 people) and have them do regular, real-world use. Testing yourself will dead-end eventually and it's always great to have fresh eyes. Products like TestFlight are great for organizing those. And if you're launching on Android...get as many devices as you can.

And one more thing! After you launch, make sure you're collecting data about app crashes and malfunctions. Apple and Google do supply you with some crash statistics, but it's always an under-representation of the truth. You can use services like Crashlytics, or you can roll your own with some easily available libraries. There's nothing worse than your Twitter feed blowing up with customers saying, "App's crashing at " and you don't have the data to reproduce it.

Good luck!

This was originally an answer to a Quora question