Before you bring your app to market, here are eleven key considerations for you to review and share with anyone who is producing an app.
1) Is there a viable market for this app and how will you reach them?
Many apps are rushed to market without cause or concern for how large the potential audience will be, and more important, how that potential audience may be reached when the app is in the marketplace. It is standard business practice to evaluate your marketplace before embarking. Apps are a game of Where’s Waldo in the app store without anything pointing consumers to find them. A wise entrepreneur or company will be very clear on how to create a focused message in the marketplace that will drive traffic to their app and get users to download the app. More importantly, they will focus on what will cause the end user to engage and to continue to engage with the app on a regular basis. App fatigue is very real. Once someone has soured on your app, you are almost as good as dead with that end user. These methods will be covered in another blog in this series.
2) Have you surveyed the app stores in iOS, Google Play, and Amazon to see if existing app(s) are already servicing your intended audience?
Surveying the competition and evaluating what they have done properly or improperly is the best method of creating progress in society. We are advancing as a civilization by standing on the shoulders of the giants who came before us. It is good practice to download and use all of your competitor’s apps to learn how they approached solving some of the same issues you are considering. Discover all of their weaknesses, and learn from them. Improve on their user experience, deliver better service, better content, improve all aspects of their product so that when yours comes to market you have clearly identified your strength in the marketplace and have defined how you stand above all others. No one wants to go to market with a “me too product.” Everyone wants to be the disruptive new app in the marketplace that breaks through the clutter and causes users to engage in ways that have all been thought through at the stage you are currently at… early development and ideation.
3) Have you thoroughly thought through all of the technical considerations of your app and the supporting system required to make it a success?
Apps are sometimes constrained solely to the operating system of the device that it is working on and nothing else. Others connect via the internet to a server system or massive server systems, to perform the countless functionalities that are available via apps today. As a result, apps are seldom just a product that is being designed and written to perform on a device, and are more often, a front end system that helps the consumer engage with a much larger back end system, as happens in all the social networks, a banking app, a streaming video app, gaming app and millions of others. Some apps are considered for large volumes of people to use where there is not a large volume of internet connectivity. An example are many apps we have thought through for use in ball parks and stadiums worldwide. The internet connectivity in volume is just now being resolved in most stadiums, but their low throughput eliminated many outstanding apps from being released over the last 7 years while this problem could be addressed on a stadium by stadium basis. Your back end server system, its scalability, its security considerations, throughput and processing considerations, mercantile considerations and backend functionalities for maintenance and updating, are all details that must be drafted before your app is budgeted and put into production. The Kodiak Viewer app above was created to pair with a wireless camera that Comanche sells for you to install in the forest and then trigger with the use of this app. There were many considerations to the technical requirements of making this set of functionalities seamless to the end user.
4) Will you write your app in native code to each format, or pick a general “one size fits all” platform like Titanium to develop your product in?
It is much more expensive to write your app in native code three separate times for iOS, Android and Windows, than it is to write it once in Titanium or similar middle authoring solutions, but in the long run, it is a very wrong choice for any serious company to entertain. A middle software product offers the illusion of savings at the outset, but most of these apps which are created in a middle authoring solution are thrown out after phase one, because the phases 2 and 3 of an app, most ususally take the app to the place where it is far more beneficial to be written in the native codes (Xcode, Objective-C,Swift, Cocoa, UIKit for iOS, Java and Eclipse for Android and C# or C++ with XAML, C++ with DirectX, and JavaScript with HTML/CSS for Windows. Your games will perform substantially better written directly for your output devices, and incorporating additional systems such as Unity when required. Long term, any serious product is always written in native for one hundred reasons too extensive to list for this blog.
5) Which is better, a trendy user interface or traditional user interface?
The very best user interface is the one that allows an end user to engage with your app in the fastest, most efficient, most intuitive way possible. It will not be garish and overpowering, nor will it be so transparent as to become annoying to find anything or do anything without a lot of knowledge. An end user expects to learn how to use your app in under 5 minutes. Much past that, if they are not engaged, your app is turned off and will disappear into oblivion with that user until they have any cause to engage with you again. So keep your user interface clean and simple and very intuitive. Make great wireframes and track through every last click of every last button until you have reduced the number of clicks to get to anything inside the app, down to the very smallest amount. Your end user should almost not even notice your app. They should only notice your app’s content. If they are having an enjoyable time experiencing your app, and the app is not glitching or breaking or stalling, then they will use it again. Your user interface should be everything it can be to serve that mission. And it must be aesthetically satisfying. In the beginning, apps each had their own style of navigation. With each iteration, that navigation is reducing in variety. This is due to keeping it all intuitive for the end user. Remember, they do not want to spend time learning how clever you were in your design process. They want to open your app and start to use it like they are old pros. Let your ego express your art somewhere else, and let your user interface be standard so that your user appreciates how “they already knew how to use your app, right when they opened it.”
6) What do the app index and wireframes accomplish?
Wireframes are the blueprints to an app. They mark every functionality, every user interface clearly so that the app development and design teams are clear about which details and functionalities and expectations apply on an instance by instance basis. The wireframes are not a design document. Let me say that again. Wireframes are NOT A DESIGN DOCUMENT. This is important because a person with final say on the design can be blindsided by not seeing the wireframe as a nice design and miss their most important function, which is to convey process of the application and systems and not to create a defined style for a user interface, the colors used, the fonts used or other visually art directed details. The wireframe, when used properly, is a great tool to sort out all of the thought required to make a spectacular app and to minimize any aspect of miscommunications between any of the parties who are collaborating to see this app come to fruition. It can avoid very expensive design detours and programming mishaps by forcing everyone to sign off on the app details at the outset of design and programming. It also qualifies the scope of the project, which is the total expectation of programming, design, testing resources required to bring a project like this to life. All technical projects are very prone to “Scope Creep,” which is the tendency for little and sometimes, not so little, details or functionalities to change as the project comes to life. These are healthy considerations and must be contemplated as they arise, but they are also financial details and must be resolved between the parties, prior to embarking upon them. This is why a wireframe is critical. It defines clearly what is expected at the beginning, when the contract is created. If details, functionalities or expectations change, both parties to the contract will want protection that they are only being asked to perform in a contract as expected. So define it upfront. Work well together to discuss opportunities that arise and put most of them into a list of phase 1.1 or 1.5 or 2.0 releases of the app, so that the initial release of the app can stay on track and not get blindsided by change requests.
7) What happens when I keep coming up with new ideas for the app?
We use a google drive document that allows us and our collaborators to continually revise a list of elements for versions 1.0 and then project all new functionalities into future potential releases of the project.These functionalities may move in priority as your business is developing, or the market is changing, but categorizing all of your continued innovations in a central location that all are party to, is a wise option for any group who is collaborating on an app release. This is the fun part of the project. Dreaming up cool stuff is one of the most exciting parts of the app creation process…. so continue to dream and never stop. But, be intelligent in your production process, by prioritizing your production from your 1.0 version of your app to subsequent versions in an orderly and methodical manner. It will save cost, reduce frustration, minimize unrealistic expectations and drive your product to success faster than adding yet another new cool feature to your developers while they are still working hard to get your previous brilliant ideas working. Work intelligently and produce effectively.
8) What is a User Persona and User Experience Document Useful For?
Your User Persona documents clearly identify as many potentially iconic users you would expect to use your app. The purpose of identifying their potential demographics, like age, nationality, gender, intelligence, interests, desires, needs, requirements, and user platforms that they are coming to your product with, is to make you narrow focused on delivering the very best product possible to service that combination of key variables. Keeping your user happy and satisfied is the core ingredient to success of a great app system. Your User Experience document takes you through a complete set of User cycles while engaging with your app. From first launch of your icon, through closing the app, the User Experience Document should clearly illuminate the flow of the experience to leave nothing left to presumption in the app design and development teams.
9) What are in-app purchases, and how can I create them?
If your app offers the opportunity to purchase anything, that is an in-app purchase. In-app purchases are subject to the 30% commission that that app stores charge, so understanding those fees, regulations, best practices and consumer reactions to in-app purchases is key to your success in this category. If your game offers incentives, short cuts, tools, toys, energy or anything else that the consumer will purchase to enhance their game experience, those are in-app purchases. If you offer subscriptions, or incentives to purchase any hard goods that ship to the consumer, those too, are in-app purchases. Before you embark on any in-app purchases, you would be wise to review the policies for in-app purchases from the stores in the app formats that you are producing your app in.
Apple policies: https://developer.apple.com/in-app-purchase/
Google Play policies: https://support.google.com/googleplay/android-developer/answer/1153481?hl=en
Amazon Store: https://developer.amazon.com/appsandservices/apis/earn/in-app-purchasing
Windows: https://msdn.microsoft.com/en-us/library/windows/apps/JJ206949(v=VS.105).aspx
10) How do I determine which features are required for a minimum viable product?
In his book, The Lean Startup, Eric Ries, discusses the “minimum viable product.” His initial definition, I think, requires a bit of adjustment to ultimately mean the product that can be produced which may produce the highest potential return on investment versus risk. This was initially a term coined by Frank Robinson and later brought to the masses by Steve Blank and Eric Ries. To determine the minimum viable product definition for your concept, take all of the potential variables that your brainstorms have generated and start stripping all of the bells and whistles off of the concept and pushing them into later phases of your release. Eventually, you will hit a point where you are considering taking away the features without which you would not have something that will bring value back to the end user, and ultimately create a return on the investment. Spend some time evaluating these features until you are certain of what you will put out as a version 1.0 and then spread the rest of those features/functionalities into lists of decreasing necessity. Then put your best 1.0 out into the world and start to make your iterations as you gain feedback from your customers.
11) Isn’t it better to save money producing your app overseas?
To generalize any individual nationality of developers, is unfair and ignorant. That said, we receive many projects showing up for us to consider when a team overseas has either dropped the ball, can’t complete a technological function that they promised to accomplish, or are burning up substantial amounts of time while they juggle numerous client projects. In any business situation, you most certainly get what you pay for. An app is such a critical investment, it is short sighted of a company or organization to work to save a percentage of their investment by taking the control of something so critical and bestowing it upon a team without a real track record.
As with all lists, this one is very incomplete. There are many topics we did not even touch upon in this discussion. If you ever have questions regarding how to produce your app or other projects, feel free to call us at 818-788-9700 x1 and let us help you organize your thoughts into a logical series of steps you will take to get your product produced.
