5 Features Your App Does Not Need

There are so many features added to mobile apps these day that just are not needed. They cost a lot of time and money to build, and take away from wonderful new features that user’s could enjoy. I have listed my top five (5) favorite features that are not needed in your mobile apps. When you create a new app you will not need these features until after your app finds a user base.

#5 About

The About feature is found in every app and serves no purpose to the user. This usually includes the Privacy Policy that nobody reads, and other legal messages that are meaningless to anyone but lawyers. I think we should stop wasting time building these meaningless features and spend that time and money on something functional.

#4 Ads

The only reason users put up with ads in mobile apps is because they are using the apps for free. Those ads serve no purpose to the user and clutter the screen. Ofter ads are not at all relevant to the user. I don’t mind interstitial ads once in a while because they usually look nicer than banner ads and do not clutter the normal app user interface. I think banner ads in mobile apps should be eliminated as a revenue source and other revenue streams explored.

#3 Walkthrough / Tutorial

Those beautifully designed walkthrough experiences that you see in apps like Evernote and 500px are not really that helpful. If your users don’t understand your app, or don’t understand how to use it without the tutorial, you should reconsider the user experience of the app. Time for a redesign based on user feedback.

#2 Tell a Friend

It is nice to have an app explode on the scene with lots of viral networking and without advertising. Think Instagram. However, the Tell a Friend feature in the app does not really contribute to that networking affect. If the app resonates with users it will be a hit. A lot of expensive UI design will not guarantee success. Beautiful does not sell. What sells is usefulness. Make sure your app resonates with user and entertains them or solves their problems.

#1 Rate This App

It is important to have lots of good ratings for your app because those stars can play a big part of a user’s decision when downloading an app. However, nudging the user to rate the app is annoying and may be counter productive. Don’t count on this feature to boost your high ratings. It may, possibly, boost your mediocre ratings.

The Mobile Six Pack

I have often been asked these two questions about building mobile apps:

  1. What size mobile team is needed to build a specific app?
  2. How long will it take to build this app?

After answering these same questions over and over for the past three years, I have come to the conclusion that most mobile app projects need to be completed quickly, and most can be first launched with an MVP, or minimal viable product.

I usually conclude that it will take about 3 months to complete a mobile MVP and most product companies like that time frame. Its not too long and not to quick. Its just about right.

I also usually conclude that the team should consist of three software engineers (SE), one quality assurance engineer (QA), one designer (UX/UI), and one technical manager (TM). The team is usually about six people and looks like this:

  • TM (1)
  • UX/UI (1)
  • SE (3)
  • QA (1)

After creating this same team structure over and over for mobile apps I realized there was a pattern growing here. There was always around six people involved in the team. Some of those six are not allows 100% allocated to the project, but for most members of the team, they are allocated 100% of their time.

A few months ago I coined the phrase “The Mobile Six Pack” to describe the default team size and configuration of a mobile development project. Since I usually concluded that the team size would be six people, I started using the term Six Pack. After a while I realized that this team configuration was only being used on mobile projects, so I tossed in the word mobile. Then I realized I had a memorable name for a mobile team: The Mobile Six Pack. After a while of using The Mobile Six Pack it started catching on with other colleagues because it was easy to remember, and it sounded pretty cool.

Not all mobile projects end up with the same resource configuration, but a good rule of thumb is a nice place to start. I am sure many of you would agree that this is consistent with many of the team proposals you have created.

#MobileSixPack @larryaasen