Guía · Diseño y UX
Proceso de diseño UI/UX: de la investigación a la interfaz
La mayor parte del trabajo de diseño se tuerce por el orden en que se hizo, no por el trabajo en sí. Así transcurre habitualmente un proceso UI/UX —desde la primera conversación sobre los objetivos hasta la interfaz que construye un desarrollador— y por qué cada etapa existe antes que la siguiente.
¿Qué es el proceso de diseño UI/UX?
El proceso de diseño UI/UX es la secuencia de decisiones que convierte un objetivo en una interfaz funcional. Empieza con lo que el proyecto tiene que conseguir y para quién es, avanza a través de la estructura y el comportamiento, y termina con un diseño visual lo bastante detallado como para poder construirse. Cada etapa reduce el número de preguntas abiertas para que la siguiente pueda decidirse con evidencia y no con opinión.
Es una secuencia, no una plantilla rígida. Las etapas siguientes describen un proceso completo; los proyectos reales las combinan, las acortan o las repiten según el alcance, y es normal volver a una etapa anterior cuando algo posterior revela un problema estructural.
UX frente a UI: cómo trabajan juntas
La UX es la parte que no se ve directamente: qué contenido existe, cómo está agrupado, el camino que recorre alguien a través de él, y qué hace la interfaz en cada paso. La UI es la expresión visible de eso: tipografía, color, espaciado, imaginería y el estilo de cada componente y estado.
Suelen describirse como dos disciplinas, pero en la práctica son dos vistas de la misma decisión. Una jerarquía es, a la vez, un juicio de UX sobre qué importa y un juicio de UI sobre tamaño y peso. Por eso el proceso resuelve primero la estructura y después la superficie: una maquetación hermosa aplicada a una estructura confusa hereda esa confusión, mientras que una estructura clara le da al diseño visual algo concreto que expresar.
Para un repaso más completo de las cualidades que debería tener el resultado final, ver qué hace buena a una experiencia de usuario.
El proceso de diseño UI/UX
1. Descubrimiento y objetivos
La primera etapa consiste en acordar para qué es el proyecto. Eso implica nombrar el resultado en lenguaje sencillo —explicar un servicio, generar consultas, vender un producto, sustituir un sitio anticuado— e identificar las restricciones a su alrededor: contenido existente, plataforma técnica, activos de marca, aprobaciones internas y cualquier cosa que no pueda cambiar. Sin esto, las decisiones posteriores se discuten por gusto, porque no hay una medida compartida contra la que discutirlas.
2. Contexto de usuario y de negocio
A continuación viene entender para quién es la interfaz y qué necesita la organización de ella. Esto puede ir desde una conversación breve con quienes hablan con los clientes, hasta revisar la analítica existente, las preguntas de soporte y el comportamiento de búsqueda. El resultado no es un documento por sí mismo, sino una lista breve de las audiencias que importan, las preguntas con las que llegan, y las prioridades de negocio a las que la interfaz tiene que servir al mismo tiempo.
3. Arquitectura de la información
La arquitectura es la estructura bajo el diseño: qué contenido existe, cómo se agrupa, qué ocupa el nivel superior y de qué es responsable cada página. Se resuelve antes que la maquetación porque determina las etiquetas de navegación, la estructura de las URL y cuántas páginas hacen falta. El contenido y la estructura se deciden juntos: diseñar una maquetación para un contenido que todavía no existe es la causa más común de rehacer trabajo.
4. Flujos de usuario
Un flujo es la ruta que alguien sigue para completar una tarea: llegar, entender, comparar, decidir, actuar. Mapear los flujos principales muestra dónde falta un paso, dónde compiten dos caminos y dónde se pide una decisión antes de haber dado la información necesaria para tomarla. Los flujos son baratos de cambiar en este punto y caros de cambiar una vez construidos.
5. Wireframes
Los wireframes fijan la maquetación, la jerarquía y el orden del contenido sin la distracción del color y la imaginería. Su propósito es responder preguntas estructurales —qué aparece primero, cuál es la acción principal, qué puede posponerse— mientras todavía son rápidos de revisar. Revisar wireframes con encabezados y textos reales, en lugar de texto de relleno, es lo que hace útil el feedback.
6. Diseño de interacción
El diseño de interacción cubre cómo se comporta la interfaz: qué es cliqueable y cómo lo señala, qué ocurre al pasar el cursor y al enfocar, cómo se abre la navegación, cómo aparecen los estados de carga y vacíos, y cómo se comunican los errores. El movimiento también pertenece aquí, y su función es explicar un cambio de estado, no decorarlo. El comportamiento definido en esta etapa es lo que mantiene una interfaz predecible una vez construida.
7. Diseño visual de UI
El diseño visual aplica tipografía, color, espaciado, imaginería y tono a la estructura ya acordada. Hecho como un sistema —escala tipográfica, escala de espaciado, funciones de color, estados de componentes— en lugar de un conjunto de pantallas individuales, se mantiene coherente a medida que el proyecto crece y les da a los desarrolladores reglas inequívocas contra las que construir. Esta etapa es donde se encuentran la marca y la interfaz, y donde una página empieza a sentirse propia de una organización concreta.
8. Diseño responsive
Cada punto de ruptura significativo se diseña, no se hereda. El orden del contenido a menudo necesita cambiar en una pantalla pequeña, los objetivos táctiles necesitan espacio, la navegación suele convertirse en un componente distinto, y cualquier cosa que dependa del hover necesita un equivalente táctil. Como la mayoría de los visitantes llegan desde un teléfono, suele valer la pena resolver primero la pantalla pequeña e ir ampliando hacia afuera.
9. Prototipado y revisión
Un prototipo cliqueable convierte pantallas estáticas en algo que se puede recorrer. Deja al descubierto problemas que las composiciones planas ocultan: un paso que se siente más largo de lo esperado, una etiqueta que se malinterpreta, un formulario que pide demasiado demasiado pronto. Las revisiones pueden ser recorridos internos u observación de personas intentando completar una tarea; el valor está en observar dónde surge la duda, no en preguntar si algo gusta.
10. Refinamiento y entrega
Los hallazgos se priorizan —lo que bloquea una tarea primero, las notas de preferencia al final— y el diseño se revisa en consecuencia. La entrega cubre entonces lo que necesita la implementación: estados de componentes, reglas de espaciado, tokens de tipografía y color, comportamiento por punto de ruptura, requisitos de accesibilidad y los propios activos. El trabajo de diseño suele continuar durante la construcción, porque surgen preguntas que ningún archivo estático anticipó.
Cómo se organizan estas etapas dentro de un proyecto se describe en la página de servicios de diseño UI/UX, y hay interfaces terminadas reunidas en el trabajo seleccionado, incluido el caso RAGHADD.
¿Cuánto tiempo lleva el diseño UI/UX?
No hay una duración estándar, y cualquier cifra dada antes de conocer el alcance es una suposición. La respuesta honesta es que el tiempo depende de un puñado de variables, y el mismo número de páginas puede llevar cantidades de tiempo muy distintas según cómo caigan.
- Alcance — cuántos tipos de página y flujos distintos necesitan diseñarse de verdad, no cuántas URL existen.
- Complejidad — un sitio de marketing y una interfaz de producto con cuentas, estados y permisos son problemas distintos.
- Preparación del contenido — si el texto, la imaginería y los activos de marca ya existen o hay que producirlos junto con el diseño.
- Ciclos de feedback — la rapidez con la que ocurren las revisiones y la claridad con la que se toman las decisiones suele ser el factor individual más determinante.
- Requisitos de implementación — la plataforma, las integraciones y quién lo va a construir determinan cuánto detalle necesita la entrega.
Una estimación realista llega después del descubrimiento, una vez que el alcance está por escrito. Cualquier cosa antes de eso es, en el mejor de los casos, un rango.
Cómo prepararse para un proyecto de diseño UI/UX
La preparación acorta un proyecto de forma más fiable que cualquier cosa que haga un diseñador. Antes de la primera sesión de trabajo, ayuda tener resuelto lo siguiente:
- Escribir el único resultado que el proyecto tiene que conseguir, y cómo reconocerías que se ha logrado.
- Decidir quién es la audiencia principal, y con qué pregunta llega más a menudo.
- Reunir el material existente: textos, imaginería, archivos de marca, analítica, preguntas de soporte.
- Identificar pronto las restricciones técnicas: plataforma, integraciones, quién lo va a construir.
- Acordar quién da el feedback y quién toma la decisión final, antes de la primera revisión.
- Ser honesto sobre qué contenido falta todavía por escribir, ya que el contenido suele ser la parte más lenta.
Si se va a sustituir un sitio existente, revisarlo primero merece la pena: la checklist de auditoría de diseño UI/UX cubre qué examinar, y a menudo muestra qué partes vale la pena conservar.
Preguntas frecuentes
¿Cuál es la diferencia entre UX y UI?
+
La UX se ocupa de la estructura y el comportamiento: qué contiene la interfaz, cómo está organizada y qué ocurre en cada paso. La UI es la superficie visible: tipografía, color, espaciado, imaginería y el estilo de los componentes. Son preocupaciones distintas, pero no proyectos separados; la interfaz expresa la estructura, y un cambio en una suele afectar a la otra.
¿Todos los proyectos pasan por todas las etapas?
+
No. La secuencia anterior describe un proceso completo, y los proyectos reales lo comprimen. Un sitio de marketing pequeño puede fusionar la arquitectura y los wireframes en un solo paso, mientras que un producto complejo puede dedicar un esfuerzo considerable solo a los flujos. Las etapas son una lista de decisiones que hay que tomar en algún momento, no un calendario fijo.
¿El contenido debería estar listo antes de empezar a diseñar?
+
No necesariamente terminado, pero sí debería conocerse su forma. Diseñar con encabezados y mensajes reales produce una maquetación que se ajusta a lo que realmente hay que decir; diseñar con texto de relleno suele producir una maquetación en la que el contenido acaba teniendo que encajarse a la fuerza.
¿Dónde encajan las pruebas?
+
Allí donde haya algo a lo que reaccionar. La estructura puede revisarse en la etapa de wireframes, el comportamiento en la etapa de prototipo, y la interfaz construida una vez publicada. Revisar antes sale más barato, porque un cambio en un flujo cuesta mucho menos que un cambio en una página ya construida.
¿Un rediseño es siempre la respuesta correcta?
+
A menudo no lo es. Cuando la estructura de fondo es sólida, la claridad, la jerarquía, las etiquetas y los formularios suelen poder mejorarse sobre lo ya construido. Una revisión estructurada es la forma de averiguar en qué situación estás antes de comprometerte con una reconstrucción.
Sobre el autor
Escrito por Anas Essam, consultor tecnológico y director creativo que trabaja en sistemas de IA, diseño web, branding y crecimiento digital. Con base en Egipto, trabaja con equipos de todo el mundo.
Primero la estructura, después la superficie
Un proceso solo es útil cuando se ajusta al proyecto que tiene delante. Si estás planeando un sitio nuevo, un producto o un rediseño, describir el objetivo es el punto de partida adecuado. Más textos en Ideas.
Empezar una conversación