From Nothing to Something with Minimum Viable Documentation

More and more startups and enterprises are recognizing the importance of high quality product documentation, but it’s tough to know where to start. I’ve taken a few enterprise software products from “nothing to something” documentation and this is the framework I’ve built for myself to create MVD—minimum viable documentation. 

Diagram using a dotted line circle with an arrow toward a pink shaded box with "MVD" inside to represent going from nothing to minimum viable documentation.

If you’re a technical writer trying to find your footing, or someone who cares about adding user documentation for your software but have no idea where to start, this is the guide for you.

What is minimum viable documentation?

If documentation is a product (and it is), minimum viable documentation is the bare minimum documentation that is useful and helpful to customers

Something good is better than something chaotic and unhelpful, and it’s much better than no documentation at all. It’s also easier to focus on getting to minimum viable documentation rather than trying to reach full-featured documentation as soon as possible, because you’re a human with a life that is not your job.

Venn diagram with overlapping circles of Helpful, Useful, and Quick intersecting to form MVD.

You might be working with a fully-functional software product that has no useful documentation. In that case, getting to full-featured documentation isn’t your primary goal—getting to minimum useful documentation is. So let’s get started.

Define minimum viable documentation for your product

Before you can write MVD, you need to define what it is for your product. MVD differs depending on your market, customer base, product type, your pricing structure, and more. 

I recommend you do the following to define what MVD looks like for your product. 

1. Talk to your colleagues

Your goal with these conversations is to get a good understanding of who the target user is for your product and the goals they want to accomplish with your product.

Diagram with 5 circles, 1 each representing PM, UX, Docs, Engineering, and Marketing.

If you have product management, start with them. Find out as much as you can about why the product is being built, who it’s for, and how the product is being positioned in the market. 

Also talk to engineering management or senior engineering subject matter experts (SMEs). What user problems are the software trying to solve? What level of expertise do the engineers assume the user has? 

If you’re lucky enough to have a sales or marketing team, talk to them. Because of their efforts defining the customer journey, they can help you understand who the audience is and what the key success workflows look like. Who is the product targeting? Why do they want to use this product? What problems are they trying to solve?

Talk to the user experience designers to get an understanding of the user personas they’re designing for and what workflows they think have the most friction. You can also get a sense for how the team approaches their role, whether they’re more focused on designing friction-free workflows or pixel-perfect screens. 

After talking to PM, EM, UX, and marketing, you can do the following:

  • Identify what level of expertise a typical product user has, both with the domain and with the product. This functions as your audience definition.
  • Write down the main goals of a user before and after they start using your product. What motivates the user?
  • Map out the key workflows that a user is going to perform in the product. What tasks are the user trying to accomplish?

2. Perform a documentation competitor review

It’s always a good idea to know what your competitors are doing! If you’re not sure what products your product is competing with, ask your sales or marketing people for a list or do some research on your own. 

Pick 3-5 companies to focus on, such as your strongest competitors in terms of funding, usage, or closeness to what your product does. 

You also want to make sure you’re not benchmarking off useless garbage when you perform your competitor review. In addition to the 3-5 competitors you identify, pick a couple industry leaders or companies that your colleagues mention as having good documentation, such as Stripe API docs, Microsoft docs, or even IBM docs, and include one or two of them in your competitor analysis. 

The advantage of choosing the documentation of a couple larger products to review is that they tend to have established documentation teams and offerings in a variety of markets. This makes it easier to find a product that is well-documented and at least somewhat adjacent to what your product does.

Diagram using different colored shaded rectangles to represent competitor documentation, with an arrow pointing to MVD.

The goal of your competitor analysis is to identify how the companies provide documentation about their product(s). Pay attention to the following:

  • How is the documentation structured?
    • By feature?
    • By use case?
    • By persona?
  • What documentation is provided?
    • What workflows are covered? 
    • What seems left out?
  • What type of documentation is it?
    • Lots of conceptual information about how the product works?
    • Heavy reference information but light on the how-to tasks?
  • Who is the documentation targeting?
    • Look for introductory content or tutorials
    • Is there advanced developer content? 
  • How is the documentation site built?
    • Use the inspect element option in your web browser or a site like to figure out what technology the documentation site is built with.
  • Anything else interesting?
    • Does a company have an interesting way of differentiating beta functionality?
    • Are code samples hidden behind toggle-to-expand options?
    • Is there a plethora of gifs, videos, or other multimedia in the documentation?

