Cómo elegir a un diseñador de sitios web

No elijas solo a un diseñador: elige el alcance de responsabilidad

Un buen proveedor de sitios o aplicaciones entiende el objetivo de negocio, puede traducirlo en un producto que funcione y muestra con claridad de qué es responsable. Un diseño gráfico atractivo no basta cuando necesitas un formulario, integración, panel para el equipo o funciones basadas en datos e IA.

Empieza por distinguir las necesidades. Para un sitio de marca sencillo pueden ser clave la comunicación, identidad y contenido. Para un producto digital son más importantes el modelo de datos, seguridad, rendimiento, mantenimiento y modo de despliegue. Una misma empresa puede atender ambos casos, pero debe saber explicar cómo cambian el proceso y la composición del equipo.

Prepara una descripción breve del problema

No necesitas una especificación técnica terminada. Antes de la primera conversación, no obstante, conviene anotar algunas cosas:

• para quién se crea el producto y qué tarea debe facilitar;
• qué funciona hoy y qué es fuente de coste, errores o trabajo manual;
• qué resultado significará éxito;
• qué limitaciones existen: plazo, presupuesto, sistemas actuales, datos o requisitos legales.

Esta lista permite comparar propuestas por la forma de resolver el problema, no por el número de pantallas del presupuesto. También da al proveedor la oportunidad de hacer una pregunta que todavía no habías considerado.

Comprueba las competencias necesarias para tu caso

No vale la pena evaluar a un socio solo por una lista de tecnologías. Importa más si puede justificar una elección y describir sus consecuencias. Si el proyecto requiere una aplicación, pregunta por diseño de interfaz, arquitectura, pruebas, despliegue y mantenimiento posterior. Si debe integrar modelos de lenguaje, pregunta por calidad de datos, control de acceso, evaluación de resultados y situaciones en las que la automatización debe pasar el caso a una persona.

Conocer Next.js, React, Python o un CMS concreto puede ser útil, pero no es un fin en sí mismo. Una buena señal es una respuesta como: «elegimos esta solución porque acorta este recorrido, permite conectar sistemas de forma segura o no os encierra en un mantenimiento costoso». Una mala señal es proponer una herramienta antes de conocer el problema.

Freelancer, estudio o software house: a quién necesitas

El nombre del proveedor no garantiza el alcance, pero ayuda a hacer las preguntas correctas.

Modelo	Encaja bien cuando	Comprueba especialmente
Freelancer	el alcance es limitado y tienes los roles que faltan de tu lado	disponibilidad, sustitución, mantenimiento y entrega de archivos
Estudio de diseño	el principal problema es la marca, el contenido y la experiencia de interfaz	quién implementará el diseño y cómo se comprueba la viabilidad
Software house / equipo de producto	necesitas aplicación, integraciones y responsabilidad técnica	discovery, arquitectura, pruebas, operaciones tras el despliegue y coste de cambios

Un equipo pequeño puede combinar estas competencias y una empresa grande puede subcontratar parte del trabajo. Pide por tanto los nombres o roles de las personas que trabajarán de verdad en el proyecto y cómo colaborarán entre ellas. El logotipo del proveedor importa menos que la continuidad de la responsabilidad.

Mira el portfolio como una prueba, no como un catálogo de imágenes

El portfolio debería mostrar no solo el resultado visual, sino el tipo de reto. Para cada ejemplo conviene preguntar:

• ¿Cuál era el problema de negocio u operativo?
• ¿Qué alcance realizó el equipo y qué correspondía al cliente?
• ¿Cómo fue el camino desde la decisión hasta el despliegue?
• ¿Qué ocurrió tras la publicación: mantenimiento, desarrollo, correcciones o entrega del proyecto?

No todo proyecto se puede describir públicamente. En ese caso importa la honestidad sobre alcance y limitaciones. Tecnologías nombradas sin contexto y wireframes sin información sobre si el producto funciona son una prueba más débil que una descripción breve y concreta de una decisión.

Pregunta por el proceso de trabajo antes de preguntar por el precio

Es fácil comparar precios cuando el alcance es similar. El problema es que al principio suele no serlo. Una oferta puede incluir solo el diseño de pantallas y otra también discovery, desarrollo, pruebas, despliegue y monitorización. Sin esta distinción, la propuesta más barata puede simplemente no incluir trabajo esencial.

Pide una descripción de etapas, puntos de aceptación y reglas para cambios de alcance. Debe quedar claro cuándo apruebas la dirección, dónde se documentan las decisiones, quién comprueba la calidad y qué queda tras el proyecto: código, acceso, documentación, instrucciones y plan de desarrollo posterior. Nuestro proceso de entrega muestra cómo estas puertas reducen el riesgo de trabajar «a ciegas».

Evalúa la colaboración por las preguntas que se hacen

La colaboración se basa en la confianza, pero confiar no significa aceptar todo. Un buen socio sabe cuestionar una solución que no conduce al objetivo y, a la vez, explica el motivo en lenguaje sencillo. No promete resultados que aún no se pueden estimar con rigor.

Fíjate en si, tras la conversación, comprendes mejor el problema y las decisiones siguientes. Si la oferta llega muy rápido, pero nadie pregunta por usuarios, datos, herramientas existentes o forma de mantenimiento, el riesgo solo se ha desplazado hacia más adelante.

Señales de alarma en una oferta

La prudencia no significa que cada oferta necesite cientos de páginas. Basta con que sea concreta. Ten cuidado cuando el alcance se describe solo con lemas generales, el plazo no guarda relación con las etapas de trabajo o el resultado final no dice nada sobre despliegue y responsabilidad tras publicar.

Conviene preguntar también por propiedad de los resultados, acceso a cuentas y repositorio, y forma de transferir conocimiento. No son formalidades para el final. De ellas depende que puedas desarrollar el producto por tu cuenta o cambiar de socio con seguridad cuando acabe la colaboración.

Es bueno dejar estos acuerdos por escrito antes de empezar el trabajo.

Qué debe quedar al terminar el proyecto

La aceptación no termina en una dirección publicada. Aclara de antemano si recibirás:

• acceso de propietario al dominio, hosting, analítica, repositorio y cuentas de servicios;
• archivos fuente del proyecto y licencias de fuentes, imágenes y componentes;
• instrucciones de despliegue, copias de seguridad, monitorización y respuesta a fallos;
• una lista de limitaciones conocidas, deuda técnica y próximos pasos recomendados;
• reglas de garantía, mantenimiento y presupuesto de cambios tras la aceptación.

El tráfico de un sitio se parece al tráfico de carretera: señales y reglas estables permiten moverse sin adivinar. Del mismo modo, la documentación y los accesos permiten al siguiente equipo desarrollar el producto sin reconstruir cada decisión desde cero.

Lista de control antes de elegir proveedor

• ¿Habéis nombrado juntos el problema y la medida de éxito?
• ¿El alcance incluye lo que realmente necesitas, no solo la vista de la página?
• ¿El portfolio explica resultados y responsabilidad del equipo?
• ¿Conoces las etapas, aceptaciones, reglas de cambio y modo de despliegue?
• ¿Al finalizar conservarás acceso a los resultados del trabajo y el conocimiento necesario para desarrollarlos?

Trata la elección de proveedor como la selección de un socio para un proceso importante, no como comprar una imagen terminada. Si quieres ordenar primero el problema y el alcance, empieza por un brief breve o consulta cómo es el diseño y planificación de una solución. Para una página orientada a una acción concreta también ayuda el artículo sobre qué es una landing page, y describimos la implementación completa en la oferta de sitios web.