Outsourcing | December 14, 2015
Setting the Requirements for an Expert Nearshore Mobile App Development Team
How to build an expert nearshore mobile app development team, Part 1 The mobile app development market has exploded in recent years, but it still takes careful effort to create and manage a perfect team to accomplish your business goals. ‘Mobile development’ can encompass a wide range of products: from a 1.5” smartwatch screen, to […]
How to build an expert nearshore mobile app development team, Part 1
The mobile app development market has exploded in recent years, but it still takes careful effort to create and manage a perfect team to accomplish your business goals. ‘Mobile development’ can encompass a wide range of products: from a 1.5” smartwatch screen, to smartphones, tablets, cars, up to 100” smart TVs. Whatever you want to develop your app for major smartphone platforms like iPhone and Android smartphones, or to use the mobile market to its fullest, it all starts with business requirements.
Client needs and requirements
The first part of the process is always to define the needs and goals of mobile development. Those requirements have a variety of details – some clients can define exactly what system they want and can create a detailed specification of their expectations. Other clients only have more general business goals. That’s ok – there are appropriate models of cooperation for each of these cases.
The process of creating and updating project requirements is often split between the client and service provider. If you have a detailed requirements and want to directly control your development team – use the team extension model and use the provider’s developers as your own team. If you have requirements, but want to make use of the experience of the service providers to improve and refine them – use a development outsource model to have the analysis, design and project development done by the service provider. If you only have business goals – use the project outsource/managed service model, in which the service provider will take over the entire process – starting with designing a business model and proposal for your project(s), refining it, implementing it, and continuously supporting and further expanding it over time.
Read more about cooperation models.
To start defining the project requirements, we need to answer a few questions. The first one is about platforms – does the client want to release the app for iOS, Android, Windows Phone? Depending on goals, you can pick all of the above, if you want to have almost 100% market coverage, or only some of them to save on expenses. Every platform is different, and each one requires a slightly different approach to designing certain features. This is specific to the mobile world – projects typically have exactly the same requirements, but the resulting apps are slightly different on each platform. They are customized to the UI standard of each platform, tailored to services offered by each platform owner, and designed to be familiar to the target audience of each system. Those differences lead to the biggest question in mobile projects: Native or cross-platform development?
Cross-platform development makes it possible to create apps for every platform in one go, so typically it’s less expensive and requires smaller teams. But this technology often creates problems relating to implementing features, performance, stability and quality. It works great for apps for which the primary requirement is to present the user with information; but features like GPS, camera, advanced use of maps, layered animations etc. can be problematic.
Native development allows the team to achieve everything that is possible on each platform, offer the highest quality and level of performance, as well as perfect customization for the UI and design patterns of each platform. Native means that each platform has its own team of developers (at least one per platform), so there are more developers and the cost is higher, but it yields the best results.
Your service provider should always help to decide between cross-platform and native, because this impacts both technical implementation and limitations, team setup, and the budget.
If you only need the app for one platform – for example you are making an application for internal use in your company, and you only use iOS – always choose native, because there won’t be any difference in cost, but the quality will be higher.
Mobile apps are rarely stand-alone. Usually the data in the application is downloaded from the Internet – by means of a mechanism called API or webservice.
The client may already have some system and database which can be integrated with mobile apps. Alternatively, the service provider can design a web-based CMS (Content Management System) that makes it possible to easily edit mobile app content in the web-browser.
Defining app logic and functionality
After setting the baseline requirements and deciding on the external webservice, it’s time to define the core of the application – features, UX and UI. Depending on the cooperation model, this can mostly be done by the client, or the client can just define the business goals and the overall idea, and the service provider can design the exact features, UX and UI.
These are the typical phases of app design:
1. Functional specification – defining what should be in the application – which features are essential and which are optional. ‘Target audiences and devices should be kept in mind throughout the process..
2. Interactive mockup/wireframe – this stage defines UX and the overall layout and screens of the application. At this stage, the UX designer focuses on designing screens, transitions, and placing UI elements like buttons, images and text etc. However this stage doesn’t include the final look – only the layout. Preparing this stage allows the client to click through the prototype, and see how the application presents data, whether it is sufficiently intuitive etc. Making changes at this stage is far less expensive than making them after the application has been finished. Therefore, iterating the design and gathering feedback from potential users is essential.
3. Graphics – when the mockup is accepted, the next stage is to design final graphics for the designed mockup. This defines the final look of the application.
Having functional specification, the mockup and graphics concludes the requirement-setting phase. The next step is to define the team required for the project and the process of development, including quality assurance and testing. We will describe all this in the following articles. So stay tuned!