Make the first useful action clear

What should someone be able to do when they first open the app? Which information is essential, and what can wait until it becomes relevant?

I use those questions to shape onboarding, navigation, and the path to the core task. We also consider returning users: where they resume, how they find previous work, and what happens when an action is interrupted.

Design the states around the main screens

The experience includes more than a successful journey. An app may need to explain a permission request, show progress, handle missing information, or help someone recover from an error.

For example, a photo-based task may need a choice between taking and selecting an image, a response to unavailable access, a waiting state, and a way to retry. We identify the states relevant to your app before finalizing the screen scope.

Agreed deliverables can include mobile user flows, interface designs with their important states, an interactive prototype, platform references, reusable components, and implementation notes.

Design handoff or an agreed app build

Design only: I design the agreed journeys and prepare the files and behavior notes your mobile developers need. We establish the target platform and any existing component or product constraints early.

Design and development: We assess the platform, features, data requirements, and technical fit before agreeing which app flows I will build. Design, implementation, review, and delivery responsibilities are recorded in the scope.

Implementation of existing designs: If the designs are ready, we can assess them as a build starting point, including missing states and platform-specific decisions.

I use AI coding tools such as Claude Code, Codex, and Cursor where appropriate in development. The agreed platform and technical requirements determine the implementation scope.

Decide how the app will be reviewed and delivered

Before implementation, we agree the target devices, platform versions, connected services, and checks the work needs. Store preparation and submission are separate responsibilities to define, along with the accounts and materials they require.

A working demo, a test build, and a published app are different delivery states. We specify which one the project is working toward and what must be supplied for it. Store approval remains subject to the platform’s review.

If the mobile app also depends on an admin dashboard or staff workflow, explore product design for broader workflows so both sides can be scoped together.

Questions about your app project

Can you redesign part of an existing app?

Yes. We can focus on a defined journey, such as onboarding or a core action, while accounting for existing navigation and interface conventions.

Can you build the app too?

Development can be included after the platform, features, and technical requirements have been assessed. The proposal defines the parts I will implement and any dependencies.

Which platforms can the project cover?

Share your intended platforms and current setup. I confirm what I can take on after reviewing those requirements; coverage is not assumed to include both iOS and Android.

Are store submission and launch included?

Only when explicitly agreed. We need to define account access, required assets, submission responsibilities, and the intended delivery state. Submission does not guarantee approval.

Can you work with our mobile developers?

Yes. We can agree design references, handoff details, and any implementation reviews around your team’s platform and workflow.

What affects cost and timing?

The target platform, journeys, screen states, connected services, and release responsibilities. We scope these before making a project commitment.

Tell me about the app and its next step

Share the core task, intended platform, and what already exists. If you have designs, a test build, or a development team, include that context so we can discuss the right scope.