Interesting take. I do think state-charts (and state machines) can potentially be a huge benefit to both design and development. However, your login/auth exam

Interesting take. I do think state-charts (and state machines) can potentially be a huge benefit to both design and development. However, your login/auth examples are really poor fits for this kind of solution. While you could use statecharts, you could also just use generalizable global form validation. There's not a lot of benefit in defining statecharts for common UI paradigms. That said, here's an example from my own recent experience where formal statecharts/state machines became a necessity to even move forward. My colleague published a finite state machine for swift (https://github.com/softwarenerd/Stately https://github.com/softwarenerd/Stately) that grew out of necessity from a project we worked on together. The project (https://news.microsoft.com/videos/cities-unlocked-a-voyage-of-discovery/ https://news.microsoft.com/videos/cities-unlocked-a-voyage-o...) was creating a turn by turn navigation system for the blind. From a workflow perspective (and UI/UX) it was never terribly complex. There are a handful of primary actions, with a handful of intents and a single common workflow with branching outcomes. Over time and iterations, we reduced the workflow complexity quite a bit further as well. But we kept having more and more functional regressions and exploding bug counts as more and more subsystems and capabilities were integrated into the experience. The issue was that, while workflow and UI were both simple, the number of potential application states exploded. For a long period we used simple if/then logic, followed by tracking increasingly global variables to detect state conflicts/dependencies during flows. This was messy at best and became an unmanageable nightmare. Enter the state-chart. We followed nearly the same process as you've outlined, with visual charts first. It gave us the initial frame to build a state machine from, followed soon after by sub-hierarchies. It worked well for us because the majority of our states were not many:many interdependent. Most states had a 1:1 or 1:few correlation with others. Statecharts likely aren't the next big UI paradigm because most applications are driven by workflow (Line of Business apps) or by state machines that are already well-known (form validation, auth, network graph navigation, CRUD, etc) where those charts are already implicitly well handled by browsers, services or existing frameworks. I think the magic area for statecharts is in applications with many independents or semi-linear state workflows that don't match up to visual or experiential interaction workflows.