As someone who dabbles in both design and development, this is so close to web development that I can't immediately see where it would be useful to me. If I have to write React anyways, why not just build a small prototype?
The video positions this as a tool for designing around edge-cases and offloading work from the developer to the designer, but to me, the main difficulty in development are the edge-cases: "What are the possible errors that can occur when I call this API?", "What would be the most fitting design for the realities of our architecture?" It's as much the developer's job to solve them as it is the designer's.
The example, "What happens if the user backgrounds the app?", is a question that inherently must be solved through back-and-forth between the developer and the designer, because the designer might not understand the realities of the operating system (see iOS multitasking). It's easy to point to loading states or network errors as example edge cases, because they're well-known. But usually, the developer will be the first to discover such problems.
The video positions this as a tool for designing around edge-cases and offloading work from the developer to the designer, but to me, the main difficulty in development are the edge-cases: "What are the possible errors that can occur when I call this API?", "What would be the most fitting design for the realities of our architecture?" It's as much the developer's job to solve them as it is the designer's.
The example, "What happens if the user backgrounds the app?", is a question that inherently must be solved through back-and-forth between the developer and the designer, because the designer might not understand the realities of the operating system (see iOS multitasking). It's easy to point to loading states or network errors as example edge cases, because they're well-known. But usually, the developer will be the first to discover such problems.