Questions Every Mobile/Frontend Developer Should Be Asking Before Building a Feature

Introduction

I originally signed up to give a talk on this topic at VarCamp this year. Unfortunately, for various reasons, I didn’t end up presenting it. Out of all the topics I had planned to talk about, this was one that never made it onto the stage. Still, I thought it would be worthwhile to write an article and share it instead.

Since this topic is primarily aimed at Myanmar developers, I originally wrote it in Burmese. This English version is a translated and polished adaptation of that article.

Input Fields

Whenever you see a text box or any input field where users can enter data, there are at least four states you should immediately think about:

• Neutral state (before any input is entered)

• Active state (when the cursor is focused on the field)

• Error state (when validation fails)

• Disabled state (when interaction should be blocked)

At a minimum, every input field has these four states.

When reviewing a design file, check whether all of these states are defined. If they aren’t, ask for clarification as early as possible. Since these UI states will likely be reused throughout the entire app, it’s worth spending extra time upfront to clearly define and implement them in a reusable way. Doing so saves a lot of time later.

Form Validation

As soon as input fields appear, you can assume there’s a form involved.

A form can generally be either valid or invalid. Once you establish that, there are several important questions to ask:

• Should invalid fields display an error state?

• If errors should be shown, when should validation occur?

  • On every keystroke?

  • When the user taps a CTA (Call-To-Action) button?

• Alternatively, should the CTA button remain disabled until the form becomes valid?

If the button is disabled when the form is invalid, you may not even need explicit error states in many cases.

These behaviors should be specified in the design. If they’re not, ask. Whenever you encounter a form, you should naturally start thinking about validation timing, valid and invalid states, optional versus mandatory fields, and any related user flows.

Lists

No application is completely free from lists. Some are horizontal, some are vertical.

Whenever you encounter a list, there are at least four things to consider:

• What happens if the list is empty or the API fails? Is there an empty state design? Should cached data be displayed instead?

• Is there a “See More” option? If so, how many items should be shown before it appears?

• If there is no “See More,” does the list use pagination? What does the pagination experience look like?

• Does the list support pull-to-refresh? (Especially important on mobile.)

These are just the ones I can recall off the top of my head. Depending on your application’s business requirements, there are usually more considerations—not fewer.

Loading States

Whenever you’re making API calls, users need some form of loading feedback.

The question is: what kind?

• A full-screen loading overlay with a spinner?

• A skeleton/shimmer loading view?

• A combination of both, depending on the section?

• Should users be allowed to cancel the loading operation?

Once you decide on a loading style, mobile developers usually need to think about two categories:

Interactive Loading

Users can continue interacting with the app while loading is in progress. They can switch tabs, navigate elsewhere, or go back. The UI isn’t blocked by a full-screen overlay.

Non-Interactive Loading

The opposite approach. While loading is in progress, users cannot interact with the interface. The only way out may be exiting the screen or the app itself.

Depending on which approach you choose, the complexity of state management changes significantly.

For example, when users leave a screen while asynchronous operations are still running, you often need to cancel those in-flight requests. Otherwise, you may waste resources in the background and occasionally introduce hard-to-track bugs.

Error Handling

Every application encounters errors.

Some errors come from user actions, while others come from API failures.

Things to clarify early:

• Will the entire app use a single error presentation style?

  • Native alerts?

  • Toast messages?

• Or will different parts of the app use different error styles?

• If multiple error styles exist, how does the client know which one to display?

In some cases, the server may need to include metadata indicating how errors should be presented.

Another common mistake is representing error styles with a simple boolean value. That may work when there are only two options, but it becomes limiting as soon as a third option appears. Using enums or constants is generally a better approach.

Scrollable Containers

This is especially relevant for mobile developers.

Whenever you see a screen—whether it’s a login page, onboarding flow, or any other view—you should immediately ask:

• Is this screen scrollable?

• Should it become scrollable on smaller devices?

Even if the design appears to fit perfectly without scrolling, it’s still worth asking.

If content comes from users or a CMS, such as long descriptions, the content length may vary dramatically. In those cases, scrolling becomes unavoidable.

Once scrolling is involved, additional questions arise:

• Should the navigation bar change appearance while scrolling?

• Should its background color change?

• Should it remain fixed or collapse?

These details should be clarified early.

Text Formatting

Text formatting comes in many forms.

For this article, we’ll focus on:

• Plain text

• Prices

• Decimal values

• Durations

• Dates

Plain Text

Even something as simple as a title raises questions:

• The design shows it on a single line, but what happens when the text becomes longer?

  • Should it wrap?

  • Should it truncate?

• If truncated, after how many lines?

• For body text, should there be a “Read More / Read Less” feature?

• If so, how many lines should be visible initially?

Another important consideration is localization.

Designs are often created in English, but translations can dramatically change text length. A short word like “Back” can become much longer in another language, potentially breaking layouts.

Developers should proactively highlight these risks.

Prices

Price formatting requires extreme attention to detail.

• While Myanmar currency typically doesn’t use decimal fractions, many international currencies do.

• Never arbitrarily decide to show one decimal place, two decimal places, round values, or apply ceiling/floor logic on your own.

