Design

Lisa Margetis

UX is in the Details: Better Empty States

Dec. 15, 2017

Empty states are the in-between spaces in any app. They’re what happens when the inbox is empty, when the special offer has expired, when you haven’t selected any favorites, or when you’ve cleared the to-do list out. And potentially they are the first screens to be seen upon signing up.

hendrix empty state

Hendrix

While empty states may seem like small flourishes, they are actually a powerful design pattern.

Anticipating empty states, understanding when and where empty states occur, requires extensive knowledge of a user’s pathway through the product. By developing good empty states, the landscape of the product can be clearer - a user can know what to expect from your app and even be guided on how to use the app before they have invested time in it.

On top of improving the user experience of an app, empty states inform your users on what information will be displayed on the screen. To put it nicely, without good empty states your product will feel not just empty, but broken!

dovetail empty state

Dovetail

So now that we have our empty states accounted for, how do we make them better?

Empty states are an incredible opportunity to build brand affinity. You can introduce branded characters and animations and set the tone of the brand’s identity through empty states. It is one of the most powerful ways to set the “tone” of your product - is it silly and loose, or purposeful and stylish? We probably wouldn’t want a dog digging for a bone in a financial product, but it’s perfect for a pet adoption app.

Hoang Nguyen Empty State

Dribbble: Hoang Nguyen

Humanizing your product with enjoyable empty states can produce familiarity and build an emotional connection. Twitter didn’t just tell you they’re down with a message - they showed you the iconic Fail Whale: cute birds cheerfully lifting a huge and grinning whale.

We may be down, but here’s an awesome cartoon.

While the endearing whale is no more, the reach of that simple empty state shows how powerful a tool they can be for a brand. Instead of a cold error message, there’s a colorful little diversion from frustration. Taking the edge off of bad news with an empty state illustration is a widely-used design pattern.

Ivy Mukherjee Empty State

Dribbble: Ivy Mukherjee

So, beyond your servers crashing - what else could we use empty states for?

They can show crucial information, acting as an onboarding agent for new users.

AirBnb Itinerary Empty State

AirBnb Itinerary Empty State

They can act as a tutorial, showing a slightly more in-depth way to use a feature.

Dropbox Empty State

Dropbox Paper Empty State

They can reveal product goals, or the power of a product.

Waze Alerts Empty State

Waze Alerts Empty State

The empty states are the chance to give the product a voice and let it speak. It’s nearly an advertisement for itself!

The most common empty state is the upload screen. The drag-here box that’s unmistakable because of its design - you just want to put your latest pic there. These “contribution” empty states are vital because they’re one of the user’s direct interaction points. It must not only look like something the user wants to use, of course - it has to work perfectly, too!

Empty states are a nudge that call us to action in our apps. Without them, users aren’t just lost - they think something is wrong. If there’s no particular place for a user to go, or if they don’t like where you’re trying to take them, then they’re going to bounce!

Blank screens hide features, but empty states reveal them

As a product designer, empty states are one of my favorite chances to be creative and really get to know a product. I get to shape how a user approaches a product’s features. What should this app feel like? What will they use it for? How will they want to use it? What will signal to them: this product is secure, safe, but also simple enough to use?

Now that we’ve explored why emtpy states are so crucial - did you notice an empty state you’d never thought about? Do you have a favorite empty state? Let me know in the comments!

Lisa Margetis

What People Are Reading

Technology

11/20/17

Cross-Platform mobile development is cost-effective and faster to launch

Two years ago, if a person approached us for mobile app development, the first question would be what platform to launch on first - iOS or Android. It was almost double the cost to deploy on both and double the maintenance.

Fast forward to today, we can deploy on iOS and Android quicker before, at the same time, and with the expected native quality.

So what has changed? Technology has gotten a lot better. We particularly use React Native, an open source framework from Facebook, that allows developers to develop in a common language, Javascript, and deploy on both iOS and Android.

And it is native! Previous technologies for cross platform mobile apps would create a wrapper of a web view. Think of the older experience as using the browser on your phone for a site with a few more bells and whistles. It was close but the difference is noticeable when switching to native applications, from scrolling to the overall experience.

How does this impact everything now?

Cost is no longer double for both platforms. It can even cost less due to wide spread community support developing open source libraries.

Maintenance is a lot easier. A majority of the issues can be fixed in one code base and of the same language.

Recruitment and team knowledge is easier. Your team only need to know one language and most developers know Javascript. iOS is written in Objective C or Swift and Android is written in Java.

