Diseño web offshore: cuándo sí y cuándo no.

Un equipo offshore trabaja desde un país a muchas horas de distancia, en tu administrador de contenido y tu repositorio, con especificaciones por escrito. El término nació en Estados Unidos. Si tu empresa es mexicana, un equipo en México es local (onshore), Colombia es nearshore, y Filipinas, India o Egipto son offshore.

Desde la Ciudad de México (UTC-6 todo el año), India (UTC+5:30) va once horas y media adelante y Filipinas (UTC+8) catorce. Ninguno de los dos cambia la hora en verano. Egipto usa UTC+2, o UTC+3 en verano desde 2023, así que va ocho o nueve horas adelante.

Fuente: Base de datos de zonas horarias de IANA

Seamos claros: si tu sitio es en español y tus clientes están en México, un equipo aquí casi siempre te conviene más. Comparte tu horario, tu idioma y tus referencias, y las revisiones se hacen en vivo.

El offshore tiene sentido en casos más específicos. Por ejemplo, un sitio grande en inglés para clientes en Estados Unidos, con cientos de páginas de producto hechas con pocas plantillas. O si necesitas migrar un catálogo o un blog extenso y la regla de cada página ya está escrita.

Hay una pregunta más: ¿tu equipo trabaja cómodo en inglés? Con un equipo offshore, casi toda la comunicación escrita será en ese idioma.

El offshore funciona donde la respuesta ya está escrita. Entre más clara la especificación, mejor el resultado.

El trabajo offshore avanza con entregas por escrito, no con llamadas. Así se ve un ciclo normal:

Cada ticket poco claro cuesta un día. Si alguien encuentra una duda sobre un espacio, un estado que falta o un enlace roto, adivina o espera a tu mañana.

Un buen ticket enlaza el marco exacto de Figma y lista todos los estados: al pasar el cursor, con foco, con error y vacío. También indica los tamaños de pantalla y dice qué queda fuera. Para una migración, adjunta el mapa de direcciones. Para pruebas, la lista y los navegadores.

Una revisión de accesibilidad encaja bien en offshore cuando el estándar está por escrito. Las WCAG 2.2 del W3C son la referencia habitual. Sumaron criterios fáciles de pasar por alto, como el tamaño mínimo de los botones o que el foco no quede tapado por un encabezado fijo.

Dale al equipo los criterios que vas a revisar, una plantilla para reportar problemas y una regla de qué bloquea el lanzamiento. Las decisiones de diseño se quedan con quien diseñó.

Fuente: W3C, Pautas de Accesibilidad para el Contenido Web (WCAG) 2.2

Con pocas horas compartidas, las reglas de acceso hacen más trabajo. Déjalas por escrito antes de arrancar:

Fuente: Ley Federal del Derecho de Autor, arts. 83 y 83 bis (Cámara de Diputados)

Menos horas compartidas significa respuestas más lentas. En un sitio, eso duele sobre todo antes de que los diseños estén cerrados y en la semana de lanzamiento. Mantén cerca de tu equipo:

Una comparación general para trabajo web, vista desde una empresa mexicana.

La mezcla funciona solo si quien diseñó escribe las especificaciones y revisa lo que llega. Las decisiones y el diseño se quedan en tu horario; la producción bien definida puede ir lejos.

En OTRO, el sitio lo diseña y lo construye un equipo senior que también hace producto, en tu mismo horario. A veces una parte del proyecto encaja en offshore, como una migración grande en inglés. Si es tu caso, te lo decimos en el plan y te explicamos cómo sería la revisión.