Let's be honest, there are a lot of ordinary apps out there and in an increasingly noisy marketplace, another ordinary app will just disappear from view.
On the 5th anniversary of the App Store in July of this year, Apple announced that more than 50bn apps have been downloaded since it opened in 2008. That's a lot of apps, in fact Apple claims that customers are downloading around 800 apps per second, and of course Apple represents around 20% of the European smartphone market.
So, if you're thinking that you want to develop an app, there are a number of key points to consider before you proceed in order to ensure that it stands a chance of being successful and stands out from the crowd. From small start-ups to large corporates, some core principles apply to anyone building mobile software. Do you really need an app in the first place? If you do, how do you go about creating one and how can you guarantee that it is a success? How do you make sure that you don't end up with a slow, bug-ridden, unresponsive and unmaintainable app that costs you a small fortune to create and maintain?
A poorly performing app can create customer backlash and generate both high levels of dissatisfaction and negative publicity.
Whether you are looking to create an app to improve an internal company process or an external app to improve customer interaction, this article provides the key points and considerations when planning and developing an app to help you ensure it is a success.
1. Be Clear About Why You Are Building an App
In today's app-driven world, there is an ever-growing expectation - your employees and customers expect you to have an app, and quite rightly they expect using it to be a good experience. Think about the end results of the app, and what you want it to achieve.
Apps have many benefits; they can improve internal company processes, provide a fast & efficient way for your customers to interact with you, increase customer engagement and improved brand presence, create new business/sales, promote you as an innovator in your field and they can also generate hard revenue directly through paid downloads, in-app advertising or in-app purchases.
If you just want your website available on a mobile device, create a responsive website. A mobile app can add so much more and should enhance and complement the offering of your existing website, not just copy it.
You also need to consider the balance between generating downloads and setting the right price. Understand how your choice will impact on the app usage and how the user will view your brand. Free downloads are still far more popular than paid ones so charging for your app should only be done if it truly adds value through content or functionality.
2. Understand Your Target Users
To design and create an app, you need to understand who your end users are. What are the demographics and technical abilities of your audience - savvy or novice? What will their usage patterns be? When do you expect them to use the app? And for how long? Where will they have connectivity and what mobile platforms and devices do you expect them to use?
Considering these questions, even if you can't answer them all, will help you to define and design your app to ensure is it useful and usable.
3. Clearly Define What the App Will Do
The keys to a successful app are simplicity, usability and reliability. An app should be developed to meet a specific need, or perform a specific task. It is better to launch a simp le application that does one thing well, rather than one that does lots of things badly.
Think about the app from the end user's perspective. What are the key functions that they will want to perform? And how will they flow through the app to complete them?
The more detail you can add at this stage, the better, as it will help your development team to provide more accurate estimates and delivery plans. No one wants surprises later in the project as new requirements add extra cost and time delays.
Consider how the app will compliment your existing website, brand and any mobile apps you have already launched, and how it could support these to provide a consistent and interconnected user experience.
4. Content is King
Applications generally fall into 2 categories - those that are used to consume content, and those that are used to create it. If you're consuming content, it is vital that you spend some ti me thinking about where that content comes from, and how it gets into your app.
Whether the content is embedded into the application, or downloaded from a server, will massively affect both the size of the application, and the complexity of the code. Embedding the content makes it harder to update, but makes the code simpler. Downloading content from a server makes the code more complex, but makes it easier to update.
5. Design an Intuitive UI
A good user experience is critical to the success of any app - if the experience isn't good it will massively impact on your brand. Expectations are high; users are accustomed to well-designed, functional applications. An app that is not intuitively designed only serves to put up barriers to adoption.
When considering the UI, it's important to recognise that all smartphones are not created equal. Whilst a consistent look and feel helps to reassure users on different platforms that your brand values are consistent, users of an Android device do not expect apps to behave like they're using an iOS device. Each platform has certain idioms which users become used to - an app which breaks those idioms feels jarring to use, and will generally be rejected.
Designing the UI is a process that may take much iteration to arrive at a final design. Recognising this and avoiding starting code-development until that design has been finalised and tested can save time and money. It's quicker, cheaper and easier to test a paper or HTML-based mock-up of a user-interface than it is to fully-develop the application and then discover that t he UI doesn't work with real-world users.
6. Use a Team Capable of Delivering a Great App
You may have a compelling idea and a detailed brief but, if you are new to application development, making it real can seem daunting. One of the questions you need to answer is, do you have the capability and expertise in house to design and create the app, or do you need to bring in a partner to undertake some or all of the project?
You may also want to create a mix of internal and external teams to cover the various roles required, from Back-End System Engineers, User Experience Designers, Graphic Designers, Mobile App Developers, Testers and Project Management. Choosing the right partner and ensuring the interfaces between all of the parties is clear and understood will be major factors in determining your success.
There are a lot of companies who can create basic apps, but not all of them have the relevant experience to build you an innovative, compelling and intuitive app that reflects the quality of your company and brand.
The right partner should take a holistic approach - developing an app isn't just about programming. An experienced supplier should be able to take you through concept creation & definition, user interface design, development, testing, launch, social media integration, analytics and on-going support to fix bugs and ensure compatibility with new platform versions and devices as they launch. Ensure what is included within the cost is clear.
Be careful and consider the following when selecting a partner:
- What is their Mobile Experience?
Do they have a proven track record of successfully delivering similar projects on the same mobile platforms?
Check out their portfolio and get references from previous customers. How much of the apps were they actually responsible for
- all of it, or just some of it?
Do they have a deep understanding of how to build mobile software that can handle the small memory footprints, changing connectivity status, security, power consumption and device fragmentation on mobile devices?
Do they outsource any of the work to other contractors/companies, or do they have the experience and capability internally to deliver your project?
Where is their development/project team based and is it easy to meet the people who will be working on your project? If in doubt, ask for CVs - any reputable supplier would be happy to provide them.
- Do they Understand your Requirements?
Does the supplier have a clear understanding of the considerations of implementing your requirements on the selected platforms? Have they identified any potential risks with the project and stated how they will mitigate against them?
Do they have the experience to question (in the nicest possible way) your requirements and assumptions and suggest ideas to improve the app?
Ask the developer about their app development strategy and what they propose is the best solution for your project - Native, Web, Cross Platform Development Tools or a Hybrid app. Understand the pros and cons for each solution and how they fit your needs in terms of performance, offline capability, reusing existing web content, future updates, maintenance and costs and delivery timescales. Ensure that what you will receive from the supplier is clear.
- What is their Delivery Plan?
No one likes surprises on a project, so you should review your supplier's plan to make sure it is accurate and encompasses the key stages of your project - this should include timescales and key dependencies.
Regular releases will enable you to assess the progress and quality of the project as it develops, and identify any changes you wish to make earlier in the project.
It is also important to consider what testing they will perform, and how they will support you post launch.
- What is their Development Process?
What is their development process for the key aspects of software engineering such as: Requirements Definition, UI Design, Source Control, Coding Standards, Architecture Design, Code Reviews, Continuous Build, Testing, Change Control, Release Management etc...?
What happens if change happens on a project, and let's be honest it does happen. Will your supplier hit you with a Change Request (CR) immediately, or will they work with you to mitigate the change as much as possible before raising the change as a CR?
What documentation will the supplier deliver on the project?
Will the supplier include any open source components, and what legal, project and commercial implications will that impose on you?
Understand what development methodology will be used. Whether the process that you or your partner follows is Agile, Waterfall, Test-Driven, or Business Driven, is less important than making sure that it fits with your expectations as a customer. More often than not, the difference between one process and the next is a series of trade-offs. In general terms, a process which allows for greater flexibility, in terms of requirements for example, is likely to be more expensive than a process that emphasises up-front specification. The trade-off is that a specification-heavy process requires far more work up-front, and is less flexible once development begins.
7. Ensure that the App will be Launched Using Your Brand and ID
This is really important - unless it is agreed up front for "commercial reasons", don't let the supplier launch your app under their name. This can confuse users and it can be difficult to change later.
If you create a great app, it should have your brand all over it.
8. Get the Source Code
Again, unless it is agreed up front for "commercial reasons", ensure that you own the source code.
You've paid for it after all! Also make sure you actually receive it - this may sound obvious, but it still surprises me how this isn't always the case.
Owning and possessing the source used to build the app gives you options when it comes to maintenance and future releases, regardless of whether you are happy with your current app supplier or not. It would also be a good idea to receive regular drops of the source code throughout the project, and get it independently verified to guarantee that you get quality software that is easy to maintain and extend in the future.
9. Test, Test, Test
One of the most valuable lessons we have learnt over the last 15 years is to involve the test team early in the development process. It allows them to understand the scope of the project, highlight any issues, provide input, and start to define the test plans. This can massively reduce problems when the application is nearing completion.
One of the foremost challenges when dealing with apps is maintaining support across multiple devices and platforms. The only way to do this is to test. Define the testing process, who needs to be involved and what the acceptance criteria is, early in the project. Detail the expected device support list and platform versions, and understand the latest trends in terms of OS adoption and market share. If you need to support all users, you will not be able to test on every possible device, so you will need to define a strategy to test on the lead devices, and perform a reduced test on a larger range of devices. Covering all OS versions will make targeting new OS features impossible.
You also need to understand the different types of test that you will require at different phases of the project, and understand what testing will be provided by your supplier; System Testing, Integration Testing, Smoke Test, Regression Testing.
Also define whether you will be undertaking manual or automated testing, and understand the costs and test coverage of each method.
Ensure you understand and define the edge cases that can occur in mobile app usage such as a sudden loss of connectivity, changing IP addresses or loss of battery at any point, and test for them. In our experience, regular app releases and testing throughout the project will help to make sure you develop a stable and intuitive product - you do not want a shock towards the end of the project!
Our typical approach to development and testing is to recognise that mobile platforms incorporate a huge number of variables, and whilst development requires stable and repeatable environments; testing apps needs a larger degree of variation in handsets, radio environments, battery states and even geographic locations to find those complex bugs. Be warned, if you don't find them, your users will!
After initial launch, and whenever you make a new release, ensure you retest it to make sure nothing has been broken - your users and their app store comments will not take kindly to you breaking their favourite app!
Finally, you need to define the process for defect triage, fixing and management and outline what tools you will be using for defect management. Our final tip here, no matter which tool you use, is to ensure that everyone uses the same tool. Migrating defect lists between different systems is going to cause you a lot of time and effort.
10. What About After the App is Launched?
An app is not just for Christmas, unless you want it to be. An app that serves your business well could be around for years, but will need updating to keep it fresh and working on the latest devices and platform versions.
Think about the long-term roadmap for your app and how it will support the new mobile platform releases and devices that will be launched. Has the architecture of the app and software been created with this in mind?
It is not always possible for a developer to guess the future, but you will need to understand how ongoing support for defects or user feedback will be managed. Consider having a formal Service Level Agreement from your supplier detailing the costs and how they will respond to issues after the app is launched.
Review the app store rating and comments to get feedback from users. Also assess whether to include analytics within the app to assess the app usage and trends, and use all this information to make decisions on future updates & enhancements.
11. App Marketing
Make sure your app stands out. With hundreds of new apps launching each day, it isn't enough just to launch a great app and hope it gets downloaded - it won't unless people know it exists. Plan the launch and ongoing promotion of your app with a comprehensive marketing plan that fits within your overall marketing strategy. You will need to consider whether your app needs a wider distribution than just the normal app stores. You don't always have this option available, but if you do, you'll need to think about how you get your app to your customers.