Diseño de producto B2B: qué cambia

Un producto puede ser complejo sin ser complicado. Lo he visto en interfaces donde una decisión depende de permisos, alarmas y datos de distintos dispositivos. Una pantalla más limpia no arregla una lógica difícil de entender.

Si lideras un SaaS B2B o una plataforma interna, aquí encontrarás cómo abordo estos sistemas y qué evidencia pediría a quien vas a contratar.

¿Qué hace complejo a un producto B2B?

La complejidad no depende del número de pantallas. Aparece cuando un mismo producto debe coordinar roles, permisos, reglas, datos y estados sin perder coherencia. Nielsen Norman Group describe las aplicaciones complejas como sistemas que soportan objetivos abiertos, flujos no lineales, grandes conjuntos de datos y decisiones potencialmente críticas.

Antes de dibujar, aclaro cinco puntos:

• Roles: ¿quién consulta, quién opera, quién aprueba y quién administra?
• Permisos: ¿qué puede ver o modificar cada persona, instalación o equipo?
• Reglas: ¿qué validaciones, dependencias y excepciones condicionan una acción?
• Datos: ¿de dónde viene la información, qué significa y cuándo se actualiza?
• Estados: ¿qué condiciones puede tener un elemento y qué acción corresponde a cada una?

Imagina una herramienta de mantenimiento industrial. Una alerta puede ser visible para un operador, editable por un supervisor y configurable por un administrador. Si diseñas solamente la tarjeta visual de la alerta, no has resuelto quién se hace cargo, qué ocurre al cambiar su estado o qué sucede cuando falla la conexión. Eso no es un detalle técnico posterior: define la experiencia.

Lo mismo pasa cuando parte de las decisiones las toma un agente de IA: antes de la pantalla hay que definir qué puede hacer solo, qué necesita aprobación y cómo se interviene. Lo desarrollo en Human in the loop: supervisar agentes de IA.

¿Por qué la UX de software empresarial es distinta a la de una app de consumo?

Porque la persona que compra el software puede no ser quien lo usa todos los días. Un CTO puede evaluar seguridad e integración; operaciones puede exigir trazabilidad; quien utiliza la plataforma necesita completar tareas en medio de interrupciones. El diseño debe atender esas necesidades.

También hay usuarios que no eligieron la herramienta: forman parte de un proceso organizacional y deben trabajar con ella aunque prefieran otro sistema. Por eso no basta con preguntar si la pantalla les gusta. Necesito entender la tarea, su frecuencia, qué información consultan fuera del producto y qué consecuencias tiene equivocarse. La investigación sobre usabilidad empresarial de Nielsen Norman Group distingue la experiencia individual de la coordinación entre equipos y de los efectos en toda la organización.

La diferencia se vuelve especialmente clara con tareas repetitivas. Un usuario experto puede preferir una tabla densa, filtros persistentes y acciones rápidas antes que tarjetas espaciosas. La investigación de NN/g sobre aceleradores de interfaz explica por qué los sistemas usados constantemente deben equilibrar facilidad de aprendizaje y eficiencia para quien ya domina el trabajo.

Mi principio es sencillo: no elimino complejidad que el negocio necesita; elimino trabajo mental innecesario para manejarla.

¿Cómo diseño un sistema B2B complejo sin hacerlo complicado?

No empiezo por un rediseño visual. Sigo tres etapas que corresponden al trabajo real de mi servicio: modelar, simplificar y sistematizar. Cada una produce algo que producto e ingeniería pueden revisar, no solamente una colección de pantallas.

1. Modelo el sistema antes de la interfaz

Primero reconstruyo el funcionamiento: actores, entidades, reglas, permisos, estados y excepciones. Reviso los flujos existentes y separo lo que el usuario intenta lograr de lo que hoy le obliga a hacer el software. La guía de análisis de tareas de NN/g diferencia el objetivo de una persona de los pasos concretos con los que intenta alcanzarlo.

Mi entregable inicial reúne roles, permisos, transiciones y dependencias. Lo valido con producto e ingeniería antes de dibujar. Si falta un dato o un permiso rompe una regla, prefiero descubrirlo antes del desarrollo.

Por ejemplo, «resolver alarma» puede requerir registrar un motivo, actualizar el estado del activo y notificar a otra persona. Dibujar un botón «Resolver» sin aclarar esas condiciones sería adelantar la interfaz a una decisión que todavía no tomamos.

2. Simplifico los flujos que más cuestan

Con el modelo claro, selecciono tareas críticas: las que se repiten, requieren demasiadas decisiones, generan errores o tienen consecuencias importantes. No intento optimizar toda la plataforma de una vez. Trabajo un flujo concreto, construyo un prototipo navegable —o en código si la interacción lo necesita— y reviso cómo se completa la tarea.

Aquí contradigo un consejo habitual: simplificar no es reducir clics a cualquier precio. Nielsen Norman Group explica por qué la regla de los tres clics no es un indicador universal de usabilidad. Un paso adicional que permite verificar una acción irreversible puede ser más útil que un acceso directo sin contexto.

