Thinking of Building an App? – Five Things to Consider Before You Start
Posted by aonenetworks On April 12, 2014
Building a company app can open up all sorts of doors for you. It can lead to new marketing frontiers, provide better and more up to the minute information to your customers, provide information tailored to your customers based on their purchase histories, and provide you with more detailed and complete information about who your customers actually are and what motivates them.
The problem, of course, is that none of that happens in a vacuum. In order to get all that information out of a conjectural app that you might build, you’ve got to have a firm plan. See the ideas below to help you get off to a good start!
1) Don’t try to do too much
The first rule of software development is to create a design document and stick with it. You need a road map. A clear plan that outlines what you want the app to do, and what data you want it to generate, collect, and provide. Your app can’t possibly be all things to all people. Narrow your scope and focus. If needs be, you can create a second (or even third) app if your scope is just too big. An example here would be, for example, let’s say you want an in-store app for your customers. You want to be able to tell them about specials and deals, and to be able to access their previous purchase history to better target them. You also want them to be able to do their own price checks in-store, so you build in a barcode scanner and pricing database. Great! Stop there. If you also want an app that can monitor the performance of your product, tell when it is beginning to fail, and inform the customer, that probably needs to be a different beast.
2) Avoid feature creep
Your design document is sacred. Unless there is a dire need to make changes to it (as in, your company’s bottom line takes a big hit if you don’t), it stays as is. The rule of thumb should be, once the design document is “set,” nothing gets added, period. There should be huge barriers in the way of people who wish to add features beyond this point. Note here that fixing bugs isn’t the same as adding features.
3) When in doubt, ask
If you’re not sure what your app should “do,” exactly, ask . Form a focus group from a slice of your customer base. Ask them what they want to see in an app you create. What would help them most? What would get them excited? If you ask them, they’ll tell you, and the answers might not only surprise you, they might be quite different from what you had in mind. Listen to your customers. They know what they want better than you do.
4) Test, test, test
The worst thing you can do is to release code blind. If you’re not testing, re-testing, and testing some more, you’re asking to get burned. Few things will alienate your customer base faster than promising them the moon and delivering them a big slice of stinky, rotten cheese. Don’t do that. Don’t ever do that! If the app’s not ready on schedule, then it’s not ready. Better to be late and solid than released on some arbitrary date and create a messy public spectacle.
Don’t create busy work or headaches for yourself.
5) It’s an iterative process
Don’t imagine that once the app is built, you’re done. You aren’t. You probably never will be. Once the app is “in the wild” and being used by your customers, new ideas will emerge. Improvements and refinements will reveal themselves. Take advantage of all customer feedback and start planning a “Design Document 2.0″³. Then act on it!
