Kit UI de CRM para dashboards SaaS: contactos y estados

Un kit UI de CRM para dashboards SaaS debe ayudarte a construir una tarea completa de gestión de clientes: encontrar una ficha, comprender su contexto, editarla con seguridad y reconocer el resultado. Parte de esas tareas y adapta después navegación, tablas, campos y mensajes. Una portada de analítica bien resuelta aporta material visual, pero no demuestra que una persona pueda recuperarse de un guardado fallido.

Aplicaremos el kit a North Studio, un CRM ficticio para pequeñas empresas. La primera entrega incluye contactos, responsables de cuentas y una fecha de próximo seguimiento. Los ejemplos son decisiones de diseño propuestas, no funciones de un CRM existente. Sirven para preparar un prototipo acotado y descubrir qué partes de la biblioteca sostienen de verdad el trabajo previsto.

Mapear la tarea antes de elegir pantallas

Escribe una situación verosímil antes de revisar dashboards: «Encontrar un contacto asignado a mí, actualizar su empresa y programar el próximo seguimiento». Así cada componente tiene una función. El esquema inicial conecta una lista, una ficha y un formulario; los informes quedan fuera de esta primera prueba de aceptación.

En North Studio, la lista permite saber quién necesita atención. La ficha explica quién es esa persona y qué ocurrió recientemente. El formulario cambia campos acordados. La confirmación aclara qué se ha guardado y devuelve a un contexto útil. Dibuja esos destinos con contenido corriente antes de aplicar colores y tipografía. Si una pantalla no corresponde a una acción de la situación, aplázala hasta tener un motivo para construirla.

Define un vocabulario pequeño: Contacto, Empresa, Responsable, Último contacto y Próximo seguimiento. Aclara qué valores son obligatorios, cuáles pueden desconocerse y quién puede editarlos. «Sin seguimiento programado» debe significar algo distinto de «No se ha podido cargar la fecha». Esa diferencia será importante al componer los estados vacíos y los mensajes de la biblioteca.

Prepara una ficha de cobertura con cuatro columnas: tarea, superficie necesaria, componente disponible y comportamiento pendiente. Buscar requiere búsqueda y resultados; editar la empresa necesita un campo etiquetado; programar seguimiento exige una interacción de fecha; guardar necesita espera, éxito y fallo. Un componente reutilizable puede resolver solo una parte. Anota el hueco en lugar de dar por terminada la tarea porque la captura se parece al objetivo.

La guía de componentes para dashboards ofrece un punto de partida más amplio. Aquí la decisión es concreta: ¿permite este kit resolver la tarea del contacto con controles coherentes? Utiliza esa situación en la primera revisión del prototipo, en vez de comparar únicamente cuántas pantallas incluye cada biblioteca.

Adaptar el marco sin copiar sus métricas

El espécimen real de EmviUI que aparece debajo muestra barra lateral, búsqueda, tarjetas de resumen y zonas de gráficos. Ayuda a estudiar la estructura. Sus cifras son contenido de demostración: no definen informes de CRM, datos de producción ni resultados de negocio.

Utiliza el marco para acordar la jerarquía. Propón Contactos, Empresas y Seguimientos en la navegación y decide dónde estará la búsqueda. Un campo limitado a la lista de contactos debe explicitar su alcance; una búsqueda global necesita objetos consultables definidos y resultados distinguibles. Mantén esa diferencia en el prototipo aunque ambos controles compartan el mismo componente visual.

El catálogo actual de componentes de EmviUI ofrece referencias visuales para componer interfaces. EmviUI ayuda a partir de controles y estructuras de dashboard coherentes en Figma. Los registros de clientes, los permisos, la sincronización y el guardado efectivo requieren decisiones de producto e ingeniería. Un kit de Figma no equivale a un backend de CRM operativo.

Para la primera revisión, sustituye las muestras por registros sintéticos creíbles. Incluye una empresa con nombre largo, un responsable sin asignar y un seguimiento vencido. Define cada métrica propuesta en lenguaje claro: «Contactos con seguimiento para hoy» necesita una zona horaria y una regla para las tareas completadas. Si aún no existe ese acuerdo, prescinde de la tarjeta en este prototipo. Puedes evaluar el trabajo sin inventar precisión analítica.

