A UI Designer‘s Guide to Communicating with Developers Using FSM Tables

As a UI designer, you pour your heart into crafting elegant, intuitive interfaces. But have you ever struggled to get developers to implement your vision? Found yourself redesigning components because you forgot to specify a loading state?

If this sounds familiar, I‘d like to introduce you to a powerful tool: Finite State Machine (FSM) tables. In this guide, I‘ll show you how FSM tables can help you comprehensively define UI states and effectively collaborate with developers. Let‘s dive in!

The States of UI Design

Before we explore FSM tables, let‘s clarify some terminology. A UI state is the configuration of a component at a moment in time, usually in response to a user action or system event. One state may have multiple possible views.

For example, consider a simple submit button. It might have the following states:

• Default – button is enabled, awaiting click
• Loading – button is disabled, request in progress
• Success – button is disabled, request completed
• Error – button is disabled, request failed

Each state could have several visual treatments. The loading state might show an animated spinner, progress bar, or "Submitting…" text. So while there are five common UI states (default, loading, success, error, disabled), a component may have dozens of potential views across those states.

As designers, our job is to define these states and specify when and how they occur. But all too often, designs are passed to developers with states missing or poorly defined. That‘s where FSM tables come in.

The Trouble with Traditional Approaches

Traditionally, designers have used flowcharts to illustrate UI states and navigational flows. While flowcharts are great for showing high-level relationships, they have some key limitations:

• Inconvenience – crafting and updating editable flowcharts requires cumbersome software
• Imprecision – flowcharts don‘t cleanly specify which states require unique views or what prompts state transitions
• Complexity – using the right symbols and layout to produce a comprehensible flowchart is deceptively difficult

Interactive prototypes can demonstrate state transitions but are time-consuming to produce and don‘t provide a clear map of all states and pathways. Spreadsheets of notes are better than nothing but lack visual clarity.

Designers need a better solution for defining and communicating UI states. Enter the FSM table.

The Power of FSM Tables

An FSM table is a concise, systematic way to represent all possible states a component may occupy and what triggers transitions between states. It‘s used in computer science to model everything from vending machines to video games.

Here‘s a simple FSM table with three columns:

Current State	Action	Next State
Default	Click	Loading
Loading	Request Completes	Success
Loading	Request Fails	Error
Success	Reset	Default
Error	Reset	Default

At a glance, this table tells us:

• All possible states (default, loading, success, error)
• What actions are allowed in each state (click in default, request completion in loading, reset in success/error)
• What the next state will be after an allowed action

Compared to flowcharts, FSM tables have several advantages for UI design:

• Comprehensive – it‘s easy to spot missing states or transitions
• Precise – allowed actions and views per state can be clearly specified
• Simple – the tabular format is quick to create and readily understood by developers

But how do you actually go about creating an FSM table for your UI components? Let‘s walk through an example.

Designing a Login Form with FSM Tables

Consider a login form containing:

• Header
• Username field
• Password field
• Login button
• Alerts

Our goal is to comprehensively define the states of each element and how they interrelate. We might begin with a high level flowchart:

This gives us an overview, but we need to specify at a more granular level. For example:

• When is form validation triggered?
• Should the login button be disabled until the form is valid?
• How do we handle empty vs invalid inputs?

To define these behaviors, let‘s create an FSM table:

Element	Current State	Action	Next State	View
Username Field	Default	Focus	Active	Standard
	Active	Blur (empty)	Error	Red outline, "Required" alert
	Active	Blur (invalid)	Error	Red outline, "Invalid username" alert
	Active	Blur (valid)	Default	Standard
	Error	Focus	Active	Standard
Login Button	Disabled	Form valid	Enabled	Green fill
	Enabled	Click	Loading	Spinner icon
	Loading	Request completes	Success	Checkmark icon
	Loading	Request fails	Error	Alert icon

This table provides a complete specification for the form‘s behavior:

• Validation is triggered on field blur
• Specific views for empty and invalid states
• Login button disabled until form is valid, with loading states

Since FSM tables are quick to produce, we can rapidly iterate on them to optimize the user experience. Should we validate on every keystroke or only on blur? Disable the login button until the form is valid or leave it enabled and show an alert on submission? With FSM tables, these options can be mocked up and discussed with minimal effort.

Beyond Forms

FSM tables aren‘t just for forms. Any UI component with multiple states can benefit from being specified this way.

For instance, say our login page header should shrink and switch to a solid background as the user scrolls down, like on this beautiful site. We could define that behavior in an FSM table:

Element	Current State	Action	Next State	View
Header	Large	Scroll > 100px	Small	50px height, white background
	Small	Scroll to top	Large	200px height, transparent

Now developers know exactly how to implement the desired behavior without lengthy back-and-forth discussions.

Bridging the Designer-Developer Divide

By combining wireframes, flowcharts, and FSM tables, UI designers can arm developers with a comprehensive blueprint for any user interface:

The wireframes provide the visual design, the flowchart maps out user paths, and the FSM tables exhaustively define component states and interactions. With this trio, designers can communicate their vision with precision, while saving countless hours of spec revisions and redlines.

But the benefits extend beyond efficiency. By adopting FSM tables, designers naturally begin to think more systematically about their interfaces. Edge cases and error states come to the fore early in the process, resulting in more robust, fault-tolerant designs. Designers and developers begin to speak a common language, reducing friction and enhancing collaboration.

Leveling Up Your Designs

UI design is hard. Designers today are expected to craft experiences that are not only beautiful, but robust and intuitive across a dizzying array of screens and states. Meeting these challenges requires both creative talent and systematic thinking.

FSM tables are a powerful tool for modeling UI states and behaviors. By incorporating them into your process, you can design more comprehensively, communicate more effectively, and elevate your collaboration with developers.

I hope this guide has given you a solid foundation for starting to use FSM tables in your own work. Give them a try on your next project — I think you‘ll be surprised at the clarity and efficiency they can bring. As always, I‘d love to hear about your experiences and any additional tips you discover.

Let‘s transition to more effective designer-developer collaboration with FSM tables. Your users (and developers) will thank you!