Synergistic design solutions using a dry-wipe medium

This blog post is not brought to you by Simply Glass Wipeboards, nor do I receive any form of commission on purchases or compensation for writing it.


So a while back I got tired of throwing away pad after pad of paper drawing mockups and making notes. Iain swung by my desk recently and saw my solution: a desktop glass whiteboard, which he thought might be worth sharing with everyone.

Pictured below is an early design of this blog post I drew up on it. Honest.

Whiteboard

It’s been great for to do lists: I can’t remove anything until it’s done, as it’s lost forever. It’s good for rough designs, you can quickly erase and try again – though granted not for a whole application (only being A3 sized). It’s bad for handing over designs to colleagues, as they try to steal it from you.

If of interest, this is it!
http://www.simplyglasswipeboards.co.uk/desk-top-wipe-board/desk-top-glass-dry-wipe-board-a4-size/

P.S. Eliminate all sharpie pens from near your desk if you do go for this.

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

DiBi #1: Designing for users, not devices

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


One of the early talks at DiBi was by Anna Debenham on Games Console Browsers. Usage on these might be a bit higher than you think: Anna quotes that 26% of 14–24 year olds in the UK use consoles to visit websites. Interestingly, in an effort to get pages to render normally, most console browsers tell lies in their user agent strings – so it’s actually quite difficult to measure usage on them. But it was this slide that showed a tweet by Will Roissetter that really stood out:

A student completed their Student Loan Application on a Nintendo DS

The Hub filled with laughter from all the delegates at this seemingly strange behaviour. But then a memory stirred, and I began to feel a little… uncomfortable.

In August 2012, I completed my final student finance application using an Xbox 360.

Yeah, yeah… laugh it up.

My excuse at the time was that my laptop had died and had been shipped away for service. As to why I didn’t use my phone: no idea. But the point here is that I doubt this was a scenario Student Finance accounted for – but it worked.

Anna quickly pointed out that while she would go into detail on some of the console based browsers – her talk wasn’t really about games consoles. It was about how every screen can (and in many cases has) become some sort of web browser. Traditional “mobile” devices aside we now have web browsers on digital cameras, printers, cars, exercise equipment – even taps.

Now this is not a pitch to drop everything, go back and make everything you’ve ever built support a web browser in a digital smoothie maker*. The warning here was to not fall prey to designing things for the current three “device silos”.

This theme was echoed a lot in other talks: when designing for the web, design for users not for specific devices or specific screen resolutions. Not only will you create something that is much more future-proof, but it will help reduce technical debt. Ryan O’Conner, UX Creative Director for BBC News digital, spoke of his regrets when redesigning the BBC News app which launched early last year which – though it is responsive in its design – had loads of different “templates” for specific different devices and resolutions. They had quickly thrown in lots of variants and tweaks for very specific cases – and this has already become unmaintainable.

Because, silly device examples aside, the broad categories we’re becoming familiar with – mobile, tablet, computer – don’t make sense any more. Tablets and phones come in pretty much every shape and size now with the lines blurred between them (I will not use this word, ever). Combined laptop / tablets are becoming more popular. A desktop connected to a large screen can’t really be considered identical to a tiny netbook.

So destroy the silos, comrades! We can’t play catch-up forever designing to whatever device is “in” right now, or assuming everyone will or won’t do things on a specific device.

There will be more to follow on my exploits at DiBi over the next few days: apologies it’s taking me so long – I insisted on writing this on the web browser built in to my new internet enabled pepper mill**.


* Author not thorough enough to check if this was a thing or not.
** Patent pending.