Document your findings, of course, and feel free to share your findings with your team during a demo. After all, they might be wondering what you’re doing if you haven’t started writing yet. 

3. Assess the current state of your documentation

If there is any sort of documentation for your product, you want to know what it is. It might be a sad README and some code comments, it might be detailed multilayered documentation without much organization or clear goals. 

Diagram with a transparent dotted circle pointing to {} encasing a column chart, circles with customers, marketing, UX, engineering, and PM, plus a dotted outlined rectangle with "existing content?" inside pointing to an MVD square, representing the pre-planning process.

To get a sense of the current state, I recommend doing the following:

  • Audit the existing content. Identify which topics are covered in the documentation already, and where. Make a list, and also keep track of what topics seem to have a lot of detail, and what you suspect might be outdated. This is a cursory audit, not an in-depth one that you might perform if you were migrating content.
  • Look at the documentation analytics. If you have analytics for the documentation site, take note of which pages are most frequently viewed, which pages might be serving as entry points, and how much time people spend on various pages. 
  • Talk to your team and get their thoughts on the current documentation. Who has been writing it so far? Are they attached to any topics in particular? Do they share specific topics with customers regularly?
  • Interview customers of the product and documentation to see what they want to see or find most useful today.

Depending on the quality of the existing documentation, these steps might not be that helpful in informing your approach, but help you set benchmarks for documentation growth and quality, plus identify links you likely don’t want to break.

If you don’t have any documentation, still talk to your team and customers. If you can’t talk to customers for some reason, you can look for discussions about the product on social media like Reddit, Twitter, or Hacker News to identify themes that people ask questions about or really enjoy about your product.

A brief note about terminology: As you review competitor and existing documentation and interview internal and external folks, you might find that your product has some inconsistent terminology. At this stage, you might want to delay the writing process while you create a definitive list of terms to use for the product. This type of work can take more time upfront but it’s easier to create consistency from the beginning than to apply it after the fact. 

Define the structure of your documentation

Before you start writing, you want to create a structure or a framework to place your topics into. 

Diagram with the empty circle pointing to shaded rectangles structured in a hierarchy of three chapters, one with 3 topics below it, one with 2, and another with 4, all pointing to the MVD shaded square.

The structure for your MVD is directly informed by the work you did to define what MVD looks like for your product, plus some information-architecture-specific research. 

  • Revisit your conversations with colleagues. What workflows and functionality might be important to highlight? Who is buying your product? Who is using your product?
  • Refer to your competitor review notes. How did your competitors and benchmark docs structure their documentation?
  • Research information architecture best practices. Refer to some key articles from the Nielsen Norman Group, as well as the book How to Make Sense of Any Mess by Abby Covert, and the associated worksheets.

After this research, draft up some chapter headings and possible topic titles to start with, then get feedback from your UX, PM, Engineering, and Sales and Marketing folks. How accurate, relevant, or helpful does the new structure seem? Have you made any assumptions that don’t make sense for the customer base?

Expect this information architecture to change as you write the MVD and especially as you develop full-featured documentation. This is the nature of a minimum viable product! Put a task in your backlog to plan to refine the structure after you finish MVD and are approaching full-featured documentation so that you can iterate without confusing your customers with frequent changes, and plan so that you don’t break any links.

After you design the initial information architecture, you can start writing. 

Start writing minimum viable documentation

So you know what minimum viable documentation might look for for your product, but how do you get there? MVD is all about creating useful content for your users, so start with the entry content! 

Venn diagram with three circles, one with identify key information, one with describe the path to success, and a third with clarify complexity, with MVD at the intersection of all three.

Focus on key information for customers

As with any “minimum viable” approach, you’re trying to get a basic functional framework down before you start improving it. As you lay that framework, be mindful of scope creep.

Think back to the key workflows that you mapped out earlier. Broadly cover the top few workflows and then flesh out details as you get more comfortable with the product and understand the user goals better. Why go broad instead of going deep into a specific workflow? You’re still learning what the customer finds useful, and what level of detail they might want or need about a specific workflow. 

If you spend a lot of time writing a highly detailed workflow that you thought was important and it turns out it’s actually pretty intuitive for customers—that’s time that you could have used to write about something that was really confusing and holding back customers from succeeding with your product. 