• These are sensitive business decisions and should be clearly defined across the entire application.

You should also clarify:

• Should currency symbols use short or long forms?

• Should the symbol appear before or after the amount?

• Are there exceptions?

Understanding these rules upfront allows you to build reusable components correctly.

Decimal Values

For values such as user progress, reward points, or other numerical metrics:

• Can decimals exist?

• If so, how should they be formatted?

These decisions should be defined consistently.

Durations

Many applications need to display durations.

The formatting depends heavily on the nature of the app.

For example, video applications often display hours, minutes, and seconds.

Questions to ask include:

• Should durations always be displayed as HH:MM:SS?

• Or should the format adapt dynamically?

  • Show seconds only when appropriate.

  • Show MM:SS when minutes exist.

  • Show HH:MM:SS only when hours are present.

As always, understand all possible formatting variations early so reusable solutions can be built correctly.

Dates

Dates introduce another set of considerations:

• 12-hour format or 24-hour format?

• Display UTC time or convert to the user’s local timezone?

• What date format does the API return?

• What format should be sent back to the server?

These details should never be assumed.

Navigation Transitions

This is another mobile-specific concern.

When moving between screens, what type of transition should be used?

• Drill-down navigation

  • A new screen slides in from the right.

• Bottom sheet

  • A partially expanded view rises from the bottom and can typically be dismissed with a swipe.

• Full-screen sheet

  • Similar to a sheet, but covers the entire screen and often cannot be dismissed with a swipe.

• Modal dialog

  • A small overlay dialog used for confirmations, such as delete actions.

Another question:

Can a screen only ever appear through one transition type, or does the transition depend on context?

The answer can significantly affect implementation.

Search Bars

Search bars introduce many possible states.

Questions worth asking include:

• If the search bar is placed in the navigation area, what happens when users scroll up or down?

• If the search bar starts in a collapsed state, what happens when it expands?

• Can its appearance change based on scrolling behavior?

• When the search bar becomes active, where are results displayed?

  • On the current screen?

  • On a separate screen?

For example, in Grab’s mobile app, the home screen search bar behaves more like a button. Tapping it navigates users to a dedicated search screen.

You should also consider:

• What happens when there are no search results?

• What should be displayed before users enter any search query?

State Management in Large Flows

State management is a challenge for every frontend developer.

Imagine a multi-step flow consisting of:

• Step 1

• Step 2

• Step 3

Suppose the user completes Step 2 and exits the flow.

Questions arise immediately:

• Should data entered up to Step 2 be cached?

• Or should it be discarded?

Now suppose the user goes back from Step 2 to Step 1 but remains inside the flow.

• Should Step 2’s data still be preserved?

• Or should it be reset?

If data is cached:

• When should it be cleared?

• Should it persist indefinitely?

Another scenario:

Suppose users complete all steps and arrive at a summary screen that allows editing.

Now consider:

• Does the summary screen become the source of truth?

• If a user edits Step 2 data from the summary screen, what should happen when they return to Step 2?

  • Show the updated value?

  • Show the original value?

And finally:

• If users leave the summary screen, should all previous step data be retained or cleared?

These questions are easy to overlook but become critical in complex flows.

Logout Flow

Whenever users log out, you should know exactly which data should remain and which should be removed.

For example:

• Should access tokens be deleted?

• Should refresh tokens be deleted?

• What cached data should persist?

These decisions should be deliberate, not accidental.

Other Considerations

• Does the app support only portrait mode, or landscape mode as well?

• Does the app support only light mode, or dark mode too?

• Does the app support dynamic text scaling?

  • For example, should the UI respect the user’s font size preferences configured in the operating system?

API Calls

Although not directly related to UI, there are still many API-related considerations worth discussing.

• Should an API be called only once, or every time a screen opens?

• If a screen requires multiple APIs, should they be executed in parallel or sequentially?

• Should optimistic UI updates be used?

For example, imagine a ”+” button that increments a counter.

Instead of waiting for the API response, you can immediately update the UI, send the request in the background, and only revert the change if the API fails.

This improves perceived responsiveness and user experience.

Other considerations include:

• Client-side rate limiting

  • Even if the server handles rate limiting, expensive third-party services may require additional protection.

• Retry strategies

  • How many retries?

  • What retry intervals?

  • Should retries be automatic or user-triggered?

• Circuit breakers and exponential backoff

  • Particularly useful when dealing with unstable services.

• Fallback UI

  • What should users see if critical APIs fail?

• Offline support

  • Can the app function without a network connection?

  • Should it continuously retry requests?

  • How should downloads behave when connectivity is lost?

    • Resume?

    • Cancel?

Modern platforms have made handling some of these scenarios easier, but they still require thoughtful planning.

Conclusion

These are some of the frontend-related issues I’ve encountered throughout my career—problems that often cause delays because they aren’t identified early enough.

My goal in sharing this list is to help other developers recognize these considerations sooner, ask the right questions earlier, and avoid wasting time later.

I’m sure I’ve missed some things. Some people may consider many of these points to be common sense. Personally, I think a lot of them also come from experience and domain knowledge.