Acota la adaptación de marca. Cambia colores aprobados, roles tipográficos y espaciado mediante la estructura que admita el kit; revisa después los controles afectados. La guía de UI kit y sistema de diseño aclara el alcance de los recursos y su mantenimiento. El prototipo necesita consistencia; la propiedad compartida y las políticas de publicación necesitan acuerdos explícitos del equipo.

Construir la lista alrededor de decisiones

Elige columnas según la decisión que debe facilitar la lista. Nuestro ejemplo comienza con Contacto, Empresa, Responsable y Próximo seguimiento. Una fila abre la ficha; un control identificado permite cambiar responsable. Especifica cada interacción por separado para que la fila no concentre varias acciones que compitan entre sí.

La documentación de tablas de Carbon distingue ordenación, selección y acciones sobre filas. Utiliza esa separación al revisar la cobertura del kit. Seleccionar un contacto y abrirlo son estados diferentes aunque ambos parezcan resaltados. El diagrama es un espécimen de lista de contactos, no una afirmación de que todos los CRM deban llevar esas columnas exactas.

Da sentido al orden inicial. En North Studio, ordenar por próximo seguimiento es una hipótesis razonable porque la tarea piloto busca atención para hoy. Muestra la ordenación activa y comprueba con usuarios si resulta útil. Al volver desde una ficha, búsqueda y filtros deberían conservar sus valores visibles según el contrato propuesto. Documenta esa continuidad para implementación; no presupongas que la biblioteca ya la ofrece.

Antes de añadir acciones en lote, especifica el alcance de la selección. ¿«Seleccionar todo» abarca la página, los resultados filtrados o todos los contactos? Explica el alcance y la cantidad antes de confirmar una reasignación. Limitarse a la página puede resultar más sencillo de explicar y validar en una primera entrega. Es una decisión ilustrativa, no una recomendación universal para cualquier volumen de datos.

Comprueba la composición con contenido verosímil. Un contacto puede no tener empresa, varias personas pueden compartir nombre y una cuenta puede ocupar mucho más que la muestra. Añade un dato identificativo cuando la ambigüedad importe. Decide cómo expresar los valores ausentes. Llenar todos los huecos con un guion no ayuda si nadie sabe si significa desconocido, inaccesible o no aplicable.

Distingue por último un filtro sin resultados, una lista vacía en el primer uso y una solicitud fallida. Cada situación permite una acción distinta: limpiar filtros, añadir contacto o volver a cargar. Revisa los tres estados junto a la lista con datos. Si el kit trae una ilustración de estado vacío, adapta su mensaje a la causa en vez de repetir «No hay nada» para condiciones diferentes.

Diseñar una edición que permita recuperarse

Una ficha útil conserva la identidad mientras deja cambiar campos acotados. En North Studio, editar empresa y seguimiento mantiene visible el nombre del contacto y presenta Guardar y Cancelar claramente. El historial de actividad queda fuera del grupo editable salvo que la tarea requiera modificarlo.

La guía de campos de texto de GOV.UK exige etiquetas y explica por qué un placeholder no puede sustituirlas. Usa nombres visibles para los campos y añade instrucciones cuando sean necesarias. «Empresa» sigue presente al escribir; un placeholder desaparece justo cuando hace falta revisar lo introducido. Trata las notas como contenido multilínea, en vez de encajarlas en un campo de una sola línea.

Define la validación desde las reglas reales del producto. En el ejemplo ficticio, programar seguimiento requiere una fecha; la empresa puede quedar vacía. Explica la corrección junto al campo correspondiente. La guía de resumen de errores de GOV.UK combina un resumen enlazado con mensajes locales y gestión de foco. Es un patrón concreto para evaluar, no una obligación de copiar el contenido de un servicio público en cualquier CRM.

Conserva lo escrito si falla el guardado. Prepara un espécimen de error con el cambio intentado, una explicación útil y una opción de reintento. Distingue además validación incorrecta, problema de conexión y cambio de permisos. Las salidas propuestas difieren: corregir el valor, reintentar cuando vuelva el servicio o comprender que la edición ya no está disponible.

Acordad qué hace Cancelar antes de enlazar el prototipo. Si no hay cambios, puede volver a la ficha. Si existen cambios sin guardar, decidid si se pide confirmación antes de descartarlos. Anota el comportamiento elegido y prepara un caso de revisión. No añadas un diálogo automáticamente a cada acción: aquí su propósito sería proteger una modificación relevante que aún no se ha guardado.