It’s likely that you’ll encounter cases and situations that you want to write more about. That’s great! Write them down and put them in a backlog to address later. For now, you want to stay focused on these minimal workflows to build out the minimum viable documentation for your product. You can get fancy with use cases and in-depth examples later. 

Identify the simplest path to success

Within those broad key workflows, start with the simplest path to success, the “happy path” that most of your customers will take. 

That might involve writing a series of topics like:

  • “Get started using Best Product Ever”
  • “Install Best Product Ever”
  • “Set up Best Product Ever”
  • “Accomplish Straightforward Task in Best Product Ever”. 

Get those written, reviewed, and published and start helping people use your product that much sooner. 

Clarify any complexity

After you write the documentation to support the simple path to success, what do you write next? Documentation that unravels where complexity lurks in your product. 

Depending on your product familiarity, you might need to take more time to research and lean on technical subject matter experts (SMEs) a bit more to write this, but it’s worth it. This documentation content might be topics like:

  • “Configure the Weird Setting You Must Touch”
  • “All About This Task That Everyone Wants to Do but No One Can Find”.

You don’t want to get bogged down in documenting around product complexity here. Stay focused on the complex aspects of the key customer workflows, and the crucial information customers need. What might confuse someone if you left it out? What assumptions have you been making about the user that need to be made explicit? 

This is often the step when I remember to write things like software requirements, role-based restrictions to functionality, or other crucial cases that are often assumed when developers write their own documentation.

Get feedback and iterate

I assume you’re focusing on minimum viable documentation because you have more work than you have time to complete it. That’s why it’s important to iterate. Yes, I just harped on the importance of prioritization and focus—and it’s essential to make sure that what you prioritize and focus on is still important. 

Diagram showing an MVD shaded rectangle with an arrow pointing across to circles with PM, engineering, and customers, then another arrow pointing back to MVD, to emphasize the importance of a feedback loop for your MVD.

Check in with product management and engineering management regularly (I’d recommend weekly for an every-few-months or less release cadence) about what you’re prioritizing and why. 

This check-in is mostly about getting signoff and validation, not direction—but don’t ignore the direction that PM and EM can offer you! If there are important releases coming up that will affect one of the key workflows on your list, you might want to document that workflow sooner, or in more detail than you might otherwise for MVD. 

Use these conversations as a way of discovering what customers are paying attention to, and what your PM and engineers are paying attention to as well. 

As you send your documentation out for technical review, you might also get feedback that you can use to improve your approach to MVD. With any luck, much of the feedback will duplicate what you have planned—and that’s helpful validation for your approach.

You might get so much feedback that you have to dump a lot of ideas into “plans to write this later” and a backlog that feels like it’s spiralling out of control, but if you stay focused on your scope, you’ll get to that backlog sooner and with a more comprehensive understanding of your documentation and your customers. 

If the direction and feedback you get from your team is pretty far removed from your approach to MVD, it’s helpful to discuss why that might be and treat it as prioritization guidance for your future plans. Maybe you misunderstood a key target customer, or the purpose of the product in the market. You might discover you need to realign your understanding and vision of the documentation with that of your team. 

What’s next after MVD?

When do you know that you’ve reached minimum viable documentation? It’s somewhat of a fuzzy line. When you notice that you’re writing documentation by adding to existing topics, or writing net new example content, or documenting new features instead of existing features — you’ve moved past MVD and into shaping full-featured documentation. 

As you start shifting into that mode, you’re no longer focused on creating the skeleton structure to build off of, but filling in the details and settling into the usual work of modern technical writing.

Shaded MVD box pointing to {} boxes emphasizing the headers that follow, work through backlog, improve product, create examples, collect feedback, review analytics, all pointing now to a filled in square labeled full featured documentation.

1. Go through the backlog

Start going through your backlog of ideas. Revisit those ideas and group similar ones together, adding audience definitions, acceptance criteria, and learning objectives where you can. Note who the technical SMEs are and whether any upcoming releases are relevant for some of the tasks. 

Ideally, you’re storing this backlog in the same spot as your engineering backlog so that your work is visible to the engineering team. 

Work with PM or EM to prioritize those tasks and start working through them. As any writer for a fast-paced development team knows as well, the product development often happens faster than you can write about it, so you’ll never run out of tasks in your backlog.

