Living Docs

I‘ve been a big fan of the London-based agency comuzi for some time. One approach I copied from the team is the idea of a “living deck” or “living doc”.

In short: a Google Doc, that‘s used as a project documentation + project narration tool. It can be used to, quote:

• link to documents (spreadsheets, digital boards, other decks…)
• share interesting references
• document chats, ideas, crits, workshops…
• that “we should be keeping a list of these ideas somewhere” moment

María Izquierdo Alfaro wrote a longer article all around living docs on medium.

Another example is the “dashboard” Bryan Boyer used to remotely organize his “civic futures” course at University of Michigan Taubman College of Architecture and Urban Planning during.

How to use Living Docs

These are a couple of rules I made for using Google docs as an effective project documentation / project narration tool.

• Document everything — If it’s not in the doc, it didn’t happen.
• Write for your team — Don‘t write for yourself, document for your team.
• Create sub-docs as necessary — I usually work with one main document (called “basecamp”) as long as possible but often branch out into smaller more focussed docs for certain aspects or sub-projects that are linked in the main one.
• Structure, structure, structure — Never lose track, use headings logically, keep the table of contents in the sidebar clean.
• Latest first — The latest meeting, the latest update, the latest decision is always at the top.
• ’@’ is your best friend — Use the shortcut to insert dates, names, or elements without taking your hands off the keyboard.
• Pageless > Page — Google has the option to create page-less documents. They are usually easier to read and skim, especially long ones.

The WIP world

Yuhki Yamashita, CPO at Figma recently shared a rather insightful piece on how the use of docs as a room for work, rather the product of it, change the speed of it. Or as he‘s calling it “welcome to the work in progress world”.

Files are no longer static documents that you attach to an email and send to collaborators. Browser-based tools make it so that work can be shared with anyone, anywhere via URL, allowing everyone to look at and work on the same file at the same time. As it turns out, when people are able to iterate on their work in real time, they share it earlier, too. If you‘ve ever added a “[WIP]” or “Work in Progress” annotation to the title of your file, you know the power of an in-progress draft. It‘s a signal that lowers the stakes, letting any potential viewers know that this is, indeed, in progress. Designers can share early directions with product managers, just as writers can share rough drafts with their editors.

Though it should be noted (as Cennydd Bowles does) that using this WIP mode of work as an interface with the outside world might not be the most ideal approach. It smells a bit too much like Facebook‘s “move fast and break stuff”.

There‘s certainly a place for scrappiness in design, and a WIP-iterative way of working. But, whatever empirical dogmatists might have you believe, there‘s also a role for polish and finesse, even before launch. Advanced design expertise involves matching the approach to the scenario. I‘m not sure Figma understands or welcomes that fluidity.