A Content Designer’s README

How a best practice in software documentation helped me be vulnerable and build trust

Ashlee Phillips
4 min readMar 11, 2021
Image credit: Frank Abgrall

When I joined my team in 2020, I had not stepped foot in the office let alone met a co-worker in real life. I was having a difficult time feeling connected, reading people, and opening up. Vulnerability and transparency are major aspects of collaboration, so when there’s something in the way, like screens, the working relationships and the work suffer.

Enter: README.

Generally used for software documentation, README files introduce and explain a project. It helps people understand what’s going on under the hood, so to speak.

Simple, straightforward and tech-oriented (perfect for my engineer cohort), README seemed like the best way to:

  • Explain my role
  • Describe what to expect from me as a partner
  • Explore my working style
  • Highlight my principles and goals

README

What I do

10% of my time is spent writing. I’m a grammar expert, plain language lover, and editor. But most of the time, I’m collaborating with cool peeps like you, not writing. I’ll be reaching out to Legal, other writers, engineers, data scientists — to name a few — before my pen touches paper (or fingers tap keys?).

I’m not sentimental about my writing — give me feedback! Straight up, I love to hear how my words are hitting you. Doesn’t mean I’ll change it, but any chance to defend or discuss what I’ve written is precious.

Let’s follow a process (or at least a consistent routine). Look, I get it. Not everyone loves coloring inside the lines. With that said, consistent work comes out of practice and repetition. Is it sexy? No. Does it produce great work? Totes.

In meetings, know that I think by thinking, not talking. If I’m quiet in a meeting, I’m processing. I thrive with time to think and prepare. I’ll speak when I’m ready, or I’ll follow up with key questions or insights. In 1:1s, it’s a different story entirely.

I’m here to help. That’s it. If I can make your job simpler, I want to do that.

Tell me about you. When was the last time you touched a monkey? What do you think of the taste of horse? Was your dad cheap when you were growing up? Let’s dish, bish!

My goals

  1. Bring value to my teams and teammates.
  2. Represent writers.
  3. Bridge any gaps between design, experience, implementation, and content.

My principles

Serve the team, and serve our users.

Stand together.

Share the workload, success, and failure.

Be candid, not offensive.

Miscellaneous mentions

I’m an introvert. Hopefully, that’s no biggie. I might not attend every social function, and if I do, I’ll keep to myself a bit. Get me in a 1:1, though, and I’m animated, bubbly, and talkative.

I take an “always learning” approach. I don’t know everything — how exciting is that? But I have a hard time asking questions, so I research and study to feel more comfortable (read: prepared) in meetings.

I love what I do. Like most content designers, I found this job through an eclectic mix of writing gigs. The more I grow my craft and build community, the more I love it.

I look forward to working with y’all. You’ll be another reason I fall deeper in love with content design.

My bookshelf

“I’m not saying that you have to be a reader to save your soul in the modern world. I’m saying it helps.” — Walter Mosley

A small-ish request

If, after reading this, you find areas where I’m not meeting these standards, put me on blast. This document’s a living, breathing organism — both of us are evolving. Reach out with any specific feedback.

My product designer, Kenny liked my README so much he mentioned it in my end-of-year review. He said:

It gave me insight into how to better work with her and help me understand how she thinks about her role.

If you’re struggling to build a solid working relationship (especially on fully remote teams) or want to explore your working style, a README could help you break the ice. Feel free to use mine as a template.

--

--