Skip to content
Gary Storey
TwitterGithub

Design for your SELF

Design, SELF, Rant2 min read

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. A lot of designers only design the happy path and will neglect/ignore all the unhappy paths in their mocks.

A lot of designers only design the happy path... Me

There I said it. I'm sure that's going to piss a lot of designers off. Sorry... but if it pisses you off its going to be for one of two reasons:

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

To those in the first group, thank you. To those in the seconds, listen up. I'm going to explain a concept to you for documenting your UI states.

I call it SELF.

WTF is SELF?

SELF stands for Success, Empty/Excess, Loading, Fail.

These are the four states your UI design can be in at any given time. And you as a designer need to have a design for all four of these states. If you don't, you aren't doing your job.

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

Success

You all know what this is. This is the one screen you give us. This is the "happy" path, the everything's hunky-dory path. I think you get this one... mostly (future rant on form components forth coming).

Empty/Excess

This one is forgotten about a lot. It's when you have "no data" or "too much" data. What does your screen look like when the user has no data entered? Is it just a blank screen because you didn't give the developer an idea of what you wanted? At least add a "Add content" button for them... just something. Its also a great place for some marketing pushing a new or specific feature.

What happens when the user enters a really long title for their document? Or they type in a literal novel for a description? Will the UI handle it? Just things to keep in mind when you are creating your mock-ups as these things weill happen in the real world.

Loading

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/tricks about the app

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

Fail

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.

Summary

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, -G

© 2023 by Gary Storey. All rights reserved.