A state machine is any device storing the status of something at a given time. The status changes based on inputs, providing the resulting output for the implemented changes. A finite state machine has finite internal memory.
Finite state machine (FSM) is an abstract machine that organizes all possible states and inputs. This methodology is commonly applied in programming and all kinds of devices. The FSM is just a collection of states and inputs. It’s that simple. Let’s take a deeper look at the usage of this table, and experience the power of it.
There are three columns in the table: From State, Input, and To State.
In the column From State, each cell represents one possible state the component can have.
The Input column contains the most important information in the table: what limited actions can be executed or inputs to receive in each state.
Finally, the To State column is in fact the output state according to the corresponding input.
The table clearly lists three things:
- All the possible states
- When each action can be completed
- The result of completing a certain action
Besides lowering communication costs, the FSM table encourages a mindset as well. It helps build a clear connection between cause and effect, preventing you from making decisions without the support of sound logic.
c. How to get initial ideas for FSM when conducting user interview
The below diagrams illustrate the two-sided nature (the screen is showing something on one side, and the user is reacting on the other side) with a bar. Above the bar is what the user sees. Below the bar is what they do. An arrow connects the user’s action to a new screen with yet another action. It’s an ongoing conversation.
The format is really fast to sketch, and it communicates the essentials of what needs to happen as I’m imagining it. For such simple examples, you don’t really need a shorthand. But for more complicated flows, especially of entirely undesigned sections of an app, the shorthand can illustrate a lot of behavior. Here’s a more complicated example for a log-in flow:
This log-in flow includes a few more notations. The dotted line separates alternate actions. There’s only one login screen, but there are multiple possible actions on that screen. The dotted appears above each additional action. Think of it as “or”. When there are multiple actions, the arrows point from an action to a new screen. Screens where the possible actions are uninteresting or out of scope simply have no bar below them. Like “Dashboard” in the diagram above.
After sketching, you would have all the From State, Input, To State to fill in the FSM table.