Designing systems
Facets of good system thinking
Based on notes from this article:
Working atomically / Defining the basics. This automates system-wide changes and avoids rework and unintended consequences.
Making things reusable early and often. Actively evaluate parts to optimize for reusability. Don’t optimize too early.
Respecting the butterfly effects. When designing a system, nothing happens in isolation. Something that feels like a small change in one place can amplify into massive revisions on the other end of your system.
Oscillating between micro and macro vision. Never lose sight of the wholeness and coherence of your system while you’re considering even the smallest details.
Empowering yourself (or others) for exploration. A system that’s too prescriptive will stifle creativity. Systems need to evolve organically over time. Defining a system means finding the balance between consistency and flexibility. Design for emergence and disobidience.
Rationalising your decisions against the system. If you can’t explain why your choice is the right one, it’s probably wrong!
Documenting your system. This can be a laborious task, but you need to document the decisions you make so they can understand the system you’ve created. If you work alone, that documentation still happens, but it may be all in your head — never externalised.
Designing systems
- Start where the product most benefits from the coherence offered by a system. For example, a component that’s being used extensively.
- Try to remain in the habit of tackling the smallest problem you can.
- Apply a hypothesis to the problem at hand; if it works, change the parameters of the problem. Continue this process until the solution breaks, expand the scope of the solution accordingly, and—if you’re comfortable with the current solution’s ability to adapt—make the solution available for use, with the promise of it becoming even more suitable in the future.
- When creating something brand new to solve a problem, ask yourself: What implications does this have on the rest of the system? How can I change the solution to fit those rules, or limit the changes to those rules?
- Avoid context to determine the beahvior or appearance of a component.