También ocurre lo contrario: si una persona revisa incidentes continuamente, esconder filtros y columnas para lograr una pantalla minimalista puede hacer su trabajo más lento. La documentación de tablas de IBM Carbon contempla ordenamiento, expansión y acciones por lotes porque distintas tareas requieren distintas formas de acceder a los datos.

Antes de aprobar el flujo, pregunto: ¿se encuentra lo crítico?, ¿se entiende el siguiente paso?, ¿puede recuperarse de un error?, ¿se mantienen visibles los datos necesarios para decidir?

3. Dejo un sistema que ingeniería reutiliza

Cuando el flujo funciona, consolido componentes, tokens y especificaciones. No entrego botones duplicados: defino el comportamiento de tablas, alertas, filtros, estados vacíos y casos límite.

Un token debe expresar una decisión semántica, no simplemente guardar un color. Por ejemplo, un estado crítico necesita una representación consistente en una tarjeta, una fila y un mapa. La documentación de tokens de Atlassian explica su función como decisiones reutilizables compartidas entre diseño y código.

Cierro con un handoff que ingeniería pueda discutir e implementar: comportamiento esperado, componentes, estados, restricciones, ejemplos y criterios de aceptación. Si solo rediseño un módulo, sistematizo los patrones que ese módulo necesita; no vendo un design system completo por defecto.

¿Cómo apliqué este método al rediseño de SIAC?

SIAC es mi caso principal de rediseño de una plataforma de supervisión operativa en uso, en seguridad industrial e IoT. El producto está orientado al monitoreo en tiempo real de 20.347 activos críticos, entre distintos tipos de dispositivos y elementos supervisados. La complejidad no era decorativa: el operador tenía que reconocer situaciones distintas y navegar entre información conectada.

En la auditoría del producto revisé flujos de alarmas, seguimiento y gestión de usuarios, además de los tokens visuales y la jerarquía de información. Había estados poco diferenciados, respuestas visuales insuficientes ante ciertas acciones y navegación que requería conectar mentalmente distintas vistas.

La primera decisión fue modelar seis estados operativos diferenciados, cada uno con su token visual. No era solo elegir colores: era hacer que la misma condición pudiera reconocerse de forma coherente en distintas partes del sistema. También consideré permisos por rol, porque el alcance de una acción cambia según quién la ejecuta.

Cómo se traducen esos estados, las alarmas y la frescura de los datos en la pantalla del operador lo desarrollo en cómo diseñar dashboards operativos en tiempo real.

La segunda decisión fue priorizar lo crítico. Reorganicé la jerarquía para que el estado general, los incidentes y las acciones frecuentes tuvieran una lectura más directa. Las alarmas quedaron diseñadas para gestionarse en pocos pasos, mientras mapa, información técnica y detalle del activo conservan su relación.

Por último, sistematicé ocho vistas interconectadas con patrones reutilizables para KPIs, tablas, mapas, alarmas y permisos, sobre cinco tipos de activo. La decisión importante fue que cada pantalla no inventara su propia manera de mostrar un estado o responder a una acción.

Para proyectos nuevos, prefiero acordar una línea base antes de intervenir: éxito de tarea, errores, tiempo o necesidad de asistencia, según el problema. NN/g recomienda establecer esa referencia antes del rediseño para poder interpretar lo que cambie después. Si el problema es un embudo digital, también explico cómo cruzar GA4 y Clarity para investigar el comportamiento; no usaría esas herramientas como sustituto de observar una tarea operativa.

¿Cómo evaluar a un Product Designer para software B2B complejo?

Si eres CTO, founder o líder de producto, empezaría por el portafolio, pero no por la calidad de las imágenes finales. Pediría ver cómo pasó de una regla de negocio a una decisión de interfaz y cómo consiguió que ingeniería pudiera construirla sin reinterpretaciones.

No espero documentos confidenciales públicos, pero sí explicaciones precisas, artefactos anonimizados y claridad sobre la contribución personal. Una captura atractiva sin decisiones justificadas no alcanza.

¿Qué preguntas haría en la entrevista?

Estas son preguntas que puedes copiar. No evalúes si usa las mismas palabras que yo: escucha si puede razonar con restricciones reales.

1. «¿Cómo descubres los permisos y las excepciones antes de diseñar?» Una buena respuesta describe conversaciones con negocio e ingeniería, revisión del sistema y un modelo validable.
2. «Muéstrame una decisión donde no elegiste la opción visualmente más simple». Busca un trade-off explícito entre velocidad, información disponible, riesgo y aprendizaje.
3. «¿Qué probarías antes de pedir que ingeniería construya todo el módulo?» Debería elegir una tarea, una hipótesis y un prototipo que permita observarla.
4. «¿Qué entregas cuando tu archivo de diseño está terminado?» Espera componentes, variantes, estados, reglas, criterios de aceptación y una conversación real de handoff.
5. «¿Qué sabes que mejoró y qué no pudiste medir?» Una respuesta sólida separa métricas, observaciones e hipótesis; no inventa porcentajes.

