It wasn't that long ago that we designed webpages, a vestigial reference to another form of media, printed pages. That changed as the web medium grew more robust. Randy Hunt in Product Design for Web emphasized calling the medium being designed screens as if to denote something more interactive or dynamic that pages.
It was apparent in 2010 that the web wasn’t simply an evolution of past analog media but a different organism. This was apparent in how we now referred to screens rather than pages. Today, the virtual DOM, along with other evolutions like continuous deployment and feature flagging indicate that the web is again becoming a different idea.
In place of pages and screens, complex and continuous apps now deal with an order of magnitude more system states, representing a massive increase in complexity and state explosion. Along with this complexity comes a higher possibility of introducing faults in the design process. I use the term Fault Design to suggest a methodology of uncovering faults or failures within a system and finding resolutions prior to development. Faults such as content hierarchy and accessibility are easy to address while blank states or null states might be harder to spot without a more robust mapping of an app, regardless faults are endemic to app building. One approach to fault design might be statecharts.
Statecharts are defined as "A visual formalism for complex systems." State machines are an abstraction of a machine that inhabits a given state from a finite list of states. It is somewhat analogous to user flows but centered on the machine where the user drives actions as a state is entered or exits.
States can also be driven or differentiated by user segments and software releases all the way down to components and interactions. It isn't that low fidelity sketches or paper prototypes aren't useful but that they fail as the gap between intended and implemented software design widens. As a product team moves from discovery conversations, which is the most abstract, to defining a product spec, faults are addressed through iterative design work. A paper prototype might uncover faults in flows. Similarly, a lofi mockup might reveal faults in hierarchy or content.
Lacking however from the design process is a method to manage the various states that each screen or component might exist as. A given screen might be served up slightly differently for each user type or their flows could diverge. In current practice this is often done through some amount of tedious work, duplicating artboards for each state, or by capturing states in documentation for reference. Statecharts offer another method for designing and documenting a system.
Statecharts to map a feature
Statecharts as a UI todo list
Statecharts to define microinteractions
