Empiece por una tarea común del cliente
Imagine una empresa de alquiler de equipos de Budapest preparando web y aplicación para organizadores de eventos. El cliente reúne equipos en una lista y solicita presupuesto. En un portátil, una tabla puede facilitar compararlos; en un teléfono, una lista compacta puede resultar más cómoda. Ambas deben describir los mismos equipos y requisitos.
Antes de revisar pantallas pulidas, especifique brevemente el comportamiento: accesorios obligatorios, significado de las cantidades y cuándo un borrador pasa a solicitud enviada. Si la aplicación llama «confirmado» a un borrador, un logotipo idéntico no resuelve la confusión. Son reglas propuestas para este servicio hipotético, no afirmaciones sobre un cliente existente.
Comparta significados antes de copiar componentes
Pida un pequeño catálogo de decisiones de diseño compartidas. Los valores con nombre, llamados habitualmente design tokens, pueden definir color corporativo, funciones tipográficas, espaciado y aspecto de advertencias. «Acción principal» explica para qué existe un valor; «botón azul» dice menos sobre su propósito. Incluya significado y ejemplo junto a cada valor.
El catálogo debe cubrir también textos y estados comunes. Borrador de presupuesto, solicitud pendiente de revisión y solicitud finalizada necesitan etiquetas acordadas. Compartir componentes puede reducir trabajo repetido, pero adaptar un componente universal complejo puede costar más que mantener dos controles sencillos. Reutilizar debe facilitar entender cambios futuros.
Permita diferencias útiles para el cliente
React Native permite separar implementaciones por plataforma. Android también recomienda diseños adaptados a distintas pantallas. En el ejemplo del alquiler, la tabla del ordenador y la lista del teléfono pueden servir a la misma tarea sin compartir todos los detalles visuales.
Especifique qué hace Atrás, dónde sigue disponible un presupuesto sin terminar y cómo reabrir una ficha de equipo. Revise el teclado en la web y las interacciones táctiles en la aplicación. Android también recomienda alternativas a acciones exclusivamente gestuales por accesibilidad. Aquí, eliminar un artículo debe tener un control localizable, aunque exista un atajo mediante deslizamiento.
Haga visibles las diferencias para el equipo
Mantenga una ficha comparativa: tarea del cliente, regla común, tratamiento web, tratamiento móvil y responsable. Cada diferencia debe explicarse: la tabla facilita comparar; la lista móvil deja más espacio para cada artículo. Una diferencia inexplicada en accesorios obligatorios es un defecto que investigar.
Al cambiar una regla común, identifique las pantallas afectadas antes del lanzamiento. Registre su versión y cualquier comportamiento temporalmente no compatible. Si solo está lista una plataforma, decida si aplaza el cambio o limita claramente su disponibilidad. Un archivo de diseño compartido no mantiene por sí solo alineados productos publicados por separado.
Use esta lista en la próxima revisión
Empiece por el recorrido del presupuesto y repita la revisión cuando cambien sus reglas. Pida al equipo estas demostraciones en versiones funcionales de ambos productos.
- Use los mismos equipos y cantidades de ejemplo; compare requisitos y etiquetas de estado.
- Vincule cada color, función tipográfica y advertencia compartidos con una definición acordada.
- Pruebe navegación, eliminación de artículos y vuelta al presupuesto pendiente en cada plataforma.
- Registre diferencias intencionadas, discrepancias pendientes y quién se responsabiliza del siguiente cambio.