25 June 2016

Do’s and Don’ts of Mobile App Design


Do you have an idea you think could set the world on fire? How about creating the next big app that everyone can’t stop talking about? Or are you more focused – there’s an industry in need of a solution and you have the perfect one?

Before you get started writing a single line of code or designing a screenshot for your mobile app, you’ll want to make sure to check our Do’s and Don’ts of Mobile App Design.

We’ve built many mobile apps for clients here at Stickboy® Creative, and while it’s incredibly rewarding, it can also be unbelievably punishing if you don’t watch your step.

Your big dream is to spark a revolution with your big idea, and the last thing you want is to have it all fall apart because you didn’t know what an “MVP” or a “stack trace” is (both explained below). The web is littered with huge success stories and the craters of ideas that crashed hard. You want to be the former, not the later. So what are some of the big things you should look out for? What knowledge do you need to put your app in the best position to succeed?

We’ve listed the biggest ones here in our experience and this is only scratching the surface.


MVP is “Minimum Viable Product”, which was popularized by Eric Reis of The Lean Startup. It essentially means breaking down your idea to it’s core, and only launching with the minimum amount needed to satisfy a need and be able to track progress. Too many people think of it as a “prototype and get it out the door” type of product. But it’s much more than that.

You can’t just pick 3 features, put them in a box, and ask people to click “download”. You need to make it compelling, but you need to deliver something to market. It can be a thin line to walk; you want to solve a problem (or create an opportunity), but you need to be sure you have enough value in your application so that people will want it.

What we’ve seen that works in the past is to lay out your features in a list and see what kinds of problems or opportunities that each one solves. Do two or more of these features do similar things? Then keep one and toss the rest. Another one is to see where most of your users will spend most of their time, and spend most of your time there as well. It’s not worth it to burn precious development time to develop a feature if almost no one uses it.

Set your MVP early and stick with it, because if you don’t…


This will happen if you keep focusing too much on the details of your app idea. Details are important, in some cases very important, but a 2 hour meeting on the color of the buttons, or delaying a project so that the headline text is juuuuuuuuust right may not be the best thing.

Before your app is out in the market, you’re working off of assumptions. You should make those as educated as you can, but in the end you’re still guessing. You can keep guessing and refining and second-guessing and second-refining and third-guessing and are you seeing the pattern? You have to get your product out to market at some point and nothing can delay a project more than “wanting to take another crack at it”. Refinement is good, and you can refine after launch – but holding back the broader business goal for minor things doesn’t help anyone.

Remember that the only way to be certain is if it’s actually out there in the market trying to achieve your goals.


This is related to the above two points. Even with your MVP in place, and progress being made, it’s far too easy to tack on feature after feature thinking it will make the app better than without it. Scope Creep. Everyone knows about it because it happens to everyone.

If you keep adding new feature after new feature, even if it could work out, you run the risk of ballooning budgets, shifted deadlines, and development with no end in sight. That helps no one.

Instead develop a “roadmap”. Create a method to allow for updates as the market reacts to your app and features. If you want to allow your users to upload and stream video, react with stickers, send instant messages to each other, discuss things in a forum – that’s great. Plan them as a series of releases stretched out over time. You’ll engage your user with frequent updates, as well as getting valuable feedback on how each feature is doing.

This doesn’t mean plans can’t change. It just means you need to be very careful about them if you want to change them.


You have two options on gauging how your app is going to perform. One is to make an educated guess. The other is to do the research. Both are going to point you in a direction, but one has better odds of giving you the best results.

You want to initially start at the biggest, meatiest section of your target market because they’re going to be most of your customers. It’s called the “fattest part” of the bell curve, and it’s where most of your potential users are.

You may get feedback from a handful of people that this button or report doesn’t do this one thing they need it to do, but if it’s only 1% of your audience that needs it, and 99% of your audience are happy with it, are you sure you need to chase that 1%?


The worst thing happened – your app crashed! But why? What caused it? That’s where automated error reporting comes into play.

Ideally you want 2 kinds of error reporting – passive monitoring, and active reporting with “stack tracing”.

Passive monitoring will give you and your dev team a good way to know the ‘pulse’ of your app. How it’s performing, how many people are using it, etc.

Active reporting will alert you if something happens, and a “stack trace” will let you know all of the things that happened before it so your dev team can find the source of the problem.

Both of these are the bare minimum necessary for the health of your application and quicker bug fixes. For passive monitoring we’re huge fans of New Relic. And for active monitoring with error reporting we use Sentry.


This is an investment, not a lottery. I’ve always heard, “when there’s a gold rush, you want to be the guy making shovels”. The reason you want to make shovels is twofold – you don’t want to chase the herd and you have a guaranteed market for those that do.

The first one is that you don’t want to follow the herd and count on a bubble, because bubbles burst.

The other is why be the one digging in this one spot when you can sell the shovels to everyone who wants to go digging?

If you think your app is the Next Big Thing, that’s great. But don’t think of it as your ticket to a gold-plated helicopter. A lot of people have made huge money with apps, but many, many, manymanymanymanymany more haven’t. So what do you do?


It’s the backbone of every business, and that is your business plan. What’s your market? How are you going to scale? What will your pricing be? One of my favorite shows is Parks and Rec, and in it one of the characters, “Tom”, is always starting a brand new business that’s all flash and no substance.

In every single business, he just chucks the “boring stuff” like accounting and planning aside and each one fails. It wasn’t until he actually stopped to think things through that he had a business that succeeded.

Until it failed, then he wrote a book about the failure that then was a wild success. It was a hilarious show.

The point is, you need to treat your app as if you’re starting an established business, like making a holding company for dry cleaning chemicals (Parks and Rec again, seriously, check it out). Even though it’s an exciting business that can really revolutionize the way we do something – it’s still a business. You need to make sure you have that in mind as you build it out.

In the end, your amazing app idea is the tip of a very big iceberg. Beneath that is all of the hard work in developing, maintaining, and running a business around it. It could be hugely lucrative, or a great learning experience. Our hope is that with these Do’s and Don’ts, you won’t end up making a mistake you’ll look back on with a “wish I knew that ahead of time”.

Got an amazing app idea that’s ready to set the world on fire? Let’s talk