Noções Básicas de Colaboração de Produto

10 exemplos para você começar a traduzir designs em interações móveis viáveis no Expo SDK 57 - o que validar antes do compromisso do sprint, como conversar com design e PM em termos móveis e onde as suposições da web falham em telefones.

Pré-requisitos

A colaboração de produto pressupõe um aplicativo padrão Expo SDK 57 com tokens de design e pelo menos um perfil de build de pré-visualização.

npx create-expo-app@latest MyProductApp --template blank-typescript
cd MyProductApp
npx eas init

Ferramentas: Estes exemplos visam Expo SDK 57 (expo ~57.0.4), React Native 0.86.0 e React 19.2.3. Combine com Noções Básicas de Sistemas de Design para tokens e Noções Básicas de Animações para viabilidade de movimento.

Exemplos Básicos

1. O Handoff de Design é uma Conversa, Não um Drop de Arquivo

Trate a exportação do Figma como o início do refinamento - não o fim do design.

## Checklist de Handoff (por tela)
- [ ] Artboards iOS + Android OU "plataforma segue HIG/Material" explícito
- [ ] Margens de área segura anotadas (notch, Dynamic Island, barra de navegação)
- [ ] Estados do teclado: padrão, focado, erro inline
- [ ] Carregando, vazio, erro - não apenas o caminho feliz
- [ ] Tópico de comentário de viabilidade do engenheiro aberto antes do planejamento do sprint

• O PM agenda uma passagem de viabilidade de 15 minutos com engenheiro + designer antes de apontar
• "Parece bom" no Figma ≠ "lança neste sprint" em duas plataformas
• Registre bloqueadores no ticket - "precisa de spike de módulo nativo" é um resultado válido

Relacionado: Trabalhando com Design e Movimento - revisões de viabilidade pré-pixel

2. A Área Segura Muda Cada Cabeçalho "Fixo"

Mocks da web com barras superiores position: fixed ignoram o notch e a barra de status.

// src/screens/ProfileScreen.tsx
import { View, Text } from "react-native";
import { useSafeAreaInsets } from "react-native-safe-area-context";
 
export function ProfileScreen() {
  const insets = useSafeAreaInsets();
 
  return (
    <View style={{ flex: 1, paddingTop: insets.top }}>
      <Text accessibilityRole="header">Perfil</Text>
      {/* O conteúdo rola sob o cabeçalho transparente apenas se projetado dessa forma */}
    </View>
  );
}

• Mostre aos designers duas molduras de dispositivo: iPhone com Dynamic Island + Android com furo
• Números mágicos paddingTop: 44 falham em hardware novo - use insets
• Rodapés fixos precisam de insets.bottom para sobreposição do indicador inicial

3. Bottom Sheets Não São Modais da Web

Diálogos modais centralizados da web geralmente se tornam bottom sheets ou fluxos de tela inteira no celular.

• Sinalize as expectativas de descarte por gesto - deslizar para baixo vs. tocar fora difere por plataforma
• Veja Decisões de Paridade de Plataforma quando iOS e Android divergem intencionalmente

4. Evitar o Teclado Faz Parte do Design

Um formulário que parece perfeito no Figma pode ocultar a CTA principal quando o teclado abre.

import { KeyboardAvoidingView, Platform, ScrollView } from "react-native";
 
export function SignUpForm() {
  return (
    <KeyboardAvoidingView
      style={{ flex: 1 }}
      behavior={Platform.OS === "ios" ? "padding" : undefined}
      keyboardVerticalOffset={Platform.OS === "ios" ? 64 : 0}
    >
      <ScrollView keyboardShouldPersistTaps="handled">
        {/* campos + envio - designer revisa com teclado levantado */}
      </ScrollView>
    </KeyboardAvoidingView>
  );
}

• A revisão de design deve incluir captura de tela com teclado levantado no menor telefone suportado
• android:windowSoftInputMode pode precisar de um plugin de configuração - não é JS puro
• Rótulos flutuantes que animam precisam de orçamento de movimento - Reanimated 4

5. Alvos de Toque Superam a Densidade Pixel-Perfeita

O Figma com zoom de 100% tenta botões de 32px; Apple HIG e Material recomendam mínimo de 44–48dp.

// design-systems/PrimaryButton.tsx - impõe alvo de toque mínimo
import { Pressable, Text, StyleSheet } from "react-native";
 
type Props = { label: string; onPress: () => void };
 
export function PrimaryButton({ label, onPress }: Props) {
  return (
    <Pressable
      onPress={onPress}
      style={styles.hitSlop}
      accessibilityRole="button"
      accessibilityLabel={label}
    >
      <Text style={styles.label}>{label}</Text>
    </Pressable>
  );
}
 
const styles = StyleSheet.create({
  hitSlop: {
    minHeight: 48,
    minWidth: 48,
    paddingHorizontal: 16,
    justifyContent: "center",
    alignItems: "center",
  },
  label: { fontSize: 16, fontWeight: "600" },
});