Revisa con ingeniería una edición concurrente. Otro compañero puede cambiar el registro mientras el formulario está abierto. Detectar el conflicto depende de la implementación, pero la biblioteca necesita un lugar donde explicar el resultado y ofrecer un siguiente paso. El archivo de diseño no impone control de concurrencia. Sí permite entender la recuperación prevista antes de cerrar el contrato con el backend.

Cubrir mensajes y anchos estrechos

Revisa espera, confirmación y fallo para la misma tarea. Mantén visible la identidad del contacto para que el mensaje se asocie al registro correcto. La hoja de estados propuesta utiliza texto e indicadores discretos; un detalle verde por sí solo no explica qué ocurrió.

La guía WCAG sobre uso del color indica que el color no debe ser el único recurso visual para comunicar información. Acompaña la etapa comercial o el resultado con una etiqueta significativa. «Necesita seguimiento» debe entenderse sin interpretar un punto ámbar. La guía WCAG de mensajes de estado aborda la comunicación de actualizaciones a tecnologías de apoyo sin necesidad de mover siempre el foco. Especifica ese requisito junto al estado visual.

Para este prototipo, define una regla de espera: conservar lo introducido y evitar un envío duplicado accidental mientras el mismo guardado sigue en curso. Prueba después éxito y fallo con demoras realistas. Otro producto puede necesitar un comportamiento distinto, especialmente con trabajo sin conexión o actualizaciones optimistas. Documenta la regla; dibujar un botón desactivado no demuestra que esté implementada.

En un ancho estrecho, prioriza nombre del contacto, empresa y siguiente acción. Una lista de resúmenes compactos puede servir mejor a esta tarea que todas las columnas de escritorio. Mantén acceso a la ficha completa y muestra los controles que en escritorio dependen del hover. Si comparar columnas sigue siendo necesario, conserva un tratamiento apropiado de tabla y revisa esa tarea por separado.

La guía WCAG de Reflow explica la condición de 320 píxeles CSS y las excepciones para contenido que necesita disposición bidimensional. Prueba también la página y el formulario. Una excepción de tabla no justifica desplazar horizontalmente la navegación ni recortar Guardar. Consulta la guía de tablas adaptables cuando comparar datos sea el trabajo principal.

Prueba muestras de interfaz inglesas y españolas de forma independiente. «Next follow-up» y «Próximo seguimiento» deben caber en sus contenedores, igual que errores y confirmaciones. Utiliza textos creíbles al menor ancho admitido y comprueba la navegación por teclado en la implementación. Un frame ordenado de escritorio no establece ni usabilidad móvil ni orden accesible del foco.

Revisar el kit con un espécimen de aceptación

Termina con un espécimen trazable que conecte lista, ficha, edición y resultado. Las variantes de Figma permiten organizar configuraciones relacionadas de componentes. Nombra los estados para repetir la revisión, manteniendo comportamiento del prototipo e implementación como evidencias separadas.

Pide a una persona que encuentre un contacto asignado, abra su ficha, cambie la empresa, programe seguimiento y se recupere de un guardado fallido simulado. Observa dónde pierde el contexto o no puede anticipar una acción. Registra el problema contra el estado correspondiente, con resultado previsto y corrección propuesta. Es un plan práctico de evaluación, no una afirmación medida de que el kit mejora la finalización de tareas.

El handoff debe incluir datos sintéticos, reglas de campos, nombres de estados, decisiones de composición y preguntas abiertas. Referencia los componentes utilizados y señala las ampliaciones propias. Entrega casos de aceptación para continuidad de búsqueda, alcance de selección, entrada inválida, fallo de guardado y finalización en ancho estrecho. Una captura ayuda a explicar cada caso, pero también hace falta escribir el requisito de comportamiento.

1. Busca a Maya Chen con el filtro de responsable y comprueba que el alcance sea visible.
2. Abre la ficha y cambia la empresa sin perder la identidad del contacto.
3. Envía sin la fecha requerida; revisa corrección y valores conservados.
4. Simula un guardado fallido, reintenta y confirma el cambio previsto.
5. Repite en ancho estrecho con teclado y muestras de ambos idiomas.

Acepta el kit para esta tarea cuando el equipo pueda explicar el recorrido completo y sus recuperaciones con componentes coherentes. Si queda un hueco crucial, crea una ampliación deliberada o reduce la primera entrega. Esta conclusión resulta más operativa que declarar un kit «listo para CRM»: identifica el flujo evaluado y el trabajo pendiente para llevarlo a producción.