Guía de producción y puesta en escena para diseñadores: 2026

La mayoría de los diseñadores aprenden sobre desarrollo, pruebas y producción cometiendo errores en el entorno equivocado. Se envía un Loom. Un ingeniero se estremece. Un hilo de Slack comienza con "¿Espera, qué URL es esta?". Ese es todo el proceso de incorporación.

Esta es la explicación que deberías haber recibido desde el primer día. Sin jerga innecesaria, sin rodeos, solo los tres entornos, quién trabaja en cada uno y qué debes hacer como diseñador en ellos.

Si alguna vez has preguntado "¿Ya está publicado?" mientras mirabas la pestaña equivocada, este documento es para ti.

Por qué existen los tres entornos

El software tiene un problema que los productos físicos no tienen. Una vez que se lanza, se lanza a todos, inmediatamente, al mismo tiempo. No hay planta de producción, ni mercado de prueba, ni implementación gradual por defecto. Un cambio fallido puede afectar a un millón de usuarios en lo que se tarda en actualizar una página.

Los tres entornos existen para que el equipo tenga la oportunidad de cometer errores antes de que los usuarios los detecten. En la fase de desarrollo (Dev), puedes cometer muchos errores. En la fase de pruebas (Staging), puedes cometer algunos. En la fase de producción (Producción), no puedes cometer ningún error, porque hay personas reales observando.

Puedes imaginarlo como el mismo artículo pasando por tres revisiones editoriales. El primer borrador es tosco, la versión para pruebas está casi impecable y la revista impresa ha sido leída por diez personas. Nadie publica el primer borrador y nadie diseña directamente para producción por la misma razón.

Los equipos que se saltan fases lo hacen porque son pequeños, rápidos o imprudentes. A veces, las tres cosas. La estructura existe para que el equipo pueda superar la imprudencia sin ralentizarse.

Guía rápida de los tres entornos

Antes de profundizar, aquí tienes la guía rápida que puedes capturar y sobre la que no tendrás que volver a preguntar.

| Entorno | Propósito | Audiencia | Datos | Patrón de URL | Activador de despliegue | Estilo de revisión |

|---|---|---|---|---|---|---|

| Desarrollo | Crea y rompe libremente | Un ingeniero, a veces tú | Falso o con semillas, a menudo roto | localhost:3000 o tunombre.dev.app | Cambios de código locales | Trabajo en parejas, compartir pantalla |

| Entorno de pruebas | Verificación final antes de los usuarios | Equipo interno, diseñadores, control de calidad | Realista, anonimizado, actualizado | staging.app.com o pr-123.app.com | Fusión de PR o envío manual | Revisión asíncrona, Loom, comparación con Figma |

| Producción | El producto final | Clientes, el mundo | Real, sensible, irreversible | app.com | Lanzamiento etiquetado o fusión de la rama principal | Monitoreo, control de calidad posterior al lanzamiento |

Si solo recuerdas una fila, recuerda la fila de datos. Desarrollo tiene datos falsos, entorno de pruebas tiene datos realistas, producción tiene los datos que te pueden acarrear una demanda si los manipulas. Trata los tres entornos como corresponde.

Entorno de desarrollo: Donde viven los ingenieros, donde las cosas fallan a propósito

El entorno de desarrollo es lo que un ingeniero ejecuta en su portátil o en un entorno de pruebas en la nube. Generalmente se le llama localhost. Se ejecuta en su máquina, se comunica con una base de datos ficticia y existe para una sola persona a la vez. Casi nunca se ve este entorno, y es correcto.

Cuando un ingeniero dice "funciona en mi máquina", se refiere al entorno de desarrollo. La mitad de las veces funciona porque los datos son ficticios, la red es rápida y no hay nada más sucediendo. La otra mitad de las veces funciona porque lo terminaron hace cinco minutos y no se ha probado con nada que se parezca a la realidad.

