DEV Community

Cover image for An engineer's plea to designers

An engineer's plea to designers

jfbrennan profile image Jordan Brennan Updated on ・5 min read

There's this common set of cases that no designer I've worked with proactively designs for, but are nonetheless required.

I call them zero-1-2-1000-error.

Most designers solve for 1, sometimes 2, then hand it off for development. Yeah, I know, "We're agile", but these fundamental cases need to 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!


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:

Zero dead pets

Other examples might include no documents because the user hasn't uploaded one yet, no results match the search, no messages in the inbox, no friends like you--I mean no friends liked what you posted. Every list has a zero case to design, so please design it.

Zero isn't only needed for lists though. It also relates to first-time user experience, which can mean a lot things depending on the product. Examples include a basic welcome message, get set up (LinkedIn profile creation), guide the user to the first step (TurboTax nails this), and more.

Ok, so be a hero and don't forget zero!


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 do at least this amount, so congratulations we're moving on!


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 the 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 margin between them or should they touch?

What about mobile?

Those details can be missed when the design only shows 1. Again, I know, "We're agile," but engineers will really appreciate the design upfront because it helps them determine the best implementation.

So, before hand-off check if your design needs to go number 2.


Engineers need to know what the UI/UX should be when there's 1000 of the thing you're designing. Yes, 1,000 or more. We might just need to get agile after all!

All right, the 1000 doesn't literally mean 1,000 things. It represents a problem space of when there's lots and lots of things, sometimes too many things.

As the number of things (re: dead pets) 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 ⬅️ ➡️ buttons. Sometimes massive data sets can use zoom. Anyway, you're the expert who will design a space that accommodates surplus things.

But sometimes there really is just too many things. As a designer, don't be afraid to try to accommodate tons of data. Let your design leverage modern web technologies and frameworks that make relatively large data sets possible. Having said that, be 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.

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 bar, loading message, spinning icon, 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 (e.g. optimistic preload).


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 things you're designing. 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 very very important.

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, like Connection failed. Please try again, or even more robust recovery UX like a partially uploaded file that timed-out. From my experience, a designer will typically design the upload progress and success case, but rarely designs the error and recovery cases.

In closing, let's ponder on this completely fake proverb:
"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 managed large UI teams as well, 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.

Thank you designers!

Discussion (8)

Editor guide
fredericbonnet profile image
Frédéric Bonnet

It reminds me of the ZOMBIES method for test-driven development:

Z – Zero
O – One
M – Many (or More complex)
B – Boundary Behaviors
I – Interface definition
E – Exercise Exceptional behavior
S – Simple Scenarios, Simple Solutions

pclundaahl profile image
Patrick Charles-Lundaahl

I've never heard this shorthand before, but I love it!

elmuerte profile image
Michiel Hendriks

The same goes for developers. Testing logic with zero-1-2-10-100-1000-10000-error.
Why 10-100-1000-10000? because things do not scale as you think. The 1.000 is meant to be the "this is the max that we anticipate". The 10.000 is meant to be "this will never happen, until it suddenly does and your whole platform comes down in production at 19:00 on xmas day when you just want to take a bite of the main course".

jfbrennan profile image
Jordan Brennan Author

The joys of being on call!

cchana profile image
Charanjit Chana

In a previous life, this was something the development team took on board too. It’s very easy to implement things catering for the bare minimum but there are many scenarios that should be covered.

If the design team can come to with all of this then there’s boo excuse further down the chain of it isn’t catered for.

Some really good food for thought.

moopet profile image
Ben Sinclair

You know that joke about the QA engineer who walks into a bar?
I tell people that one when they come up with ideas or pretty pictures of how something looks and ask them to come back when it's not funny anymore :)

itsasine profile image
ItsASine (Kayla)

My requirements are only ever the 1 beer case and it makes me sad ;.;

Then I'm the weird one for ordering a sfdeljknesv

jfbrennan profile image
Jordan Brennan Author

Haha! Maybe this would resonate with more people:
no beer-1 beer-2 beers-too many beers-vomit