Whiteboard.docx

If you want to win me over, start talking about document management and file structures. It’s one of my nerdier obsessions. An endless source of debate and experimentation. Where do you put that file? What do you call the folder? How do you know which doc is which? If you’re nodding off, bail out now—no hard feelings. If you’re still with me, keep reading.

Designers, I feel, are predisposed to thinking about these things. And it’s reinforced through education and professional practice. We work with versions, we work with imagery, fonts. We share files with vendors and deliver projects to clients.

If you dive into the world of web development, these things become even more important. Your website works because of a single file located in a specific directory on your server. When you don’t sweat the details, you get an error.

But what about the rest of the working world? How do you organize TPS reports? Does anybody really care?

I’ve been working in a strictly-managed Windows 10 environment using Microsoft Office 365 for the past two years now. The learning curve was steep, coming off of 10 years using macOS exclusively.

A big focus of my design career has been about breaking down perceptions that “good design” only happens in Adobe software. That clients will always “ruin” the web design. That the output of a designer is precious. To that end, I’ve spent a great deal of time thinking about accessibility, approachability of creativity and of the creative process.

One way to make creativity approachable is to sweat the details and simplify, simplify, simplify. Go to town on your file management systems, like an auto mechanic under the hood of a clunker throwing out spare tubes and gaskets and whatnot.

One day I might come back and talk about the different systems I’ve tried, but for now I’m going to focus on what I’m practicing today.

How do projects typically start? In my case, it’s usually an email. Or a meeting. Or a passing comment. It’s an idea from someone’s brain, filtered through another brain, and thrown out into the world for someone to catch—and I’m like an old-timey firefighter lining up underneath it with a life net.

Ultimately a project starts as information looking for a home. For me that home starts out as a slab of concrete—a digital blank slate—that I improve over time, as needed.

Some folks have templates and briefs and frameworks. Those are great when your projects are relatively predictable, or when you have time and support to flesh out details. But, for less mature teams, I have found structure like that can just as easily get in the way.

So I begin with a blank Word document. I have a style set that I’ve honed over time and turned into a template I can use to replace the built in Normal.dotx template. Starting with my opinionated defaults keeps me from fiddling with formatting. (Having a time-tested style set is a huge deal for type nerds like me.)

I live in Web View. That, combined with my opinionated defaults, turns MS Word into something more akin to Notion or Apple Notes. Removes the silly constraints of letter-sized paper. This document will never be printed.

I expand the Styles pane and anchor it to the right. (When the document gets larger, open up the Navigation pane and anchor it to the left.) And I’m ready to go.

This is my digital whiteboard (not to be confused with a digital whiteboarding app like Mural or Miro). Some people call it a scratchpad, a thinkpad, a working doc… I settled on the term “whiteboard” because the nature of this document is to capture and organize information and to develop ideas. Whiteboarding as a practice is fluid, messy, impermanent. If you’re lucky, you can take over a conference room and keep the whiteboard filled over time.

Finding the right metaphor is a key part of effective naming. It stops me from wondering if there’s something better, and it ensures someone else could come across the file and understand its purpose.

If the Chief Something Officer pulls me into their office to talk about a new project, I can simply open a new document and start taking notes. I’m capturing information, one bullet point at a time. I ask questions: Who else should be involved? When does this need to happen? What does success look like? I’m pulling on threads, wringing the sponge dry. I hit Save and give the whiteboard a simple, descriptive name with the right mix of logic and memorability. I can always update it later. I’ve designed the document to be as invisible as possible so my brain can focus on the information.

When it becomes clear what this project is about, I name this document “Vaccine Campaign Whiteboard.docx” where “Vaccine Campaign” is the name of the project. Simple.

I maintain a flat directory of projects in OneDrive. Each project gets its own folder. A project begins as simple as a folder and a corresponding whiteboard document: Vaccine Campaign > Vaccine Campaign Whiteboard.docx.

Right now the entirety of this new project lives in this one document. Later on I organize the information into sections, right there in the same doc. I keep the notes as-is and add a “Meeting Notes” heading. I add a “Deliverables” heading and pull out the notes about what we need to create. I add a “Timeline” heading, and an “Objectives” heading. I don’t worry about adding these headings ahead of time—I could, but I don’t. When the information rises to the surface, I capture it and organize it.

If I anticipate more meetings, I might retroactively create a separate “Vaccine Campaign Meeting Notes” document and move those original notes over there. I replace them in the whiteboard with a link to the new document. If I have other one-on-one meetings I simply add notes to that new document.

For more formal meetings with many stakeholders, I will typically create a dated agenda/notes document. After a lot of back and forth, I settled on a “MM DD YYYY Meeting – Project.docx” convention. Front loading the date in the file name is good for sorting, keeps meeting note docs together, and provides a mental cue to which meeting I might need to reference (did we talk about that last week or last month?). I gave up on DD MM YYYY and YYYY MM DD because, even though I believe they are more rational, they are not widely adopted formats.

I add links for each meeting notes doc to the whiteboard. If we’re having weekly meetings, I might create a “Meeting Notes” folder and link to that instead.

Sometimes I have a single “Project Support” subdirectory—like a junk drawer for reference files, previous versions. (I sourced that label from Getting Things Done.)

Other types of ancillary docs and subdirectories include: messaging and talking points; forms and deliverables; reference material.

The beauty of adding links is that the contents or destinations don’t have to live in the same place as the doc itself. When other people are working on the project, I link to their docs too. Websites, online resources? Linked.

If a project grows large enough, I might create a project index. The point of an index is to catalog and provide context for the key components of a project. In practice this looks like a list of links to other documents. The whiteboard was doing this, too, but those links start to get lost. And sharing a clean project index with new contributors is a better experience than having to wade through a whiteboard.

Speaking of sharing, it’s really easy to start a whiteboard doc and send it to other project contributors. When the tone is one of collaboration, the document doesn’t have to be perfect. You’re working on it together because it’s 2021 and everything is in the cloud.

All of this is a lightweight, homegrown solution to the challenge of adopting more complex project management tools. It’s simply capturing and organizing information.

You could call this something like “progressive project documentation” as a reference to progressive enhancement in web development. Maybe there’s already name for this. But it makes me think of a cell dividing and multiplying. Projects are not static. They are living, growing organisms.

I have opinions about version control too… but need to save them for another time.