DANIEL_OS v1.0·STATUS: AVAILABLE FOR WORK--:--:--
← Volver a Work
/work/launch-mobilitySHIPPED
Portada del proyecto Launch Mobility — Senior UX/UI Designer & Front-End Developer

Launch Mobility — Senior UX/UI Designer & Front-End Developer

2024

Senior UX/UI Designer · Front-End Development · Design Systems

Design SystemsFront-End DevelopmentProduct Design
// OVERVIEW001

Qué era el reto

Como Senior UX/UI Designer y Front-End Developer en Launch Mobility, mi trabajo va bastante más allá de rediseñar pantallas: dirijo el sistema de diseño de la compañía de punta a punta (gobernanza de tokens multimarca, arquitectura atómica, componentes React Native), diseño y audito el flujo de reservas completo del producto, construyo el puente pixel-perfect entre Figma y código en piezas de producción reales, y produzco todo el material de comunicación de marca — decks, presentaciones, infografías, landing pages y contenido web.

// FEATURES002

Qué hace el producto

Gobernanza de sistema de diseño multimarca

Dirijo el sistema de diseño atómico de la compañía (Fundamentos → Átomos → Moléculas → Organismos → Patrones), incluida la migración a una arquitectura de tokens de tres niveles con cambio automático de marca.

Auditoría y diseño del flujo de reservas

Audité las ~44 pantallas del flujo de reservas contra el checklist oficial de journeys y diseñé desde cero los journeys faltantes (actualizar, cancelar y extender reserva).

Sistema de diseño para una migración completa a React Native

En la iniciativa que unifica cuatro bases de código en una sola app React Native, soy el punto de control humano que un pipeline de IA consulta cuando necesita un componente que no existe todavía.

Pagos y cumplimiento, verificados contra producción

Reconstruí pixel-perfect los 14 estados de error de pago para Android e iOS a partir de grabaciones reales de producción.

Diseño-a-código en producción real

Landing page de partnership construida a mano en HTML/CSS/JS desde un pipeline de extracción vía API de Figma, con QA automatizada en Playwright.

Comunicación de marca de punta a punta

Pitch decks, presentaciones, infografías, campañas de email y contenido web para la marca corporativa y sus sub-marcas.

Decisiones de UX basadas en evidencia

Estudié límites de caracteres probando texto real renderizado en Figma, documentando la comparación en una infografía propia.

// IMPACT003

Números

44
pantallas auditadas en el flujo de reservas
27
pantallas de producción verificadas y consolidadas
3
niveles en la arquitectura de tokens multimarca
14
estados de error de pago documentados (Android + iOS)
// PROCESS004

Cómo se construyó

  1. 01Auditar antes de tocar nada — nunca asumir un color o un texto sin verificarlo en vivo
  2. 02Diseñar o reparar sobre una copia reversible del archivo antes de tocar la versión activa
  3. 03Extraer specs reales vía API en vez de adivinar valores
  4. 04Verificar contra la lógica real de la aplicación, no solo contra su apariencia
  5. 05Documentar cada decisión donde vive el trabajo (Control Sheets, UX Notes)
  6. 06Producir el material de comunicación de marca con el mismo control que una pantalla de producto
// FINDINGS005

Qué aprendimos

  • Un pipeline de build reportó un componente como "listo" cuando el código nunca había llegado a main — lo detecté leyendo el historial real de git y lo cerré con un PR de seguimiento.
  • Un patrón que parecía tener solo un desajuste visual resultó ser contenido completamente inventado — ese hallazgo cambió mi proceso de verificación.
  • Antes de reconstruir 35 pantallas desde cero, encontré una librería de producción madura ya existente — migrar en vez de rehacer evitó tirar trabajo probado.
// TOOLS006

Con qué se hizo

Figma
Variables, Plugin API, gobernanza de tokens
React Native (Ignite)
Catálogo de componentes de producción
Storybook (CSF3)
Documentación viva de componentes
Stripe
Estados de error de pago verificados
Playwright
QA visual y de accesibilidad automatizado
GitHub
Flujo de PRs, recuperación de gaps de merge
// WAY OF WORK007

Ritmo del equipo

  • 01Nunca reorganiza ni renombra contenido existente sin instrucción explícita.
  • 02Prioriza siempre evidencia de producción sobre la suposición de diseño.
  • 03Señala vacíos e inconsistencias para decisión del negocio en vez de resolverlos por su cuenta.
← Volver a WorkKinetik StudioSereniaTul