4 things I wish more designers knew

A lot of times when working with designers I run into the same issues over and over again. Now, don’t get me wrong - I love working with designers and seeing a cool design come together in the browser. However, I feel like we could both get more done if we understood each other better. So, here are the 4 things I wish more designers knew:

1. The not so happy path

What exactly is a happy path? Here’s a quote from Wikipedia:

In the context of software or information modeling, a happy path (sometimes called happy flow) is a default scenario featuring no exceptional or error conditions.

A user visiting a page, correctly entering his credentials on the first try and logging in instantaneously would be an example of such a happy path. Of course, things rarely work that way in the real world. The user might enter the wrong password, the server might be busy and take a long time to reply or fail to reply at all because the database is down. All of these scenarios need to be taken into account when designing the UI.

Unfortunately, I am often presented with designs that only take into account the happy path. So how do you fix this?

First, always include some sort of loader in your designs. Even in a perfect scenario, making a call to the server and getting a reply is going to take some time (pro tip: obscure the UI controls with the loader so that the user can’t accidentally repeat the action).

Secondly, include some way to display an error message in the design. For general errors (“Server is down. Try again later.”) you can use toast messages, which are a quick and effective way of showing short messages. But keep in mind that messages longer than a few words might not fit well into this design pattern. If your design has a form, you absolutely need to include error messages for the various form fields.

2. Unexpected data (size)

You’re just about to finish the design for a sign-up form and need to include some placeholder for the user’s name. What about James Smith? Yeah, that sounds great and the short name fits really well with your slick minimalist design. You make the change and click save.

All done? Wrong!

In reality, your users will not be named John Smith - they’ll have names like Neftali Ricardo Reyes Basoalto or Серге́й Алекса́ндрович Есе́нин - if you’re lucky, only the length will be the issue. If not, your carefully chosen font won’t support the various diacritical marks or even the characters themselves! The error messages will not be “an error occurred” but a paragraph of text that will break the tiny box you designed for it (especially on smaller resolutions). The list of requirements for the password field will overflow the space you set aside for it. There might be 10 list items where you only made room for 3.

In short, you need to stop assuming that the data (especially user data) will fit into your designs - rather, your designs need to adjust to fit the data. Be pessimistic. Ask yourself constantly - what if this text is twice as long? What if it’s really short? Design with a certain range in mind and verify that your assumptions are correct (either by asking other team members or testing with actual users).

A special note here about device sizes - how well you use the available space is much more important on small devices because there isn’t much space to use. Something that looks okay on a larger screen will be completely unusable on a smaller one.

3. There are more than two device sizes

Generally, most designs I get these days come in pairs - a desktop and a mobile version. Very rarely is there also a tablet version. Unfortunately, the devices your design will be displayed on will run the gamut from 320 pixels all the way to 1920 pixels (and more!). A good design should be usable on every one of those resolutions. I don’t think anyone is expecting a design for every device and resolution. But it’s definitely a good idea to check how your design works at the seams.

What seams? I’m talking about the breakpoints between the mobile and desktop versions. Sure, your design looks fine on 420px but what about at, say, 500px? Or 523px? Sometimes the mobile design looks bad just before it switches to the desktop version. Sometimes there isn’t enough space for all the data on the desktop design just before it switches to mobile. Sometimes there is an overlap between the mobile and desktop designs - that is, the mobile design is going to end up being used on a device larger than the one you envisioned because the desktop version doesn’t fit (and vice-versa). This is something you, as a designer, are much better equipped to tackle than your average developer. Sure, a good developer will be able to work around this, but that is not always guaranteed.

So what can you do about it? Take the worst case scenario from #2 (in other words, stuff it with lines of text) and then see how your design holds up. Is there enough space? Is the design usable? Does it look good? Sometimes you’ll notice that certain elements or pages have breakpoints separate from the rest of the design and that’s okay - better to have an element from the mobile design in the lower range of a desktop design than a broken UI.

4. How hard could it be (to implement)?

This is probably the hardest part for the average designer to grasp because it requires you to have specialised knowledge that usually falls outside your area of expertise. When in doubt, consult your fellow developers.

To make a long story short, designers are often woefully unaware of how hard some of their designs might be to implement. This usually means that the developer will spend an inordinate amount of time implementing a design - time and effort that is not proportional to the business value created.

Developers might be afraid to question a design - they will view the design choices as something that was decided by all the stakeholders and set in stone. In reality, it might just be the first thing the designer came up with and left it as is because it was “good enough”.

So what are the pitfalls you should try to avoid?

First off, avoid using moving parts unless they’re really necessary. Menus, dialogs or error messages that move around are a pain to implement and test because of z-index positioning, clipping and viewport limits. Remember #2 - the element will appear everywhere, not just where you assumed it will.

Second, limit the amount of “states” the UI can be in. What’s a state? Take a form for example; you have a clean state (when the form is first loaded), a dirty state (when the form is edited), and a submitted state (when the form has been submitted to the server). Each state needs to be implemented and for each state, the developer needs to ask themselves - what could go wrong? How does the user transition from one state to another? Is there something the user is not allowed to do? Remember - the developer will need to implement not just the happy path, but also all the other scenarios the UI can be in. Limiting the amount of states the UI can be in means less work for the developer and a less buggy experience for the user.

The easiest way to keep state under control is to limit what the user can do. Think of a light switch. It can be on or off. That’s two states. There is very little the user can do to break a such a simple design. Now imagine a car with a manual transmission. Ugh…

Third - limitations of the technology. While we have gone a long way from the days of Internet Explorer and the time when web standards were anything but standard, certain things are still an issue to implement in 2021. I could go on and list some of them but your best bet is to just let the developer implementing your design know that the design is not set in stone and if there is an easier way to do something, to just do it.