Launching the Contiki Agent Site Redesign

Naga IT Services
Filed under: Industry, Talk notes

At last night’s UX Craft meetup, Carlo Kruger and Rich Archer from Unboxed Consulting gave a great talk about launching the Contiki agents site redesign on time and on budget. Here are my notes from their presentation.

The design team was at Contiki in London and the development team was at Unboxed in Cape Town, so they needed to work harder to establish good communication and to have good knowledge transfer. One of the things that led to their success was their focus on design as a process rather than an artefact.

The process

A previous project that redesigned a different part of the site relied heavily on using Photoshop documents (PSDs) as a starting point for development and discussions: not so this time. They started very lo-fi: sketches. The discussions around the sketches let them establish a shared vocabulary, clear up scope, and uncover things that hadn’t been thought about in detail. It also let them see areas where this wasn’t “just a reskin.”

They moved from there to Axure prototypes that the design team built, to the pleasant surprise of the dev team. The lo-fi nature of the prototypes meant that they were quick to make and quick to change, and that they could experiment easily. The design team were asking more questions and figuring things out at the prototype stage after spending a few days on it, rather than asking questions after spending a few weeks working on PSDs.

Getting sign-off

This lead to one of the more interesting aspects of the talk for me: about sign-off from management. On the previous project, the bosses had only been willing to sign-off on PSDs of whole pages. On this project, they signed off on (black and white, fairly low fidelity) Axure prototypes. It’s interesting that the aspect they were willing to relax was fidelity rather than clarity of layout.

(A few bits of further reading on the hairy topic of responsive deliverables: Responsive Deliverables by Dave Rupert; Delivery Logistics by Laura Kalbag; A Maintainable Style Guide by Ian Feather)

Front-end Style Guide

Once the prototypes had been signed off, the design team moved on to Photoshop to flesh out the designs. The dev team jumped into HTML and CSS at this point, rather than waiting for the finished PSDs. They built up a Front-end Style Guide, using a system similar to Atomic Design by Brad Frost. They also convinced the design team to work on modules rather than pages, meaning that pieces of pages could be built as design work was continuing.

Another interesting thing was the use of the style guide for states: the steps in a user journey. The style guide would display each step in the log in process, for example, next to each other on one page. This let the team check for correct styling and consistency across the steps.

Measuring the effect of the change

Perhaps the best part is that by deciding on metrics up front, they were able to measure and demonstrate a link between improved user experience and increased sales and between improved site performance (in terms of speed) and increased sales. that is pretty awesome.

Some quick thoughts about the new(ish) Foursquare

Naga IT Services
Filed under: Industry

When Foursquare did its big update, splitting it into Foursquare and Swarm, I felt a bit meh about it and stopped using it. I had enjoyed using Foursquare because it had changed from being just Check-ins to a pretty good recommendation engine, but the split felt unnecessary to me. Recently I decided to give them a go anyway, and after a couple of days playing with the new apps, here are a few quick thoughts.

The most interesting thing for me is that the new apps embrace a mobile first mindset much more aggressively that the previous iterations: single task focus, smart defaults, and just-in-time interactions.

The cherry on top is that the motion and animation of the interface is generally much improved. The interface feels more alive for it, and more fun to use.


They’ve switched to large text for input. This works well because the text you enter is short. On the previous version, it felt like lots of screen space was taken up by irrelevant stuff, forcing the text size smaller because of the limited space. Now it’s focused on the one task you’re doing: pecking out a quick bit of text.

Smart defaults

Location-based searching is now much cuter and feels much smoother. It makes a (usually good) guess at where you are, but let’s you change it easily. Using smart defaults means less work for the user: just a confirmation of the best guess rather than searching and selecting.

Just-in-time information

There are quite a few tutorial bits, but they are well placed and judged: short bursts of information that pop up as you need them. This method of just in time teaching works much better than front-loading it all and making the user wade through pages of information that isn’t immediately relevant.

More Opera Mini more of the time

Naga IT Services
Filed under: Industry, Reading

When I tweeted about the Opera / Microsoft agreement last week (saying that Opera Mini will become the default browser on Nokia’s Asha and feature phone ranges), I felt like I wanted to say more about it.

The article came back up on my radar a few days ago, courtesy of Jeremy Keith’s link log, which reminded me of why it’s important:

You might want to think about how your Angular-powered JavaScript-required web thang works in one of the world’s most popular web browsers

You might think it’s hyperbole to call it that, but let’s look at some stats. A press release from Opera the other day states that there are 100 million active users of Opera mini, just on Android, which is twice as many as a year ago. Their stats from their State of the Mobile Web report for April 2014 show 267 million unique users of Opera mobile browsers, and their more recent article “How to get the next billion online” talks about these stats in a wider context.

One key factor to consider is that people in developing countries are big users of Opera browsers because of the cost savings that they offer. When you combine this with the fact that many users, especially in developing countries, are mobile-only, you start to see why building with Progressive Enhancement, and not relying on JavaScript for key functionality is so important: you’ll be blocking huge portions of the world from using your stuff.

My own experience with Style Guides

Naga IT Services
Filed under: Industry, Process

Writing up my thoughts on Justin’s talk made me think about what I’ve been doing with style guides on client projects. Here’s a quick run-down.

I’ve used Jekyll to build a style guide before, and was quite happy with it. I did have a lot of tiny files by the end, though, and it did become a bit slow and frustrating. It was also a bit fiddly getting it to play nice with Grunt and a live reload tool.


Most recently, I’ve used Hologram, and am pretty happy with it. It’s a Ruby gem that parses comments in your CSS and generates a Style Guide based on a template that you set up. I struggled a little with the set up, but once it’s going it’s a pleasure to use. Having the documentation and code samples right next to the relevant styles is very handy.

I find that it’s very well suited to small snippets (atoms and molecules kind of sizes, to use Brad Frost’s terminology), but it’s not so great with larger snippets of HTML.

One worry is that it can make your stylesheets noisy. The comments are removed when compiling and minifying the SASS or Less files into regular CSS, so there’s no worries about extra size for production CSS. The development stylesheets become much larger and can become more difficult to read, though, due to the large comment blocks.

A living style guide

Lonely Planet’s Rizzo is the best example of a style guide that I’ve seen, and I want to aim for something like that for the next style guide I make. It’s the only truly living style guide I’ve seen: it uses the Views (templates) directly from the application rather than separate, manual, snippets of HTML.

One of the problems of working in an agency environment is that I don’t, or can’t, always get direct access to the application code: my work runs in parallel to the main application, but doesn’t touch it directly. This mean that something like Rizzo can’t be done anyway, so a separate Front-end style guide using Jekyll or Hologram is he way to go.