Diseño Multiplataforma
El mismo producto puede vivir en un monitor de 27 pulgadas, en un teléfono de gama media bajo el sol de un patio logístico y en una tablet en la mano de un coordinador de almacén. El sistema de diseño aplica en los tres contextos. Lo que cambia es la expresión, nunca la identidad.
Este documento define cómo los tokens, componentes y patrones del sistema se adaptan a cada tipo de plataforma sin perder coherencia. No es un catálogo de excepciones: es la regla de cómo la normalidad del sistema se lee en cada pantalla.
Taxonomía de plataformas
GM Transport opera en cinco categorías de plataforma. Cada una tiene un perfil de uso, un contexto físico y unas reglas de densidad distintas.
graph LR A["Plataformas GM Transport"] --> B["Web\nDesktop / ERP"] A --> C["Web\nMobile"] A --> D["App Nativa\nMóvil"] A --> E["Tablet"] A --> F["Pantalla\nEmbebida"]
Web Desktop y ERP
Contexto: Oficina, almacén con estación fija, transporte en cabina de monitoreo. Ratón, teclado, pantalla entre 13 y 32 pulgadas. El usuario puede mantener múltiples ventanas abiertas y trabaja con la aplicación durante horas ininterrumpidas.
Densidad: Alta. El espacio disponible permite mostrar más información simultáneamente. Las tablas con múltiples columnas, los filtros avanzados y los formularios completos son apropiados. La regla de densidad alta no anula la jerarquía: incluso en una pantalla densa, hay una acción primaria y una jerarquía visual clara.
Interacción: Ratón con precisión milimétrica. Los elementos interactivos pueden ser más pequeños que en touch (mínimo 32px de área de click, recomendado 36px), aunque nunca menos de eso. El hover es un estado válido y debe ser diseñado.
Tipografía: Tamaños de fuente iguales o ligeramente menores que en mobile debido a la distancia de visualización y la densidad. El cuerpo de texto base puede ser 14px en ERP donde la información es muy densa.
Web Mobile
Contexto: Consulta rápida desde un navegador en teléfono. Portales de cliente, rastreo de guías, consultas de estado. El usuario llega con una intención puntual, completa una tarea y sale. No es la plataforma de trabajo intensivo.
Densidad: Baja. Máximo dos columnas de información. Las tablas se transforman en listas de tarjetas. Las acciones secundarias se mueven a menús colapsables.
Interacción: Touch con imprecisión. El área táctil mínima es 48×48px. Los elementos interactivos tienen separación suficiente para evitar toques accidentales.
Consideración de red: Los portales web mobile deben funcionar bajo conexiones lentas. Las imágenes se optimizan. Los estados de carga son prioritarios.
Aplicación Móvil Nativa
Contexto: Operadores en campo, conductores, almacenistas. Sol directo, guantes posibles, vibración, conexión intermitente. Uso frecuente e intensivo durante jornadas largas. El error de toque tiene consecuencias operacionales.
Densidad: Baja a media. Una tarea por pantalla. Un flujo lineal y predecible. La complejidad se resuelve con flujos de múltiples pantallas, no con pantallas complejas.
Interacción: Touch robusto. Área táctil mínima inviolable de 48×48dp. Gestos simples: tap, scroll vertical. Sin swipe de múltiples direcciones en acciones críticas.
Contraste: Exceder el mínimo WCAG AA no es opcional. El texto sobre naranja primario debe ser blanco puro. El texto sobre superficies blancas debe ser onSurface (#1A1C1E).
Offline: El feedback de estado offline es una función de primer nivel. El usuario opera sin red y confía en que el sistema sincroniza después.
Tablet
Contexto: Estaciones de almacén, coordinación en campo, supervisión de operaciones. Pantalla entre 10 y 13 pulgadas. Touch, generalmente con soporte o en mano. Sesiones intermedias, uso semi-intensivo.
Densidad: Media. Dos columnas son naturales. Los formularios pueden mostrar más campos. Las tablas tienen más columnas que en mobile pero menos que en desktop.
Layout: La tablet permite layouts de dos paneles: una lista a la izquierda y el detalle a la derecha. Este patrón aplica a flujos de orden-detalle, viaje-eventos, guía-seguimiento.
Interacción: Touch con buena precisión. Área táctil mínima de 44×44dp. El hover no existe; no se diseñan estados que dependan de él.
Pantallas Embebidas
Contexto: Displays de monitoreo en oficinas de operaciones, dashboards en TV, paneles de estado en almacenes. Solo lectura, sin interacción directa. El usuario está a distancia de uno a tres metros de la pantalla.
Densidad: Media a alta, pero sin elementos interactivos. Los tamaños de fuente son mayores que en desktop porque la distancia de visualización es mayor.
Reglas específicas:
- Sin botones ni elementos interactivos en primer nivel de UI.
- Sin scroll. Todo el contenido visible debe caber en la pantalla completa.
- Los datos se actualizan automáticamente. El tiempo de refresco es visible.
- El contraste es crítico: la pantalla puede estar bajo luz ambiente variable.
Breakpoints del sistema
El sistema define cuatro rangos de ancho de ventana que determinan el comportamiento del layout. No son puntos de quiebre para ocultar y mostrar contenido: son puntos en los que la composición del layout cambia para servir mejor al contexto.
| Nombre | Rango | Plataforma típica |
|---|---|---|
mobile | 0 — 599px | Teléfonos en vertical |
tablet | 600px — 1023px | Tablets, teléfonos en horizontal |
desktop | 1024px — 1439px | Laptops, monitores estándar |
wide | 1440px+ | Monitores grandes, ERP en full-width |
Estos breakpoints se aplican en web y en los contexts responsive de aplicaciones híbridas. Las aplicaciones nativas no usan breakpoints sino clases de tamaño del dispositivo (compact, medium, expanded según Material Design 3).
Adaptación de componentes por plataforma
Los componentes del sistema se comportan de forma coherente en todas las plataformas pero se expresan con dimensiones adaptadas al contexto.
Button
| Plataforma | Alto mínimo | Tipografía | Radio de borde |
|---|---|---|---|
| App móvil | 48dp | Label Large (14sp) | radius-lg |
| Tablet | 44dp | Label Large (14sp) | radius-lg |
| Web — Desktop | 36px | Label Medium (13px) | radius-md |
| ERP | 32px | Label Small (12px) | radius-sm |
El color, la semántica y el comportamiento son idénticos en todas las plataformas. Solo cambia la densidad dimensional.
Input / Campo de formulario
| Plataforma | Alto mínimo | Tipografía del label | Comportamiento del teclado |
|---|---|---|---|
| App móvil | 56dp | Body Medium | Teclado nativo, scroll |
| Tablet | 52dp | Body Medium | Teclado nativo o físico |
| Web — Desktop | 40px | Body Small | Teclado físico |
| ERP | 36px | Body Small | Teclado físico |
Tabla de datos
Las tablas son el componente más disruptivo entre plataformas. Una tabla de ocho columnas en desktop es imposible en mobile.
| Plataforma | Transformación recomendada |
|---|---|
| Desktop / ERP | Tabla completa con columnas configurables |
| Tablet | Tabla con columnas reducidas (máximo 5), scroll horizontal |
| Web Mobile | Lista de tarjetas expandibles |
| App Móvil | Lista de tarjetas con datos críticos visibles, detalle en tap |
La transformación de tabla a lista no es una degradación de la experiencia. Es la expresión correcta del contenido para ese contexto. Los datos son los mismos; la presentación sirve al dispositivo.
Navegación
El patrón de navegación principal varía por plataforma, pero la jerarquía de acciones es siempre la misma.
graph TD M["App Móvil\nBottom Navigation\n(max 5 ítems)"] --> MA["Pantallas principales\ndesde el tab bar"] T["Tablet\nNavigation Rail lateral\no Bottom Navigation"] --> TA["Dos paneles\nen orientación landscape"] D["Web Desktop\nSidebar colapsable"] --> DA["Menú jerárquico\ncon secciones"] E["ERP\nSidebar fijo expandido"] --> EA["Árbol de módulos\ncon íconos y labels"]
En ninguna plataforma la navegación principal tiene más de cinco ítems en el primer nivel. Si hay más módulos, se agrupan bajo categorías.
Densidad de información por plataforma
La densidad no es una decisión arbitraria. Es una consecuencia del tamaño de la pantalla, el tipo de input y el contexto de uso.
| Plataforma | Columnas en lista | Filas visibles sin scroll | Acciones visibles simultáneas |
|---|---|---|---|
| App Móvil | 1 | 6 — 8 | 1 primaria + 1 secundaria |
| Tablet | 1 — 2 | 8 — 12 | 1 primaria + 2 secundarias |
| Web Mobile | 1 | 5 — 7 | 1 primaria |
| Web Desktop | 3 — 4 | 12 — 20 | 1 primaria + 3 secundarias |
| ERP | 5 — 8 | 20 — 30 | Acciones en toolbar |
Reglas de escala entre plataformas
Estas reglas son inviolables al adaptar cualquier diseño de una plataforma a otra.
No se copia una pantalla de desktop a mobile sin rediseñarla. La reducción de tamaño no es adaptación multiplataforma. Una pantalla diseñada para desktop debe ser rediseñada para mobile con las reglas de densidad de mobile.
No se inventan tokens nuevos para una plataforma. Si un diseño de ERP necesita un color que no está en el sistema de tokens, la respuesta no es crear un nuevo token. Es resolver el diseño con los tokens existentes.
El estado offline es responsabilidad de las plataformas móviles. Web desktop y ERP asumen conexión estable. La app móvil y la app de tablet en campo deben ser funcionales offline en los flujos críticos.
El hover es exclusivo de web desktop y ERP. No se diseñan estados hover para mobile ni tablet. Los estados interactivos en touch son pressed y focus.
Resumen
- El sistema cubre cinco plataformas: Web Desktop/ERP, Web Mobile, App Nativa Móvil, Tablet y Pantallas Embebidas.
- Cada plataforma tiene un perfil de densidad, interacción y contexto diferente; los tokens y la identidad son los mismos en todas.
- Los cuatro breakpoints del sistema (
mobile,tablet,desktop,wide) determinan la composición del layout en web. - Los componentes adaptan sus dimensiones por plataforma pero mantienen la misma semántica, color y comportamiento.
- Las tablas se transforman en listas en plataformas de baja densidad; eso no es degradación, es expresión correcta del contenido.
- Copiar pantallas de una plataforma a otra sin rediseñarlas es una violación del sistema.