So You Want to Make an App… 5 Questions to Ask Before Hiring a Coding Team

As a designer with 20 years of experience working in the digital space, I’ve begun to recognize a disappointing pattern in emerging tech. Too often I see tools that fail to resonate with end users because the app isn’t intuitive, attractive, inviting, or exciting. Or worse, it has a recklessly designed UX. Companies that are too focused on the tech itself often end up creating products and apps because they can — not because they should. The result is an experience that falls flat, time and time again. As a designer, my role is to help businesses and technologists bring their ideas to life. Over the years I’ve learned that many of these pitfalls can be avoided by asking five simple questions before going to market, to understand what the product is really offering in the first place. In an effort to stop the cycle of “garbage in, garbage out,” I’m sharing 5 practical questions that you should ask yourself before hiring a coding team.

1. What is the purpose? Why should users care?

Gone are the days of "There should be an app for that." To truly prove that your idea deserves a user's time and energy, challenge yourself to be clear about its purpose. Here are the three helpful categories that your technology should fall into:

• Inventing something entirely new (very rare… just try to think of an example!)
• Improving an analogue tool or product and/or changing the gold standard (the iPhone, Airbnb, Uber)
• Improving an existing app, leveraging a trend (Instagram, TikTok)

2. Who is your target audience?

In the marketing world, establishing your target audience comes at the beginning of the process. In the design world, too often establishing your target audience (and end user) falls at the end. Most importantly, as a designer, remember that you are rarely the target audience. You need to constantly test assumptions to make sure what you are building is understandable and repeatable the first, fifth, and 50th time.

At Loft, we are unique to other design firms in that we emphasize understanding the target audience and the end user as a first step. We gather information through intensive user research, and this research informs every step of our design process. If you’re new to this practice, here are some great questions to explore:

Who are my users?

• What are their needs and pain points?
• What are their characteristics, or "persona"? Are they tech savvy, tech curious, or tech intimidated? (ex: the man of the house may consider himself a “tech savvy” guy and his wife might be conditioned to think of herself as “tech intimidated.” But at the end of the day, it might be his wife who is using your app more, and you’re only going to discover this through user research).
• How much time do they spend on their phone daily and what apps do they currently use?
• How will you change their behavior from what they are doing today? How will you convince them to make a switch to your tool or app?

Who are the other stakeholders?

• Who will help build, launch, and market the product? It is just as essential that they also understand the end user
• Who else is a stakeholder in the success of my app? In the healthcare space, this could be a payer or a provider

3. The graphics and computational power of mobile phones increases exponentially. Are you making the most of it?

With this question I am challenging you to understand all angles of the tool, so that you can create the most refined experience possible. It's a competitive marketplace and if you want users to spend time on your tool, you need to make it worth their while. Don't limit the users experience with 1980's tables and graphs, you can do so much more.

User experiences that surprise and delight, technology that adds pleasurable moments to the overall experience (which in itself is still solving a problem), these are the tools and apps that break through the noise. Consider this: we’ve all experienced the fatigue of a clunky app experience, but we also remember the surprise and delight of our first swipe to unlock on the iPhone, the endless scroll capability of Instagram, and the full bleed images on The Weather Channel. Those features are making the most of the tool, and they’re making an imprint on the customer. Some features to consider when working towards a refined UX:

• Making use of big, high resolution phone screens
• Using touch/swipe/buzz interactions
• Adding tasteful animations and transitions

4. Can your coding team read your mind?

If you answered no, then you need a document that gives them clear guidance of what you want. This is called a Product Requirements Document. A PRD defines the value and purpose of a product. So, after you’ve navigated through Questions 1-3, questioned your assumptions and made the necessary revisions, you’re now ready for what you thought you were ready for in Question 1: you can formalize the idea into a format that a developer can understand.

The PRD acts as a map, providing direction towards a product’s purpose while creating common ground and shared language for the business team and the development team to communicate. It should focus on higher-level requirements and leave implementation details to the development team (ex: the minutiae of “I want the finished product to have a blue background” is not needed here). To create a clear and useful PRD, ask yourself three things:

• What are the big picture features?
• What is the high-level functionality?
• What is the desired behavior that the app or tool is trying to get out of an end user?

5. What does success look like at each stage of the process?

Each phase of product development comes with its own challenges, constraints, and considerations. It’s important to understand what success looks like in each stage of the process so that you know when you can move on, when you need to tweak, and when you need to completely pivot. Here are some helpful benchmarks:

• Schedule: how much time am I allotting to each stage of the process? What are the benchmark dates along the way? If things are constantly running behind, perhaps there are more serious issues that are being overlooked with the tech, the team, or your assumptions about the target audience. Ultimately, any project that is consistently behind schedule will eventually be over budget. Which takes me to...
• Budget: we are all familiar with the phrase, “garbage in, garbage out” Avoid this pitfall with two steps: First, invest time in questions 1-4 and second, invest money into a good tech team. Both are crucial.
• Answering Question #1, are you creating a product with a real purpose: if at any point during the process, you lose sight of your purpose, it’s time to hit pause and refocus. Schedules are useless and budgets are irrelevant if the product itself does not add true value.

As you read this post and apply the 5 questions, I encourage you to use each question as a checkpoint with unique takeaways and insights that require their own reflection time. You may discover as you move through the questions that you need to tweak, or even pivot. This is a natural part of the process that should not be avoided. Each pivot takes you back to Question 1, where the process begins again.