Each approach serves a need, but which option fits your business requirements?
Let’s say you want to create a new app. You’ve been dreaming of a technology solution to fix a problem within your company or you think you’ve identified an opportunity for your product team or you plan to enter a new business vertical.
Criteria to Consider
Let’s start by posing the question: Should I build my software as a mobile app, a web app, or something else? Is there a time when I should choose one over the other?
It’s tempting to just give a blanket answer to this question (if this, then that) however this would be disingenuous as there are so many different elements to consider when making this decision. In some cases, it might be obvious and in other cases, the answer might even be a combination of options.
So instead, our Design and Development teams tried to distill our thinking into four interconnected criteria that we think can support your decision making process:
- User Expectations
- Physical Environment
- Device Functionality
- Cost Considerations
User Expectations: How do users expect to use your software?
How people expect to interact with your software is a critical factor in its success. Social norms and behavior have been developing around specific devices and software for decades and are still changing every year.
For example, think back to how you used your laptop and mobile phone in 2011 and how you use them in 2021.
In 2011, my phone’s banking app was reserved for checking my account balance only. Anything important or financially meaningful had to be done on my laptop. It may have been entirely irrational but I thought that my laptop gave me an extra security blanket and a sense of familiarity that I didn’t have on my early iPhone.
Now in 2021, not only do I do all my banking on my phone but I get upset if they push me to the website. My expectations have changed and my bank now has to build around them.
Some thoughts to keep in mind:
- What are the tasks your users are trying to accomplish? If I publish an app that streams music, are my users using it to wind down during their bus ride commute or stay awake while they cram for an exam?
- If the app involves highly sensitive information and requires additional security measures, which devices are better equipped to apply those measures (e.g. biometrics & message based multi-factor authentication)?
- For internal or B2B tools, are your users comfortable downloading a work app on their private phone? Or would they expect to download it to a company device?
- Do screen size and real-estate matter to your user? A mobile software that uses a small screen can only fit so many features of your app while delivering functionality and a smooth user experience. If your users have to scroll through content or screens, are they expecting to use their fingers? Or would they expect a larger screen space and the help of a mouse?
User expectations are set by the users, so knowing who they are and what they think are critical to understanding how they will interact with the software and which devices it needs to run on.
Physical Environment: Where will your users use the software?
Location, location, location. Tied to user expectations is the question of where your users use the software. Are your users going to be using the app at the office? On the bus? At the beach? In a remote warehouse or facility in Northern Alberta? Because this will influence the device they use and the functionality they expect (more on that below). If your application is an internal tool for your employees, are they going to look out of place using their mobile phone in their cubicle in a busy office environment?
If your users are going to be using your software on the go or in a location away from their desktop, then it may make more sense to consider a mobile application on a phone or tablet. Alternatively, if they are going to be using the software in an office or at home, a web application they can use on their laptop’s desktop browser may be preferable.
A key thing to keep in mind when thinking about the environment is that most (but not all) web applications require an active internet connection in order to run, whereas you can design a mobile app to work asynchronously/ work offline.
Device Functionality: Does your software require device-specific functionality?
The line between devices seems to be blurred at the moment. For example, I can call my parents using Whatsapp from my MacBook and they answer on their Samsung tablet. However, for some applications, device functionality can play to the core of its business case.
Modern mobile devices offer a range of functionalities built into the hardware, including but not limited to: forward and back-facing cameras, GPS, NFC scanners, microphones, touchscreens, bluetooth, among others. And this list seems to grow each year.
Laptops and desktop computers meanwhile have their own unique set of functionalities (e.g. computing power, disk storage) and benefit greatly from the network of complementary devices such as physical keyboards, monitors, speakers, mouse, microphones, etc.
Let’s consider the amount of text your users would need to feed into your application. Using an app on a mobile device like a phone that supports a virtual keyboard is less suitable for heavy text input. However, a web application that can be easily used on a laptop or a desktop makes the user experience seamless to input/edit/ heavy volume of text with a physical keyboard.
There may also be scenarios where your software requires a combination of features from both devices (e.g. mobile app for scanning QR codes with a web-based admin that generates complex machine learning supported reports, or a mobile app connecting to a second device such as smart watch). And the functional requirements of your software may change over time as devices, environments, and social norms/expectations change.
Cost Considerations: The costs of distributing your app
Cost and distribution methods are another key consideration for your decision as there can be some hidden costs (money and time) to develop a mobile app that is distributed via the app stores such as Google Play Store, iOS App Store, etc.
If you want to list your mobile app in one of the app stores, you first need to set up an account and pay the required fees. Then you need to submit the app to the respective store for review, pass all the requirements before making it available to the users. Moreover, the app should stay compliant all the time while your app is available in a store. For this and any other transaction, the respective store takes a cut for if your application is listed.
If you instead develop an application for use in a web browser, there is no approval process or any account/transaction fees involved. Web-based apps can be a good option if you want to develop and release an app and skip the time/effort it takes for app store approvals.
What About Progressive Web Apps?
Progressive Web Apps (PWAs) are a fairly new framework for building applications that aim to combine the benefits of a web application with a mobile/desktop application.
As a quick definition, a PWA is ostensibly an existing web application that lives natively on a mobile device. It can be downloaded to a mobile device from a web browser or (most) app stores and behaves generally just like a regular mobile app and with less cost/time of entirely rebuilding the existing web app into a mobile code base.
While PWAs offer a lot of upsides if you need both a web and mobile app, there are also some limitations with this model, such as its ability to fully replicate a native look-and-feel and user experience, and Apple’s reluctance to allow for native-device features (e.g. push notifications) for PWAs on its platform.
It’s also important to keep in mind that not all web apps can be converted to a PWA. There are some key requirements:
i) The PWA should meet a user engagement heuristic
ii)The data needs to be served over a secured (HTTPS) endpoint
iii) The web app packaging has manifestation details related to PWA, and
iv) A defined service worker for offline support
This is just the tip of the iceberg. User expectations, external environments, functionality, and cost should only be the starting points that contribute to your broader UX, Technical Architecture, and Project Management discussion – in addition to your business goals and the creative solution you want to build.
Remember to keep your users at the forefront of your decision-making. Meeting their needs, knowing the kind of engagement and experience you want to create for them is of utmost priority. For example, when we were working with the Vancouver Airport Authority on streamlining the airport’s visitor authorization process, we knew that we had to keep the “human-side” of the users on top of our mind while recommending technological upgrades to their existing systems.