Monthly Archives: April 2016

Mobile app development full lifecycle – part 1


This is a really exciting stage. An idea hits you while travelling on the bus. What is missing from this world? A facebook for dogs of course! A million dollar idea.

In case you are a visual thinker, you quickly draw up screens in your head. You envision experiences, key moments in using the app. You quickly realize that this would be a very silly app, but that’s okay. It’s okay to throw out most of the ideas at this stage. Let the right side of the brain do it’s thing.

How about a pixel graphics creator app for iPad? Let’s work with this from now on.

Feature list

Let’s break up the app into a set of features. Put them on a list to be able to manage them.

Obviously a pixel graphics creator app needs a canvas.
Creating lines easily might be useful, put this also on the list.
The canvas will be zoomed in most of the time, yet it’s important to see the full picture in original size. This can be solved by a secondary non-interactive view with bird’s eye view.
Predefined color palettes! It’s hard to use color pickers, entering codes for colors are also not user friendly on mobile. Palettes solve this problem.
Animation support!
And so on.

When the list is done, let’s mark those features that are essential for the first working version of the app. These will be our MVP. We mark the canvas, secondary view, exporting, simple version of color palette as MVP. The rest are nice to haves for now.

Closing remarks

We should do a minimal market research at this stage. Check if there is a very similar app in the app store already. Even if there is, this doesn’t mean there isn’t room for a better one. But the app store is a very competitive place, with an awful search engine. It’s better to face the oncoming troubles of marketing early.


Interface builder is great, but it’s not good for mockups. I personally use Balsamiq Mockups and pen and paper.

When I designed a side-scroller platform game for iOS and Android, I cut out from cardboard all the screen sizes I wanted to support and started to play with them. I wanted to provide pixel perfect graphics on key devices, I also wanted to minimize the amount of art work as I was really slow at that then. By playing with the cardboard I found the solution. The background was created for the biggest height, but also made sure that the middle section – where all the interaction happens – also fits on the smallest height device. The rest of the background is just for visual enjoyment, so it was not a big deal when the top and bottom was cut on small devices. This also enabled a nice feature of imitating an earthquake cheaply at a key point in the game. As the screen scrolled horizontally, I didn’t have a problem with the width.

All I wanted to say is to use whatever works for you. But if you are not working alone and have to share the mockups, using a digital tool like Balsamiq can be much simpler than, e.g. scanning your hand drawings.

The mockups helps in concretizing the product. It often turns out that many features simply don’t fit on the screen. You have to iterate on them a lot and sometimes have to make painful decisions. Like when a critical feature needs to be cut out.

When the main screens are finished, the main interactions, the application flow should be designed. Be vigilant to think about possible error paths at every step. You could spend most of your time implementing the error paths, not the happy paths. In case you can simplify handling errors on the UI side (like dedicated UI element to indicate errors asynchronously) at this stage, it will save you tremendous amount of time later.

When all the screens, and application flow is done. The last step in this stage is to show it all to someone. Get some early input. They could point out major weaknesses in the design. It’s cheaper to make changes now, than later during implementation.

I’ll continue with coding the first prototype in the following post.