Estándares transversales de PDP Suite

Estándares transversales de PDP Suite

Estas reglas aplican a todos los módulos de la plataforma, salvo que el archivo de un módulo específico indique explícitamente una excepción. Cuando un módulo no menciona uno de estos puntos, se asume que sigue el estándar general aquí descrito.

Por qué existen estos estándares

PDP Suite es una herramienta de cumplimiento legal, no una aplicación de consumo masivo. Sus usuarios — DPOs, administradores, auditores y responsables de tratamiento — trabajan con datos que tienen consecuencias legales reales. Cada decisión de diseño debe transmitir seriedad, coherencia y confianza: una interfaz inconsistente o confusa en una herramienta de compliance no es solo un problema estético, es un riesgo operativo.

Estos estándares no son restricciones arbitrarias. Son decisiones tomadas para que la suite se comporte como un sistema predecible y profesional, donde el usuario sabe qué esperar en cada pantalla, puede enfocarse en el contenido y no en descifrar la interfaz.

Nomenclatura de títulos de módulo

El título de cada módulo no incluye el prefijo “Gestión” (por ejemplo: “Formularios”, no “Gestión de Formularios”; “Consentimientos”, no “Gestión de consentimientos”). Solo la primera letra del título va en mayúscula; el resto sigue las reglas normales de capitalización del español.

El prefijo “Gestión” es redundante — todos los módulos de la suite gestionan algo. Eliminarlo produce títulos más limpios y directos, coherentes con la terminología que usa el propio usuario al referirse a los módulos en el día a día.

Encabezados y descripciones de vista

Los encabezados de sección no llevan subtítulos descriptivos adicionales debajo. Si se requiere una descripción del módulo o vista, se implementa como texto plano debajo del título, nunca dentro de un componente banner.

Un encabezado limpio comunica jerarquía y permite al usuario orientarse rápidamente. Los subtítulos descriptivos bajo el título principal generan ruido visual y compiten con el contenido que el usuario realmente necesita atender.

Componentes banner

El componente banner (fondo de color, ícono informativo) está reservado exclusivamente para mensajes contextuales o temporales vinculados a una acción o estado del sistema — por ejemplo, una advertencia antes de publicar, o una notificación de que un consentimiento debe republicarse. No se usa para contenido estático permanente ni como texto informativo de uso general. Los textos informativos en color azul dentro del área de contenido de una vista o tabla deben eliminarse cuando no cumplen esta función.

El banner llama la atención del usuario precisamente porque es excepcional. Si se usa para contenido permanente pierde ese poder: el usuario aprende a ignorarlo, y cuando aparece un mensaje importante que sí requiere atención, pasa desapercibido.

Barra de filtros

El filtrado se aplica en tiempo real al escribir o seleccionar (eventos onChange / onInput), sin requerir un botón de confirmación para ejecutar la búsqueda. El campo de búsqueda por texto no muestra ícono de lupa, ya que no es una acción que el usuario deba disparar manualmente.

La única acción adicional permitida en la barra de filtros es el botón para limpiar/restablecer los filtros aplicados (el label puede variar según el módulo, por ejemplo “Limpiar filtros” o “Restablecer”, pero la función es la misma).

Los filtros disponibles deben adaptarse al contexto específico de cada vista o tab; no se reutiliza un mismo set de filtros genérico en vistas con datos distintos.

El placeholder del campo de búsqueda debe reflejar con precisión los criterios reales por los que filtra (por ejemplo, “Buscar por nombre, tipo o política” en lugar de un texto genérico como “Buscar”).

En una herramienta de compliance el usuario frecuentemente necesita verificar si un registro existe, encontrar un RAT específico o confirmar el estado de un consentimiento. El filtrado en tiempo real elimina fricción innecesaria. Un botón “Buscar” o “Ir” que el usuario debe recordar presionar añade un paso que no aporta valor y puede generar confusión cuando los resultados no se actualizan.

Tablas de listado

Las tablas no incluyen botón “Actualizar” ni acción “Refrescar”; no es un patrón estándar de la suite para este componente.

