DiBi #2: Design everything. (Also, skeletons)

Last month, I got to attend the 2016 Design it Build it (DiBi) conference at the Hub in Edinburgh. This is the second in a series of three posts about my adventures.


My second DiBi post is focussing on some specific methods in UI design that were covered at the conference that could have a really positive impact on the overall user experience.

The UI Stack

Scott Hurff, Product Designer and Lead Designer at Tinder, delivered a very interesting talk titled Fight back with the UI stack. The UI Stack is what he uses to counter awkward UI, which he describes as:

“[Awkward UI] is a missing loading indicator. It’s forgetting to tell your customer where something went wrong. Bonus points for doing so with a scary error message. It’s a graph that looks weird with only a few data points. It’s a linear snap into place when introducing a new piece of data.”

So, meet the UI Stack:

The UI Stack

Scott goes into a lot more detail on this on his blog, with lots of good and bad examples of each state – it’s well worth a read if of interest, particularly for some great examples on the states people tend to focus on less. But I will briefly summarise the 5 states:

Ideal State
Where you want your users to be. The core screens. Perhaps what you’ve spent the most effort designing…

Blank State
Scott splits this one down into three categories: how does your application look when the user first opens it, if the user clears all the data they have added, or when no results are returned in a search?

Error State
How do you handle erroring out? Will data be lost? Are your error messages dramatic and technical, or friendly and instructional? Does it tell the user how to try and resolve the problem?

Partial State
How do your screens look when partially / sparsely populated? Do you need to guide users towards the ideal state?

Loading State
How does your application transition between screens? How does it handle loading?

It’s often easy to spot when something looks a bit wrong. But it can be a lot more difficult to then work out what needs to be changed or added to make it right.

Skeletons vs Spinners

A key part of the stack that often gets neglected is the loading state. So I wanted to mention a neat little idea that Scott and others at the conference touched upon: skeleton screens. These replace common loading animations like spinners with loading skeletal frames of the page. They can be used to improve the loading time of content by loading and rendering it in skeletal blocks chunk by chunk – but can also be useful just as a more gentle transitional loading animation.

Example of skeleton screen on fiddlr, source: http://tandemseven.com/

Nowadays this is used a lot more, and not just in mobile apps or when loading things in by chunks. Slack renders templates of messages whilst it’s loading the actual ones, and displays them all at once. Facebook renders a fake news feed with blocks in while it loads all your stories.

Look familiar? Facebook skeleton loading screen. Source: https://github.com/ksux/ks-design-guide/issues/38

Replacing your loading spinners with skeletal blocks of the sort of content users should expect to see can give the perception of faster loading and give users more immediate familiarity with the content when it does load. Plus, people hate spinners.

Design everything

UX matters. A lot. We’re judged on it, and in reality we’re basically already using it as a performance measure whenever we ask our users for feedback on our work.

So, in summary:

  • Be sure to design everything, not just your UI’s ideal state.
  • Loading can impact the user experience massively. Plan and design that too.
  • Skeletons are cool.

Some related reading:

  1. Scott’s post on The UI Stack
  2. Mobile Design Details: Avoid The Spinner, Luke Wroblewski
  3. A Beginner’s Guide to Perceived Performance, Kyle Peatt