Case Studies



3 Business Decisions for Mobile Application Development – Audience and Platform

By Sean Reiche on June 5th, 2012 // No Comments


Welcome to the second post in a blog series on three concepts decision makers must understand for their own mobile application development.  Our first post was an overview of the three decisions we’ll be diving into in this series.  In this post, we’ll cover audience and platform support considerations every business decision maker should give a few brain cycles to before moving forward on their mobile development project.

Identifying Your Audience

Your first step is to identify your audience.  There can be several forks in the road that help you segment your application.  This process not only helps you define the features and functions of your software, but will be necessary in order to develop user stories around your mobile application.  You will want to consider:

  • Setting: Internal to the company or public-facing?
  • End-User: B2B or B2C?
  • Purpose: Money saving, a competitive advantage, or revenue-generating?
  • User Experience Level (UX-L): Geared towards advanced users or early-entry users?
  • Platform Support: Platform independent or specifically targeted?

Obviously this list isn’t exhaustive and there are gray areas, but this exercise will help you make important technology decisions.  The outcome of this process will help you set requirements around which software operating systems you are going to support (such as iOS, Android, Windows Mobile, Blackberry, Palm, even WebOS) and how you approach device support (smartphones, tablets, and everything in between).  We’ll get more into the form discussion later in the series.

Let’s take an example.  ABC Inc. has an outside sales group and they need to be able to send detailed survey information when visiting a client site so that HQ can validate and qualify the client.  This qualification could entail a credit check, scope of the job, validation of the salesperson’s information, etc.  The company purchases iPads with 3g (we’ll assume they are all the same version for simplicity) for all of their salespeople.

Going through our checklist above we have an internal application that is B2B and a mix of money-saving and a competitive advantage due to speed.  Our user level is going to be mixed and our platform support can be specifically targeted since everyone has an iPad.

The setting, end-user, purpose, and platform support are well defined.  Since we have a mixed UX-L, we should target our mobile application development towards the lowest level user.  Users evolve and so can this software.  This is where creating phases for our mobile application can align nicely with this UX-L evolution process.

Effects on Decisions

Now that we’ve thought about and gathered the information, we can begin to see how this will affect our mobile application development, content matrix, and requirement definition.

  • Setting: Minimal branding implications or other external concerns
  • End-User: Technical or internal vocabulary is allowed
  • Purpose: Metrics for success align with speed of service or sales closing window timespans and a reduction in costs per transaction.  All application efforts should move toward these goals.
  • UX-L: Use of standard iOS development tools and experiences should be adhered to.  Avoid unfamiliar or revolutionary techniques that a user would need to learn
  • Platform Support: iPad (iOS development).  We can expect all hardware such as GPS and camera to be fully supported and target those devices natively or through browser/wrapper/helper support.

I’m sure you can think of even more effects those decisions have on your iOS development project, but you can see the importance of thinking about the audience.


Any experienced decision maker can begin to see how these technology requirements will move the needle on budget and timeline for this project.  We can start to see technical requirements emerge from our business opportunity.  Our mobile application development and technology is being driven by our needs and not by a new fad.  This is how we create real ROI, but this is only the first step.

In our following posts in this series, we’ll dive into the speed to market and form and interaction decisions that affect our mobile application development.

Image Source

About the Author: Sean is a Project Manager for RDA's DC/Northern Virginia delivery team. His experience includes managing an e-commerce system where he led the product architecture and SDLC process (agile) for a web and mobile product intended for 300-700 stores and over one million B2C users in a SOA. The product developed used .NET 4.0, entity framework, HTML5 and Javascript for the front-end, and it integrates with the POS via WCF. He is also experienced with .NET 3.5 and SQL Server.