2. Suggest product improvements

As you went through a flurry of documentation writing to produce MVD, you likely identified some parts of the product that might need to be improved. Again, work with your PM and engineering teams to discuss possible product improvements. 

You can also suggest product improvements that directly involve the docs, doing a review of UI text in the product, or auditing pages in the product to suggest opportunities for in-app documentation or context-sensitive help. This is a great opportunity to partner with the UX team as well. 

Partner with your engineering and UX teams to make suggestions and build those relationships based on your newfound product and customer expertise. 

3. Write use cases and examples

To create more useful content for your customers, you probably want to flesh out specific example scenarios for using your product. You might have written some already as quick start use cases for getting started with your product, but you likely want to write more for the next stage of customer product understanding.

You can use example content to describe customization options for the product, or highlight domain-specific use cases for a market that your customer might be trying to break into. 

4. Ask for feedback

You put all this effort into creating minimum viable documentation, but how viable is it really? 

Ask your technical SMEs, sales and marketing teams, customers, really anyone that might interact with the documentation internally or externally if they have feedback on your documentation improvements and information architecture. 

You could perform some tree testing with the MVD structure to see if there are some improvements you can make to the information architecture as you flesh out the documentation, or just have short conversations with stakeholders. 

Use the feedback you get to help shape priorities for your backlog. However, don’t treat all feedback you get as tasks that you must perform—if someone asked for it, it must be important, right?

Instead, validate feedback against your target audience definitions and user goals. Sometimes you’ll get feedback relevant only to a specific edge case that doesn’t make sense to document in the official documentation, or feedback related to a product bug that isn’t something necessarily appropriate to address in the documentation. 

5. Review analytics

Review documentation site analytics. Analytics are an imperfect source of feedback, but as long as you established a prior benchmark, check to see if the entry-level pages that you created or updated are the most popular pages. 

  • Are the pageviews higher, or at least somewhat proportional to the user base of your product? 
  • Are there any surprising outlier pages that have a lot of views that you might want to focus on? 
  • What search terms are popular? 

You can use these to inform your plans and priorities

Get from nothing to something with MVD

It can be intimidating to create a set of documentation for a product from scratch, but I hope this post outlines a basic approach that can help.

Diagram showing an empty circle with a dotted line border and an arrow pointing to a pink shaded square labeled MVD, which points to a larger pink filled in square labeled full featured documentation.

Start by defining what MVD looks like for your product by talking to colleagues, performing a competitor review, and assessing the current state of documentation. Then do some additional research and define the initial structure of your documentation. 

After you’ve laid the groundwork, start writing. Focus on key information for customers and identify the simplest path to success. Clarify any product and task complexity, and seek out feedback. Regularly make changes to what you’ve written as you learn more about the product and your customers. 

As you evolve beyond MVD to full-featured documentation, work through your backlog, suggest product improvements, write use cases and examples, and continue asking for feedback. You can also review site analytics to get a sense of how far you’ve come and what you might want to focus on next. 

Whether you’re a professional technical writer, a committed startup founder, a generous open source contributor, or someone else, I hope you can use this framework to document your software product.

I tried my best to create a minimum viable blog post to describe this minimum viable documentation framework. As such, I might not have gone into much depth about how to perform a competitor review, get buy-in for terminology proposals, or how to handle the full range of feedback you might receive on your documentation. 

If you have feedback or questions for me, or want to see more details about a specific topic, don’t hesitate to reach out on Twitter @smorewithface

Repersonalizing Digital Communications: Against Standardizing and Interfering Mediations

Back in 2013 I wrote a blog post reacting to Cristina Vanko’s project to handwrite her text messages for one week. At the time, I focused on how Cristina introduced slowness into a digital communication that often operates as a conversation due to the immediacy and frequency of responses. Since 2013, texting has grown more popular and instant messaging has woven its way into our work environments as well. Reinvoking that slowness stays relevant, but careful notification settings can help recapture it as well. 

What I want to focus on is the way that her project repersonalizes the digital medium of communication, adding her handwriting and therefore more of her personality into the messages that she sends. I thought of this project again while watching a talk from Jonathan Zong for the Before and Beyond Typography Online Conference. In his talk, he points out that “writing is a form of identity representation”, with handwriting being “highly individualized and expressive”, while “in contrast, digital writing makes everyone’s writing look the same. People’s communications are filtered through the standardized letterforms of a font.” 

