Superadmin: Configurable, AI-Assisted Eligibility For Workforce Programs
- Categoría
- Plataforma enterprise para programas Workforce
- Rol
- Senior Product Designer (Contractor)
- Cliente
- BuildWithin
- Año
- 2025
Resumen
- Problema
- La plataforma de BuildWithin estaba dividida en experiencias separadas para cada uno de sus seis roles, lo que sumaba complejidad de navegación y dificultaba escalar entre organizaciones.
- Solución
- Una plataforma enterprise unificada y configurable, con permisos por rol y flujos de elegibilidad configurables.
- Qué hice
- Lideré el diseño end-to-end de la experiencia administrativa durante seis meses, desde la arquitectura de producto hasta los componentes reutilizables y la validación de usabilidad.
- Resultado
- Una base de diseño unificada que sostiene múltiples organizaciones, seis roles de usuario y verificación de elegibilidad asistida por IA.
- SaaS Enterprise
- Workforce
- Permisos por rol
- Roles configurables
- Flujos configurables
- Verificación asistida por IA
- Design system
- Arquitectura UX
Impacto
Alcance y capacidades del producto.
Contexto
BuildWithin necesitaba evolucionar su plataforma de gestión de fuerza laboral para apoyar a organizaciones que administran programas de formación, oportunidades de empleo, elegibilidad de candidatos y avance de participantes.
La plataforma atendía a organizaciones con requisitos operativos distintos, incluidos programas de desarrollo de fuerza laboral regidos por los criterios de elegibilidad de WIOA.
También debía acomodar seis roles de usuario distintos (Super Admin, Organization Admin, Talent Manager, Case Manager, Employer y Staff interno), cada uno con responsabilidades y acceso a la información diferentes.
Cada rol tenía su propia experiencia de plataforma separada, y los Super Admins pasaban de una a otra mediante un selector en el sidebar. Quienes administraban varias organizaciones también debían moverse entre contextos organizacionales.
A medida que la plataforma crecía, este enfoque sumaba complejidad de navegación innecesaria y hacía cada vez más difícil escalar la experiencia.
Solución
Diseñé una experiencia enterprise unificada, construida en torno a flujos compartidos, permisos por rol y configuraciones organizacionales configurables.
En vez de crear experiencias de plataforma separadas para cada rol, la solución estableció una interfaz común donde el acceso a la información y a las funciones lo determinan los permisos.
Consolidé en una sola plataforma lo que antes eran seis experiencias separadas, cambié cómo se visualizan los permisos e hice los roles configurables, de modo que se puedan crear nuevos roles según las necesidades.
Los Super Admins podían acceder a la información de todos los roles sin cambiar repetidamente de interfaz, mientras que el resto de las personas veía solo la información y las acciones relevantes para sus responsabilidades.
La plataforma también incorporó flujos de elegibilidad configurables, verificación documental asistida por IA y componentes reutilizables que sostuvieron experiencias consistentes entre los módulos administrativos.
Mi aporte
Como Senior Product Designer, lideré el diseño end-to-end de la experiencia administrativa durante seis meses.
Mis responsabilidades incluyeron la arquitectura del producto, los user flows, las interacciones empresariales complejas, las interfaces de alta fidelidad, los componentes reutilizables, el prototipado y la validación de usabilidad.
Colaboré con la CEO de BuildWithin, Product Managers, Ingeniería, Customer Success y clientes para entender los requisitos operativos y traducirlos en experiencias de producto escalables.
Más allá de diseñar interfaces, cuestioné el enfoque multiplataforma propuesto y defendí una arquitectura unificada basada en permisos por rol.
Desafío
Sostener la complejidad sin multiplicar las interfaces
BuildWithin necesitaba acomodar distintas organizaciones, responsabilidades administrativas y requisitos regulatorios dentro del mismo producto.
La dirección inicial consideraba experiencias de plataforma separadas para los distintos roles.
Sin embargo, las personas administradoras a menudo necesitaban información que cruzaba esos límites. Un Super Admin, por ejemplo, necesitaba ver la misma información operativa disponible para los Case Managers y otros roles administrativos.
Al mismo tiempo, las organizaciones necesitaban configurar sus propios requisitos de elegibilidad, documentos y flujos sin depender de desarrollo a medida para cada variación.
El desafío era crear una experiencia lo bastante flexible para sostener estas diferencias y, a la vez, comprensible, consistente y escalable.
Proceso de diseño
Entender la plataforma existente y a sus usuarios
Empecé con un análisis en profundidad del producto existente junto a la CEO y los Product Managers.
Examinamos la navegación de la plataforma, los flujos administrativos y los problemas que introducía su modelo de cambio de rol.
Junto a Customer Success identificamos clientes para entrevistar y entender mejor cómo las organizaciones usaban la plataforma en su operación diaria.
Esas conversaciones se centraron en las tareas recurrentes, las necesidades de información, las responsabilidades y las dificultades que encontraban las personas administradoras al gestionar candidatos y programas.
De la investigación a la arquitectura del producto
Los hallazgos orientaron la exploración de una experiencia unificada, construida en torno a navegación compartida, permisos y flujos configurables.
Mapeé los recorridos administrativos, definí las jerarquías de información y exploré patrones de interacción para tareas complejas como la configuración de elegibilidad y la verificación de candidatos.
Con Figma desarrollé prototipos e interfaces de alta fidelidad, trabajando de forma iterativa con Producto e Ingeniería para resolver los requisitos técnicos y operativos.
Decisiones clave de diseño
01 — Una plataforma en vez de múltiples experiencias por rol
El desafío
La plataforma existente estaba dividida en experiencias separadas por rol, y los Super Admins pasaban de una a otra con un selector de avatar en el sidebar.
Esto generaba una complejidad de navegación innecesaria, sobre todo cuando las personas administradoras necesitaban información de varios roles u organizaciones.
La dirección inicial del producto consideraba mantener experiencias separadas para cada rol.
La decisión
Cuestioné este enfoque y propuse una plataforma unificada basada en acceso y permisos por rol.
En lugar de duplicar interfaces, la plataforma compartiría la misma estructura y los mismos flujos.
Los Super Admins tendrían visibilidad completa de las funciones administrativas, mientras que los demás roles tendrían acceso restringido a información y acciones específicas según sus responsabilidades.
También rediseñé cómo se visualizan los permisos e hice los roles configurables, de modo que se puedan crear nuevos roles según las necesidades.
Esto eliminó la necesidad de que los Super Admins cambiaran repetidamente de interfaz por rol para acceder a distintas partes de la plataforma.
Por qué importó
La decisión simplificó la experiencia administrativa y estableció una arquitectura de producto más escalable.
En vez de mantener múltiples interfaces con funcionalidad superpuesta, BuildWithin podía sostener distintas responsabilidades con un sistema compartido.
La complejidad de los permisos quedó dentro de la plataforma y no se convirtió en una carga de navegación para las personas usuarias.
02 — Hacer configurables los requisitos de elegibilidad
El desafío
Las organizaciones necesitaban definir requisitos de elegibilidad distintos según sus programas y obligaciones regulatorias.
En los flujos ligados a WIOA, esos requisitos podían incluir información personal, documentos de respaldo, condiciones de empleo y umbrales de ingreso del hogar.
No todos los documentos seguían las mismas reglas de validación. Algunos exigían revisar el vencimiento, y otros necesitaban períodos de vigencia configurables según cuándo se emitió el documento o cuándo ocurrió un evento determinado.
La primera versión del flujo asumió que una lista fija de documentos por categoría alcanzaba para todas las organizaciones. La UX research mostró que no: cada organización cliente aceptaba distintos documentos válidos por categoría y aplicaba sus propias reglas.
Un formulario fijo no habría podido acomodar estas diferencias.
La decisión
Diseñé una experiencia de elegibilidad configurable, organizada en tres áreas:
- Application Fields: permitía a las personas administradoras definir la información que debían entregar los candidatos.
- Required Documents: permitía a las organizaciones elegir la documentación aceptable por categoría y configurar requisitos por documento, incluidos períodos de vigencia como 30, 60 o 90 días.
- Income Eligibility Rules: admitía límites de ingreso del hogar configurables según el tamaño de la familia.
Para manejar las excepciones por documento, introduje controles de configuración contextuales que muestran ajustes adicionales solo cuando son relevantes.
Así, quienes administran podían gestionar distintas condiciones de elegibilidad sin recorrer un formulario innecesariamente complejo.
Por qué importó
Las organizaciones podían configurar sus requisitos de elegibilidad con una experiencia administrativa consistente, en vez de depender de interfaces distintas para cada tipo de documento.
El patrón de configuración se validó con pruebas de usabilidad, y la estructura de fondo siguió siendo lo bastante flexible para acomodar requisitos adicionales.
03 — Convertir la verificación de elegibilidad en un flujo accionable
El desafío
Los Case Managers necesitaban monitorear a los candidatos durante todo el proceso de elegibilidad, identificar solicitudes incompletas, revisar la documentación y determinar cuándo era necesario intervenir.
La elegibilidad no era simplemente un estado binario. Un candidato podía estar preparando su solicitud, esperando entregar documentos, preaprobado o requerir revisión adicional. El vencimiento de documentos y la información incompleta agregaban más complejidad.
Un único indicador de elegibilidad no daba contexto suficiente para manejar estas situaciones.
La decisión
Diseñé una experiencia de revisión progresiva que conecta las tablas de gestión de candidatos, los estados de elegibilidad y la verificación a nivel de documento.
La tabla principal de candidatos mostraba badges de elegibilidad, para que los Case Managers entendieran el avance de cada solicitud sin abrir cada ficha.
Cada estado comunicaba una situación y una posible acción distintas:
- Not Started: identificar candidatos que no habían comenzado el proceso de elegibilidad.
- In Progress: monitorear solicitudes incompletas e identificar candidatos que podrían necesitar ayuda.
- Pre-approved: identificar solicitudes listas para revisión y aprobación humana.
- Needs Review: destacar información o documentos que requieren verificación adicional.
- Ineligible / Expired: identificar casos en que documentación antes válida había vencido y requería renovación.
Al seleccionar un candidato se abría una vista previa detallada con información resumida y una sección de Elegibilidad.
En esa sección, categorías de elegibilidad desplegables mostraban cada requisito de verificación, indicadores de avance y los documentos de respaldo.
Los Case Managers podían inspeccionar los archivos subidos y revisar la información usada para evaluar cada requisito.
La experiencia también incorporó procesamiento de documentos asistido por IA para extraer información relevante y completar los registros de los candidatos.
Por qué importó
El diseño conectó la verificación automatizada con la decisión humana.
En lugar de presentar la elegibilidad como un resultado aislado, la interfaz ayudó a los Case Managers a entender el avance de cada solicitud, identificar excepciones y tomar la acción adecuada.
El objetivo era hacer más transparentes y manejables los flujos de verificación complejos, sin quitar la supervisión humana.
04 — Construir consistencia con patrones de diseño reutilizables
El desafío
La plataforma debía sostener distintos flujos administrativos manteniendo la consistencia entre módulos y roles.
Algunas interacciones, como tablas de datos, navegación, formularios y tarjetas de resumen, podían reutilizarse en todo el producto. Otras, en particular la verificación de documentos y la configuración de elegibilidad, requerían componentes especializados.
La decisión
Usé shadcn/ui como base de un sistema de componentes compartido y lo extendí con patrones a la medida de los requisitos enterprise de BuildWithin.
Los componentes reutilizables sostenían interacciones comunes como gestión de datos, navegación, comunicación de estados y resúmenes de información.
Para los flujos de elegibilidad diseñé componentes especializados para vistas previas de documentos, estados de verificación, requisitos configurables y resúmenes de elegibilidad de candidatos.
Estos componentes seguían principios de interacción y visuales compartidos, y a la vez acomodaban la complejidad específica de los flujos regulados.
Por qué importó
El design system dio consistencia a las experiencias administrativas sin obligar a que cada flujo usara componentes genéricos.
Sostuvo una plataforma más coherente y permitió que la funcionalidad especializada evolucionara dentro de un lenguaje de diseño compartido.
Validación e iteración
Combiné pruebas de usabilidad, entrevistas con clientes, revisiones con stakeholders y prototipado iterativo para evaluar la experiencia administrativa.
Las pruebas en Maze ayudaron a validar la interfaz de configuración de elegibilidad y confirmaron que el patrón de interacción inicial se entendía sin requerir cambios importantes por usabilidad.
Una iteración importante surgió después del primer diseño del MVP, cuando el Product Manager y la organización involucrada identificaron requisitos adicionales para la elegibilidad por ingreso del hogar.
La interfaz debía acomodar límites de ingreso configurables según el tamaño de la familia y darle más protagonismo a esta información dentro de la revisión de elegibilidad.
Ajusté la jerarquía de la información y reorganicé cómo se presentaban los requisitos de ingreso, los documentos de respaldo y los estados de verificación.
Esto dejó clara una distinción importante: no toda iteración de diseño nace de un problema de usabilidad. Algunas surgen porque el producto debe acomodar nuevos requisitos operativos sin perder la coherencia de la experiencia.
Resultado y aprendizajes
El proyecto estableció una base de diseño unificada para la plataforma de administración enterprise de BuildWithin, que sostiene múltiples contextos organizacionales, seis roles de usuario y flujos complejos de gestión de fuerza laboral.
La experiencia reunió permisos por rol, requisitos de elegibilidad configurables, verificación documental asistida por IA y patrones de diseño reutilizables.
Aprendizajes
El aporte más importante fue cuestionar el supuesto de que distintos roles de usuario requerían distintas experiencias de plataforma.
Al diseñar en torno a flujos compartidos y acceso controlado a la información, ayudé a establecer un enfoque más escalable para la arquitectura de producto enterprise.
El proyecto también reforzó la importancia de hacer comprensibles los sistemas operativos complejos sin simplificar de más sus requisitos de fondo.
El gran diseño enterprise no consiste en quitar la complejidad, sino en organizarla para que las personas se concentren en sus responsabilidades en vez de navegar el sistema.
Más funcionalidades
Pathways: seguimiento de aprendizaje ligado a horas, tareas y competencias por programa estatal
Un Pathway es el programa de aprendizaje que una organización arma para sus participantes — por ejemplo, un pathway de Product Designer dentro del área de Customer Service. No es un plan de estudios interno cualquiera: cada pathway tiene que responder a un programa estatal que exige cumplir ciertos objetivos (horas, módulos, competencias específicas), así que diseñé el módulo para que cada organización configure su propio pathway según esos requisitos, en vez de forzar una plantilla única.
Candidate 360°: toda la información del candidato en una sola vista, con matching explicable
Antes de este rediseño, la información de un candidato vivía repartida en pantallas sueltas — documentos por un lado, aplicaciones por otro, notas en otro sistema. Diseñé Candidate 360° como el registro único de cada candidato: Overview (con sus documentos de elegibilidad), Notes, Activity, los datos de contacto y un resumen en formato tarjeta, Explore Matching, Applications, Pathways y Documents, todo dentro del mismo perfil, sin saltar entre pantallas.
Herramientas
FigmaPrototipos e interfaces de alta fidelidad
MazePruebas de usabilidad de la configuración de elegibilidad- shadcn/uiBase del sistema de componentes compartido
Más proyectos
Ver más proyectosA Conversational AI Agent To Find Jobs
Agente de IA para empleo y capacitación · 2025
Buildwithin — Candidate Portal
Portal de candidatos Workforce con IA · 2025
Altafid Platform
Plataforma white-label de gestión patrimonial (TAMP) · 2022
Risk Assessment - Altafid Platform
Evaluación de riesgo y cumplimiento · 2023
Custom Client Portal - Altafid Platform
Portales de cliente white-label · 2022
Investment Marketplace - Altafid Platform
Marketplace de modelos de inversión · 2022
Calendar - Altafid Platform
Calendario y agenda · 2022
Design System - Altafid Platform
Design System white-label · 2023A Conversational AI Agent To Find Jobs
Agente de IA para empleo y capacitación · 2025Buildwithin — Candidate Portal
Portal de candidatos Workforce con IA · 2025Altafid Platform
Plataforma white-label de gestión patrimonial (TAMP) · 2022Risk Assessment - Altafid Platform
Evaluación de riesgo y cumplimiento · 2023Custom Client Portal - Altafid Platform
Portales de cliente white-label · 2022Investment Marketplace - Altafid Platform
Marketplace de modelos de inversión · 2022Calendar - Altafid Platform
Calendario y agenda · 2022