SELF - Documenting UI States


TODO: Show screenshots for each example below both good and bad.

Design for your SELF

I have been developing a lot of component libraries in React over the last few years and each project had their own system and designers to create the mock ups. And I kept noticing the same thing happening over and over again. And that thing is... designers only design the "happy path" and don't typically neglect/ignore the unhappy paths in their mocks.

A lot of designers only design the happy path...
- Gary

There I said it.

I'm sure that's going to piss a lot of designers off. But, here's the thing... if it pisses you off its going to be for one of two reasons:

  • You do care and you do design the unhappy paths or...
  • You don't like getting called out.

To those in the first group, thank you so much. For those in the seconds, listen up. I'm going to explain a concept to you for documenting your UI states. Its easy to remember and its easy to do.

I call it SELF.


SELF tm stands for Success, Empty/Excess, Loading, Fail. These represent the four states our User Interface can be in at any given time. And you, as a designer, need to account for each of these in your designs. If you don't, you will be causing us both to have to sit through multiple meetings, emails and other such time killers. Neither of us want that.

So, in case these aren't self-evident, let's break down each one of these.


This is the UI that you always give us since it's literally your main requirement. It's the "happy path" and, generally speaking, you all do a great job at it... mostly (I'll save that for another time).


This one is forgotten about a lot. You need to check your design to work with no data and "excess" data. What does your screen look like when the user has no data entered or that API call doesn't return any date? Is it just a blank screen because you didn't give the developer an idea of what you wanted? Also, what happens when there is more data than you expected? That title is one hundred characters long, not thirty?


This is the second most common state to receive. Unfortunately it's usually some global "show a spinner". Take some time and give the user some feedback. Here are some ideas:

  • If there is a definite beginning, middle, and end then a progress bar might be useful.
  • Skeleton screens are nice simple ways to show "hey data is going to go here". (think Twitter, Facebook)
  • Give some tips or tricks about the site or how to use your application.

Use your imagination. Its the one thing I know every good designer has.


This is your error screen where something went wrong. What do you want the user to see? The error message from your code? No! So design something to show the user that explains what happened in an easy to understand way. Also, allow them to perform a follow up action such as re-doing their operation or reporting a bug.


I want you designers to know, I love what you do. Keep doing it. Just help make all of our lives easier by taking the time up front to account for all of these states in your designs.

Just remember to design for your SELF.

'Til next time the mood strikes,