moonjin

Moonjin is a newsletter service built for literary writing. Poetry, fiction, essays, and criticism.

Writers publish newsletters, manage subscribers and payments, and archive their work in one place. Readers find writers by genre and taste, subscribe, and revisit past issues whenever they want.

Client

Sonoran National Park

Year

2023

Project type

Landscape

Credits

cottonbro studio

Challenge

Writers came for the readers. The busywork came with them.

Independent newsletters let writers build a direct relationship with their audience. But running one meant
stitching together separate tools to send emails, manage subscribers, verify payments, catch delivery errors,
archive issues, and promote new work. The writing was the smallest part of the job.

Readers had a different problem. They found newsletters through social media or word of mouth, and once an issue disappeared into the inbox, it was hard to ever find again.

Research

The problem was not a lack of tools, but a fragmented experience

I analyzed eight email marketing tools, newsletter services, and publishing sites,
and interviewed six writers and eight readers.

Each product solved one slice well. Marketing tools handled sending but treated writing like a campaign.
Newsletter services handled subscriptions but not literary browsing. Publishing sites displayed work
but could not deliver it. No single product covered the path from writing to reading and back.

The research revealed three gaps

Writers combined several tools to run one newsletter. Readers had no path from finding a writer to subscribing to rereading. Neither side's journey lived in one product.

Creator

The workload grew with every new subscriber, and reaching new readers still depended entirely on outside channels like social media.

Reader

Subscriptions and reading history sat scattered across inboxes, and there was little to judge a writer by before committing to subscribe.

How might we?

How might we take the operations out of publishing, so writers can focus on writing and readers can build a lasting relationship with the writing they love?

My Role

I designed the product structure and core flows end to end

As the sole product designer, I took Moonjin from research and information architecture to final UI and QA,
working with the PM and developers to define the MVP, its scope, and edge cases.

Key Contributions

Research and product direction

Information architecture
and user flows

Taste based browsing for readers

UI design and design system

Usability testing and iteration

Developer handoff and QA

UI design and design system

Usability testing and iteration

Developer handoff and QA

Key Solutions

Three decisions that serve both writers and readers

Moonjin launched with publishing, archiving, and taste based browsing working together.
Each solves a writer problem and a reader problem at once.

Key Solution 01
Writing to publishing
The editor is built around literary writing, not marketing blocks. Writers work with essential formats, drafts save automatically, and both the email and public web version can be previewed before sending.
Delivery and payment issues surface as clear alerts, so writers only deal with operations when something actually needs them. For people whose craft is the text itself, every setting removed is attention returned to the writing.
Design Principle
Creators should feel like they are publishing writing, not configuring a campaign.
Key Solution 02
Publish once, keep reaching readers
Publish once, keep reaching readers
For new readers, the archive doubles as an introduction.
They can read a writer's actual work before subscribing. Each issue keeps working long after send day, which turns a newsletter from a one time delivery into a growing body of work.
Design Principle
A published piece should continue reaching readers beyond a single email.
Key Solution 03
Browsing by literary taste
Readers browse by genre, writer, and series, alongside editorial curation. Detail pages give enough of the actual writing to judge whether a voice fits before subscribing.
Popularity rankings favor whatever is already big, which buries new and niche literary voices. Taste based browsing gives a poet with two hundred devoted readers the same chance of being found as an essayist with twenty thousand.
Design Principle
Readers should find writing that feels relevant to them, not only what is already popular.

Series Newsletter

Series, not scattered issues

Newsletters vanish into inboxes.
Series give writing a permanent home
readers can find, follow, and return to.

Post Detail

Every issue is a page, not an email

An email disappears, a page can be found. Every issue links back to its series and forward to a subscription.

Author Profile

A writer you can browse before you subscribe

Before Moonjin, subscribing was a leap of faith. A writer page turns it into an informed choice.

Dashboard for writers

Operations in one glance, not five tools

Subscribers, revenue, and readership in one place so operations take a glance, and writing takes the rest of the day.

Outcome

The MVP found its first real users

More than 1,000 monthly active users

3× growth in active writers

Content detail visits up 24%

Publishing completion improved from 58% to 91%

Publishing time cut by 47%

Reflection

A strong product must also be one a team can sustain

Moonjin found early traction, but each new feature added operational load and deepened our dependency
on a small development team. In the end, we could not maintain the service, and it was discontinued.

That changed how I design. Scope, maintainability, and team capacity are now constraints
I weigh from the first wireframe, not realities I discover after launch.

I now ask "can we keep this running?" as early as I ask "will users want this?"