User Experience News

Here’s a collection of user interface news, as aggregated by AllTop. I take no responsibility for the content, but it’s usually very good.

No Ken Do (Musketeer Barbie Saves the Prince)

I WATCHED dozens of Barbie videos hundreds of times when my daughter was three and four years old. I can’t praise their animation, dialog, or other cinematic and literary qualities, but this I can say in their favor: every Barbie video we watched was feminist and empowering in its messaging. This was not the Barbie […]

Writing-first Design

A quick way to measure a designer’s maturity is to watch what they do at the beginning of a project. Inexperienced designers are often smitten by the allure of new tools and quick results, so they’ll jump in to Photoshop or Sketch and start messing with layouts and style explorations. Seasoned designers know this can be distracting, so they might start by doing research or drawing in a paper sketchbook instead.

Sketching is great, but before I start sketching, I start writing. Writing first has lots of advantages, regardless of the project you’re working on. Here are a few examples.

Example 1: You’re making a simple website, and your client doesn’t have any copy yet.

Great! Here’s an opportunity to write it. Skip the lorem ipsum and start telling your client’s story. What’s special about this client? What problems are they trying to solve by having this website? How can you explain those ideas to people who visit the site? And why should the site’s visitors care?

Answering these questions requires you to gain understanding. You can’t write anything without knowing your subject. You’ll be forced to learn a lot about the client’s business, their history, and their audience. Having this information will clarify your vision for the overall project.

Example 2: You’re making a website, and the client gave you copy to start with.

Great! Don’t design anything yet. Put on your editor’s hat and think critically. Is the text arranged correctly? Does it have the right tone of voice? Is it too long or too short? Is it suitable for the web? Can you chop it up into separate pages and keep it coherent? What’s still missing?

Chances are, this handed-over writing might be lousy. Be honest and propose copy changes before you get much deeper into the design. Don’t be afraid to do a rewrite — treat writing as part of the design, not just an element on the page.

Example 3: You’re making an app or interface elements.

In that case, you’re likely designing affordances — communicating actions the user can take. These might take the form of explanatory copy, prompts, buttons, labels, error messages, etc.

Great! Hop into a text editor. Write out as many variations as you can. It’s easy to mock basic UI in text, like this:

Are you sure you want to delete that file?
[ Yes, I’m sure ] [ Never mind ]
Deleting this file will remove it permanently. Are you sure?
[ Yes, delete it ] [ No, cancel ]

And don’t be afraid to have a little fun with it:

That file will disappear completely and never be found. Carry on?
[ Indeed, ashes to ashes and so forth ] [ No, I can’t let go ]

Example 4: You’re making a graphics-heavy poster that has almost no writing at all.

Great! Write down what you think you’re trying to accomplish. Spend 5 or 10 minutes on it. The notes are entirely to help you clear your head and figure out what to do.

Putting writing first improves your chances of success in the final product. It’s good practice, and it makes the rest of your job easier.

Now, what does the overall creative process look like? I’ve found it works well like this:

  • Spend time writing until you’re happy with the first draft.
  • Sketch visual ideas on paper.
  • Open your software tool of choice and explore aesthetics: colors, type, imagery, and style.
  • Put it all together and try different layouts and arrangements.
  • Continue editing once you see everything in context.

Obviously that exact order is not always right for every project. There’s no right way to do things! But following this general process helps guarantee you’re putting horses before carts and staying on the right road.

Everyday rituals and digital tech in the families of mobile workers

Quotidian Ritual and Work-Life Balance: An Ethnography of Not Being There Jo-Anne Richard and Paulina Yurman (Helen Hamlyn Centre for Design, Royal College of Art) David Kirk and David Chatting (Culture Lab, Newcastle University) Paper presented at the EPIC Conference, New York, September 2014 This paper reports on current interdisciplinary design research that explores values […]

Designing Wildcard

Card Types in WildcardThanks to everyone for the terrific reception and constructive feedback to Wildcard’s launch last week. As we start plowing ahead towards its next stage, I wanted to jot down a few thoughts about the app’s design. Team and Process Wildcard is roughly twenty-five people strong at the moment, and for the past year we’ve had…

Jared Spool – How Do We Design Designers? Live!

Why don’t design students coming out of school know about responsive design or creating mobile apps? Why are our self-taught hackers and C.S. grads having a tough time keeping up with the pace of technology innovation? It’s not that schools or professional development programs are slow to adapt; it’s more complicated than that. But our tendency to focus on skills alone just isn’t sustainable. Instead, we need to start investing in the ways we create designers and fuel their growth.

How We React to Technology

Douglas AdamsDouglas Adams, in his book “The Salmon of Doubt,” wrote that “I’ve come up with a set of rules that describe our reactions to technologies.” The rules are: Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. Anything that’s…

Driving Phantom from Grunt

While building websites at Filament Group, there are a couple tools that consistently find their way into our workflow:

  • GruntJS is a JavaScript Task Runner. It runs on NodeJS and allows the user to easily concatenate and minify files, run unit tests, and perform many other tasks, from linting to minification of images.
  • PhantomJS is a headless (Webkit-based) web browser. A headless web browser renders a page without having a visible window. Using this functionality, we can write code that you would want to run in a browser, but see its results in the command line. This allows us to run scripts and even render snapshots of pages without having to open a browser and do it manually.

