A mobile application is software used to perform specific tasks on a phone or tablet. The real question from a business perspective is not having an app, but why the customer will open it again. This guide helps you evaluate the decision to have a mobile application based on the need for use.
Find a reason to download, a reason to bounce
A restaurant's need for an app to display just its address is not the same as a service that manages a customer's weekly meal plan. In the first case, a good mobile website may be sufficient. In the latter, saved preferences, repeat orders and delivery tracking can ensure regular use. These are sample scenarios; It is not a substitute for researching your customer's behavior.
Ask the user these three questions: How is he doing this today? Where is he wasting time? What concrete difference does he need to see from the current method for installing a new app? If the answer is only "our brand looks more modern", it is too early to move on to the feature list.
What does the mobile application provide and what does it not solve on its own?
It can be valuable to resume a recorded transaction, deliver offline content on favorable terms, or provide reminders when the customer needs them. However, the availability of these features depends on the platform, permissions and how the application is developed. Being able to send notifications does not mean that the user will want to see every notification.
Pretty displays won't solve the problem when stock accuracy, customer support and delivery organization are poor. The application project should be linked to business processes. Who will update the status of the order, who will receive the cancellation request, and from which panel will the incorrect information be corrected? Customer experience also includes the answers to these questions.
Prepare a small decision file for the first release
- Type the primary user and the task they will complete.
- Separate functions that will be included in the first release and left for later.
- Define user, employee and administrator roles.
- Evaluate success with indicators such as task completion and reuse, as well as the number of downloads.
- Determine those responsible for design, software, content and maintenance.
For example, in a service reservation product, changing and canceling an appointment is as important as creating an appointment. Just drawing the successful reservation screen leaves a significant portion of the actual usage open. MVP coverage guide can be used to narrow down initial release decisions.
Clarifying design scope with Selçuk Aker
My contribution as a freelance mobile application designer; is to create the user flow, screen layout and interface system to be transferred to the developer. Working software, server operation, and store publishing are separate responsibilities. To discuss mobile application design work, you can share the purpose of your project.
Can it show its value on first use?
Before you throw a long introductory sequence and a mandatory membership form in front of the person downloading the app, consider what information you really need. The user may not understand why to open an account without seeing the product. For example, reviewing available hours in a reservation product and finalizing a reservation have different information requirements. The rules of the product determine at which step the accounting requirement makes sense.
In the first use test, ask the person to complete a single task. Can he find where to start, can he understand the outcome of the transaction, can he reverse the wrong choice? Do not reduce design evaluation to color and taste alone. These observations can be transformed into flow and display decisions when planning mobile application design with Selçuk Aker.
How do you investigate app non-use?
There may not be a single reason for low usage. Reaching the wrong audience, not being able to explain the benefits of the product, a slow or complex process, and the user rarely needing this job anyway are different problems. Don't try to solve them all with a new campaign or interface change.
- Find out what needs the person coming to the application has.
- Examine at which step of the main process it stops.
- Classify recurring questions in support requests.
- Compare the tasks of returning and non-returning user.
- Record the finding, the change to be made, and the expected outcome.
For example, exiting the reservation screen is not always a design issue; It may also be caused by not having a suitable time. Considering behavioral data and user conversation together reduces the risk of investing in the wrong problem. Do not draw definitive conclusions about the entire customer base from a single small test.
Prepare the path for promotion and support before release
Don't think of mobile app marketing as just download advertising. The web page, store images, first-use descriptions and help content explaining what the product does should create the same expectation. If the feature presented in the screenshot is not available in the first version, the user may come with wrong expectations.
The purpose of a campaign should also be concrete: promoting the product, getting the first task completed, or reusing a specific function require different messages. Instead of using notifications as a constant recall tool, associate them with events that are meaningful to the user. Which channels will be used and how preferences will be managed should also be planned.
Don't judge success by the number of downloads alone
A download alone does not indicate that the product is used or contributes to a business objective. More meaningful evaluation points may include an appointment completed in a booking app, a record submitted correctly in a business tool, or a task completed in a training product. Define the events to be measured by product; Do not make it a target to collect unnecessary personal information.
Record the initial value, change date, and comparison period for the first assessment. If the user base or campaign has changed at the same time, do not attribute the result to design alone. User research and prototype study can help understand earlier what problem you will solve.
Which topic should we continue with?
- Native, Flutter or React Native: How to Choose Technology in Mobile App?
- PWA or Mobile App? Decide Based on Your Customer's Business
- Backend and API in Mobile Application: What Should the User See When the Connection is Disconnected?
- Deliverables to Look for in a Proposal When Selecting a Mobile Application Developer
- Mobile App Developers' Guide to Working with a UI/UX Designer
- Project stages from idea to publication preparation
Frequently asked questions
Does every business need a mobile app?
No. A mobile-compatible website may be sufficient for infrequently used information and simple communication needs. Regularly repeated work and features that provide significant convenience to the user strengthen the decision to apply.
Are a mobile application and a mobile website the same thing?
It is not the same delivery. Used via mobile web browser; The implementation approach requires different decisions in terms of deployment, device features, and maintenance. Both can work together depending on usage needs.
Should we discuss price or design before applying?
The target, user roles and main flows should be discussed first. This information makes the scope of both the design and the software offer understandable. It is difficult to compare prices with an unclear feature list.
