State Machines As a Means of Collaboration

State machines and statecharts are an incredibly powerful way to manage the state of your application¹. In recent years, the XState library has made applying this approach to user interface development more popular. I’m a huge fan and have already promoted its use at two companies and seen it improve the developer experience and product quality in both cases.

State Machines Are Highly Visual

Aside from providing explicit rules around application states, state machines and statecharts are easy to visualize. With a few simple shapes, you can model even a complex statechart on paper with pencil. Luckily, you don’t have you, because there is a powerful visualizer available to turn your XState objects into interactive visualizations.

I’ve written before about The Value of Drawing Pictures. We often try to describe complex processes with words when a picture would serve everybody better. Visualizing your application’s states, events, and the transitions triggered by those events makes it easier to foster broad understanding across a team. State machines and ==statecharts are a powerful tool for collaboration== so shouldn’t be limited to use in code.

Model Your States Early

One of the things I absolutely love about using XState is that I can model my application’s states without implementing all the actions and side effects. I can take early requirements, low-fidelity mockups, user stories, whatever is available, and start modeling the functionality a high level. You’ll rarely get to a “final”² model with limited information, but this relatively low-effort step is an immensely helpful start. This early visualization can be shared with others and then the collaboration begins. The collaboration around the early attempt can be the vehicle for arriving at a more complete “final” state.

Stakeholder Alignment

I can’t take source code to product owners and managers and expect it to be a helpful visual aid. I can reliably to that with a diagram. When that diagram is interactive and incredibly fast to iterate on in real time, the conversation results in better alignment and actual usable code! In this way we not only get product and technology folks on the same page, we codify that agreement in an artifact that will ultimately drive the implementation.

Consensus Within The Sprint Team

Once we know we’re on the right track, we can share that statechart and the associated visualization with the dev teams who will be involved in building the feature. This is a great, high-fidelity way to drive conversation, answer questions, and identify gaps. It’s not uncommon to miss some potential error states when talking through this state with stakeholders. Developers and QA team members are good at spotting and calling out these gaps.

Avoid Forgotten UX Designs

With a big picture and all the individual states and their transitions defined, we can identify gaps in our UX designs. In my experience, designs are always provided for the happy path, but error states are often overlooked. The state diagram provides clearly defined context for all paths, even the unhappy ones. The end result is more complete designs and a more cohesive user experience.

Streamlined QA

Throughout my professional career, one of the things I see happen just about everywhere is the back and forth between devs and QA testers toward the end of feature development. There always seems to be some ambiguity in how a feature is defined, some decision is made during implementation and that decision isn’t captured. That leads to defects that may or may not be true defects and conversations that could be avoided. This probably won’t ever be entirely avoidable, but having an agreed upon source of truth for app states helps everyone see the expected outcome more clearly than when it’s just words in some work tracking application.

Conclusion

The structured nature of statecharts make them an incredibly powerful tool for your entire team. They can not only drive your code, they also create clarity for the entire team. I’m a huge advocate for the use of XState as a tool that can be used holistically to get you and your team from idea to implementation.

If you’re not familiar, this introduction to state machines and statechartsis fantastic! ↩
I keep quoting final because software is never really finished and models will likely evolve after you’ve shipped the first “final” version. ↩