At a glance
Role. Product Designer, sole designer. Jul 2024 to May 2026, fully remote. Freelance collaborator since 2019.
Team. Six developers (mobile, full-stack, frontend), product managers, customer support, sales and the CTO.
Scope. Reader, publisher dashboard, checkout, login, subscription tables, emails, client banners, several versions of the website, and an internal prototyping platform.
Stack I worked in. Figma for design; Laravel, Livewire, Flux UI and Tailwind for the prototypes, on the same stack the developers shipped.
The problem
Publica.la lets publishers distribute and sell eBooks, audiobooks and magazines under their own brand. When I joined as the only designer, the product had grown for years without a design owner. The reader, the dashboard and the storefront each looked like a different product. Publishers evaluating the platform saw the age of the interface before they saw what it could do, and every new feature request landed on a team with no shared visual language and no fast way to try an idea before building it.
The real bottleneck was not visual. It was the distance between a design and a shipped feature. A Figma file went to a ticket, the ticket went to a developer, and the questions that appeared while building went back to me weeks later. With six developers and one designer, that loop was the thing to fix.
Constraints
One designer for everything. Reader, dashboard, checkout, login, emails, website, sales material. I had to choose where design time mattered most and give the rest a system the team could apply without me.
A live product with paying publishers. Nothing could break. Every change to the reader or the checkout reached real readers buying real books, so I designed in small, reversible steps.
Client-driven deadlines. Large publishers arrived with lists of requirements from their previous provider and dates that were not negotiable.
NDA. Most of the work cannot be shown in detail. This page shows the reader before and after, and describes the rest.
Process
I started with the surfaces publishers and readers touched most: the reader, then the publisher dashboard. Each redesign began with an audit of the current flow, a list of friction points ranked with support and sales, and a design system pass so that whatever I drew could be reused.
The change that mattered most came later. I built a prototyping platform on the team's own stack: Laravel, Livewire, Flux UI and Tailwind, the same components the developers used in production. Instead of static mockups, each idea became a working prototype with its own URL. Developers pulled the code, product managers clicked through the flows, and the questions that used to arrive weeks later were answered in the prototype itself.
The platform grew its own tooling: share links for reviews, pinned comments on any screen, comment export to CSV, and a link from every prototype to its Linear ticket. Between January and April 2026 I shipped 23 prototypes through it, covering checkout and payments, the publisher dashboard, billing and refunds, the reader, the storefront and onboarding. Forty-three commits reference Linear issues across the three product teams, which is the trail I would show anyone who asks how design connected to delivery.
Solution
The reader
What it does. The reader is where end users spend their time: reading, listening, adjusting the page, moving between chapters. I redesigned it end to end: onboarding, reading view, settings, and the transitions between them.
Key decision
Keep the reading surface almost empty and move every control into one settings layer. The old reader competed with the book; the new one steps back.
Before
After
Under pressure. When a major new publisher required a long list of reader changes to match what their previous provider offered, we delivered a new reader with every change in under a week. The prototyping platform made that possible: the team built from working screens, not from a document.
The prototyping platform
What it does. An internal Laravel application where every prototype is a real page, built with the production component library, with share links, pinned comments, CSV export and a link to its ticket.
Key decision
Build it on the team's stack instead of a design tool. A prototype in Figma is a picture of a feature; a prototype in Livewire is the feature's first draft. Developers could copy from it.
Trade-off
It cost me real engineering time up front and it only works because I write the same code the team writes. For a designer who does not, a design tool with good handoff is the better choice.
Dashboard, billing and subscriptions
What it does. The publisher dashboard is the business side: catalog, sales, subscriptions, refunds and analytics. I redesigned the main views and the subscription tables, and prototyped the billing and refund flows before they were built.
Key decision
Tables first. Publishers live in tables, so the density, sorting and states of those tables set the tone for the whole dashboard.
Checkout and login
What it does. The buying flow and the entry point for readers and publishers. I redesigned both, and prototyped the payment steps so the developers could test edge cases before shipping.
Communication and brand surfaces
What it does. Transactional emails, banners for publishers' storefronts, and several versions of the marketing website over the years. Earlier, as a freelancer, I designed the 2023 website, book covers for publishers, and the slide deck the company presented at Startup Chile in 2019.
Design system
I evolved the existing design system into a documented component library, so that the same buttons, tables, forms and empty states appeared in the reader, the dashboard and the prototypes. The library lived in code, in Flux UI and Tailwind, which is what let the prototypes and the product share parts.
Impact
Feature delivery went from months to under a week in most cases. That is the number I care about, because it came from changing how design reached engineering, not from a redesign alone. The reader rebuilt in under a week for a demanding new client kept that account moving. The prototyping platform produced 23 shipped prototypes in three months with a paper trail to every ticket.
What I would do differently
Build the prototyping platform earlier. I built it in my second year. The first year would have gone faster with it.
Document the system as I went. The component library was documented late, after the parts already existed in code. Writing it as I built it would have saved the team questions.
Team
Me, sole product designer. Six developers across mobile, full-stack and frontend, product managers, customer support, sales, and the CTO.
