Una propuesta de desarrollo puede mostrar pantallas atractivas y dejar sin responder las preguntas que definen el uso diario del sitio. Para evaluar una web orientada a captar consultas, conviene revisar qué entenderá el visitante, qué podrá hacer y cómo llegará esa información al equipo comercial.

Pedí una estructura basada en decisiones

El menú no tiene que copiar el organigrama de la empresa. Puede organizarse según lo que una persona necesita resolver: conocer un servicio, ver proyectos, comprobar si atienden su mercado y consultar un alcance. Cada página importante debería tener un motivo claro para existir.

Como ejercicio, escribí las preguntas que recibís antes de una venta. «¿Trabajan con empresas como la mía?», «¿Qué incluye?», «¿Cómo empezamos?» y «¿Qué información necesitan?» pueden orientar contenido más útil que una lista de adjetivos sobre la marca.

La evidencia necesita contexto

Un caso puede explicar una necesidad, el trabajo realizado y lo que se entregó. Si incluye resultados, pedí que indique qué se midió y durante qué período. Si solo hay una descripción de alcance, presentarla como tal es suficiente para que el visitante entienda el tipo de intervención.

El mismo criterio sirve para tecnología, certificaciones o experiencia: publicá información que el equipo pueda respaldar y mantener actualizada. Una web comercial tiene que facilitar una decisión informada sobre el servicio.

Probá el contacto en móvil y con teclado

Revisá que cada campo tenga un nombre visible, que el botón se pueda alcanzar y que los mensajes expliquen cómo corregir un dato. La guía de W3C recomienda notificaciones claras tanto para errores como para envíos exitosos y relacionar el error con el campo correspondiente. Fuente: notificaciones en formularios accesibles.

Un ejemplo de revisión práctica es completar el formulario desde un teléfono, provocar un error de email y corregirlo sin perder el resto de los datos. Luego seguí el envío hasta el sistema donde lo atenderá el equipo. Eso ayuda a descubrir un problema que una captura del diseño no puede mostrar.

Acordá quién puede editar qué

  • ¿El equipo puede cambiar textos de servicios sin modificar el diseño?
  • ¿Puede crear artículos, elegir categoría y programar una publicación?
  • ¿Hay vista previa y una forma de recuperar una edición anterior?
  • ¿Las imágenes permiten describir su contenido para quienes no las ven?
  • ¿Está claro quién administra usuarios y permisos?

No todas las empresas necesitan el mismo panel. Lo útil es que las tareas habituales queden cubiertas y que la entrega incluya una explicación de uso. El mantenimiento técnico y la edición cotidiana pueden tener responsables diferentes.

Si reemplazás una web, cuidá las rutas útiles

Prepará un inventario de páginas existentes antes de cambiar la estructura. Decidí qué URLs se conservan, cuáles cambian y dónde llevará cada enlace anterior. Google recomienda organizar el contenido de forma lógica y cuidar la relación entre versiones de una misma página. Fuente: organización del sitio en la guía de SEO de Google.

En la propuesta, separá el desarrollo del trabajo de migración: carga de contenido, imágenes, metadatos, enlaces y revisión de redirecciones. Esas tareas forman parte del proyecto aunque no se vean como una sección nueva en el diseño.

Un criterio concreto de aceptación

Elegí una página de servicio y seguí su recorrido completo: el visitante entiende la oferta, encuentra evidencia, envía una consulta y el equipo puede localizarla. Repetí la revisión en móvil y en escritorio. Sumá edición, recuperación y mantenimiento según el alcance. Así la aceptación del proyecto se apoya en funciones que el negocio necesita.

En desarrollo web trabajamos ese recorrido junto con contenido e integraciones. Si el formulario entrega información a un CRM, el alcance de automatización debe quedar definido desde el inicio.