De un vistazo
Rol. Product Designer, única diseñadora. De julio de 2024 a mayo de 2026, en remoto. Colaboradora freelance desde 2019.
Equipo. Seis desarrolladores (mobile, full-stack, frontend), product managers, atención al cliente, ventas y el CTO.
Alcance. Lector, panel de editoriales, checkout, login, tablas de suscripción, emails, banners para clientes, varias versiones del sitio web y una plataforma interna de prototipos.
Stack con el que trabajé. Figma para diseño; Laravel, Livewire, Flux UI y Tailwind para los prototipos, el mismo stack con el que el equipo de desarrollo publicaba.
El problema
Publica.la permite a las editoriales distribuir y vender eBooks, audiolibros y revistas con su propia marca. Cuando entré como única diseñadora, el producto llevaba años creciendo sin nadie a cargo del diseño. El lector, el panel y la tienda parecían tres productos distintos. Las editoriales que evaluaban la plataforma veían lo antigua que era la interfaz antes de ver todo lo que podía hacer, y cada pedido de funcionalidad nueva llegaba a un equipo sin un lenguaje visual compartido y sin una forma rápida de probar una idea antes de construirla.
El verdadero cuello de botella no era visual. Era la distancia entre un diseño y una funcionalidad publicada. Un archivo de Figma pasaba a un ticket, el ticket pasaba a un desarrollador, y las preguntas que aparecían durante el desarrollo volvían a mí semanas después. Con seis desarrolladores y una sola diseñadora, ese circuito era lo que había que resolver.
Restricciones
Una diseñadora para todo. Lector, panel, checkout, login, emails, sitio web, material de ventas. Tuve que elegir dónde importaba más el tiempo de diseño y darle al resto un sistema que el equipo pudiera aplicar sin mí.
Un producto en uso con editoriales que pagan. No se podía romper nada. Cada cambio en el lector o en el checkout llegaba a lectores reales comprando libros reales, así que diseñé en pasos pequeños y reversibles.
Plazos marcados por los clientes. Las editoriales grandes llegaban con listas de requisitos heredadas de su proveedor anterior y con fechas que no se podían negociar.
Acuerdo de confidencialidad. La mayor parte del trabajo no se puede mostrar en detalle. Esta página muestra el lector antes y después, y describe el resto.
Proceso
Empecé por las superficies que editoriales y lectores más usaban: el lector y después el panel de editoriales. Cada rediseño arrancó con una auditoría del flujo actual, una lista de puntos de fricción priorizada junto con atención al cliente y ventas, y una pasada por el sistema de diseño para que todo lo que dibujara se pudiera reutilizar.
El cambio que más importó llegó después. Armé una plataforma de prototipos sobre el stack del propio equipo: Laravel, Livewire, Flux UI y Tailwind, los mismos componentes que el equipo de desarrollo usaba en producción. En lugar de mockups estáticos, cada idea se convertía en un prototipo funcional con su propia URL. Los desarrolladores tomaban el código, los product managers recorrían los flujos, y las preguntas que antes llegaban semanas después se respondían en el prototipo mismo.
La plataforma sumó sus propias herramientas: enlaces para compartir en revisiones, comentarios fijados en cualquier pantalla, exportación de comentarios a CSV y un enlace desde cada prototipo a su ticket de Linear. Entre enero y abril de 2026 publiqué 23 prototipos con ella, que cubren checkout y pagos, el panel de editoriales, facturación y reembolsos, el lector, la tienda y el onboarding. Cuarenta y tres commits hacen referencia a issues de Linear de los tres equipos de producto, y ese es el rastro que le mostraría a cualquiera que pregunte cómo se conectaba el diseño con la entrega.
Solución
El lector
Qué hace. El lector es donde las personas usuarias pasan su tiempo: leen, escuchan, ajustan la página, se mueven entre capítulos. Lo rediseñé de punta a punta: onboarding, vista de lectura, ajustes y las transiciones entre ellos.
Decisión clave
Dejar la superficie de lectura casi vacía y llevar todos los controles a una sola capa de ajustes. El lector anterior competía con el libro; el nuevo da un paso atrás.
Antes
Después
Bajo presión. Cuando una editorial grande que se sumaba pidió una larga lista de cambios en el lector para igualar lo que ofrecía su proveedor anterior, entregamos un lector nuevo con todos los cambios en menos de una semana. La plataforma de prototipos lo hizo posible: el equipo construyó a partir de pantallas que funcionaban, no de un documento.
La plataforma de prototipos
Qué hace. Una aplicación interna en Laravel donde cada prototipo es una página real, hecha con la librería de componentes de producción, con enlaces para compartir, comentarios fijados, exportación a CSV y un enlace a su ticket.
Decisión clave
Construirla sobre el stack del equipo en lugar de usar una herramienta de diseño. Un prototipo en Figma es una imagen de una funcionalidad; un prototipo en Livewire es su primer borrador. Los desarrolladores podían copiar de ahí.
Contrapartida
Me costó bastante tiempo de desarrollo al principio, y solo funciona porque escribo el mismo código que escribe el equipo. Para quien diseña y no programa, una herramienta de diseño con un buen handoff es la mejor opción.
Panel, facturación y suscripciones
Qué hace. El panel de editoriales es la parte de negocio: catálogo, ventas, suscripciones, reembolsos y analítica. Rediseñé las vistas principales y las tablas de suscripción, y prototipé los flujos de facturación y reembolsos antes de que se construyeran.
Decisión clave
Primero las tablas. Las editoriales viven en tablas, así que la densidad, el orden y los estados de esas tablas marcan el tono de todo el panel.
Checkout y login
Qué hace. El flujo de compra y la puerta de entrada para lectores y editoriales. Rediseñé los dos, y prototipé los pasos de pago para que el equipo de desarrollo pudiera probar los casos límite antes de publicar.
Comunicación y superficies de marca
Qué hace. Emails transaccionales, banners para las tiendas de las editoriales y varias versiones del sitio web a lo largo de los años. Antes, como freelance, diseñé el sitio web de 2023, tapas de libros para editoriales y la presentación que la empresa llevó a Startup Chile en 2019.
Sistema de diseño
Hice evolucionar el sistema de diseño existente hasta convertirlo en una librería de componentes documentada, para que los mismos botones, tablas, formularios y estados vacíos aparecieran en el lector, en el panel y en los prototipos. La librería vivía en código, en Flux UI y Tailwind, y eso es lo que permitió que los prototipos y el producto compartieran piezas.
Impacto
La entrega de funcionalidades pasó de meses a menos de una semana en la mayoría de los casos. Ese es el número que me importa, porque salió de cambiar cómo llegaba el diseño a desarrollo, no solo de un rediseño. El lector reconstruido en menos de una semana para un cliente nuevo y exigente mantuvo esa cuenta en marcha. La plataforma de prototipos produjo 23 prototipos publicados en tres meses, cada uno con su rastro hasta el ticket.
Qué haría distinto
Armar la plataforma de prototipos antes. La construí en mi segundo año. El primero habría sido más rápido con ella.
Documentar el sistema sobre la marcha. La librería de componentes se documentó tarde, cuando las piezas ya existían en código. Escribirla mientras la construía le habría ahorrado preguntas al equipo.
Equipo
Yo, única diseñadora de producto. Seis desarrolladores de mobile, full-stack y frontend, product managers, atención al cliente, ventas y el CTO.