His project that he discusses in part of that talk, Biometric Sans, “elongates letterforms in response to the typing speed of the individual”, thus providing another way to reembody personality into digitally-mediated communications. He describes the font as “a gesture toward the reembodiment of typography, the reintroduction of the hand in digital writing.” It’s an explicit repersonalization of a digitally-mediated communication, in much the same way Cristina Vanko chose to handwrite her text messages to do the same. Both projects seek to repersonalize, and thereby rehumanize, the somewhat coldly standardized digital communication formats that we rely on. 

Without resorting to larger projects, we find other ways to repersonalize our digital communications: sharing stickers (I’m rather fond of Rejoinders), crafting new expressions (lol) and words, and even sending voice responses (at times accidentally) in text messages. In this way we can poke at the boundaries of the digital communication methods sanitized by standardized fonts for all users.

While Jonathan stayed rather focused on the typography mediation of digital communication due to the topic of the conference, I want to expand this notion of repersonalizing the digital communication methods. Fonts are not the only mechanism by which digital communications can be mediated and standardized—the tools that we use to create the text displayed by the fonts do just as much (if not more). 

The tools that mediate and standardize our text in other ways are, of course, automatic correction, predictive text, and the software keyboards themselves.

Apple is frustratingly subtle about automatic correction (autocorrect), oftentimes changing a perfectly legitimate word that you’ve typed into a word with a completely different meaning. It’s likely that autocorrect is attempting to “accelerate” your communications by guessing what you’re trying to type. This guess, mediating your input to alter the output, often interferes with your desired meaning. When this interfering mediation fails (which is often), you’re instead slowed down, forced to identify that your intended input has been unintentionally transformed, fix it, perhaps fix it again, and only then send your message.

Google, meanwhile, more often preemptively mediates your text. Predictive text in Google Mail “helps” you by suggesting commonly-typed words or responses.

Screenshot of Google Mail draft, with the text Here are some suggestions about what I might be typing next.  Do you want to go to the store? Maybe to the movies? What about to the mall?  What do you listen to? Sofi Tukker? What other DJs do you have? Where "have?" is a predictive suggestion and not actually typed.

This is another form of interference (in my mind), distracting you from what you’re actually trying to communicate and instead inserting you into a conflict with the software, fighting a standardized communication suggestion while you seek to express your point (and your personality) with a clear communication. Often, it can be distractingly bland or comical.

Screenshot of google mail smart responses, showing one that says "Thank you, I will do that." another that says "thank you!" and a third that says "Will do, thank you!" In Google Mail, this focus on standardized predictive responses also further perpetuates the notion of email as a “task to be completed” rather than an opportunity to interact, communicate, or share something of yourself with someone else. 

Software keyboards themselves also serve to mediate and effectively standardize digital communications. For me personally, I dislike software keyboards because I’m unable to touchtype on them (Frustrated, I tweeted about this in January). Lacking any hardware feedback or orientation, I frequently have to stare at the keyboard while I’m typing. I’m less able to focus on what I’m trying to say because I’m busy focusing on how to literally type it. This forced slowness, introducing a max speed at which you can communicate your thoughts, effectively forces you to rely on software-enabled shortcuts such as autocorrect, predictive text, or actual programmed shortcuts (such as replacing “omw” with “On my way!”), rather than being able to write or type at the speed of your thoughts (or close to it). Because of this limitation, I often choose to write out more abstract considerations or ideas longhand, or reluctantly open my computer, so that I have the privilege of a direct input-to-output translation without any or extensive software mediation. 

In a talk last June at the SF Public Library, Tom Mullaney discussed the mediation of software keyboards in depth, pointing out that software keyboards (or IMEs as he referred to them) do not serve as mechanical interpreters of what we type, but rather use input methods to transcribe text, and that those input methods can adapt to be more efficient. He used the term “hypography” to talk about the practice of writing when your input does not directly match the output. For example, when you use a programmed shortcut like omw, but also when you seek to type a character that isn’t represented on a key, such as ö, or if you’re typing in a language that uses a non-latin alphabet, a specific sequence of keystrokes to represent a fully-formed character in written text. Your input maps to an output, rather than the output matching the input. 

