There's a common set of use cases that no designer I've worked with proactively designs for, but are nonetheless needed.
I call them zero-1-2-1000-error.
Most designers solve for 1, sometimes 2, then hand it off for development. These fundamental cases should become part of every unspoken design and engineering agreement. It should become the norm that these cases are explored and designed before fingers type code.
I'll explain what this is and why it's important for engineers; the rest will be up to you!
*zero*-1-2-1000-error
Engineers need to know what the UI/UX should be when there's zero of the thing you're designing.
For example, if you're designing a list of deceased pets you would also consider, and design, the case where no pets are dead. Like this:
Other examples might include no documents because the user hasn't uploaded one yet, no results match the search, no messages in the inbox, etc. Remember, every list has a zero case to design for, so please design it.
Zero isn't only needed for lists though. Zero also means first-time user experience, which can be a lot things depending on the product. Examples include a basic welcome message, getting set up (e.g. LinkedIn profile creation), guide the user to the first step (TurboTax nails this), and so much more.
So, be a hero and design for zero!
zero-*1*-2-1000-error
Next, engineers need to know what the UI/UX should be when there's 1 of the thing you're designing.
This is the only case designers do. I kid! Some of you do 2 ;)
All designers are doing 1, so we're moving on...
zero-1-*2*-1000-error
Engineers need to know what the UI/UX should be when there's 2 (or 3 or 4) of the thing you're designing.
The reason this is any different than 1 is because an engineer is going to have questions about how things look when they're next to each other. Having only one dead cat in a dead pets design is not enough to know what to build when there's two dead cats, and so the engineer has to wonder:
Do I lay these out horizontally or vertically?
If horizontal, do I wrap them at some point or overflow and scroll?
Is there space between them or should they touch?
What about mobile?
Those details will be missed by some engineers if the design only shows 1. Engineers will really appreciate this design upfront because it helps them determine the best approach to building the list.
So, before the hand-off double check if your design needs to go number 2.
zero-1-2-*1000*-error
Engineers need to know what the UI/UX should be when there's 1,000 of the thing you're designing.
The 1,000 doesn't literally mean a Figma with 1,000 items. It represents a problem space when there's lots and lots of things, sometimes too many things.
As the number of things grows past zero-1-2, there will eventually be too many of them for the designed space to accommodate it. An engineer is either going to overflow-y: auto at a reasonable height or let things scroll into eternity if you don't design it. Scroll can be good, but let's make sure it was intentional. Another common option is pagination and maybe prev/next buttons. Sometimes massive data sets can use zoom. Anyway, you're the expert who needs to design a space that accommodates a surplus of things, like 5,000,000 dead cats.
Sometimes there really are just too many things. As a designer, don't be afraid to try to accommodate tons of data. Let your UX design leverage modern web storage technologies and frameworks that make relatively large data sets possible. Having said that, become aware of what your product's potential data sizes are and the implications. Designers tend to know the breadth, but not the depth of their product's content. You should know if there's only like 20 or 100,000 of the thing you're designing for. It absolutely makes a difference to the engineer, so work with them to create a better UX for possible data sets.
A travel website, for example, is not going to be able to fetch and display all the possible flights in the world for a given date range. This will mean lots of upfront search and filter over the network and that means latency, so be sure to know the depth of your content and design for latency.
Designing for latency can mean progress bars, loading messages, spinners, etc. Latency sucks, so don't make a big deal out of it by over-designing. Make it purposeful and sufficient and nothing more. More importantly, brainstorm with your engineer on ways to fix, mitigate, or even hide latency with optimistic strategies.
zero-1-2-1000-*error*
Engineers need to know what the UI/UX should be when there's an error.
This usually happens when they're trying to fetch the content you're designing for. It's not an exciting use case, but it's important. In the case of say, uploading a large file or typing out a long blog post, it's a critical case to get right.
Designing for the error case is sometimes as simple as showing a message, which engineers will still need a design for. Don't let a poorly-handled error further ruin the UX by not supplying a design.
Other error cases require recovery actions. For example, most designers will design the upload progress and success case, but rarely designs the error and recovery cases. Both need good design.
So remember, not designing for error is an error.
That my friends is zero-1-2-1000-error. I've been building UI for 10+ years at companies large and small and I've also managed large UI teams, and in all instances I've never seen a designer proactively design for these cases and the results have been mixed. Too few designers are doing it and even fewer engineers know how to fill the gaps.
It's time for all of us to elevate the quality of our builds by covering these fundamental cases in a less agile and more intentional way.