We can design a game from theory first: start with a premise, decide on major goals, and then design systems and mechancis that will function, while meeting all the goals, and still adhering to the premise.
I'm reading Fred Brook's The Design of Design. (Brooks is the author of the more famous The Mythical Man-Month.) It tackles the commonalities of all design processes, though he is focused on fairly technical ones. I am reading it both as a sometimes-progammer and as a graphic designer. Brooks addresses work in teams, and this is something I've been thinking about in my professional life. One thing has struck me so far. Brooks views design as a fundamentally iterative process, which agrees with my thoughts and experience -- but I had not seen iteration in the same places.
If a bank is creating new paper notes, what sizes should it issue to make transactions easiest for the public? This is one example of an type of problem I've become interested in. It is basically about how to divide a scale into discrete intervals, under various constraints. It seems very abstract, but it actually has a lot to do with real-world design and engineering.
Graphs and charts often mislead by obscuring the unreliability of their source data. But even if a graph-maker wants to do better, it can be hard to present such information intelligibly, without long or technical sidebars. Here is one approach for visually displaying both the primary data, and their reliability, in one graph.