• Designers usam grade de 8px de Noções Básicas de Sistemas de Design - engenheiros impõem minHeight nos componentes
• Tabelas de dados densas no telefone geralmente precisam de uma alternativa de lista de cartões - negocie em refinamento
• WCAG 2.5.5 (44×44) é uma decisão de produto, não uma surpresa de auditoria pós-lançamento

6. Gestos Precisam de Engenharia Cedo

Deslizar para excluir, arrastar para reordenar e puxar para atualizar competem pelos mesmos manipuladores de pan.

## Viabilidade de Gestos (modelo de ticket)
**Interação:** Deslizar linha para a esquerda → revelar Excluir
**Bibliotecas:** react-native-gesture-handler + Reanimated
**Conflitos:** Rolagem vertical do FlatList pai
**Spike:** 0.5 dia se for um padrão novo
**Fallback:** Pressionar longamente → action sheet

• Se o mock mostrar arrasto baseado em física, vincule Gesture Handler no ticket
• "Igual ao Mail do iOS" não é uma especificação - registre o limite, haptics e padrão de desfazer
• O gesto de voltar do Android pode cancelar swipes incompletos - teste no emulador API 35

7. Estados Além do Caminho Feliz

Telas publicáveis precisam de carregando, vazio, erro, offline e permissão negada - não apenas o frame de marketing.

type ViewState = "loading" | "empty" | "error" | "ready";
 
export function OrdersList({ state, orders }: { state: ViewState; orders: Order[] }) {
  if (state === "loading") return <OrdersSkeleton />;
  if (state === "empty") return <EmptyState title="Nenhum pedido ainda" cta="Navegar no catálogo" />;
  if (state === "error") return <ErrorState onRetry={refetch} />;
  return <FlatList data={orders} renderItem={renderOrder} />;
}

• Critérios de aceitação do PM: "o usuário vê X quando a rede falha" - não implícito
• Esqueleto vs spinner é uma decisão de sistema de design - um padrão por densidade de dados
• Strings de permissão (NSCameraUsageDescription) exigem build da loja - sinalize na estimativa

8. Tipografia e Tipo Dinâmico

fontSize: 14 fixo no Figma quebra quando os usuários habilitam texto maior nas configurações do sistema.

import { Text, StyleSheet } from "react-native";
 
export function BodyText({ children }: { children: string }) {
  return (
    <Text
      style={styles.body}
      maxFontSizeMultiplier={1.3} // limite do produto - documentar em ADR de a11y se for menor que o sistema
    >
      {children}
    </Text>
  );
}
 
const styles = StyleSheet.create({
  body: { fontSize: 16, lineHeight: 24 }, // token: typography.body
});

• Designers entregam tokens de escala de tipo, não tamanhos únicos - Tematização e Sabores de Marca
• Revise o tipo dinâmico XL no iOS e a escala de fonte 1.3 no Android antes da aprovação
• Regras de truncamento: numberOfLines vs expandir - decisão de cópia de negócios

9. Seletores Nativos vs. Dropdowns Personalizados

"Select personalizado" da web geralmente consome meio sprint no celular; seletores de plataforma lançam mais rápido.

• Documente UI personalizada intencional em ADR quando o seletor de plataforma for rejeitado
• Seletores personalizados precisam de a11y: ordem do leitor de tela, foco preso, gesto de descarte
• Tabela de trade-off do PM em refinamento é melhor do que redesenho no meio do sprint

10. Demonstração no Dispositivo Fecha o Ciclo

Termine o refinamento com uma demonstração no dispositivo de 10 minutos - protótipo, build de pré-visualização ou Storybook no telefone.

# Compartilhe a pré-visualização com design + PM antes do início do sprint
eas build --profile preview --platform all
# QR nas notas de refinamento; mesmo build para aceitação de QA

## Refinamento concluído quando
- [ ] O designer viu iOS + Android (simulador ou dispositivo)
- [ ] O engenheiro registrou os riscos de viabilidade no ticket
- [ ] O PM aceitou o fallback para qualquer item "pendente de spike"
- [ ] Movimento marcado: Animado vs Reanimated vs estático

• Stakeholders superestimam a fidelidade do Figma - a demonstração no polegar redefine as expectativas
• Grave a gravação de tela para PMs assíncronos - 30 segundos é melhor do que um parágrafo
• Ligações para Comunicação com Stakeholders para linguagem de lançamento

FAQs

Relacionado

• Decisões de Paridade de Plataforma - quando iOS e Android diferem de propósito
• Trabalhando com Design e Movimento - viabilidade antes que os pixels sejam finais
• Comunicação com Stakeholders - atualizações de status em linguagem simples
• Noções Básicas de Sistemas de Design - tokens e APIs de componentes
• Noções Básicas de Animações - enquadramento Animated vs Reanimated
• Gesture Handler - conflitos de pan e scroll
• Builds de Pré-visualização em PRs - demos QR para stakeholders

Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).