Building for States
Thinking about the many states of systems
I’ve come to the realization lately that states sit at the center of everything we do in product development. I started thinking about it originally because I was trying to articulate the challenges designers sometimes face in working with engineers (especially frontend engineers). I’ve since realized that it’s even bigger than that, and states do a pretty good job describing the difference between levels across the whole product team.
What I mean is that one of the essential qualities you’re looking for in a senior designer or engineer is the ability to envision, design, and deliver systems that function in every conceivable situation. As a non-engineer myself, this was an interesting revelation, as it gave me a clear understanding of what separates a junior and senior engineer that went beyond the much-harder-for-a-non-engineer-to-understand code quality debate.
Although I may be bastardizing the term from an engineering point of view, when I talk about “states” I mean all the possible outcomes of a new feature: What happens when you press this button, or that button, or those buttons together, or we get this data back but not that data. Bugs, for the most part, are a matter of overlooked states. From a design perspective, states are about thinking through all the different ways the elements on the page might live and interact. This includes obvious ones, like empty states and error messages, as well as not so obvious ones, like random button combinations or accidental page refreshes.
What’s the point of all this? I’m not totally sure yet, except it strikes me as the thing toward which every member of a product team needs to constantly work. What’s more, I believe there are probably better ways to help people think through states from the beginning. While specs and system designs help the team understand needs and spot potential flaws, there’s got to be something more focused on helping anyone looking at a design (whether visual or system) and ensure that they’ve covered as many states as possible. From there, can we find a way to measure state coverage in the same way we measure test coverage? Like I said, I’m not there yet, but I know it’s important.