Las tablas no incluyen un buscador propio dentro de su área de contenido; toda búsqueda se realiza desde la barra de filtros superior de la vista.

Las cabeceras de columna son únicamente texto, sin íconos.

Tener un único punto de búsqueda por vista elimina ambigüedad: el usuario no tiene que decidir dónde buscar. Los íconos en las cabeceras de columna no aportan información adicional y añaden ruido visual en un contexto donde la densidad de datos ya es alta.

Columna de Acciones

La columna de acciones por fila expone únicamente los controles estándar correspondientes al contexto (típicamente Ver, Editar y Eliminar, aunque algunos módulos pueden tener acciones adicionales específicas, como “Ver riesgos” y “Mapa de calor” en RAT). Cada ícono de acción debe mostrar un tooltip descriptivo (texto corto que indique la acción) al pasar el cursor (hover), sin atajos de teclado (shortcuts) asociados. Cuando existen tres o más acciones, se agrupan bajo un único encabezado de columna llamado “Acciones”.

Hacer clic en una fila completa de la tabla no debe ejecutar ninguna acción por sí solo (como abrir el detalle); las acciones deben dispararse únicamente desde los botones/íconos de la columna de Acciones.

En una herramienta que gestiona datos con consecuencias legales, el usuario debe ser intencional con cada acción. Un clic accidental en una fila que abre un registro o inicia un flujo es un riesgo de operación involuntaria. Las acciones explícitas, claramente identificadas y con tooltips, reducen errores y hacen la interfaz más segura para usuarios que trabajan con volúmenes altos de registros.

Identificadores técnicos

Los identificadores técnicos internos (UUID, hash, ID técnico) no se exponen visualmente en la interfaz de usuario. Cuando el usuario necesita identificar un registro o versión, se usa un valor legible (por ejemplo, un número correlativo) en lugar del identificador técnico.

Un UUID no comunica nada al usuario humano — no puede memorizarlo, compararlo ni mencionarlo en una conversación. Exponer identificadores técnicos genera confusión y puede revelar información sobre la arquitectura interna del sistema sin ningún beneficio para el usuario. En contextos de auditoría, donde el usuario debe poder referirse a versiones o registros específicos, un número correlativo claro (v1, v2, v14) cumple esa función mucho mejor.

Patrón de campos de formulario

El patrón de campos es vertical: el label se ubica arriba y el input debajo (no horizontal con label a la izquierda).

El layout vertical es más legible en formularios con múltiples campos, especialmente en pantallas de contenido denso como las que tiene esta suite. El label sobre el input reduce el tiempo de lectura y es más accesible para distintos tamaños de pantalla.

Botones primarios

Los botones primarios de creación usan el verbo “Crear” como prefijo de acción (por ejemplo, “Crear formulario”) y no incluyen íconos.

Los botones que agregan un nuevo elemento dentro de un contexto que ya es de creación no deben repetir el nombre del elemento que se está agregando (por ejemplo, dentro de un formulario de creación, el botón debe decir simplemente “Crear”, no “Crear X”).

El verbo “Crear” es explícito y unívoco: el usuario sabe exactamente qué va a pasar. Verbos alternativos como “Agregar”, “Añadir”, “Nuevo” o “Ingresar” generan inconsistencia entre módulos y obligan al usuario a interpretar si la acción es la misma. La consistencia en el vocabulario reduce la carga cognitiva en una herramienta con muchos módulos y flujos distintos.

Wizards (flujos de creación/edición en pasos)

Los wizards no tienen una barra de botones fija en la parte inferior de la pantalla; los controles de navegación y guardado (Volver, Siguiente, Guardar) se ubican en el header del wizard. El botón “Volver” es solo texto, sin ícono, ubicado a la izquierda de “Siguiente”/“Guardar”.

Los pasos de un stepper se muestran con un número de paso y el texto del nombre del paso, sin íconos adicionales junto al label.

Ubicar los controles en el header mantiene el área de contenido del wizard libre para los campos del formulario, evitando que una barra fija inferior compita visualmente con el contenido y reduzca el espacio útil de la pantalla. El stepper con número y texto es suficiente para orientar al usuario sin agregar complejidad visual innecesaria.