El entorno de desarrollo también es donde aparecen los nuevos componentes por primera vez. Si le entregaste un patrón de tarjeta a Figma, la primera vez que existe en código real es en el entorno de desarrollo de algún ingeniero. Probablemente te enviarán una captura de pantalla o un Loom desde localhost. Eso es mostrarte el borrador, no la versión final.

No revises el desarrollo para comprobar el nivel de detalle. Revisa el desarrollo para confirmar la estructura, el comportamiento y la intención. Guarda las notas sobre los píxeles para el entorno de pruebas.

Entorno de pruebas: El ensayo general

El entorno de pruebas es donde el equipo se prueba antes de que lo hagan los clientes.

Se ejecuta en infraestructura real, con datos reales, en una URL que normalmente empieza con la palabra "staging" delante de tu dominio habitual.

Cualquier miembro del equipo puede verlo. Los clientes no.

Aquí es donde realizas la mayor parte de la revisión de diseño. Lo comparas con el archivo Figma. Navegas por el flujo en un dispositivo real. Detectas los detalles que siempre se ven bien en Figma y que resultan extraños en el código: interlineado, estados de enfoque, qué sucede cuando un nombre tiene cuarenta caracteres, qué sucede cuando no hay datos.

El entorno de pruebas suele replicar el entorno de producción lo más fielmente posible. Misma estructura de base de datos, mismos servicios de terceros en modo de prueba, mismas banderas de características, mismo flujo de autenticación. Cuanto más cerca esté el entorno de pruebas de producción, menos sorpresas habrá al lanzar un producto. Los equipos que permiten que el entorno de pruebas se aleje de producción terminan lanzando errores que podrían haber detectado sin problemas.

En el entorno de pruebas también se descubre si el ingeniero interpretó el diseño como se pretendía. En la mitad de los casos, sí. En la otra mitad, es donde realmente comienza la conversación.

Producción: Donde interactúan los usuarios

Producción es el sitio web en vivo. Es lo que ven tus clientes cuando escriben tu URL en un navegador. Se ejecuta en una infraestructura real, con datos reales, dinero real en circulación y consecuencias reales para cada cambio. Al navegar por él, interactúas con el mismo sistema que tus usuarios.

Este es el entorno donde dejas de ser diseñador y te conviertes en un usuario. En producción, no se hacen pruebas de ideas. No se experimenta con cambios. No inicies sesión como un usuario falso para ver qué sucede, porque en producción no existen usuarios falsos, solo usuarios reales con registros reales que podrías dañar accidentalmente.

Producción se utiliza para monitorización, comprobaciones puntuales tras un despliegue y capturas de pantalla de elementos que ya están en producción. Si necesitas probar algo, vuelves al entorno de pruebas. Si en el entorno de pruebas no se puede mostrar, solicitas una vista previa. No se manipula el entorno de producción.

La prueba de madurez de cualquier equipo radica en su rigor con respecto a esta regla. Los equipos junior acceden constantemente al entorno de producción. Los equipos senior lo tratan como un laboratorio independiente.

El ciclo de vida de un solo cambio

Un solo cambio de diseño pasa por todos los entornos antes de que un usuario lo vea. Conocer este ciclo de vida es lo que diferencia a los diseñadores que frustran a los ingenieros de los que los satisfacen.

Así es como se desarrolla un cambio:

1. Se entrega el diseño en Figma, con anotaciones, estados y casos límite.
2. Un ingeniero incorpora el cambio a su entorno de desarrollo y lo compila localmente.

Luego, el trabajo se hace público para el equipo:

3. Abren una solicitud de extracción (pull request), que crea una implementación de vista previa con una URL única.

4. Se revisa la vista previa, se dejan comentarios, se solicitan cambios y se aprueban.

Finalmente, llega a los usuarios:

5. La solicitud de extracción se fusiona y el cambio se envía al entorno de pruebas para una última revisión del equipo.

