Been creating a some quite complex documents recently. I find that I start thinking I’ll do something one way only to start building it and realising there is a better way.
Rather than just starting to build straight away, do any of you follow a more rigorous process that you have found helpful?
I have tried listing things out and sketching mindmaps and basic process flows but feel like I’m still missing something.
I want to be able to churn out docs like a machine because I have so many I want to create and don’t want to waste time!!
I recorded a series on how to approach building complex docs here:
There’s a post that preceded the series — it features some best practices in text form (faster to consume but nowhere near as complete):
For building systems of connected docs I suggest using Sync Tables Pro instead of Cross-doc right away. I just gently launched it last week:
P.S. Sometimes I do some sketching but usually I just follow my best practices to build docs that can adapt to changes. You can’t plan everything ahead anyway, but you can follow the system that will make it easier to make new changes as the doc evolves. My framework worked well for me and for the docs I built for clients in the past three years.
Beyond all the unmatched info Paul posted, the above point is what I go by also. Generally:
Follow K.I.S.S., make tables and features simple.
Avoid adding new features (columns, buttons, etc) unless you really need them. Things will become obvious as you use your docs over time.
Keep docs focused to specific responsibilities as much as reasonable, and use cross doc.
Make copies of docs to prototype big changes without breaking the existing doc.
When changing a column to behave differently or refactoring a system:
Create a new system (columns, buttons, etc) alongside the old system instead of modifying the existing one.
Add buttons to do data migration to the new system, if needed.
Hide the old system and show the new one.
Delete the old system once your new replacement is in use and working.
Finally, and this is a matter of taste, I try to minimize the number of Coda features that I use. The more formulas, functions, packs, settings, controls or configurations that are in use, the more complicated the document becomes and:
the more likely that a user uncovers an unsupported scenario or bug
the more knowledge is needed to extend and maintain the doc
In other words, just because you can doesn’t mean you should. Creating complicated docs is fairly fast and easy, but working with them over the years is more time consuming.