“Necesitamos un portal de clientes” parece una solicitud funcional, pero suele describir un servicio que conecta clientes, empleados, documentos, mensajes, identidad y soporte. La pantalla de ingreso es la parte visible más pequeña. Las decisiones difíciles determinan quién actúa por quién, qué registro tiene autoridad, qué ocurre al cambiar el acceso, cómo se recupera una cuenta y qué trabajo permanece en correo o teléfono. Esta guía convierte la idea en un plan que operaciones, seguridad, privacidad, accesibilidad y atención pueden revisar antes de desarrollar el flujo equivocado.
La idea principalPlanifique un portal como servicio completo: usuarios y recorridos reales, permisos por objeto, identidad proporcional, documentos gobernados, estados confiables, tareas accesibles y operación sostenible. El ingreso solo sirve cuando la empresa explica quién puede hacer qué, con cuál registro y qué sucede cuando falla lo normal.
Mapee usuarios, objetivos y el recorrido fuera del portal
Enumere grupos reales y las tareas de cada uno. “Cliente” puede ser un comprador individual, un asistente en nombre de un ejecutivo, varios contactos de una empresa, un cuidador o un antiguo cliente que todavía necesita registros. Entre los usuarios internos están el personal de servicio, finanzas, gerencia, soporte y administración. Entreviste representantes y observe el proceso actual para que el portal responda a necesidades, no a departamentos o tablas de datos que ya existen.
Siga cada recorrido desde el hecho que lo inicia hasta la evidencia que lo termina. Una solicitud de documento puede comenzar en el sistema de casos, llegar mediante una notificación, requerir carga y revisión, volver para corregirse y cerrarse tras la aprobación interna. Incluya llamadas, correo postal, reuniones y adaptaciones de accesibilidad. El Digital Services Playbook insiste en la experiencia completa porque un portal elegante no arregla una carta confusa, soporte inalcanzable o un proceso interno que nunca actualiza el estado.
Decida qué no hará la primera versión. Quizá el cliente vea facturas sin pagarlas, cargue archivos sin editar el caso o envíe mensajes sin esperar chat inmediato. Declare esos límites en el alcance y ante el usuario. La ambigüedad puede hacer que alguien suponga que enviar un mensaje detiene un plazo o que editar su perfil actualiza cada sistema. Cuando una acción tenga consecuencias legales, financieras u operativas, explique el canal autorizado y la confirmación necesaria.
- Grupos externos e internos, incluidos delegados y antiguos clientes
- Recorridos completos entre puntos digitales y no digitales
- Evidencia que demuestra el cierre de cada tarea importante
- Límites iniciales y canales alternativos con autoridad
Diseñe permisos desde relaciones y acciones concretas
Prepare una matriz antes de diseñar la navegación. Para cada rol especifique qué organización, cuenta, caso, persona, mensaje, factura o documento puede listar, ver, crear, cambiar, aprobar, descargar, compartir y borrar. Compruebe reglas sobre cada objeto, no solo la visibilidad del menú: ocultar Editar no impide una solicitud no autorizada al servicio subyacente. La orientación de OWASP diferencia autorización a nivel de objeto, propiedad y función, y todas necesitan verificación.
Modele relaciones que cambian. Un consultor atiende varias organizaciones; un empleado cambia de área; la autoridad de un tutor vence; una persona cubre casos temporalmente. Defina quién concede y retira acceso, qué evidencia necesita, cuándo vence y si otra persona aprueba cambios sensibles. Evite un único rol de “administrador” cuando responsabilidades más estrechas reducen acceso accidental y facilitan decisiones de soporte.
Escriba escenarios de abuso y error junto con los normales. ¿Qué sucede si alguien adivina otro identificador, abre un enlace antiguo, carga al caso equivocado o conserva la sesión después de salir de una empresa? ¿Qué puede ver el personal de soporte al ayudar? Decida qué acciones exigen autenticación reciente, confirmación, aviso o segundo aprobador. Ajuste los controles al riesgo; demasiada fricción puede empujar al usuario hacia soluciones menos controladas por correo.
- Ver, crear, cambiar, aprobar, descargar, compartir y borrar por rol
- Relación con organización y registro comprobada en cada acción
- Procesos de concesión, revisión, delegación, vencimiento y retiro
- Casos de abuso, acceso antiguo, soporte y errores humanos
Planifique identidad, ingreso, recuperación y soporte juntos
Determine cuánta confianza necesita el negocio en la identidad declarada y elija inscripción y autenticación proporcionales al daño posible. NIST SP 800-63-4 separa prueba de identidad, autenticación y federación, lo que evita tratarlas como un solo ajuste. Una biblioteca de bajo riesgo y un portal con registros sensibles pueden requerir evidencias, autenticadores, sesiones y recuperación diferentes. Solicite revisión especializada cuando exista regulación o una consecuencia grave.
Diseñe creación y recuperación antes del camino ideal. Decida quién invita, cuándo vence la invitación, qué ocurre al cambiar el correo, cómo se sustituye un autenticador perdido y cómo el personal de soporte verifica la identidad sin solicitar secretos. Un proceso de recuperación débil puede eludir un inicio de sesión robusto. Registre el acceso excepcional y avise cuando corresponda, pero no exponga datos sensibles por correo o mensaje solo porque esos canales transportan la alerta.
Haga que la autenticación sea accesible y comprensible. WCAG 2.2 incluye criterios de autenticación accesible y exige controles operables, instrucciones claras, errores identificables y comportamiento predecible. Permita gestores de contraseñas y pegar texto cuando sean compatibles con el nivel elegido, avise antes de que expire la sesión, conserve el trabajo recuperable y ofrezca ayuda humana a quien no complete el flujo estándar. Pruebe con teclado y tecnología asistiva; un análisis automático no basta.
- Identidad y autenticación proporcionales a la consecuencia real
- Invitación, vencimiento, cambio, recuperación y retiro de cuenta
- Verificación de soporte sin depender de recopilar secretos
- Ingreso, errores, tiempo y alternativas de recuperación accesibles
Dé a documentos y datos personales un ciclo explícito
Inventaríe cada clase que el portal recibe o muestra: perfil, contratos, estados, evidencia de identidad, archivos de proyecto, información médica o financiera, mensajes y actividad. Para cada una registre propósito, fuente, sistema autorizado, lectores, usos, intercambio, almacenamiento, retención, corrección, exportación y eliminación. El Privacy Framework de NIST ofrece una estructura de riesgo para gobernar el tratamiento de datos en vez de asumir que un aviso de privacidad resuelve todas esas decisiones.
Defina el comportamiento documental. Especifique tipos y tamaños permitidos, tratamiento de malware, versiones, nombres duplicados, vista previa, descarga, reemplazo, firma, vencimiento y estado. El usuario debe saber si “cargado” significa recibido, analizado, aceptado o aprobado. Conserve historial justificable cuando sea necesario, pero no retenga cada artefacto para siempre sin propósito. Decida cómo responder si un cliente carga información de otra persona o pide corregirla.
Reduzca copias y propiedad confusa. Enviar cada archivo por correo a varios empleados puede anular controles y retención del portal. Cuando el flujo lo permita, prefiera un aviso que lleve al autorizado hasta el registro controlado. Si un proveedor externo de almacenamiento, firma, analítica o mensajes procesa datos, documente qué cruza el límite, quién posee la cuenta, términos, eliminación, fallas y cambio de proveedor.
- Propósito, fuente, lectores, uso, intercambio y retención por clase
- Validación, análisis, versiones, estado y corrección de archivos
- Diferencia clara entre recepción, revisión, aceptación y aprobación
- Límites, propiedad, fallas y salida de cada tercero
Comunique estados confiables sin duplicar la verdad
Elija el sistema autorizado para casos, citas, facturas, documentos y preferencias. El portal puede mostrar o iniciar trabajo sin convertirse en la fuente autorizada de cada campo. Documente cuándo refresca información, cómo se ve un estado antiguo y cómo resuelve cambios en conflicto. Si el personal usa otro sistema, pruebe demoras y fallas para que el cliente no lea “completo” mientras la operación todavía muestra “en espera”.
Trate los avisos como invitaciones a actuar, no como registros. Defina evento, destinatario, canal, contenido seguro, momento, reintento, preferencias y destino de cada mensaje. Evite documentos confidenciales o detalles en el asunto del correo o pantalla bloqueada. Distinga acción obligatoria de noticias y ofrezca historial interno cuando la comunicación importe. Explique qué canales se monitorean y si responder a un correo automático llega al equipo.
Diseñe para mensajes perdidos y repetidos. Las direcciones rebotan, los teléfonos cambian, los filtros bloquean y los proveedores tardan. Muestre pendientes importantes dentro del portal, permita cambios de canal apropiados y dé al personal visibilidad de entrega sin mostrar ruido técnico. Para plazos o avisos de gran consecuencia, responsables comerciales y legales deben decidir si lo digital basta y qué alternativa se usa. “Entregado” por un proveedor no prueba lectura ni comprensión.
- Sistema autorizado y frescura esperada de cada estado visible
- Evento, público, contenido seguro, canal y destino del aviso
- Preferencias, rebotes, reintentos y respuestas monitoreadas
- Alternativa para plazos y comunicaciones de gran consecuencia
Especifique tareas accesibles, operación y despliegue controlado
Convierta recorridos en aceptación. Pruebe invitación, inicio de sesión recurrente, acceso delegado, carga, error, corrección, descarga, mensaje, sesión vencida, acceso retirado y recuperación. Incluya pantallas móviles estrechas, ampliación, teclado, foco visible, anuncios del lector de pantalla, etiquetas, resumen de errores y conservación de datos. WCAG es una base técnica, no prueba que el servicio tenga sentido; investigue usabilidad con personas representativas, incluidas personas con discapacidades.
Defina operación: monitoreo, respaldos y restauración, actualizaciones, revisión de auditoría, horario de soporte, escalamiento, incidentes, contenido y cambios en organizaciones. Decida qué eventos registrar y durante cuánto tiempo cumplen un propósito comercial, técnico o legal. Limite acceso a esos datos. OWASP ASVS ayuda a expresar controles comprobables, pero el negocio aún debe asignar responsables y decidir cómo un hallazgo se transforma en corrección.
Haga un piloto acotado con casos comunes y difíciles. Prepare migración, invitaciones, capacitación, guiones de soporte, comentarios, criterios de reversión y continuidad manual. Mida tareas terminadas, ayuda, errores, accesibilidad y excepciones, no solo cuentas activadas. Amplíe cuando el equipo demuestre que puede sostener el servicio. Un portal puede reducir parte del correo y las llamadas, pero crea responsabilidades permanentes de identidad, acceso, datos y soporte.
- Aceptación de éxito, errores, delegación, vencimiento y retiro
- Pruebas manuales de accesibilidad con usuarios representativos
- Responsables de monitoreo, recuperación, registros y soporte
- Piloto, continuidad, reversión, comentarios y criterios de expansión