6. Una vez que el entorno de pruebas aprueba el cambio, este se implementa en producción y los usuarios lo ven.

Los pasos tres y cuatro son la nueva herramienta fundamental. Las implementaciones de vista previa permiten ver el código en tiempo real, sin tener que esperar a que el entorno de pruebas lo complete. Se ve en cuanto el ingeniero sube su rama. Esto antes era un lujo y ahora es imprescindible.

Si tu equipo no cuenta con implementaciones de vista previa, esta es la mejora más importante que podrían implementar. ¡Insiste en que se implementen!

Las implementaciones de vista previa lo cambiaron todo

Hace diez años, revisar el diseño implicaba ir corriendo al escritorio del ingeniero o esperar hasta el lanzamiento de la versión de prueba del martes siguiente. Hoy en día, todas las plataformas de alojamiento modernas asignan una URL a cada solicitud de extracción (pull request). Vercel las llama implementaciones de vista previa, Netlify las llama vistas previas de despliegue, y Render, Cloudflare y AWS Amplify ofrecen versiones similares.

En la práctica, esto significa que cada rama, cada solicitud de extracción y cada cambio en curso tiene una URL interactiva que puedes revisar sin esperar nada. El ingeniero sube su rama, la vista previa se compila en dos minutos y un bot inserta la URL en la solicitud de extracción. Haces clic, revisas, comentas y listo.

Las implementaciones de vista previa reducen el ciclo de revisión de diseño de días a minutos. Además, hacen que los videos de Loom sean mucho menos necesarios, ya que una URL de vista previa es un video de Loom con el que puedes interactuar. Si no las has estado usando, pídele a tu ingeniero que te indique dónde está el comentario del bot en cualquier PR abierta. El enlace está ahí mismo.

Algunas cosas que debes saber sobre las vistas previas: se ejecutan con datos de prueba o de desarrollo, nunca con datos de producción. Son temporales y se eliminan una vez que se cierra la PR. Tienen su propia URL por rama, por lo que puedes tener diez abiertas a la vez para diez funcionalidades diferentes.

Variables de entorno, configuraciones y por qué ves "Modo de prueba"

Cada entorno ejecuta el mismo código, pero se comunica con diferentes servicios. Desarrollo usa una base de datos de prueba, desarrollo usa una base de datos de desarrollo y producción usa la base de datos real. Cada entorno también usa diferentes versiones de cada herramienta de terceros: Stripe en modo de prueba en desarrollo y desarrollo, Stripe en modo en vivo en producción. Lo mismo ocurre con los remitentes de correo electrónico, análisis, autenticación y todas las dependencias externas.

La forma en que los equipos mantienen todo esto organizado es mediante variables de entorno, también llamadas configuraciones o secretos. Se trata de valores con nombres específicos, como DATABASE_URL o STRIPE_KEY, que varían según el entorno. Herramientas como Doppler, las variables de entorno Vercel, AWS Secrets Manager o 1Password Connect los gestionan.

¿Por qué es importante esto para ti como diseñador? Si ves que Stripe muestra números de tarjeta de prueba en el entorno de pruebas, significa que la clave Stripe del entorno de pruebas está activa. Si ves tu foto de perfil de desarrollador, pero una tarjeta de crédito totalmente falsa en el entorno de desarrollo, significa que el entorno de desarrollo está accediendo a una base de datos falsa, pero con una autenticación Clerk real. Si algo funciona en el entorno de pruebas pero falla en producción, en el 90% de los casos se debe a una variable de entorno que falta o es diferente.

No necesitas gestionarlas. Solo necesitas saber que existen para que, cuando un ingeniero diga: «Espera, eso está usando la clave Stripe de producción, no hagas clic en ese botón», sepas a qué se refiere.

Paridad de datos: Lo que realmente verá

Los datos de cada entorno determinan qué se puede probar y qué no. Este es el aspecto que los diseñadores suelen pasar por alto.

