Łukasz Makuch

When business people were explaining their ideas to me, they were often using slides with various boxes and arrows. These diagrams were high-level illustrations of how to complete various business processes and how things may go.

It's easy to understand. The language of boxes and arrows is great to explain ideas.

When UX people were providing me with user flows, they were using the language of boxed and arrows as well. Their work looked like a map, where each screen was an island that might be connected with other islands by bridges named after the interactions leading to the transitions.

It's easy to understand. It worked for them, because it's a great way to capture how the UI changes as the user interacts with the application.

When technical writers were showing me their work, it wasn't all just text. Complex processes were described using drawings of boxed and arrows.

It's easy to understand. Such a documentation is clear to people with different backgrounds.

When I was about to implement a new feature, I loved to grab a pen and a piece of paper and quickly sketch how the data flows and how the behavior changes.

It's easy to understand. Seeing all the important steps and states is a great framework for thinking. It helps to understand what are we supposed to build.

When I was delivering the requirements, the implementation was made solely of text. The desired behavior was achieved by utilising consitions checking if some values are true or not.

It's not easy to understand. Especially taking into consideration the fact that all these boxes and arrows may be thought of as a visualisation of one of the fundamental concepts in computer science - a state machine.

Maybe state machines are purely theoretical or not really useful in practice? By no means! They are already being used in various branches of software development, spanning from video game development to space exploration.

I wish we, the web developers, could leverage the power of this common language.