A solution by design lives inside and out
I trained in project management and have led design implementations, so I tend to look at the details and the whole as part of my regular process. I first learned to see the triangle of constraints (scope, time and budget) behind stakeholders' decisions, the focus of priorities and the pressure on a team. Over time, I've learned to recognize how many more things affect the balance of a project, and of my own design work.
For me, design happens inside and out. Inside is the thing being designed and its own logic. Out is everything around it: the team, decisions, communication, knowledge, constraints, resources and stakeholders. Projects tend to converge around an imperfect state of constant input, adaptation and output, held within the pull of all these elements as a whole.
This pull is unique for each place, team and project. Processes, standards and established systems give you a head start. But honesty has to transform them: the real state of the team, its resources and skills, the quality of its relationships and communication. Then, while priorities shift the focus and constraints press on specific points, the frameworks guide the path toward the goal. So they serve as foundation, road map and aspiration, but never as a script for how each step should or will be performed at any given moment.
Once, I had to design a feature for an app whose Figma file was far behind the live product. The standard runs from design to code, but the real state of the project was that everything was handled directly in the code. So, honesty led me to reverse the direction: tokens in code became the source, prototypes were built on them, and Figma was generated afterwards. It cost us unaccounted-for time, scope and budget up front, but then the speed of the process and the consistency of each delivery absorbed the difference, and we got to flatten the rhythm and meet the deadline without strain, with a clearer standard for our internal processes and a higher level of quality and consistency in delivered tasks. The next stages started from a stronger framework, with a handoff document that labeled every decision, which helped to keep the improvements ahead in sync, and kept design-development collaboration as an open, continuous channel.
This state of constant adaptation based on honesty and standards is what I call a good enough system. It lets me be guided by frameworks, but also by logic and coherence. As long as there is a clear goal, proper resources and a team willing to adapt, it's like magic happening, and professional growth and impact reach new heights regardless of the size of the team or the task at hand.