Esta evaluación también debería incluir a una persona de ingeniería. El proceso de contratación de Product Designers de GitLab contempla entrevistas interdisciplinarias: tiene sentido porque aquí diseño y factibilidad técnica no son conversaciones separadas.

¿Cuáles son las banderas rojas?

Desconfiaría de quien propone rediseñar todas las pantallas antes de conocer el dominio, confunde un kit visual con un sistema de diseño, omite los estados de error o afirma haber «optimizado la operación» sin explicar cómo lo midió. También es una alerta que nunca mencione dependencias, permisos ni colaboración con ingeniería.

No es una lista para descartar perfiles jóvenes. Es un criterio para ajustar el nivel de autonomía que requiere tu proyecto: una interfaz acotada y un sistema crítico no demandan la misma experiencia.

¿Cuáles son los errores más comunes al rediseñar plataformas internas?

Primero, diseñar la navegación sin modelar el trabajo. Si los usuarios pasan de una alarma a un mapa y después a un historial, separar esas vistas por estética puede romper una secuencia que necesitan mantener. La investigación de NN/g sobre flujos de trabajo recuerda que una acción puede condicionar las siguientes.

Segundo, confundir limpieza visual con eficiencia. Quitar columnas a una tabla puede ocultar las variables con las que se decide. Prefiero acordar qué datos necesita cada rol y qué puede aparecer bajo demanda.

Tercero, diseñar solo el camino feliz. Deben existir respuestas para ausencia de datos, permisos insuficientes, errores de carga, estados inconsistentes y acciones que no pueden completarse.

Cuarto, no establecer una línea base. Un antes y después visual muestra un cambio de diseño. Para demostrar desempeño hacen falta tareas y mediciones comparables, no una impresión sobre cuál pantalla se ve mejor.

Quinto, entregar componentes sin reglas. Un botón reutilizable no resuelve qué hacer con una alerta crítica o cuándo permitir una acción irreversible. La reutilización necesita comportamiento, semántica y restricciones documentadas.

¿Cuándo no necesitas un especialista en productos complejos?

No todo encargo B2B exige una intervención profunda. Si necesitas corregir una inconsistencia tipográfica, construir una página comercial o aplicar componentes ya definidos, un diseñador de interfaz con buen criterio puede resolverlo. Tampoco tiene sentido iniciar una arquitectura completa si todavía no conoces las tareas y los usuarios del producto.

Sí buscaría experiencia específica cuando varias personas trabajan sobre los mismos datos, hay autorizaciones distintas, decisiones difíciles de revertir, integraciones, tareas intensivas o una plataforma que creció sin patrones comunes. En ese escenario, el costo no suele estar únicamente en cómo se ve el software: está en las reglas que nadie explicó antes de construir.

¿Qué preguntas frecuentes aparecen sobre diseño de producto B2B?

¿Qué diferencia hay entre UX B2B y UX B2C?

En ambos casos se diseñan tareas para personas. En software B2B empresarial, además, suelen intervenir objetivos organizacionales, múltiples roles, procesos compartidos y restricciones operativas. No asumiría que todos los productos B2B son complejos ni que todas las aplicaciones de consumo son simples.

¿Cómo saber si mi software necesita un rediseño profundo?

Revisa si la dificultad aparece en una pantalla concreta o si atraviesa permisos, navegación, estados, datos y varios módulos. Si cada mejora local genera inconsistencias nuevas, probablemente necesites modelar primero el sistema.

¿Qué debe mostrar un buen portafolio UX empresarial?

El contexto, el problema, las restricciones, el modelo de funcionamiento, decisiones alternativas, prototipos y colaboración con ingeniería. Si incluye resultados, debe indicar qué se midió y cómo. Las imágenes finales son evidencia del diseño, no de su efectividad.

¿Cuándo conviene crear un sistema de diseño B2B?

Cuando aparecen patrones repetidos que varios módulos o equipos necesitan mantener de forma consistente. Puede empezar con un conjunto acotado de componentes y tokens; su tamaño debe responder a la necesidad real de reutilización, no a una plantilla prefabricada.

¿Es mejor una interfaz con menos clics y menos datos?

No necesariamente. Para un operador experto, una tabla bien organizada o una confirmación adicional puede facilitar una tarea o evitar una acción equivocada. Mide la comprensión, los errores y la finalización de la tarea, no solo el número de clics.

¿Qué hacer si tu plataforma B2B ya se volvió difícil de usar?

Antes de contratar un rediseño visual, identifica qué parte del sistema concentra la dificultad, quiénes la enfrentan y qué necesita validar ingeniería. Empieza por un workflow crítico, no por una promesa de transformar toda la plataforma.

En mi servicio de Complex Product Design trabajo precisamente esa secuencia: modelo roles, reglas y datos; simplifico flujos críticos; y entrego componentes y especificaciones reutilizables. Si lideras un SaaS o una plataforma empresarial y necesitas decidir qué rediseñar primero, podemos revisar juntos el alcance del problema.

Volver al blog