{"id":15502,"date":"2018-07-02T10:59:25","date_gmt":"2018-07-02T09:59:25","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=15502"},"modified":"2020-09-03T12:55:30","modified_gmt":"2020-09-03T11:55:30","slug":"design-ui-states-communicate-effectively-using-finite-state-machine-table","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/design-ui-states-communicate-effectively-using-finite-state-machine-table\/","title":{"rendered":"How to Design UI States and Communicate Effectively with Developers Using the Finite State Machine\u00a0Table"},"content":{"rendered":"

Life can be tough sometimes for UI designers. While they get to create great designs, they also get to deal with pressure from clients or PMs. They\u2019re required to consider user experience and user flow. And they often struggle to find an effective way to communicate with developers.<\/p>\n

To relieve some of the pressure from my fellow designers, I want to help by introducing a better way of handling UI components with state variations. I believe this is one of the biggest challenges designers face.<\/p>\n

Dealing with state variations of UI components is painful. At first, I thought it was so difficult because you need to create different views, which can be boring. But then I realized that design is not the terrifying part. Rather, missing states and telling developers exactly what you want are. So, this article will address these two issues.<\/p>\n

State and flowchart<\/h2>\n

To prevent the design team from failing to prepare necessary states, these<\/a> five<\/a> states<\/a> have been proposed as the norm for designers to follow. But for the sake of accuracy, I\u2019d like to point out the difference between a state and a matching view first.<\/p>\n

State is in fact the output of a UI component after receiving an input. One state might or might not need a matching view to interact with users.<\/p>\n

Therefore, a UI component can only have five states<\/a>, but each state can actually have various versions of the views. Confused? Let\u2019s take a look at an everyday example of a submit button, and I think you\u2019ll grasp it immediately.<\/p>\n

\"\"<\/a>

A submit button usually includes state of default, loading, success and error, and each state could have various\u00a0views<\/p><\/div>\n

But how do we know that there are three others states besides the initial one? And how do these states switch between each other? It\u2019s easier to understand this question by looking at a flowchart.<\/p>\n

\"\"<\/a>

Flowchart is not enough to tell design\u00a0details<\/p><\/div>\n

The method that helps us manage UI states is crucial. It should convey the message of what state the component should switch to after receiving certain input. But even though that flowchart is a powerful tool in most cases, it\u2019s not ideal for detailed state variations, because of these disadvantages:<\/p>\n

    \n
  1. Inconvenience<\/strong>. It requires the help of software or plugins (other than classic office or design software) to draw, modify, or maintain the chart. And it\u2019s huge.<\/li>\n
  2. Complexity<\/strong>. It requires extra attention when choosing correct symbols and colors.<\/li>\n
  3. Confusion<\/strong>. It\u2019s hard to tell which states require a view, and which inputs switch the states.<\/li>\n<\/ol>\n

    To sum up, it\u2019s inefficient and inaccurate to manage the states of UI components using a flowchart. I believe most designers would agree. So, I\u2019m now going to propose a better way here.<\/p>\n

    Finite State Machine (FSM)\u00a0table<\/h2>\n
    \"\"<\/a>

    FSM table inspired by Krasimir\u2019s FSM introduction<\/a><\/p><\/div>\n

    Designers, don\u2019t get freaked out by the tech-sounding name! Let me break it down.<\/p>\n

    What is the Finite State\u00a0Machine?<\/h2>\n

    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. Take a look at the finite state machine example of a turnstile illustrated in Wikipedia<\/a>, and you\u2019ll have a better idea right away.<\/p>\n

    Again, the FSM is just a collection of states and inputs. It\u2019s that simple. Let\u2019s take a deeper look at the usage of this table, and experience the power of it.<\/p>\n

    How to use the FSM\u00a0table<\/h2>\n

    There are three columns in the table: From State<\/strong>, Input<\/strong>, and To State<\/strong>.<\/p>\n

    In the column From State<\/strong>, each cell represents one possible state the component can have.<\/p>\n

    The Input<\/strong> column contains the most important information in the table: what limited actions can be executed, or inputs received, in each state.<\/p>\n

    Finally, the To State<\/strong> column is in fact the output state according to the corresponding input.<\/p>\n

    Why is this\u00a0better?<\/h2>\n

    The table clearly lists three things:<\/p>\n