You Want to Design an App for That, But Should You?
Below we will dive into each of these buckets further to identify how they can help you determine what kind of app (if any) you need.

Who are my users?

While this may seem obvious, it is the most common step I see missed in the software design process. To truly understand who your users are, I recommend you break this task down into two main buckets: segmentation and engagement

If you are an impact organization, your customers may be very diverse with unique needs and in fact, you may target those especially diverse or niche needs specifically. As you consider the questions above, I recommend you start with why customers engage with your organization specifically and that will lead you to what attributes your customers share. If you are an impact organization, your customers may be very diverse with unique needs and in fact, you are ready to move on to understanding what tech solutions your organization can provide.

What are my organization’s strengths and capacity?

While customers may be asking you daily why you don’t have an app, understanding what your organization can actually manage and support is just as important as understanding what your customers want.

Some key considerations here are:

Is an app consistent with your brand and the experience you want to generate for customers?

Does your organization have the technical know-how to support an app?

Does your organization have the capacity to provide customer support for the app? Who will your customers call when they need help?

Can your organization afford an app?

Let’s look at these considerations in detail:

Is an app consistent with your brand and the experience you want to generate for customers?

Brand image is a critical asset for any organization and can quickly be eroded by a negative experience. While apps can make engagement easy and convenient, they can also feel impersonal and reduce the opportunities you have to provide excellent customer service. Think about if you are making a major investment and purchasing a complex piece of equipment. While an app may let customers browse at their convenience, it would be very difficult to replace a helpful, knowledgeable, and available sales representative. Any new technology you decide to release to consumers must be consistent with the experience you want to create for customers.

2. Does your organization have the technical know-how to support an app?

One common thread I have heard when implementing technical solutions, is an assumption that they can hire contractors or get volunteers to technically support the app. Unfortunately, apps require frequent management and updates, and inconsistent people working on coding or updates can lead to increased issues and a Jenga tower of code. I have specifically seen this with impact organizations who engage volunteers on a project basis to manage the app, but when the volunteer leaves, so does the knowledge. Even if you will not want to add functionality to your app, there will still need to be updates as phone operating systems, security standards, and other connected technologies evolve. Your organization will need to be able to clearly articulate the structure, code locations, logins, etc. as you onboard anyone new to the app, and a contractor who leaves may not provide you the necessary documentation. Even if you do not have a highly technical coding level expert, you will, at a minimum, need someone who can onboard each new person working on the app, which requires time and technical capacity.

3. Does your organization have the capacity to provide customer support for the app? Who will your customers call when they need help?

The other common fallacy I have heard surrounding app launches is the mentality that once it is launched, the workload on the organization will decrease and will not require ongoing attention. Aside from the continued technical support discussed above, you will also need resources for customers who are struggling with the app. Even a well-designed app that is intuitive for users will still generate login issues, download or update questions, and, depending on the functionality of the app, even more issues such as refunds for transactions that did not process correctly, questions about security or hacked accounts, and more. Your organization will need to have a plan in place for how to support these users, clear communication to users on how to reach you, as well as sufficient manpower to address them.

Image source: Unsplash

4. Can your organization afford an app?

The final false belief I hear commonly is that they went online and found a site where they can develop an app for around $200. If you do a quick google search on “cost to develop an app” you will see figures ranging from $1,000 to $100,000 or even $1,000,000. This is very dependent on the type of app you want, who you want to build it, and what quality you expect. Here is the honest truth… building a good app takes time. Not just time to write the code, but also time to understand the requirements, develop an approach, create the architecture, perform testing, fix any issues, document the design, and more. These are all just the basic element of launching any app. This does not include if you want users to login (or even more expensive, login through a shared service like Facebook), connections to payment systems, an excellent and clean user experience, or geolocation. Someone will need to document and design every page a user could land on within your app. In addition to the basic cost of just building the app, there are also extra costs like adding the app to the app store, integrations, and data storage. In order to add an app to the app store, someone in the organization (or perhaps the contractor creating the app) will need access to the app store, with a yearly license at $100 for just the Apple App store. Integrations are the other piece which can exponentially drive costs up. While you may not think you need any integrations, think about any system from which you need to pull data (checking order status, getting a user’s history of logins or purchases, locations of stores), as well as any system to which you need to add data (someone places an order, provides feedback, accepts a request). All of these will require some method to communicate this data to or from the app and will cost extra. Finally, any information you want users to be able to access in the app will need to be stored somewhere. Think about a simple app that retrieves your order status. That app will need to know who the user is, connect that to some system that has information about what they ordered, and where it is in the process. All that data has to live somewhere that the app can access, such as Google, Amazon Webservices, or Salesforce.

While this may all seem like a “Debbie Downer” perspective, being able to manage and support an app once it is launched is even more critical than getting it initially set up. I have seen many projects fail because they didn’t think about the maintenance and could not support the app long-term. Considering these factors early will set your organization and your app up for success.

What is my organization’s true need?

Alright, so you’ve worked through the above. Your customer segments would love an app and can use one. Your organization can support an app through their brand, technical and support capacities, and financially. Now what?

My final question is .. do you truly need a custom app to meet this need? There are absolutely some strong benefits to building a custom app, such as that it can meet your users needs exactly without extra functions and the app can be branded beautifully to meet your customer expectations. However, there are other options to consider before building a custom app.

The first is purchasing an existing app and adapting it to your use. In an outside IT context, think of this as buying a pre-built house and remodeling or going with a builder model and customizing everything down to the color floors. With a pre-built you know the structure is solid, the general design is good, and most importantly, you are relying on the expertise that comes from building thousands of homes. In the app context, think about if you were a restaurant and wanted to create your own app so customers could order delivery. While there are some perks to this, it would likely make more sense to partner with an organization which already has an app, such as GrubHub or Doordash. Sure, you lose some flexibility and profit, but if something breaks, you aren’t on the hook either. In general, purchasing an existing app takes much of the burden off of the organization in terms of enhancements, maintaining the security standards, and designing an app from scratch.
['Glenn Bugala']
['Isteaching', 'Technology', 'Design Thinking', 'App Development', 'Isinsights']