Mariana Ovejero
Diseño de producto y sistemas
Lleva la documentación de tokens, variantes y estados. Antes trabajó seis años en equipos internos de banca, donde aprendió a escribir reglas de uso que sobreviven al cambio de sprint.
No empezamos con una agencia ni con un equipo grande. Empezamos con cuadernos de bocetos, capturas de pantallas rotas y la costumbre de anotar por qué una jerarquía visual no funcionaba. Estos son los tramos que marcaron el rumbo.
2019
Tres flujos de onboarding armados para un estudio chico de Buenos Aires. Todavía no había catálogo: cada maqueta se entregaba como archivo aislado y el cliente la abría sin contexto. Ahí apareció la idea de documentar decisiones, no solo pantallas.
2021
Sumamos dashboards y tableros de datos al repertorio. Cada pieza empezó a incluir notas de accesibilidad, estados vacíos y variantes de error. La regla fue simple: si una interfaz no se puede recorrer con teclado, no entra al catálogo.
2022
Un marketplace de servicios nos pidió ordenar botones, campos y tarjetas que cada sprint resolvía distinto. Salimos con tokens de color, espaciado y tipografía, más estados de foco y deshabilitado. Fue el primer sistema pensado para que lo lea alguien nuevo en el equipo.
2023
Empezamos a trabajar con equipos de producto de Tucumán, Córdoba y Montevideo que querían ver el comportamiento de una interfaz antes de invertir en desarrollo. Acortamos las revisiones a sesiones de una hora con foco en flujos concretos.
2024
Freelancers y estudios chicos empezaron a pedir el catálogo completo para mostrar su propio trabajo sin armar un sitio desde cero. Consolidamos el formato: maqueta funcional, capturas de proceso y notas de rendimiento en una misma pieza.
Quiénes sostienen el estudio
Tab Navigator empezó como un archivo compartido entre dos personas que armaban maquetas para equipos de producto en Buenos Aires. Hoy somos cuatro, seguimos trabajando en el mismo formato: cada pieza del catálogo pasa por revisión cruzada antes de publicarse, y las decisiones de jerarquía visual quedan anotadas junto al archivo.
No tercerizamos la documentación ni el armado de tokens. Si un flujo de onboarding no se puede recorrer de punta a punta, no entra al portafolio.
Diseño de producto y sistemas
Lleva la documentación de tokens, variantes y estados. Antes trabajó seis años en equipos internos de banca, donde aprendió a escribir reglas de uso que sobreviven al cambio de sprint.
Interacción y prototipos navegables
Arma los flujos que se pueden recorrer: alta de usuario, checkout, tableros con datos en vivo. Se obsesiona con los estados de error y con que el foco sea visible en cada componente.
Accesibilidad y contenido
Revisa contraste, tamaño de área táctil y orden de lectura. También escribe las notas de proceso que acompañan cada caso, para que se entienda por qué una pantalla quedó así y no de otra forma.
Front-end y rendimiento
Traduce las maquetas a componentes reales cuando el cliente quiere medir peso y tiempos de carga. Su criterio: si una interfaz no se sostiene en una conexión mediocre, todavía no está lista.
2019
Primer portafolio navegable publicado para un estudio de la región.
4 personas
Equipo estable, sin intermediarios entre quien diseña y quien documenta.
3 revisiones
Cada pieza del catálogo pasa por revisión de interacción, accesibilidad y contenido antes de salir.
Tab Navigator no nació como estudio. Empezó como una carpeta compartida entre dos diseñadores que se cansaron de explicar lo mismo en cada reunión: cómo se comporta una interfaz cuando el usuario la toca.
Un cliente de servicios profesionales pidió ver el alta de usuario antes de contratar desarrollo. Armamos el flujo en cuatro pantallas con estados de error reales. Fue la primera pieza que dejó de ser un mockup y empezó a comportarse como producto.
Dejamos de vender "pantallas sueltas". Cada caso pasó a documentarse con decisiones de jerarquía visual, notas de accesibilidad y capturas del proceso. Onboarding, dashboards y checkout quedaron como categorías con criterio propio.
Un marketplace que crecía cada sprint nos pidió reglas, no pantallas. Ahí aparecieron los tokens, las variantes y los estados. La documentación tenía que servirle a alguien que se sumaba al equipo sin preguntar.
Seguimos con base en Buenos Aires y clientes de Argentina, Chile y Uruguay. La mayoría llega con la misma pregunta: cómo se ve esto funcionando antes de invertir en desarrollo. La respuesta sigue siendo la misma carpeta, ahora mucho más ordenada.