Bookish Boutique: Validating a Direct Sales Platform Through Technical Prototyping

After five years working with independent authors, I heard the same frustration repeatedly:

The existing options were missing key pieces. Generic storefronts buried authors' unique brand identities under one-size-fits-all templates. Custom websites required $10,000+ upfront investments plus ongoing developer fees. E-commerce platforms meant wrestling with confusing plugins and watching fees devour already slim margins.

The Gap

Most platforms handle digital sales adequately, but authors sell across formats. Each format brings distinct operational requirements—audiobooks need instant delivery, paperbacks require shipping calculations, hardcovers involve different fulfillment partners. Authors also need integrated reader engagement and release promotion tools. Standard e-commerce platforms treat books like any other product, missing these publishing-specific workflows entirely.

My research confirmed what authors told me: Over 300,000 independent authors currently juggle 5-6 different services, spending $1,000-2,500 annually on partial solutions. Another 33% plan to start selling direct within the next year. A $2-4B market exists—sustainable rather than venture-scale—serving professional authors who need purpose-built tools.

I built a comprehensive prototype to validate whether one platform could elegantly solve these interconnected problems.

I spent four months building the complete platform to understand how design decisions compound across a marketplace. Making each format its own product with distinct fields, building visual editors for social share cards, creating focused editing interfaces that match author mental models—these design challenges only revealed themselves through implementation.

The Design Opportunity

To deliver on this value proposition, I considered several design challenges that would differentiate Bookish Boutique from existing solutions:

• Integrated Shopping Experience: Readers needed to browse and buy without leaving an author's site. This meant designing checkout flows that felt native to each author's brand while maintaining consistent functionality.
• Editing Without Overwhelm: Authors felt paralyzed by the layers panels and infinite options of modern website builders. I designed a constrained system with predefined sections they could drag and drop, with customization limited to what matters: color, text, and typography. Each section opens in its own drawer, focusing authors on one task at a time instead of showing them everything at once.
• Managing Backend Complexity: The platform handles merchant services, multi-format fulfillment, print-on-demand, and tax compliance behind the scenes. I designed the admin interface to surface only relevant information at each step—showing shipping options only for physical products—without burying critical features.
• Planning for Platform Growth: New payment methods and fulfillment partners would need to work across every author site automatically. I kept this in mind while designing, using modular templates and dynamic components that could accommodate future features without forcing authors to rebuild their sites.

These challenges shaped design decisions from component structure to editing flows and more. The goal was always to let authors focus on their work instead of the technology.

Architecture-First Design

Bookish Boutique flipped my typical design process. Instead of starting with UI mockups, I started with system constraints.

I learned Next.js 14's routing system and Swell's commerce API through trial and error. Without a technical background, I hit plenty of dead ends. Each one taught me to understand the boundaries before designing features that pushed against them.

Information architecture came first, visual design second. I needed to know what was possible before deciding what was desirable. Figma became a sketching tool rather than a documentation tool. Rough concepts went straight to code—no detailed wireframes needed. This matched what many design teams have discovered after abandoning wireframes entirely.

Understanding technical constraints shaped better user experiences. Take checkout flows. Knowing that Swell and Stripe needed different data at different steps led me to design smarter paths. Digital downloads skip shipping forms. Mixed carts only show relevant options. The technical understanding focused my creativity on solutions that actually worked.

1. Social Share Cards: Satisfying Emotional Needs

Authors were frustrated that sharing their books on social media promoted the marketplace more than their own brand. Most platforms put their logo and branding front and center in share cards.

I gave each author's site its own social share card. Authors upload their image, write their text, and see exactly how it will appear on social platforms. The system handles the Open Graph tags automatically.

This reinforced what made Bookish Boutique different. Authors get their own storefront, not a seller page on someone else's platform. When they share a link, it's their brand people see.

2. Focused Editing

Modern page builders show everything at once—layers panels, property inspectors, component trees. Authors found this overwhelming. They think in terms of page sections, not nested components.

I designed around progressive disclosure. The main view shows page sections as simple, labeled blocks. Click edit, and a drawer slides over with just that section's controls. One section, one task, no distractions. Changes appear instantly in the preview.

The system makes smart decisions by default. Text colors auto-adjust for readability. Spacing maintains consistency. But authors can override anything when they want to. This balance came from recognizing that most authors want good results quickly, with the option to fine-tune later.

3. Designing Around API Constraints

I started with standard e-commerce thinking—one product, multiple variants. But Swell's API treats physical and digital products as separate entities. Ebooks and paperbacks need different data fields entirely.

I worked around the constraint. Each format became its own product with tailored experiences. Audiobook listeners review narration quality. Ebook readers comment on formatting. Print buyers discuss paper quality. The workaround became a better solution.

This structure benefits everyone. Authors can write different descriptions for each format, set independent prices, even stagger release dates. Readers land directly on the format they want. Marketing campaigns can target audiobook listeners separately from print readers.

To users, it still feels simple—just pick your format. But the underlying structure enables much more sophisticated selling strategies.

Design Insights Through Rapid Prototyping

I skipped extensive documentation and went straight from sketches to working prototypes. Building with real content revealed problems that mockups hide.

The drag handle placement looked fine in Figma. In practice, it caused text overflow and crowded the action buttons. Moving it to the left fixed everything—obvious once you could interact with it.

My sub-navigation started as blocks, matching the main navigation pattern. But once I could actually navigate between pages, the blocks felt heavy and slow. The icon list made scanning faster and kept the focus on the page content rather than the navigation itself.

The biggest revelation came from removing features, not adding them. I'd built a "See Changes" button because that's what CMS interfaces do. But once real-time updates worked smoothly, the button felt like unnecessary friction. Watching sections reorder instantly as authors dragged them changed the entire feel. It transformed the UX from filling out forms to directly manipulating content.

When Performance Shapes Design

Small interactions made a bigger impact than expected. Switching between book formats on the authors' Books page felt clunky until I added Framer Motion animations. Watching books smoothly reorder themselves when filtering by format transformed a functional feature into something that felt polished.

Having the ability to tweak Framer Motion settings until animations feel "just right" is the kind of transformative design depth that mock-ups don't reach. I couldn't have prototyped this animation in Figma. Being able to test multiple variations of the animations, adjust speeds, and reordering logic all within minutes made the design process more iterative and responsive to real user needs while achieving a level of polish that would be hard to achieve with static designs.

Design Takeaways

Building Bookish Boutique helped me grow as a product designer. Working with real commerce APIs, payment systems, and multi-vendor architectures revealed the gap between what seems logical in Figma and what actually works in practice.

Sometimes constraints became design opportunities. Swell's product structure pushed me toward a cleaner format-based architecture. Building actual checkout flows showed me where users need guidance versus freedom. Implementing the drag-and-drop editor taught me which interactions need polish and which just need to work.

Strategic Outcome

Over four months, I built a complete marketplace—multi-vendor storefronts, admin dashboards, payment processing, and a visual site builder.

The prototype validated core assumptions about what authors need and what readers expect. More importantly, it gave me hands-on experience with the technical decisions that shape user experience in ways mockups can't reveal.

Moving Forward

This project changed how I collaborate and approach systems-level design. I ask better questions because I've felt the constraints myself. I can better discern between "technically possible" and "worth building" because I've built both.