El entorno de desarrollo suele tener datos de prueba: un pequeño conjunto de usuarios, productos y demás elementos ficticios, que se actualizan cada mañana. Los nombres serán absurdos, las direcciones de correo electrónico serán de Springfield y los avatares serán pequeños cuadrados grises. No intente evaluar estados vacíos ni casos límite con estos datos, ya que se crearon para que el flujo de trabajo habitual funcione correctamente.

El entorno de pruebas suele tener datos de producción anonimizados o un conjunto de datos realistas y seleccionados. Formas, longitudes y casos límite reales, pero los nombres y correos electrónicos se han eliminado. Aquí es donde realmente se ve cómo se ven los diseños con un cliente llamado Christopher Hassan-Williamson III o con un pedido de sesenta y tres artículos. Este es el único lugar donde se puede realizar un control de calidad de diseño real.

El entorno de producción tiene datos reales, y precisamente por eso no se deben manipular. Puedes consultar instantáneas y paneles de control, pero nunca uses el entorno de producción como campo de pruebas.

El rol del diseñador en cada entorno

La mejor manera de entender tu trabajo en cada entorno es asignarte un rol diferente en cada uno.

En desarrollo, eres un miembro más del equipo. Realizas revisiones rápidas compartiendo la pantalla, validas que el ingeniero haya comprendido el diseño y detectas los problemas estructurales importantes a tiempo. No haces correcciones en desarrollo porque el ingeniero aún está trabajando en el proyecto.

En preproducción, eres el responsable de control de calidad del diseño. Comparas con el archivo Figma, verificas los estados y creas la lista de pendientes. Aquí es donde realizas la revisión exhaustiva, dejas comentarios estructurados y apruebas o bloqueas el cambio. El entorno de preproducción es tu dominio.

En producción, eres un usuario externo. Verificas que el cambio se haya implementado, tomas una captura de pantalla y revisas las analíticas si esa es tu función. En producción, no haces pruebas rápidas ni experimentas sin rumbo.

Ten presentes estos tres modos y serás uno de los diseñadores más fáciles con los que tu equipo de ingeniería haya trabajado.

Errores comunes de los diseñadores

He visto a diseñadores cometer todos estos errores. Yo mismo he cometido algunos. Ninguno es el fin del mundo, pero todos ralentizan al equipo y perjudican la buena voluntad del equipo de ingeniería.

Los clásicos:

• Enviar una URL de desarrollo a un cliente. El equipo de desarrollo está en su portátil, así que el cliente hace clic en el enlace, recibe un error de conexión y pregunta si siquiera están lanzando algo.

• Reportar un "error activo" desde una caché de CDN obsoleta. Estás viendo una versión almacenada en caché hace seis horas, y una actualización forzada lo soluciona.

El siguiente grupo de errores surge de la confusión sobre qué está activo y dónde:

• Reportar un error por algo que ya está solucionado en el entorno de pruebas. Consultaste el entorno de producción, viste la versión antigua y reportaste un error de pánico con el código Slack. La corrección lleva una semana en el entorno de pruebas.

• No pedir un enlace de vista previa. Esperas tres días a que llegue al entorno de pruebas cuando el ingeniero podría haber compartido una URL de vista previa en el momento del despliegue.

Los dos últimos puntos tratan sobre respetar la distinción entre el entorno de pruebas y el de producción:

• Acceder a producción para "probar" algo. Ahora eres un usuario real con consecuencias reales, así que deja de hacerlo.

• Preguntar "¿Ya está disponible?" en lugar de consultar el registro de despliegue. La mayoría de los equipos tienen un canal Slack donde se publican todos los despliegues, así que guárdalo en favoritos.

Cada uno de estos errores se soluciona con una sola línea de código una vez que sabes que existe. Ninguno es absurdo. Simplemente son cosas que nadie te ha dicho.

Cómo pedir lo que necesitas

