Each day, thousands of mobile apps are published to the Google Play and Apple App Stores. Some of these mobile apps are games, others are social networks, and many are ecommerce apps. All of these apps, if professionally built, should follow a similar mobile app development process. At BHW, we have built over 350 web and mobile apps. In this article, I will outline the strategy, design, and development processes we follow.
Each app is different and our methodologies are always evolving, but this is a fairly standard process when developing mobile apps. This mobile app development process typically includes idea, strategy, design, development, deployment, and post-launch phases.
Idea
As trite as it sounds, all great apps began as ideas. If you don’t have an app idea, the best place to start is to train yourself to always think of things in terms of problems and potential solutions. You want your brain to instinctively ask “Why do we do things this way?” or “Is there a better way to solve this problem?” If you can identify a problem or market inefficiency, you are half way to your idea!
The next thing to do is understand why this problem exists and think about why nobody else has made an app to solve this problem previously. Talk to others with this problem. Immerse yourself in the problem space as much as possible. Once you have a complete grasp of the problem, begin to evaluate how a mobile app could solve the problem.
This is where having some understanding of what mobile apps can do is extremely valuable. We are frequently asked, “Is this even possible?” Fortunately, the answer is often yes, but it is imperative that this answer is sound. You are about to invest a considerable amount of time and money into an app, so now is the time to challenge your idea’s validity and viability.
Strategy
Mobile App Process – Strategy Diagram
Competition
Once you have an idea, you need to plan for your app’s success. One of the best places to start is by identifying your competition. See if any other apps serve a similar purpose and look for the following:
Number of instals – See if anyone is using these apps.
Ratings and reviews – See if people like these apps and what they like/dislike about them.
Company history – See how these apps have changed over time and what sort of challenges they faced along the way. Try to see what they did to grow their user base.
There are two main goals of this process. First, learn as much as you can for free. Making mistakes is time consuming, frustrating, and expensive. Often, you have to try a few approaches before getting it right. Why not save yourself a few iterations by learning lessons from your competitors? The second is to understand how hard it will be to compete in the marketplace. Are people hungry for a new solution? Is there some niche not being filled by the existing options? Understand what gaps exist and tailor your solution to meet them. If your idea is completely new, find other “first to market” apps and study how they educated consumers about their new product.
Monetization
Unless you just enjoy building apps for their own sake, you are probably hoping to make money on your mobile app. There are several methods of monetization that could work, including: in-app purchases, subscription payments, premium features, ad-revenue, selling user data, and traditional paid apps. To determine which is best for your app, look to see what the market expects to pay and how they expect to pay for similar services. You also need to consider at what point you begin monetizing your app. Far too many apps (particularly startups) skip this step and have a hard time later turning a profit.
Marketing
This step in the mobile app development process is all about identifying the biggest challenges you will face when marketing your app. Assuming you have a reliable app development and app design team, your biggest hurdles will likely be driving app adoption. There are thousands of beautiful and quite useful apps on the app stores that simply go unused. At this point you need to understand what your marketing budget and approach will be. In some cases (like internal-use apps or B2B apps) you might not even need marketing.
Road Map (MVP)
The final stage of the strategy process is defining your app’s roadmap. The goal of this process is to understand what your app could one day become and what it needs to be successful on day one. This day one version is often called your Minimum Viable Product (MVP). During this process, it can be helpful to write on a whiteboard all of the things you want your app to do. Then begin ranking these items by priority. Consider what your app’s core functionality will be, what is needed to gain users, and what can be added later. If there are some features you think users might want, they are likely great candidates for later versions. As you gain users with your MVP, you can solicit feedback on what additional features are desired. App monitoring (covered later in this article) can also assist in this process.
User-Experience Design
UX Design Diagram for Mobile Apps
Information Architecture
Information architecture refers to the process of deciding what data and functionality should be displayed within your app, and how it should be organised. This is usually done by creating a list with the features you want your app to do and listing the items that need to be displayed in the app. These are the foundations upon which the wireframes will be built.
We use the following tools: Pencil and paper, whiteboards, pencils
Wireframes
Next, create screens and assign each function and data. While it is fine for some items to live in more than one place, you must ensure that each item has its own home. This is often done on whiteboards or papers. It is cheaper to make minor changes now than later on in the process. After you have created several screens, start to think about your app’s workflows.
We use the following tools: Pencil & Paper, Balsamiq, Sketch, Whiteboards and Pencil.
Workflows
Your app’s workflows describe the paths users can take within your app. Think about the actions you want users to perform and calculate how many clicks it takes to accomplish them. Each click should be easy to understand. It is fine if it takes several clicks to complete a task, but common tasks should take no more than a few clicks. If you discover problems in your workflows, make changes to your wireframes and retry. Make sure to go through each iteration of your features to ensure that you didn’t increase the difficulty of any one action.
Tools we use: Whiteboards, Pencil & paper, Invision
Click-through models
Click-through models allow you to test your wireframes or workflows. These models allow you to test your wireframes using a smartphone for more realistic testing. Our clients receive a link that allows them to navigate the wireframe. The app does not have any functionality, but clients can click on the pages to test the navigation. You can make adjustments to your wireframes as you discover issues. Keep iterating until you are satisfied.
We use Invision as a tool.
User-Interface Design
Mobile App Design Diagram
Style guides
Your app’s style guide is basically its foundation. A sound style guide can make your app more user-friendly. Your call to action buttons should not be placed at different places on the screen. Users will feel more comfortable using your app if you use a consistent design language.
It is not easy to determine the style of an app. It is important to think about who you are as well as who your customers will become. Do you plan to use your app at night? A dark theme might be best to avoid blinding your users. Is it likely to be used by busy employees? Keep the clutter down and focus on your main message. Experienced designers or teams can produce an app that will be a good fit for your customers and you. This phase produces a variety of colors, fonts and widgets (buttons or labels, etc.). These will be used in the design of your app.
Rendered designs
Rendered design refers to the process of replacing grayscale elements in wireframes with elements from your styleguide. Each wireframe screen should have a rendered screen. While it is important to stick to your style guide, you don’t need to be rigid about it. You can update your style guides if you feel the need to change or create a new style. When you are done, make sure that your design remains consistent.
We use the following tools: Pencil, pencil & paper, and sketch.
Rendered Click through models
After you’ve finished rendering all screens, go back to the click-through application and test your app once again. This is where you want to really take your time in the app development process. While the app has been developed with a lot of effort, changes can be costly. This is similar to reviewing a floor plan before concrete is poured. Mobile app development can be a lot more flexible than construction. However, this approach can be the most cost-effective.
We use Invision as a tool.
Design-to-Development Handoff
Your development team must realize your vision after you have put so much effort into your app’s form and function. This step is often overlooked in mobile app development. This could be due to agencies and organizations only offering design and development services, or because of the sometimes hostile relationship between developers and designers. No matter the reason, it is important to find a team that provides both design and development services. They can also handle the next step of the process.
The proper use of tools is key to smooth transitions and precise implementation. Zeplin is an app that allows developers to quickly access style guides to help them design. This isn’t foolproof. Zeppelin can be a powerful tool but its guides may not be perfect or the best. For example, it can use explicit dimensions instead of dynamic ones. It is a great advantage if your developers are able to use design software (such as Photoshop or Sketch) in these situations. Your team must not rely on their best guesses about dimensions, hex values (colors), or positioning. The design team made great efforts to make sure everything was correctly positioned and aligned. Your goal as a developer should be to ensure pixel-perfect implementation.
We use Zeplin.
Tech Stack: High-level technical design
There are many ways to create a mobile app. Each approach has its strengths and weaknesses. While some might be more affordable, others may be less efficient and take longer to implement. Building on an outdated or unreliable technology stack is the worst option. This could mean that your app will need to be rebuilt or you may have to pay more for developers. This is why it is important to have a trusted partner who is experienced in these types of decisions.
Front-end (the app for mobile devices)
There are three main approaches to front-end development. There are three types of front-end development: platform-specific native (cross-platform native), hybrid, and cross-platform native (cross-platform native). This article will give you a quick overview of each method and provide more detail.
Native apps that are platform-specific – These apps are created for each mobile platform. Although code cannot be reused between Android devices and iOS, these apps can be optimized for each platform. The UI can be completely native so it fits in with the OS. And the app should run smoothly. This is the most costly approach but it has been proven to be very reliable.
Cross-platform Native Apps – Apps created with this approach share some code (or all) but still run natively. Native Script, Xamarin and React Native are all common technologies. This solution is a good compromise between all the other options. It is cheaper, but it can be styled and optimised for each platform.
Hybrid Apps – Hybrid apps use web technologies (HTML CSS Javascript, CSS) and are installed using a native wrapper. You can do this using technologies like Cordova, Phone Gap and Ionic. This is the most affordable option, but it can also present some real problems.
Back-end (Web API and Server)
Your app’s performance is largely determined by its server. These technologies are very similar to the ones used in web-based apps. Before you start writing code, here are some things to consider.
Language – There are many languages you can use to build your API. C#, Java, Go-lang and javascript are all common languages. Many languages have many frameworks that can also be used.
Database – There is a main type of database, SQL or noSQL. SQL is the most traditional choice and it’s the best in nearly all situations. There are three main SQL implementations: MSSQL (MYSQL), and PostgreSQL. You must also choose a database engine and design your database schema. Your long-term success depends on having reliable, well-organized data. This is why it’s important to plan your data.
Hosting Environment (Infrastructure). This step will allow you to choose where and how your API/database will be hosted. These decisions will impact the cost, scalability, and reliability of your app’s hosting. Rackspace and Amazon AWS are two of the most popular hosting providers. You need to consider how your system will scale with your users. Cloud-based solutions let you pay for resources as a utility, and scale up or down as necessary. They can also assist with database backups, server uptime and operating system upgrades.
Mobile App Development Diagram
Iterative mobile app development is key to sound results. Most people have heard of “sprints” and “agile methodology”. It basically means you break down all development work into smaller milestones, and build your app over a series of cycles. Each cycle will contain planning, development and testing. This process is so complex that there are many books on it. We will only briefly cover each step. These steps can be used in a similar way if your company uses another process. However, the order and length might differ.
Plan
Planning is the division of the tasks that will be completed during each iteration. Each task must have clearly defined requirements. Developers will need to understand the requirements and then estimate the time it takes to complete each task. This allows for a more balanced workload in the sprint.
During this phase, developers also start to plan their solutions. Software developers who are skilled in software reuse can find clever ways to do so throughout their applications. This is particularly important when implementing shared functionality and styles. You don’t want multiple places to update code if a design has to be modified (believe me, it will). Software that is well-designed can be modified in a few places to make such large changes.
Development
Your development team will start implementing the styles, functionality and design of your app during the development phase. Once they’re done, they are sent back to the project manager or QA tester for approval. Project managers who are skilled in distributing tasks throughout the sprint can optimise developer workloads.
Your development team must be able to understand both the overall goals of the application and the particular feature they are working on. The developer assigned to that feature is the most knowledgeable. They must understand the requirements. Developers are often the ones to tell you if something isn’t making sense.
We use private beta platforms for development (Testflight iOS and Google Play Beta Android). These platforms allow us to securely and privately distribute the in-development app to clients, testers, and other developers. These platforms notify users about new builds so everyone can test it. They also provide crash reporting and allow only approved testers access to your app. This is a great way for everyone to be kept up-to-date on the progress. We try to update beta builds at least once a week during development.
Test
Non-developers should do most of the testing, or at least someone who is not your app’s primary developers. This will ensure that you have a more authentic testing experience. There are many types of testing that should be done during every sprint. These include the following:
Functional Testing – This is testing to verify that the feature meets the requirements. QA teams will usually have a test plan that includes a list and desired behaviour.
Usability Testing – Testing to make sure the feature is intuitive and user-friendly. It is often helpful to bring in additional testers during this step.
Performance Testing – While your app may work flawlessly, if it takes 20 seconds for a list to load, no one will use it. Although performance testing is more important during later sprints, it’s still vital to monitor the app’s responsiveness.
Fit and Finish Testing – Even though the design phase has been completed, that doesn’t mean your designers can be locked in a room. Designers need to review every feature and make sure that the vision is being implemented. This is why it is beneficial to have one agency that handles both design and development.
Regression Testing – Remember the one feature you used in the last sprint? It doesn’t mean it is still working just because it was tested last month. Good QA teams will have a list to run at the end each sprint. This will include previous sprints.
Device-Specific Testing: There are thousands of operating system and device combinations around the globe. Your app should be tested on a variety of screen sizes and OS versions when testing. Google Firebase is a tool that automates this process, but you should always test your app on at most a few physical devices.
User Acceptance Testing – This is testing that an app owner or future users performs. Keep in mind who the app is being built for, and seek their feedback during the entire process. What use is a feature that fails to pass all of the above tests?
As issues are identified, assign tasks to developers to ensure that they can be solved and the issue is closed. After testing is complete and all tasks are completed, it’s time to move on to reviewing.
Review
Talk with all stakeholders at the end of each sprint to determine how it went. Try to avoid similar problems in future sprints if there were any difficulties. You can apply what went well in one area to other areas. There are no exact blueprints for every project. Everyone should be striving to do better in all areas. After the review is completed, you can start planning again and continue this process until your app is finished!
Extended Review
Your app should now be fully tested and feature-complete (at least for the MVP). You should test your app with some of your potential users before you spend too much time or money marketing. This can be done in two ways.
Focus Groups
Focus groups are interviews with testers or groups of testers about the app. It is important to get to know the testers, their learning habits, and whether they have used similar apps before. Before you even start working on your product, get to know them. Next, let your testers begin using your app. This is not a time to coach them. Instead, let them just use the app as if it was new to them. Watch how they use it and identify common problems. Get their feedback after they have finished using the app. Don’t let one tester guide you. Instead, combine feedback to make informed decisions based on all the available information.
Beta Testing
You can also launch your app beta without having to hold focus groups. Beta testing is when you get a group to test your app in real life. The app is used in the same way as it was launched but with a smaller number of testers. These beta testers are often power users and early adopters who could be your best customers. You must make sure they feel respected and valued. You should give them plenty of opportunities to offer feedback. Let them know when the app is being updated and how. Beta testing is an excellent way to test your app on different devices, operating systems, and network conditions. This step requires sound crash reporting. If something goes wrong but is not diagnosed and corrected, it does no good.
Refinement
It is common to hold a final sprint for any new issues after these lengthy review periods. Ensure that you continue beta testing throughout this process, and that your issue and crash reports are decreasing. Now it’s time to prepare for deployment.
Deployment
Mobile App Deployment Diagram
Two main components are required to deploy your mobile app in the world. The first is to deploy your web server (API), into a production environment that’s scalable. The second involves deploying your app on the Google Play Store or Apple App Store.
Web API (Server)
Mobile apps need a server backend in order to function properly. These web servers transfer data between the app and its server. The app will not work if the server becomes overloaded or ceases to function. Servers that are properly configured can be scaled to accommodate your current and future users, without being too expensive. This is where “cloud” comes into play. Your server can be deployed in a scalable environment such as Amazon Web Services, RackSpace, or other services. It should be able handle higher traffic spikes. Scaling mobile apps is easy. However, you need to make sure your team understands what they are doing. Otherwise, your app may crash just as it becomes popular.
App Stores
It is not difficult to submit your app to the app store. Make sure that your apps are ready for release. Fill out multiple forms for each store. Submit screenshots and marketing materials. Write a description. Apple also reviews every app submitted to its app store manually. They may request that you make some changes to your app in order to comply with their regulations. These changes can often be discussed with Apple to get their approval. Sometimes, however, you may need to make some changes in order to gain access. If everything goes well, your app will go live in Google and Apple as soon as it is submitted.
Monitoring
Monitoring Diagram for Mobile Apps
It would be foolish to assume that the mobile app development process is over once the app has been shipped. You will find a long history in app updates even for moderately popular apps. These updates can include performance improvements, new features, fixes, and other changes. To fully understand the needs for updates, it is important to monitor your system. These are some things to be aware of.
Crashes
You can use many libraries to track app crashes reliably. These libraries contain information about the user’s activities, the device they used, and other technical details that can be crucial to your development team when attempting to resolve the problem. You can set up apps to notify
you via text/email when there are crashes. These crashes can then be viewed and sorted accordingly.
We use the following tools: Sentry, Bugsnag
Analytics
App analytics systems can provide a wealth of information. These systems can provide information such as age, gender, location, and language that will help you to understand your app users. You can also see how they use it (time spent in the app, screen viewed in the app, etc.). You can even view heat maps of the app so you can see which buttons are being used most frequently. These systems give you a valuable insight into the use of your app. This information will help you to determine where to invest your future efforts. Do not hold onto parts of the app you don’t use often. Instead, invest in the areas that have the most potential for growth.
We use the following tools: Apptentive, Facebook Analytics, and Google Analytics
Performance
Your app’s technical performance is a vital metric that has not been covered by the other two monitoring categories. How fast it runs. Every system we use has performance monitoring. We can track the number of times an action was performed and how long it took. This information is used to identify areas that could be optimised. We have alerts that let us know when a certain action is taking longer than we expected so we can quickly check for any problems. These performance tools often include reporting, alerting, and dash-boarding functionality.
Prometheus is one of the tools we use.
App Store Management
App store reviews and ratings are very important, especially for newer apps. Engage the reviewer whenever a review is posted to your listing. You should thank users for leaving great reviews. Also, help those who are frustrated. With a little bit of customer service, hundreds of bad reviews have been transformed into 5-stars. App developers and owners don’t have to be available 24/7. This will help you build your online reputation.
More Iteration and Improvement
All this monitoring is done to help you know what to do next. Apps are rarely finished. There are always new features and improvements that can be made. Blindly building on an app would be extremely wasteful. Take the data you’ve gathered from users and monitor platforms. Next, you can repeat the steps of your mobile app development process. Keep improving your app’s conversion rates, install base, revenue, and other aspects. Mobile apps can be fluid. You can take advantage of this by improving and growing your mobile app.
Conclusion
It can seem complicated and overwhelming to develop a mobile app. It is not easy. There are many steps to follow and some difficult decisions to be made. It is a rewarding process that can lead to a lot of money. It is tempting to skip steps during this process. However, this guide was developed from years of working with app owners who chose to skip certain steps.
You’re in luck if you want to create your first or next mobile app. App owners of all stages are welcome to join the BHW Group. We can help you create a mobile app that is both innovative
and useful, no matter if your company is a startup or Fortune 50. Contact us immediately if you have any questions.