Together, these tools allow us to get consistent feedback for our code, by further automating checks that would normally require opening a browser.

For this example, we’re going to build a Grunt task that takes a screen shot of the pages we’re building (similar to Wraith, but far less advanced). There are multiple parts to make this work, so let’s break it down. First, we will write a PhantomJS script that renders each page. Second, we make a NodeJS function that calls this script. Finally, we make a GruntJS task that calls that Node function. Fun!

To get started, we need to make sure that PhantomJS is installed. Since we’re using Phantom from the context of a NodeJS application, a very easy way to install it is by using the NPM PhantomJS installer package. Installing Phantom in this manner allows us to make sure we have easy access to the path for the Phantom command while simultaneously having a local, project-specific version of it installed.

To install locally: npm install phantomjs.

Now, we need to write a script to give to PhantomJS that will render a given page. This script will take two arguments. The first is the URL of the page that needs to be opened. The second is the file name for the output. PhantomJS will open the page, and when the page has opened successfully, it will render the page as a PNG and then exit.

var page = require( "webpage" ).create();
var site = phantom.args[0],
    output = phantom.args[1]; site, function( status ){
    if( status !== "success" ){
        phantom.exit( 1 );
    page.render( output + ".png" );
    phantom.exit( 0 );

Let’s create a lib directory and save this file in it. We’ll call it screenshotter.js. We can test this quickly by running this command from our command line (in the same directory we installed phantom): ./node_modules/.bin/phantomjs lib/screenshotter.js google. This should create a file in the same directory named google.png.

Now that we have a PhantomJS script, let’s work on making this run from Node. PhantomJS is a completely different runtime than Node, so we need a way to communicate. Luckily, Node gives us an excellent library named child_process and in particular, a method from that library called execFile.

If we look at the documentation for the execFile method, we can see that it takes up to four arguments. One is mandatory, the other three are optional. The first argument is the file or, in our case, the path to PhantomJS. For the other arguments, we’ll need to pass PhantomJS args (the URL and output from above), and we’ll also want to include our callback function—so we can make sure we grab any output or errors from running Phantom.

var path = require( "path" );
var execFile = require( "child_process" ).execFile;
var phantomPath = require( "phantomjs" ).path;
var phantomscript = path.resolve( path.join( __dirname, "screenshotter.js" ) );

exports.takeShot = function( url, output, cb ){
    execFile( phantomPath, [
    function( err, stdout, stderr ){
        if( err ){
            throw err;

        if( stderr ){
            console.error( stderr );

        if( stdout ){
            console.log( stdout );
        if( cb ){

Our example code from above is written as a Node.js module. It has a function that takes three parameters. These parameters are the same parameters that are used in the PhantomJS script from above and a callback function to run when the task has completed. It then calls execFile and passes it three arguments. The first is the path to PhantomJS. The second is an Array with the our passed in parameters. The third is our callback function. This callback function is called with three arguments: err, stdout, and stderr. err is the error thrown by Phantom if something bad happens within that script. stderr and stdout are the standard error and standard output streams. This should give us everything we need to call our script as though it’s a regular NodeJS function, which will make it perfect for a Grunt task. Let’s save it in lib/shot-wrapper.js.

Now, for the Grunt task:

var screenshot = require( "../lib/shot-wrapper" );

grunt.registerMultiTask( 'screenshots', 'Use Grunt and PhantomJS to generate Screenshots of pages', function(){
    var done = this.async();
    // Merge task-specific and/or target-specific options with these defaults.
    var options = this.options({
        url: '',
        output: ''

    screenshot.takeShot( options.url, options.output, function(){

Let’s take a look at this piece by piece. First, we require the shot-wrapper library we built above. Then, we create the task screenshots by using grunt.registerMultiTask. Since the takeShot method is asynchronous, we need to create a done callback function that lets Grunt know when to complete the task. The options object sets defaults for url and output in case they aren’t passed in (in this case, they’re empty strings, which won’t work). Finally, pass the options and the done callback into the takeShot method. Now, when somebody calls this Grunt task, your code will run.

Let’s give it a try. Here’s an excerpt from my Gruntfile:

screenshots: {
  default_options: {
    options: {
      url: '',
      output: 'ala'
An animated gif running screenshots tasks

The task has run, so we’ll open the file produced:

open ala.png

And voilà: as you can see from this rather large image, we have a full-page screenshot of A List Apart’s homepage. (Note: you may notice that the web fonts are missing in the rendered image. That’s currently a known issue with PhantomJS.)

Just imagine what you can do with your newfound power. Phantom and Grunt give you ample freedom to explore all sorts of new ways to enhance your development workflow. Go forth and explore!

For more in-depth code and to see the way this works when building a project, check out the repository.

Health tech and the digital revolution

healthtechandyouThe London Design Museum has launched Health Tech and You – a search for the best new health tech ideas, inventions and devices. Director Deyan Sudjic reflects on how the digital revolution is breaking down doors in the health industry – and showcases three recent life-changing innovations. “Healthcare is perhaps among the most private and […]

November #UX newsletter out soon!

Coming soon to an inbox near you: the November edition of our UX newsletter.

If you're not a subscriber yet, please sign-up now.

...and, while you're at it, why not subscribe to our blog's RSS feed too? ;-)

the workoutcomputer

the workoutcomputer from BLESS is a PC with a keyboard made out of punch bags: