Showing posts with label Writing. Show all posts
Showing posts with label Writing. Show all posts

What I’ve learned writing for billions of users

Mike's Notes

I came across this gem in Smashing Magazine.

"What are the takeaways from writing for billions of users across dozens of languages, time zones, and cultures? Nick DiLallo has summarized everything he has learned writing for products used by a meaningful percentage of the world’s population. The result is a list of 70 valuable lessons learned that you can apply to your own writing right away." - Smashing Magazine

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Smashing Magazine
  • Home > Handbook > 

Last Updated

25/08/2026

What I’ve learned writing for billions of users

By: Nick DiLallo
Medium: 03/08/2026

Nick DiLallo is a writer based in Brooklyn. Past clients include Apple, Airbnb, Etsy, and Google. He currently leads UX writing at Clay.

...

Insights from products that grow and grow.

...

A few years ago, after running a complex global product launch, I wrote down everything I learned. To track my own ideas. To make sense of things. I’ve kept adding to it ever since.

I’ve worked on products used by a handful of people and products used by a meaningful percentage of the planet. The second kind taught me things the first never could.

This is what I’ve picked up along the way, writing for billions of users across dozens of languages, time zones, and cultures. Some of these lessons are about words. All of them are about people.

...

01: Most interfaces are mostly words. Take away all the text and screens stop making sense.

02: When you have a giant user base, people will interact with your product in ways you never intended. You’ll be shocked. You’ll also learn from them.

03: Good interfaces don’t need instructions. If you need to write things like “look for the arrow” or “scroll right,” the UI needs fixing. Words shouldn’t explain the design.

04: Naming features is hard. Renaming them is nearly impossible, especially if millions of people have already started using the product. You get one chance to get it right.

05: The typeface matters as much as the writing.

06: People have high expectations for software, and that includes the writing. World-class products don’t have mistakes, typos, or clunky phrasing.

07: Saying one thing is better than saying two or three things.

08: Fixing the writing can fix the entire company. Support tickets go down by the thousands. Conversion goes up. Users stay longer. There’s a reason the world’s best companies hire and value talented writers.

09: A shorter sentence is almost always a better sentence.

10: It’s always a good idea to fix things. You don’t need a rigorous business case for it. Don’t waste time trying to calculate the ROI of spelling “Connecticut” correctly.

11: People won’t read everything you put in the interface. They’ll skim and scan and scroll to what they want. You need to write for those people.

12: Rewrite everything twice. Rewrite important things twelve times.

13: Our relationship with technology changes. Writing can shape that change. Remember, we used to be afraid of using our real names online or entering our credit card.

14: Good writing just feels different. This can be hard to explain to non-writers. There’s a certain kind of click that happens in your head. Revise until you get there. You’ll know it when it happens. Developing this instinct takes a long time.

15: With a giant user base, you can get stuck trying to write “for everyone.” Try writing for one specific user. An Olympic athlete struggling to set a new record. A first-time mom who’s using your product at 4am. A surfer on their honeymoon in Tahiti. Choose one person and write.

16: Longer writing needs to be worth it. We expect more from a paragraph than a headline. Make everything the right length.

17: Users will read what you wrote, then do the exact opposite. It’s okay.

18: Details matter. The best teams spend time arguing over formatting and punctuation. Is it $45 or $45.00 or 45 (USD)? Do we say “July 5th” or “Next Tuesday”? Is it Settings or Preferences? You need to decide.

19: More opinions can sharpen your work.

20: Sometimes the last thing you need is more opinions.

21: A perfect error message is still an error message. Try to fix the root cause. Smarter inputs, clearer phrasing. An error is a last resort.

22: Words can’t do everything in an interface. Understand where other forms of information can help. A great description of a hotel room is no match for a photograph. A street address doesn’t show the same context as a full map.

23: Writing quality signals product quality. Users make judgments based on the writing. You can’t ask someone to trust you with their private data if they can’t trust you with your commas.

24: Small wins add up. A clearer headline here. A shorter error message there. A more direct call to action somewhere else. Fix enough little things and the product will completely transform.

25: Actions matter more than words. You can’t write one thing and do another. Don’t call it a “free trial” and then require a credit card. Don’t say chats are private if they aren’t. If you’re using writing to hide features or “convince” users, that’s a problem.

26: Most brand voice guidelines aren’t very helpful. Because most don’t say anything interesting or unique. Calling your brand voice “human” is not enough.

27: It’s usually a good idea to trust writers with writing. I’ve seen products fail because the wrong person was making decisions about words.

28: Grammar should be internalized. Learn the rules and break them when it feels right. But don’t talk about grammar too much. Using the phrase “past participle” in a meeting won’t get anyone excited. It’ll make them think of high school English class.

29: It’s hard to scale your product with a vague, meaningless value prop.

30: Tell the truth. I’ve seen a single vague sentence generate more support tickets than an actual outage. If something will take nine minutes, say it will take nine minutes.

31: Don’t invent words when you don’t need to. Digital products have a shared vocabulary that users already understand. Stick with common words and phrases. Log in. Save. Delete. Update. Edit.

32: Be careful about overwriting. This was something I saw lots of products doing for a long time, adding too much personality and too much text. Making a product “conversational” can sometimes just make it annoying to use.

33: A great onboarding will solve much more than an endless help center. First-time users who get confused don’t file tickets. They just leave.

34: You can’t evaluate writing in a spreadsheet or doc. Put the words in the interface and see how they read. Read them in the prototype. Read them on the device you’ll be using. Get as close to the real experience as possible.

35: Language is always changing. It happens faster than you think, and it’s the job of a writer to keep up. Look at the way people younger than you communicate, or the way your parents email. Nobody’s right or wrong. Language just moves.

36: Write without My or Your. Don’t call it My Photos or Your Photos. Just call it Photos. If you don’t, you’ll be chasing this down forever and confusing everyone along the way.

37: Writers who understand how products are built make better decisions. Learn as much as you can about strategy, technology, and business. A writer should understand how a company makes money and what their long-term vision is. Get as close to the decision-makers as possible.

38: Come back and read it tomorrow. Time away always helps.

39: If someone is using your product, they’ve already decided. Don’t market to them. You might talk them out of it.

40: Pick a word for something and use it everywhere, across every screen, for every user. Don’t call it a “folder” on one screen and a “workspace” on another.

41: Trust your own instinct as much as you trust your user research.

42: Users don’t know — or care about — your org chart. Your brand should have a single voice. It doesn’t matter if your emails, notifications, and support documentation come from different teams. Get everyone aligned.

43: Be careful with playfulness. A button that says “Pay” is clearer than one that says “Ka-chingggg.”

44: Word and image should work together. Give users context.

45: The things we build often reflect who we are. Selfish people build selfish products. Kind people build kind ones. To build the best product, build the best team and hire the right people.

46: Remember that translating for global products is a lot more complicated than swapping out text. Different languages reflect different cultures — and sometimes entirely different ways of thinking.

47: Be careful about making too many decks. You’ll start thinking in keynotes and bullet points, not UX and interface decisions.

48: Language has power. Writing makes people laugh and sob and get angry and feel joy and connect with other humans. A gradient can’t do that. A date picker or corner radius can’t do that.

49: Sometimes words can convey multiple meanings. “New” can mean exciting, but also unproven. Calling a transaction “safe” might make the user worry. Think about every word and what else it might be saying.

50: Not everything needs a login or account. Let people use your product. If they like it, they’ll stick around.

51: Not everything needs to be a subscription, either.

52: You get better by writing more. There’s really no shortcut to this one.

53: Know that your tools as a writer will keep changing. You’ll be working differently and using new software in 5 years. Maybe sooner.

54: One of the biggest challenges you’ll face is translating your product into right-to-left languages like Arabic or Hebrew. The entire UI starts to break. Icons, progress bars, and indicators might appear backwards. Build a writing system that can flex across all layouts and languages.

55: Never, ever mess around with money. There is no faster way to lose trust or infuriate a giant user base. Tell people what things cost. Don’t add “convenience fees” at checkout. Keep auto-renew off by default.

56: Good writing can’t fix a bad product. But it can reveal problems faster.

57: Get the first draft done. A bad draft is better than a blank screen.

58: Bringing writers in early is always a good idea. You can tell when a writer was added to the team the week before launch.

59: Delete as much as you can.

60: Good writing is not enough. You also need good layout, hierarchy, and typography.

61: The legal team will ask you to add words. Rewrite them so they make sense to regular people.

62: Laws are different everywhere. Required disclosures in Australia are different from those in California or the EU. Create different versions of the same screen if you need to. Don’t try to create one “hero version” that appeases everyone. It will end up being the clunkiest option.

63: Avoid the word “content.” It devalues everything it tries to describe. A film is not “content.” Writing is not “content.”

64: Users aren’t stupid. But they’re sometimes busy or distracted or tired.

65: Your writing will teach people how to think about your product. Clear language creates clear thinking. Vague or inconsistent language does the opposite.

66: Deliver bad news quickly and clearly.

67: Write for the user, not the press release or launch video. Too many companies get this wrong. They start with the marketing assets and then try to build the product around it. It usually doesn’t go well. Designing a screen for a keynote is different than designing it for a user, and great marketing won’t ever be able to fix usability issues.

68: It’s better to write something well the first time. A ten-second fix, multiplied across a billion sessions, is measured in years, not minutes.

69: If you’re making changes but things aren’t getting better, try fixing something other than the words. Use different components. Add animation. Adjust the navigation. Keep trying new ways to make the UI better. Don’t just rewrite. Rethink.

70: Accessibility can’t be layered on top of good writing. Turn on a screen reader and listen to your own writing. Use your product with different settings. You need to understand how people actually use your product, then write for them. All of them.

71: Build writing guidelines and documentation in the tools your team actually uses. Don’t make a PDF that never gets opened.

72: Users notice inconsistency before they notice almost anything else.

73: If you’re stuck, close your laptop and go outside.

You Will Be Accused of Using AI. Here Is How to Prove You Wrote It

Mike's Notes

This Substack post by Dr Sam Illingworth lists 8 useful steps to prove authorship. For future reference.

Resources

References

  • Slow AI: Knowing When to Use AI and When to Leave It Alone, Sam Illingworth, 2026. Kindle.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

23/08/2026

You Will Be Accused of Using AI. Here Is How to Prove You Wrote It

By: Dr Sam Illingworth
Substack: Slow AI: 07/08/2026

Sam Illingworth is a Professor of Critical AI Literacy at Edinburgh Napier University, where his work looks at how we use artificial intelligence with judgement: when it helps, and when to leave it alone.

He is the founder of Slow AI, a newsletter on using AI with judgement, and the author of Slow AI: Knowing When to Use AI and When to Leave It Alone. He has written and presented for the BBC, and his work has appeared in Nature, Scientific American, and The Conversation.

His path runs from atmospheric physics to poetry, and he still uses poems and games to open up conversations across communities. He lives in Edinburgh, and he is still learning to take his own advice.

...

A novelist lost two million dollars because nobody could show how his book was written. Your record takes twenty minutes.

...

Jerry Falade’s own agents took his book away from him. His debut crime novel drew a two-book offer from Minotaur reported at more than two million dollars, people who had read the manuscript started saying it looked like AI, and within days his own representatives withdrew it, because they could no longer establish how it had been written.

In this post I will:

  • Show you exactly what the evidence in this case was.
  • Give you the audit trail to build, and the two steps that matter if you only have twenty minutes.
  • Say plainly how I use AI to write this newsletter, including the bit where a detector calls me a machine.

Most of you are writing a newsletter, or a dissertation, or a report your manager will read on a train. The mechanism that ended Jerry Falade’s deal is the one now sitting under all of it.

Call Me, I’ll Hide the Body went to a fourteen-way auction and drew that offer from Minotaur, an imprint of Macmillan US. Reports of the figure vary from two to two and a half million. His co-agents at Europa Content, Marc Gerald and Ashley Coleman, pulled it.

Falade denies using AI.

“The accusations are wrong, and I am completely innocent,”

he told the reporter Jeff Sneider. Adding:

“I was on the verge of success, and then all of a sudden, there were rumors, but no one asked me anything. I don’t know why my agency did not have my back.”

Accusation is now one tap away

As I have previously discussed Substack partnered with the detector Pangram on 21 July 2026. Any reader on web or iOS can press a button on an eligible post and get a number back about whether a human wrote it.

LinkedIn have now also added a button that lets users report posts as AI-generated slop, on a platform that spent two years encouraging everyone to generate posts using AI. Your university has a detector. Your publisher has a policy.

The tools to accuse you are one tap from every reader you have, and none of them come with a standard of proof.

The evidence was a book review

The case against Falade’s manuscript, as reported, was three things:

  1. Negative parallelism, meaning sentences built on ‘this, not that’.
  2. Off-kilter metaphors.
  3. A flat prose style.

Those are criticisms. They belong in a workshop, or a two-star Goodreads review, or the margin of a first draft. Every one of them describes a large quantity of published human writing, some of it very good.

There is a second strand. The Bookseller reports a meeting on 29 July at which aspects of Falade’s account changed, and that this is what triggered the withdrawal. However, the agency has so far produced no detector log, no set of drafts, no version history, and no timestamp.

Sandy Hodgman of Hodgman Literary, who handled the potential foreign and UK rights, put it like this:

“Unfortunately, we are no longer able to authenticate how the manuscript fully evolved from origin to completion.”

They had accepted his assurances at first. Then they could not substantiate them, so the book was withdrawn.

Who is being asked to prove themselves

This is already happening at scale. Hachette cancelled the US release of Shy Girl by Mia Ballard in March 2026 and withdrew the UK edition, after a lengthy investigation prompted by evidence the New York Times brought to it. Ballard says an acquaintance she hired to work on an earlier self-published version used AI without her knowledge, and she has told the New York Times she is pursuing legal action.

Falade is a young Black writer and a doctoral student. He has said publicly that three Black authors landed major deals this year and all three saw those deals cancelled or disrupted after AI suspicion.

As I have written about numerous times now, researchers at Stanford, writing in 2023, ran seven widely used detectors over 91 essays written by non-native English speakers. Across the seven, the average false-positive rate on that human writing was 61.3%, and 97.8% of the essays were flagged as AI by at least one detector. The same detectors read US eighth-grade essays with near-perfect accuracy. Careful, standard, unadorned prose looks machine-made to many of these AI detectors, and that describes most people writing in a second language and most people taught to write formally.

The error in the Stanford study fell overwhelmingly on one group of writers. When the tool is uneven, asking who keeps getting called out is a reasonable question.

What produced the verdict in the Falade case was rumour, a changed story, and a reading of the prose, with no record on either side.

How to build an audit trail, starting today

An audit trail is a record of how a piece of writing came to exist, made while you are writing it.

Here is how to create an audit trail for your own work. If you have twenty minutes, do 1 and 4. Version history and an AI log cover most of what anyone will ever ask you for.

  1. Write somewhere that keeps its own history. Google Docs keeps full version history for free, and so does Word with AutoSave on. Substack’s own editor keeps drafts and revision timestamps, so if you draft in the app you already have more than you think. Version history is the single strongest artefact you can hold, because the timestamps are set as you go. You can’t manufacture three weeks of edits after an accusation arrives.
  2. Keep the ugly early drafts. Do not overwrite. Save dated copies at real milestones: the first mess, the structural rewrite, the version you sent to a friend. Five saved drafts across three weeks say more than any detector output ever will.
  3. Keep your raw input, whatever form it takes. This might be the photograph of a notebook page, a voice memo in the car, a scribbled outline, or the twenty-eight-tab research session you had open. Keep it.
  4. Log the AI, specifically. If you use AI in your writing process than keep a single running file per project. One line per session, copy this shape: 

    2 Aug | Claude Opus 5 | structural edit, section 3 | took the reordering | rejected the new opening Date, tool, what you asked for, what you took, what you refused.

    This is the artefact almost nobody has, and it is the one that answers the question Falade’s agents actually asked.
  5. Ask your editors and contractors what they use. Ballard’s account of her own case turns entirely on this: work she paid someone else to do, using tools she says she did not know about. If you hire a developmental editor, a copyeditor, a ghostwriter, a VA, or a cover designer, put one line in the agreement asking them to disclose AI use and to keep their own drafts. You are responsible for work that goes out under your name, including the parts you did not do.
  6. Keep your research trail. Sources, links, saved PDFs, and notes on what you read and when. A piece that can name where every claim came from reads as researched, because it was.
  7. Write your AI use statement before anyone asks for it. Three or four sentences on how you work, published somewhere durable: an about page, a pinned post, the back matter of a book. Here is a template to adapt:

    I use [tool] for [specific tasks: research scanning, structural feedback, proofreading, and image generation]. I do not use it to [generate first drafts / write in my voice / produce the arguments].

    An accurate statement about heavy AI use is worth more than a flattering one that falls apart.
  8. Put a provenance clause in the contract. For book deals and commissioned work, agree upfront what evidence you would provide, to whom, on what timescale. Publishing contracts routinely carry an AI warranty now. Very few of them define what proof would look like, or name who decides. Get that written down while everyone still likes each other.

Do you know someone who is being falsely accused of using AI in their writing? Then please share this with them.

This is not a guide to evading detection

Some people will read those eight steps as advice on how to look human.

Writing to beat a detector means changing your sentences to fool a classifier. It makes your prose worse, it is a losing game against a system that updates without telling you, and it is dishonest.

Building an audit trail means keeping a record of what you did. It changes nothing about your writing. It works whether you use AI heavily, lightly, or not at all, because the record simply says what happened.

If you have never used AI and you kept nothing, you are as exposed as anyone else here, and that is the unfairness at the centre of this. Your defence is a record, and you deserved to be believed without one. Unfortunately many will not.

My own trail, since I am asking for yours

Pangram scores my writing as 100% AI generated. The maximum the system gives. I wrote about the rollout in Substack’s AI Detector and the Return of the Witch Hunt, where that post scored 100% machine and a humanised version of the same text scored 100% human.

My writing is AI assisted, and I have never once claimed otherwise. So the score describes the surface of the text. It says nothing about how the text was made, and that is what anyone actually wants to know.

Here is mine, written out, because I am asking you to write out yours.

Finding the subject. I watch what my own readers argue about in the notes, and I run agent checks across social platforms and news feeds to see what is surfacing and what is already exhausted. The machine does the scanning. I decide what matters this week from what comes back.

Drafting. I mostly do this via Whisper Flow and I speak the draft out loud, making edits as I go, combing it with snippets of notes that I have taken during the week via the research phase.

Editing. I hand the draft to Claude and ask it to peer review, to argue with the structure, and to suggest edits. I also run a persona check, five imagined readers from a near non-user to a hostile expert, to find where the piece loses people. I take some of it and ignore plenty.

Everything around the words. The SEO, metadata, and artwork are all generated using AI.

Then there is my thesis

Take something you wrote before ChatGPT existed and put it through a detector. Use something old, where you already know the answer.

I ran my PhD thesis. Atmospheric physics, submitted in 2010, at a point when the technology being accused of writing it was more than a decade from public release. Running it through a detector in 2026 returns around 70%.

A physics thesis is exactly the careful, formal, low-perplexity register that the Stanford study found classifiers flag.

A detector tells you one thing: that a piece of text resembles a statistical distribution. The question in the room is who wrote it, and no detector has ever answered that one.

Why this matters

None of this should be your job. You should be able to write a book, sell it, and have the people who represent you assume you wrote it. That world is gone, and I am not going to insult you by pretending it comes back if we are patient.

Two years ago the burden of proof sat with the accuser. It has moved. As I wrote in Guilty Until Proved Human, we now start from suspicion and work backwards, and the person carrying the cost is the one being asked to prove a negative, which cannot be done. What you can do is make the question answerable.

Falade lost a two million dollar deal in the gap between an assurance and a record. Fill your gap this week. Turn on version history, start the log, and write the four sentences about how you work.

As you do this, notice who gets asked to prove the provenance of their writing, and who never gets asked at all.

What is your process? Tell me in the comments how you actually write, AI or no AI. There will be no judgement here, as I would like this thread to be a safe space where we can learn from each other as readers, and writers, and humans.

Go slow.

Why Handwritten Notes Matter Now More Than Ever

Mike's Notes

So true.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > 1000 Libraries Magazine
  • Home > Handbook > 

Last Updated

01/08/2026

Why Handwritten Notes Matter Now More Than Ever

By: Vincent Phan
1000 Libraries Magazine: 15/06/2026

Editor-in-Chief, 1000 Libraries Magazine. At 1000 Libraries, we believe in humanity’s inherent goodness and celebrate the enduring power of books as symbols of our capacity to do good. In a world dominated by digital noise and disheartening news, we cherish the joy of reading—a quiet yet powerful revolution. Our mission is to make inspiration accessible to everyone through the best book-related stories, fostering a diverse, non-religious, non-political community of book lovers who are keeping the written word alive in the 21st century. 

Discover why writing by hand makes the brain work harder, remember more, and process information deeper than typing on any keyboard.

Dear Juliet,

I’m writing to you, in this beautiful city of Verona, to tell you of my own tale of love. Everyone has heard the story of you and Romeo and fallen quite in love with it, although in truthfulness we hope our own affairs have gentler endings. I am here, putting pen to paper, because some tales deserve effort. And because, even if I don’t admit it to myself, writing down such details makes them all the more real.  

For the lovers and romantics out there, a letter like this might ring familiar. In the city of Verona, Italy – the backdrop for Shakespeare’s Romeo and Juliet – there exist those who still believe in the power of handwritten letters. 

The ‘Secretaries of Juliet’ are the guardians of love letters, and they have been since 1972. In the 1930s, Ettore Solimani, the guardian of Juliet’s Tomb, noticed he was receiving letters addressed to Juliet. These powerful letters of love touched Solimani in such a way that he never left one unread. They moved him so much that he began to reply to each notelet of love, and thus he became the original ‘Juliet’s secretary.’ 

Why Handwriting Feels Human

Photo Credit: Tehiya Benzur

Each year, the ‘Juliet Club’, a club made up of many such secretaries of Juliet, receives tens of thousands of letters. All of them are simply addressed to ‘Juliet, Verona’, and each one of them ends up read, translated, and responded to. People from all cultures, who speak all languages, have poured their hearts out and into their ink, all to be read by a stranger, often on the other side of the world.

Photo Credit: DongHyun Park

These letters contain something rarely seen in our digital age – a sense of vulnerability and raw imperfection. Unlike a laptop or computer, handwritten notes or letters cannot be easily erased or started again. You have to carefully consider the things you want to say and accept that they might not be what we consider ‘perfect’. Humans, or any non-robotic entity, have flaws.

We put our own human fingerprint into everything we do, mostly without realising it. Yet this only adds to the beauty. Anyone can create and read AI-generated articles or stories, but most of us are (thankfully) more drawn to things crafted by human beings, imperfections and all. 

Why the Brain Prefers Pen and Paper

The beauty of the handwritten extends past just the human fingerprint. Beyond literary appeal, handwriting is often better for our brains. Despite most of our lives – professional, academic, and personal – moving onto screens, one cannot deny the scientific evidence that suggests a return to the era of analogue. 

Typing takes mere seconds, but handwriting takes much longer. Some may see this as an inconvenience, time wasted, but neuroscience argues that this added time embeds the information into our brains. Writing out each word in pencil or ink doesn’t just look better but slows our minds down enough to consider what we are writing.

We think about the ideas, the information, and the meanings contained within them. Such an activity engages our motor, visual, and language skills, and helps us truly understand and memorise the content of our writing. 

What Neuroscience Says About Writing by Hand

Schoolchildren who grew up having to physically write all of their notes and assignments might have complained about such labour, but perhaps they were able to better retain the information they wrote. In fact, if we were to look at the scientific literature, we could say they definitely retained this information better. Audrey van der Meer, professor of neuropsychology at NTNU, found that students of this generation were often ‘typing without thinking’. Hearing the words and repeating them on their screens, with little interaction with their content. Prioritising swiftness rather than subject matter. 

To further test this hypothesis, researchers set up a test that examined the brain activity of a group of students as they were writing. The first time they ran the test, students wrote by hand; the second time, they typed. The difference was astounding. Handwriting lit up brains like a summer carnival, whilst typing produced minimal activity. Unlike a key on a keyboard, a person writing feels the difference between each letter. There is a bodily experience for each new word or phrase. Experiences like these help inform the brain of a person’s next action and give them the necessary information on how best to act in their environment.  

So, whilst critics might complain that writing is ‘outdated’, can we really call it ‘progress’ if it achieves worse results? The digital age has brought many undeniable benefits – but that was never in contention. Now we should perhaps question how much digitalisation is too much and allow the simple pleasures of handwriting to slow down our brains. 

Slowing Down in a Digital Age

I am not claiming to exist sans technologie, but I know my mind thanks me for returning to ink and paper every so often. I truly believe we are all continual learners. Graduating from school does not mean graduating from life – and being the best, most empathetic versions of ourselves means being an eternal student. So, when I find a subject that I am intrigued by, I make a note to write down whatever I learn by hand. After all, often the smallest changes make the biggest difference.

Perhaps people still write handwritten letters to Juliet because they know love deserves time. Our innermost thoughts – whether they are full of light or darkness – are those that demand to be written.

How Stripe Built a Writing Culture

Mike's Notes

Stripe’s Documentation Manager shares how the company built a culture where writing is second nature. The article is copied from SLAB.

The draft Ajabbi Design System Style Guide is based on the open-source MailChimp Style Guide published on Slab. Many sample or open-source complex documents are available on Slab.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

18/05/2025

How Stripe Built a Writing Culture

By: RC Victorino
SLAB: 02/09/2020

For a company whose product focuses on numbers, Stripe has built an enviable writing culture.

Their quarterly software engineering magazine (Increment) and publishing imprint (Stripe Press) are impressive on their own. But it’s Stripe’s internal writing culture that differentiates the company. Whether it’s an email to a colleague or a memo to an entire team, Stripe employees strive to write with excellence.

Their strong writing culture benefits the organization in several areas:

  1. Time efficiency. Sharing ideas through writing eliminates the need for repetitive verbal updates to disseminate ideas and information.
  2. Knowledge sharing. Documenting important ideas forces clarity of thought and makes information more accessible to everyone in the company, versus slide decks that are ephemeral and require less rigor of thought.
  3. Communication. Clear writing requires clear thinking, meaning employees invest more time shaping their ideas before sharing them.

“Writing forces you to structure your thoughts in a manner just not possible when you verbalize it. When I write, I have to offer structured, precise thoughts.”

Dave Nunez
Documentation Manager at Stripe

The result is that Stripe’s internal and external documentation is a central pillar of the company’s reputation and brand.

How did this happen? We sat down with Stripe’s Documentation Manager, Dave Nunez, to learn more about what it takes to build a strong writing culture.

Leaders must demonstrate quality writing

Getting employees to write more frequently shouldn’t be your ultimate goal. Getting them to write more proficiently should be.

One of the most effective ways to encourage proficient writing is to demonstrate it.

“The first emails I saw from our CEO [Patrick Collison] literally had footnotes,” Nunez recalls. “He structured his emails to be like research papers and put the peripheral information at the bottom so as not to detract from the core information.”

Today, footnotes are a common component of internal emails at Stripe. The CEO set the expectation; employees strive to uphold it. But Collison’s approach to writing did more than demonstrate the value of a footnote. It’s understood that at Stripe:

  1. Writing matters. Make it count.
  2. Everyone’s time is valuable. Make the effort to put together coherent ideas in writing.
  3. The clearer the writing, the clearer your message and intent will be.

Collison isn’t alone in his passion for quality writing. The modus operandi for leadership communications across Stripe is carefully structured narrative documents and emails. You’re far more likely to read a narrative memo during a Stripe project kickoff meeting than to sit through a PowerPoint presentation.

“From leadership on down, we default to writing,” Nunez said. “We don’t really have slide decks.”

How can you lead by example to foster a writing culture? Here are two ideas inspired by the Stripe playbook.

1. Exemplify quality writing in everything you and your leadership team share.

Footnotes might not be right for every company, but strategies anyone can adopt include citing reputable sources, being economical with your words, and ensuring your writing is free from grammar and spelling errors.

As a leader, consider having someone else review your writing for clarity and readability. Then, let your team know you had your writing reviewed. This transparency showcases just how committed you are to increasing the impact of your words.

“You wouldn’t ship code without having it reviewed; your words are just as important,” says Nunez.

2. Make writing the default method of sharing knowledge.

Eschew slide decks for narrative memos. Share new ideas through carefully crafted emails.

When an employee pitches an idea to you, ask them to expand on it in writing.

Show them you value the effort required to convey one’s thoughts into writing by explicitly granting them the time necessary to think through and process their thoughts into writing.

“I’m only a month into my time at Stripe, but I’ve never encountered a tech company of this size where writing is such a center of gravity.”

Shaun Young
Editorial at Stripe

Give teammates a starting point with sample docs

Nunez and his team create sample docs that other teams can use as inspiration for their own documents.

For example, his team published a detailed guide on the life of a Stripe charge. They walked through every step of the process, from the point of sale with the customer, to the back end, bank transactions, and more.

While the content itself was specific to a Stripe charge, the document serves as a valuable reference to other teams on how to write a guide. Teams use this document to understand what type of language to use, to see what types of visuals are most effective, and to learn how to structure their writing for better comprehension (such as when and where to use subheads and lists).

Stripe has similar sample docs for READMEs, runbooks, and FAQs. Nunez believes these sample documents are more useful than fill-in-the-blank templates, because they provide readers more context and content to work with.

“We create docs that offer some of the basics, so engineers aren’t forced to stare at a blank page — which can be terrifying,” Nunez says.

Not every company has a dedicated documentation department. But creating sample documents doesn’t have to be an arduous task. Identify the types of documents most teams would want to produce — then have your most proficient writers create ambitious documents that can be later used as reference documents.

Know when to standardize and when to give autonomy

Standardizing how your team documents shared knowledge ensures content is easy to understand and streamlines the writing process.

But it’s neither scalable nor empowering to standardize everything.

It’s not scalable because it would take constant oversight to ensure every document met a specific format. Few companies have (or are willing to invest in) the resources for this kind of oversight.

It’s not empowering because what works for one team won’t necessarily work for another. Standardizing your entire documentation process robs teams of creating an experience that works best for them.

Stripe toes the line between control and autonomy by establishing a standardized approach for high-leverage documents only — those with a broader audience (like a document intended for multiple teams) or significant implications (like if it impacts business operations).

This approach ensures that the most widely read information receives the oversight it deserves, while teams still maintain autonomy over how they document knowledge most pertinent to them.

In contrast, each team at Stripe has far greater control over the look and feel of documents with a smaller audience and impact.

Standardization at Stripe isn’t represented by a series of templates employees plop their knowledge into like Mad Libs. Rather, standardization at Stripe is more about ensuring the clarity of the content and the reading experience live up to the company standard of quality writing. To ensure this, Nunez typically gets his team involved in reviewing these high-leverage documents before they’re shared.

Replicating this process is straightforward — establish criteria that differentiate high-leverage documents from low-leverage ones. For example, you could define high-leverage documents as:

  • Intended to be read by three or more teams
  • Contains information that will go unchanged for at least one year
  • Will impact general business operations

Documents designated as high-leverage should either follow a specific format, be reviewed by a dedicated team before publication, or both.

Make your documentation easy to read

The point of documenting something is to get others to read it. Without active readers inside your company, your writing culture will never flourish.

So, how do you get people to read what you wrote?

“I think the visual aspect is super important,” Nunez says, “because the first impression tells someone whether the content is approachable or not.”

A visually appealing document doesn’t always contain images and graphics. Nunez has seen beautiful documents that contain no visuals at all.

“You can look at the document and see, ok, this is super simple,” he says. “The intro is very short, there’s bulleted lists down here, and it just gets to the point.”

But, he admits, that’s rare. Visuals and diagrams simplify documents. They make them more approachable, which is why he suggests whenever you can replace text with diagrams, do it.

Diagrams or not, everyone on your team should consider the visual aspect of their writing. Here are a few items to consider:

  • Keep paragraphs short (3–4 sentences). If possible, make the first paragraph of a document 2–3 sentences.
  • Use subheads and bulleted lists to break up walls of text.
  • Consider your audience when writing. Some audiences value complex words — some don’t. The goal is to find the most compelling language for the audience you need to reach and act on your document.
  • Edit frequently. Edit your own work, and ask peers to edit it as well. Editing is the key to getting the best clarification of your idea.

Create a support system

Writing well is not supposed to be easy. Writing well requires more critical thinking (than, say, speaking off the cuff), which produces better results.

The payoff is worth the effort, which is why everyone on your team should strive to be strong writers.

However, sometimes the writing process can create significant barriers that prevent team members from ever sharing their ideas.

Employees who struggle with writing, or whose native language isn’t English, may feel less confident contributing their knowledge.

Nunez has seen this throughout his career — he worries that a company does itself a disservice when some employees don’t feel empowered to share their ideas in a writing-heavy environment.

To address this, he emphasizes the importance of onboarding classes for new hires focused on writing and documentation, as well as office hours, and self-service resources. This demystifies the documentation process — but it also emphasizes just how important documentation is to business operations from the outset.

One thing Nunez is starting to experiment with is pairing ESL employees with writing mentors. He’s done this informally over his career, but would love to see companies create more formal programs for writing mentorships.

“The idea here is that you come with your writing, and a judgment-free expert writer will help you as if they were your college English professor,’” Nunez says.

But even your team’s strongest writers need support. Nunez, for example, is the first to admit that his writing can become long-winded and confusing. So, he regularly shares his work with a handful of colleagues he trusts to offer kind but honest feedback.

Many others across Stripe have colleagues review their work, as well.

“Engineers do this with their code,” he says, “and we do it with our writing.”

Building your culture of writing and documentation

When your CEO uses footnotes in his email and your company publishes full-length books, it’s clear that writing matters.

But you don’t have to be Stripe to develop a culture that embraces writing and documentation. Lead by example; know when to standardize internal writing and when not to; make your documents easy to read; develop a support system that encourages and empowers everyone to write. These are the building blocks from which any company can build a culture where writing and documentation become second nature.