These inputs are often standardized, allowing you to learn the shortcuts over time and serving the purpose of accelerating your communications, but in the case of autocorrect or predictive text, they’re frequently suffering from new iterations—new words or phrases that interferingly mediate and change a slip up into a skip up, encourage you to respond to an email with a bland “Great, thanks!” or attempt to anticipate the entire rest of your sentence after you’ve only written a few words. Because I also have a German keyboard configured, my predictive text will occasionally “correct” an English typo into a German word, or overcapitalize generic English nouns by mistakenly applying German language rules. 

All of these interfering and distracting mediations that accelerate and decelerate our digital communications, alongside our ongoing efforts to repersonalize those communications, has me wondering: What do we lose when our digital communications are accelerated by expectations of instantaneous responses? What do we lose when they’re decelerated by interfering mediations of autocorrect? What do we lose when our communications are standardized by fonts, predictive text, and suggested responses?

Kill Legacy Apple Software

Benedict Evans pointed out in a recent newsletter, “there’s a story to be written about Apple feeling its way from a piecemeal legacy technology stack for services, evolved bit by bit from the old iPod music store of a decade ago, to an actual new unified platform, something that it is apparently building.”

I’d argue for a focused set of decoupled applications, rather than a new unified platform. iTunes has bloated beyond practicality. The App store doesn’t work well for users or developers. Here’s where I think the future of these applications lies.

Continue reading

Taylor Swift and Being Between Stars

Taylor Swift has been blowing up the music industry lately, first by surprising everyone with the beauty of her latest album. SNL dubbed it a result of Swiftamine, and I can certainly say I’m under the spell.

Then, pre-release, she removed her entire discography from Spotify. The Atlantic reflects on this decision by pointing out, “Owning music outright, instead of renting it through a streaming service, would be better for listeners and artists in the long run. Indeed, it would be better for just about everyone except Spotify.”

Continue reading

Quantified Health and Software Apps

I went on a bit of a Twitter rant last night, about how MyFitnessPal doesn’t give me much helpful data:

While it’s called MyFitnessPal, it doesn’t feel much like a pal, and feels more like a diet app than a fitness app:

It’s like a friend congratulating you for eating a lot of whole wheat, but making a face because the egg you ate has a lot of cholesterol in it, even if it’s the only egg you’ve eaten that week.

Continue reading

Software, Sharing, and Music

Here’s what was important this week…

Software is everywhere lately. My boyfriend asked me what I thought the next big website would be (after the success of Google, Myspace, Facebook, Twitter, etc.), and I realized it’s just as likely (if not more likely) to be a software application rather than a website. Paul Ford took some time to enshrine some works of software in a “software canon” — Microsoft Office, Photoshop, Pacman, the Unix operating system, and eMacs (which I’d never heard of until this essay came out).

Software has had a noticeable effect on our day to day lives (especially those with smartphones), but it’s also had a huge impact on music and the way it’s created, recorded, and produced. Fact Magazine went through 14 works of software that shaped modern music (electronic music started way earlier than I thought). One of those software applications is Auto-Tune, and the Sounding Out! blog happened to post about the history of Auto-Tune.


Continue reading

Women, the Web, and the App Takeover

Here’s what was important this week…

Today is Pi day. Here is more than you probably ever wanted to know about pi day.

Last Saturday, March 8 was International Women’s Day. Started as a revolutionary holiday to honor the achievements of women, International Women’s Day is recognized in many countries. However, in Nepal it is recognized by women only, rather than as a day where men pay tribute to the women. Nepal also has another holiday that only women observe:

“In early September in Nepal, Hindus – who make up 81 per cent of the country’s 30.5 million people – celebrate Rishi Panchami, a festival that commemorates a woman who was reborn as a prostitute because she didn’t follow menstrual restrictions. It is a women’s holiday, and so Nepal’s government gives all women a day off work. This is not to recognise the work done by women, but to give them the time to perform rituals that will atone for any sins they may have committed while menstruating in the previous year. (Girls who have not begun menstruating and women who have ceased to menstruate are exempt.)”

However, the interesting thing about a cultural distaste and monthly banishment that occurs surrounding menstruation, is that “they talk openly – more openly perhaps than the average teenage girl in the UK might – about what they use for sanitary protection. Some use sanitary pads, some are happy with cloths, although they dry them by hiding them under other clothes on washing lines.”

Continue reading