Iterative development works best when design and implementation co-evolve gracefully in the presence of late discovery. Adam Solove suggests that shared enumeration of control states and state transitions will provide the necessary coordination. medium 
A major change has been a focus on explicitly describing display states. The designer creates an artboard with side-by-side designs of each of the widget’s states. The code similarly branches on those same states.
We can see a strategy to apply whenever a problem becomes too complex for teams to think and communicate about together:
▶︎ Look for a missing idea not explicitly reflected in the problem’s current representation.
▶︎ Find a new representation that makes that idea explicit and helps us represent what we know and what we still need to think through.
▶︎ Then, only at the end, worry about the technology and process to use to bring this representation to life.
The idea we’re still missing is that of an application’s control state. Previously we enumerated all of an interface’s display states as all the meaningfully different ways it should display. A control state is all the possible states of the interface that have different sets of allowed interactions.
Control states can be naturally represented in our code. No longer should we define a single handler for each button, with lots of cases inside it depending on the action history. Instead, transitions are defined for a specific pair of the current control state and the action. If your language supports some kind of pattern matching, this can turn into quite lovely code.
.
Swim Test-Case Visualization made good use of a common representation for states and transitions in the form of automated tests cataloged by panel, button and email emitted. page