La otra cara de la moneda de estos errores es la etiqueta. La comunicación entre diseñadores e ingenieros sobre entornos se basa principalmente en la especificidad. Las solicitudes vagas cuestan tiempo, las específicas no cuestan nada.

Mal: "¿Podrías subir el nuevo diseño de la tarjeta a algún sitio donde pueda verlo?"

Bien: "¿Podrías subir la rama del diseño de la tarjeta y enviarme la URL de vista previa cuando esté lista?"

Mal: "¿Ya está disponible la actualización de la página de inicio?"

Bien: "¿Ya está en producción la solicitud de extracción 412 o sigue en el entorno de pruebas?"

Mal: "Algo parece estar fallando en el sitio web."

Bien: "En producción, a la tarjeta de precios en /pricing le falta el borde inferior. He actualizado la página, pero sigue fallando. Adjunto captura de pantalla."

El patrón se repite en todos los ejemplos. Indica el entorno, el cambio y proporciona las pruebas. Los ingenieros harán lo imposible por los diseñadores que hagan este tipo de solicitudes. En cambio, se resentirán en silencio con quienes no lo hagan.

Indicadores de características: Entorno de pruebas dentro de producción

Existe un cuarto concepto que rompe con el modelo de desarrollo/pruebas/producción de forma útil: los indicadores de características. Una bandera de características es un interruptor en el código que indica "mostrar esta nueva característica al usuario X, pero no al usuario Y". Los equipos las utilizan para implementar código en producción, exponiendo la nueva característica solo a un pequeño grupo de usuarios, generalmente personal interno.

Herramientas como LaunchDarkly, Statsig, ConfigCat y las banderas propias de Vercel hacen esto. El nuevo diseño está técnicamente en producción, pero solo lo ven quienes tienen la bandera interna. El resto ve la versión anterior.

Esto es importante porque la respuesta a "¿está disponible?" se vuelve más ambigua. El código está disponible, pero la característica podría no estarlo, por lo que es posible que deba pedirle al ingeniero que active la bandera para su cuenta. O podrían decir: "Ya está implementada, solo que con una bandera; la activaremos para todos el martes".

Las banderas de características son la forma en que los equipos experimentados implementan código de forma continua sin afectar a todos. También permiten realizar el equivalente a una revisión de entorno de producción con datos reales, usuarios reales y con bajo riesgo.

Lo que cada entorno te enseña sobre el equipo

La forma en que un equipo gestiona estos tres entornos revela prácticamente todo sobre su madurez de ingeniería. Utiliza esto como una lectura rápida para cualquier cliente o rol nuevo.

Un equipo sin entorno de pruebas avanza a toda velocidad y con la esperanza de que todo salga bien. Tarde o temprano, encontrarán un error que les costará un cliente, y entonces crearán un entorno de pruebas.

Un equipo con entorno de pruebas pero sin implementaciones de vista previa se encuentra en un punto intermedio. Las revisiones son lentas, el ciclo desde "terminado" hasta "el diseñador puede revisarlo" se mide en días, y pasarás mucho tiempo esperando.

Un equipo con implementaciones de vista previa, un entorno de pruebas real, producción supervisada y indicadores de características opera al nivel deseado. Los ciclos de retroalimentación son cortos, los errores se detectan a tiempo y nadie entra en pánico el día del lanzamiento. Una vez que has trabajado en este nivel, los demás resultan agotadores.

Tres entornos, tres públicos, tres conjuntos de datos, un ciclo de vida que los conecta. Ese es el concepto fundamental. Todo lo demás son herramientas adicionales.

No necesitas saber cómo implementar código ni administrar una cuenta de Vercel. Solo necesitas saber en qué entorno te encuentras, qué permisos tienes y cómo solicitar la URL correcta. Si haces esto, te convertirás en el diseñador con el que tus ingenieros realmente querrán trabajar.

Guarda el registro de implementación en tus marcadores, solicita el enlace de vista previa y deja de intervenir en producción.