Reusable code for desktop web views. With React Native, we are able to share over 50% of the code with the web view, saving all of the above even more.

Stay tuned, as I’ll be going more into the technologies and other benefits.

Technology

1/6/17

React Lessons for Newcomers

At 20spokes, developers spend a roughly equal amount of time between Ruby on Rails and React. While we enjoy working in both frameworks, they are quite different in approach, and going from a Rails way of thinking to a React way of thinking can be an adjustment.

One major way in which these frameworks are different is that Rails takes care of a lot of architectural issues that React leaves open for interpretation. Coming from a Rails background, I found the openness of React to be a bit anxiety-inducing at first, but I've come to really embrace it, because it's forced me to think more carefully than ever about how other developers would approach my code.

As a team, we've also considered what our best practices should be towards React, as we all want to make our code understandable and friendly to anyone who encounters it. To that end, below is a (growing) list of our approaches to making our React projects not only maintainable, but enjoyable to work with.

Be relentless with components

The basic building block of React is the component. To those new to React, they can best be thought of as modules.

As a developer, I start to get nervous when I see large components that perform various functions. The solution to keeping your files short and sweet is to take every opportunity to break your objects into re-useable components. Having larger components may not seem like a big deal when starting a project from scratch, but if you relentlessly component-ize you'll thank yourself as your project grows.

There are some code smells to recognize when you should create new components. If you see lots of groups of markup within a single div, those groups should probably be their own component.

If we have lots of renderXXX functions within in one component that render more markup, that's usually a code-smell that whatever is being returned from those functions should be their own component.

Make components as reusable as possible by passing dynamic data as props.

Privilege functional components over class-based ones

In many cases, it's overkill to Use React's Component class for every component you create. Not all components need access to the Lifecycle Methods or local state that Component provides. Start with stateless functional components and turn them into React Component instances as needed.

Take advantage of PropTypes

We started the practice of listing out PropTypes at the bottom of every component, so other developers can quickly reference what props are needed or optional. Oftentimes, we'd investigate what data we should expect in a component by looking up examples of that component elsewhere in the codebase. This easily can be avoided by using PropTypes, which provide a quick way to see what data is being passed, and of what type that data should be. Here's an example from our reusable Button component:

Button.propTypes = {  
  text: PropTypes.string.isRequired,
  onPress: PropTypes.func.isRequired,
  disabled: PropTypes.bool,
  icon: PropTypes.string,
}

We're pointing this out because, while Facebook already notes it as a best practice in their documentation, it's something that's easy to skip over or forget to do. But for something that's not hard to do at all, it provides a lot of value when developing and maintaining your app.

Use Lifecycle Methods with care

Despite being incredibly powerful, lifecycle methods (like ComponentDidUpdate) can cause a lot of headaches to those new to React. Be careful when updating state or props within these methods, as it may cause infinite looping.

For this reason, I prefer to place lifecycle methods at the very top of a component declaration, so I can see all of that logic together when debugging.

Check out part 2 of this series, Redux Lessons for Newcomers.

Operations

8/29/16

Watch us eat our own dog food

20spokes is trying a new diet, so to speak. If you’re unfamiliar with the phrase “eating your own dog food,” it’s a common expression in the software world referring to a developer’s practice of using their own products. It’s said to have originated from 1970s television advertisements for Alpo dog food, where the owner of the company would make a point of feeding Alpo to his own dogs. So in its broader interpretation, “practice what you preach” would be an appropriate alternative. Either way, if we can help others build great products, we want to show that we can build our own great products as well.

It’s something we’ve thought about for a while, and now we’re finally taking the steps to make it happen. Client work will still always be our primary focus, but we have the team, the experience, and the aspirations; why wouldn't we work on our own ideas too? Like our clients, though, we don't want to jump into these ventures haphazardly only to end up with a well built app that nobody else wants. So we're putting these ideas through the same process of discovery, validation, and planning that we would with anyone who came into our office. In a way, by becoming clients of our own process, we’re getting our first helping of dog food!

Over the last week or so, we’ve adopted the mindset of a founder with a vision, and taken one of our ideas through the first steps of conception. Working through this process as the “founder” has already given us some great new insight, and we're excited to share this journey with you. So stay tuned for the next several weeks as we document all the steps we take and lessons we learn along the way; we're going to find out just how good our dog food tastes.

Trying to get your own product idea to market? Contact us to learn more about our process and how we can help.