In wanting to develop an App to support your online business, you can get lost in the technical issues. Do you want to have it developed for a native platform (iOS, Android, Windows8, Blackberry), or do you want to use open HTML5 Web standards, or a hybrid of both? Then there are the permutations of all of this for tablet or phone, which can result in needing to create and support multiple versions. I would like to suggest that from your perspective as a customer, it is more important that you focus on the features that you want the App to deliver.
The one thing that having a foundation of experience in SDLC and Waterfall design methodologies has taught me is to have a strong appreciation of the requirements and design phase of the project. Agile methodologies focus on the same requirement/feature first mentality – bringing added value in prioritization of the requirements and chunking releases of these into smaller cycles.
My definition of a Requirement is that it describes the “who” and the “what,” while Design describes the “how.” Consider the following example: A requirement may be that you want your App to be able to use location information to provide the user with a map to your closest store. Whether the App uses Google maps on an Android device or Apple maps on an iPhone is a design decision.
Having led the effort to deploy systems for very tech-savvy customers, I found there was always an issue with the customer coming to me with a Design, rather than a Requirement. Having some knowledge, they were already contemplating the “how.” I believe this to be problem because it tended to result in a limitation to considering only one solution to the Requirement. I would then probe and ask questions to try to draw out the real motivation behind what was said, the real Requirement. Establishing this then provided a basis for the designers to brainstorm other cool and innovative ways of meeting the Requirement. This, in the end, would satisfy the customer much more than if we just delivered the App based on the initial discussions, by delivering the best solution possible.
One aspect of Agile methodologies that I really like is that they have spelled out specific roles in a development project. The Product Owner being the role that understands the user personas and needs. This is a role that I believe should sit on your side of the App development house, or someone who has a real understanding of the features you want delivered. This results in an investment by your company in terms of time and expertise, and should be considered in your internal costing for the App. In the end, however, it will result in a better end product being delivered.
Once these features are understood they can be evaluated, in terms of whether they are appropriate for web, tablet or phone. Engaging with the developers can open up discussions on difficulties in development (and costs) on a specific device which may then inform on the priority and schedule for delivery
In conclusion, when you want an App developed, focus your in-house resources on the feature sets you want in the App, and assign an expert to own that role within your company, and then engage with the development house to deliver on these features.