Vistas de versionado e historial

El versionamiento de registros no es un comportamiento universal de la suite: cada módulo define si mantiene o no versiones de sus registros, según su propia lógica de negocio. Por ejemplo, el módulo Formularios no tiene versionamiento (se eliminó por decisión de producto), mientras que el módulo RAT sí lo mantiene. Para saber si un módulo específico tiene versionamiento, consultar su archivo correspondiente; no asumir un comportamiento por defecto.

Cuando un módulo sí mantiene versiones publicadas de un registro, aplica esta regla: no se permite la coexistencia de más de una versión en estado “publicada” al mismo tiempo. Al publicar una nueva versión, la anterior cambia automáticamente a un estado de archivado/histórico, y no se permiten acciones de modificación o eliminación sobre versiones ya publicadas.

El versionamiento no es burocracia — es un requisito de auditoría legal. Cuando un DPO o un regulador necesita saber cómo estaba configurado un tratamiento de datos hace seis meses, debe poder acceder a esa información de forma confiable e inmutable. Por eso no todo módulo versiona: solo aquellos cuyos registros tienen valor probatorio en el tiempo (como el RAT o los consentimientos) necesitan ese historial. Aplicar versionamiento donde no tiene sentido legal añade complejidad sin beneficio.

Validación de formularios

Todos los campos marcados como obligatorios deben validarse antes de permitir avanzar o guardar; no deben quedar exceptuados de la validación campos específicos mientras otros sí se validan.

Un registro incompleto en una herramienta de compliance no es solo un dato faltante — puede ser una obligación legal sin cumplir. La validación consistente protege al usuario de crear registros inválidos y a la organización de tener documentación incompleta ante una auditoría.

Funcionalidades técnicas no orientadas al usuario final

No se exponen al usuario final estructuras o flujos técnicos de back-office (por ejemplo, edición de JSON crudo para cargas masivas) cuando existe una interfaz de carga equivalente más simple e intuitiva.

Los usuarios de la suite son profesionales de compliance, no desarrolladores. Exponer complejidad técnica innecesaria no solo dificulta el uso — puede introducir errores difíciles de detectar en registros que tienen consecuencias legales.

Idioma de la interfaz

Todo el contenido visible para el usuario (incluyendo tooltips, mensajes emergentes y textos de ayuda) debe estar en español. No deben quedar textos en inglés en ninguna parte de la interfaz.

PDP Suite opera en el contexto de la legislación chilena (Ley 21.719) y su público objetivo son organizaciones y profesionales que trabajan en español. La terminología jurídica y regulatoria tiene matices específicos en español que no se traducen literalmente del inglés. Mezclar idiomas en una herramienta de cumplimiento genera confusión y puede comprometer la precisión de los registros — especialmente en campos con implicancias legales.

Celdas sin valor en tablas

Cuando una celda de una tabla no tiene valor para mostrar, debe presentarse con un guión ”—” en lugar de quedar vacía sin ningún indicador, para comunicar explícitamente la ausencia de contenido.

Una celda vacía es ambigua: el usuario no sabe si el dato no existe, no fue cargado, o hay un error de visualización. En una herramienta de compliance donde la ausencia de un dato puede ser tan significativa como su presencia, el guión comunica explícitamente “este campo no tiene valor” — una distinción importante para quien audita o revisa registros.

Configuraciones normativas o paramétricas con datos asociados

Cuando una configuración, versión o parámetro ya tiene registros o evaluaciones asociadas que dependen de sus valores (por ejemplo, una versión de configuración normativa ya usada en evaluaciones), el sistema debe bloquear su edición directa y exigir la creación de una nueva versión o configuración, en lugar de permitir modificar valores que ya están en uso.

Este patrón protege la integridad de los registros históricos. Si los criterios con los que se evaluó algo pueden modificarse retroactivamente, la auditoría pierde validez: ya no es posible saber bajo qué condiciones se tomaron las decisiones pasadas. El bloqueo y la exigencia de crear una nueva versión garantizan que cada evaluación siempre pueda trazarse a los criterios vigentes en el momento en que se realizó.