Development Is an Expensive Place to Figure Out Your Product

A developer asks what should happen when a customer changes a booking after approval. The founder imagines an automatic update. Operations expects a review. The designer has drawn only the original booking screen. Work pauses while the team decides which version of the product it is building.

The problem is not that development exposed a question. Some questions can only be answered through implementation. The avoidable problem is treating an unresolved product decision as if it were a finished requirement. Once that assumption is embedded in interfaces, data structures, and integrations, changing it can involve several people and systems.

Before development, aim for explicit decisions about the important workflows, with uncertainty clearly marked. You do not need a specification for every future possibility. You need enough shared understanding to build the right next release.

Separate product uncertainty from technical uncertainty

Product uncertainty concerns who the app serves, what they need to achieve, and which rules shape the experience. Technical uncertainty concerns whether a proposed approach can work within the relevant systems and constraints. Design can investigate the former, while technical discovery may be necessary for the latter.

For example, a prototype can test whether people understand a permission request. It cannot establish whether a legacy system can provide the required data quickly enough. Ask the development partner to investigate that dependency before presenting the interface as a confirmed solution.

Keep an assumption register

Write down each consequential assumption, why you believe it, the cost of being wrong, and how you will investigate it. Give it an owner. “Users can finish this inspection without connectivity” needs both workflow research and a technical conversation about local storage and synchronization.

Use simple statuses such as supported, contradicted, and unresolved. Do not let a polished mockup silently turn an unresolved assumption into a requirement. Bring the register into design reviews so visual progress does not obscure product risk.

Make the main workflow understandable without a presentation

A useful flow explains the trigger, the user’s steps, system responses, and the final outcome. Another team member should be able to follow it without the founder narrating every screen. Where the flow crosses roles or tools, show that transition explicitly.

A hypothetical approval app might involve a requester, a manager, and a finance team. A single “Approved” screen does not explain who can approve, what happens when information changes, or whether finance receives a notification. Those are product rules that affect the interface and implementation.

Define states as well as screens

For each important object, list its relevant states: draft, submitted, under review, approved, rejected, cancelled. Then define which transitions are allowed and who can trigger them. Keep this list appropriate to the release rather than copying an elaborate model from another product.

Show the corresponding interface states. A user should understand what happened, what is available now, and what happens next. Include loading, empty, error, and permission states where their absence would prevent a team from implementing the intended journey reliably.

Resolve mobile constraints while decisions are still flexible

Mobile workflows are affected by context. Someone may switch apps to retrieve a code, lose reception while uploading a photo, or decline access to location. If these situations are plausible for your users, make them part of the product discussion early.

Ask which information must remain available after an interruption. Decide whether a user can resume an unfinished task and how the app communicates unsaved changes. These decisions are easier to review in a flow than to infer from a collection of finished screens.

Use permissions when their purpose is clear

Specify why a permission is needed at that point in the journey and what happens if the person declines. Avoid designing a compulsory location or camera step when a viable alternative is part of the intended service.

Accessibility also belongs in this stage. Labels, reading order, understandable errors, contrast, and touch targets influence component design. They should be discussed as properties of the experience rather than left as an unspecified check after implementation.

Validate comprehension before expanding visual detail

A prototype is useful when it answers a question. Choose a realistic task, let someone attempt it, and note what they expect at each decision. Do they know whether they are editing a draft or changing a confirmed request? Can they find the next step without coaching?

Use the findings to revise the interaction model before polishing every screen. If participants repeatedly misunderstand the underlying workflow, more refined icons will not resolve the issue. Revisit the sequence, language, or product rules that create the misunderstanding.

Test the risky branch

Teams often demonstrate the cleanest route because it makes the product easy to explain. Also test the branch most likely to expose a costly misunderstanding: changing an approved request, recovering from an interrupted submission, or handling an unavailable service.

Capture the actual finding and the resulting decision. Distinguish a participant’s preference from evidence that they could not complete a task. Record what remains untested so the receiving team can make informed tradeoffs rather than assuming everything has been validated.

Prepare a design handoff that explains behavior

A development-ready design package should connect screens to decisions. Include the core flows, component states, key content rules, interaction notes, and responsive behavior within the agreed device scope. Make reusable patterns consistent enough that developers can identify what is shared and what is genuinely different.

A scalable design system starts with the components the product actually needs. Define buttons, inputs, navigation, feedback, and other repeated elements with clear states. Avoid building a large library of hypothetical components while essential workflow questions remain unanswered.

Review acceptance criteria together

For a consequential step, write a concrete expected behavior. “When a submission fails, retain entered information, explain the failure, and offer a retry” is more actionable than “show a friendly error.” Review that behavior with the team that will implement it.

Keep product rules, design intent, and technical proposals distinguishable. The development partner may suggest a safer or simpler implementation. Use that conversation to refine the agreed experience, documenting any compromises instead of leaving conflicting expectations in separate files.

Know when to move forward

You are ready to progress when the release has a clear purpose, the essential journey is coherent, major dependencies have owners, and unresolved questions are visible. Absolute certainty is not a realistic target. A shared basis for delivery is.

If scope is still unstable, start with defining your MVP’s core job. You can also review Grona’s product design approach and mobile UX/UI projects to understand our focus on making complex workflows understandable.

Grona provides mobile product strategy, UX/UI design, and design systems. We do not provide in-house software development; the implementation work belongs with your chosen development team. If you want help resolving the design questions before that handoff, share your current idea or prototype, and we can discuss an appropriate next step.