Foundations · v0.2
Synchronized processes, evolving systems
The original proposal of SyncThinkDesign, with its own vocabulary and scope. The rest of the site is subordinate to this page.
How to read this page
Here are the principles (F) of SyncThinkDesign: they express the proposal and are not proven; they are adopted, debated or rejected. The aspirations (A) are what the proposal wants to become. The tools for applying it and the hypotheses about its effects are in the formalization; its technological implementation, in AAA3. Neither of those two layers redefines what is said here.
The central idea
SyncThinkDesign proposes understanding the creation of systems as the evolution of a system through synchronized, interdependent and continuously fed-back processes.
The word system is deliberately broad: it can be software, a service, an organization, a course, a work of art or an ecosystem of tools. What matters is that it is conceived, built and used, and that those three things do not happen once and in order, but overlap throughout its life.
The four processes
Capture (Sync), Ideate (Think), Execute (Design) and Optimize (Refine) are processes able to operate in parallel, influence one another and change the evolution of a system while it is being conceived, built or used.
| Process | What it is in SyncThinkDesign | What changes compared with a sequence |
|---|---|---|
| Capture (Sync) | Continuous gathering of data, signals and context throughout the system's life. | It does not happen only at the start: it informs the other processes while the system evolves. |
| Ideate (Think) | Generation of ideas that happens in parallel with capturing, executing and optimizing. | Ideas do not wait until the end of a cycle to be validated; they are tested as they emerge. |
| Execute (Design) | Building that evolves with every new capture and ideation. | There is no waiting for a complete design before starting: executing is part of designing. |
| Optimize (Refine) | Continuous improvement that happens alongside the other processes. | It is not a later phase: each part is improved while it evolves. |
- CaptureSync↓ Ideate: data and context
↑ Ideate: what to observe - IdeateThink↓ Execute: ideas and decisions
↑ Execute: findings - ExecuteDesign↓ Optimize: the system in use
↑ Optimize: improvements - OptimizeRefine↓ Capture: new questions
↑ Capture: signals - Evolving system
Synchronization
Synchronization over sequence. The information one process produces can affect the others without waiting for a phase to close. Synchronizing does not require literal simultaneity or zero latency: response time depends on the nature of the system.
This is the principle the others follow from. It does not say how information must flow —a conversation, a board, a document, the system itself in use— but that it must not be held back waiting for a stage to end. There are many ways to achieve it, and the formalization describes some without claiming to exhaust them.
Organic, continuous evolution
Organic, continuous evolution over rigid sequences. A system can change its goals, its structure, its components and its behavior as a result of the continuous interaction between its processes.
Evolution and iteration are not incompatible. A continuous evolution can contain thousands of small iterations, as well as reviews, deliveries and versions. What SyncThinkDesign questions is that the system should have to wait to complete a whole phase or cycle before taking in relevant information. No fixed cadence defines the method.
Emergence over exhaustive planning. Solutions can arise from the interaction between synchronized processes and not only from a plan defined in advance. Planning remains useful; what is questioned is the pretension that the plan determines everything.
Adaptive systems over static products. Each project can be understood as a system that adapts to its environment and keeps changing, rather than as a finished artifact. The comparison with living systems is a conceptual analogy: it helps us look, it does not claim to explain.
Validating, optimizing and capturing without pause
Continuous validation over final verification. Ideas and decisions are tested while the system evolves, not only at the end of a cycle.
Optimization integrated into evolution. Improving is not a phase that comes after creating. Each part of the system can be optimized while it evolves.
Permanent capture of information. Observation of the system, of the people who use it and of its context accompanies its whole life, and feeds the other processes as it happens.
People and organization
Breaking down functional silos. If research, design, development and improvement live in isolated teams or moments, synchronization becomes impossible. Processes need channels through which to influence one another.
A synchronous mindset. Applying SyncThinkDesign calls for a disposition before a tool: accepting that what is being built today may change because of what is observed tomorrow, and organizing work so that this is possible.
Complexity and uncertainty as possible sources of innovation. What cannot be foreseen is not only a risk to manage; it can also be the origin of solutions no plan would have contained.
Design as evolution
Design is also the way something evolves. Designing a system includes deciding what can change in it, what information makes it change and who can take part in that change.
What SyncThinkDesign does not require
- That the four processes literally work at the same time, or respond in zero time.
- Any particular tool, format or record.
- That every creative, organizational or technical decision be framed as a refutable hypothesis.
- Giving up planning, iterating or releasing versions.
- That everything change at once: one part of the system can stay stable while the others keep evolving.
Scope
SyncThinkDesign is not limited to software, integrations or projects that use artificial intelligence. The original proposal speaks of ecosystems, and we keep them as fields in which to examine it. We do not claim it works better in all of them: we present them as a proposal open to experimentation.
| Ecosystem | What evolves | What synchronization could look like |
|---|---|---|
| Technological | Software, platforms, integrations between systems. | Real use changes what is being built, without waiting for the next major version. |
| Experience | Interfaces, services, interactive experiences. | What is observed in the people using something changes its design while it remains in use. |
| Organizational | Processes, structures, ways of coordinating. | What one operation learns changes another area's decision without going through a yearly cycle. |
| Creative | Works of art, music, design, audiovisual production. | What appears while executing a piece changes the idea of the piece. |
| Educational | Courses, programs, materials. | What is observed in learners changes the course while it is happening. |
| Strategic and service design | Strategies, service models. | Signals from the environment change the strategy without waiting for the next planning round. |
That SyncThinkDesign can be examined in technological, organizational, creative, educational, strategic and service-design contexts, and that those examinations also say where it does not help.
What applying it is expected to bring
The original proposal holds that synchronizing processes shortens timelines, increases adaptability, lets quality emerge from continuous validation and speeds up the appearance of new solutions. We keep those expectations, but not as facts: they are hypotheses H1, H2, H3 and H4 of the formalization, and they need evidence.
Relation to other approaches
SyncThinkDesign does not replace other frameworks: it seeks to integrate with them and contribute the synchronization between processes they tend to treat separately. The table sums up, as honestly as we can, what it recognizes in each and how it relates.
| Approach | What STD recognizes | How it relates |
|---|---|---|
| Concurrent engineering | Overlapping phases that used to be sequential in order to catch problems earlier. It is the most direct precedent. | It shares the overlap. STD puts the emphasis on the system's evolution and on emergence, and carries it into areas beyond manufacturing. |
| Agile / Scrum | Short iterations, adaptability, incremental delivery. | Sprints can live inside STD; what STD adds is continuous synchronization between the four processes, also within a sprint. |
| Design Thinking | Human-centered, empathy, creative ideation, prototypes. | STD shares co-creation, but does not separate research from building, or ideation from validation. |
| Lean Startup | Hypothesis validation, minimum products, pivots. | It is the closest relative. STD proposes that capturing, ideating, building and measuring run at the same time on different parts of the system, not only in successive turns of a loop. |
| DevOps | Continuous integration, automation, monitoring. | It shares the coupling between building and operating; STD extends it to the ideation and observation that come before the code. |
| Human-centered design | Focus on human needs, contextual research. | STD makes research a permanent process that feeds the others throughout the system's life. |
If STD contributes something of its own, we believe it lies in taking the evolution of the system as its object —not only the delivery of a product— and in asking how synchronization between processes changes it, including the appearance of results nobody foresaw.
Aspirations
That anyone can apply and study SyncThinkDesign without depending on proprietary tools.
That studies by third parties come to exist, including those that contradict the proposal.
References
- Winner, R. I., et al. (1988). The Role of Concurrent Engineering in Weapons System Acquisition (IDA Report R-338). Institute for Defense Analyses.
- Takeuchi, H., & Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review, 64(1).
- Holland, J. H. (1995). Hidden Order: How Adaptation Builds Complexity. Addison-Wesley.
- Ries, E. (2011). The Lean Startup. Crown Business.
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
- Brown, T. (2008). Design Thinking. Harvard Business Review, 86(6), 84–92.
- Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook. IT Revolution.
History
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-10-27 | First documentary version. It reduced the proposal to an operational definition centered on detecting false assumptions. |
| 0.2 | 2026-10-28 | The founding conception is restored: synchronization as continuous mutual feeding, evolution, emergence, adaptive systems and a cross-domain scope. The operational definition moves to the formalization, subordinate to these principles. |