“To invest in art and design means putting public money into areas whose value cannot be captured on a spreadsheet”

Andrew Marr, Can good design save the economy?

If you’ve ever worked with clients, you’ve probably had a brief that reads something like: ‘We need a [x] to increase our [x], by [x]‘. Studios and agencies are often hired to ‘get results’ for a goal—and on a medium—that’ve been settled on before the first meeting.

Rather than simply delivering the artefact, isn’t the whole point to explore beyond it? To challenge what lead to the chase for the goal in the first place. To study an organisation’s DNA and discover what they’re trying to do, why they’re trying to do it and whether design can offer a better way.

Doing this involves something organisations are generally averse to — risk. It requires acceptance that the results of the process might not be immediately measurable, or at least not measurable in a way marketers can use.

This process is largely what I understand user experience design to be. Not a box of tricks or exercises hacked into a process where the output is already known, but an approach to questioning the validity of that output in the first place. It shouldn’t need a new label—it’s just good design. But let’s leave UX definitions out of this. I don’t want to incite a riot.

The respect and trust required to prove design is capable of more has to be earned. To do that, we have to believe that design being disruptive and challenging assumptions actually produces better responses. I’m interested in how we earn that respect and trust.

It isn’t enough to do the work, or to simply believe in what we’re doing. We have to give people enough reasons to believe it for themselves. Only by living our values and beliefs can we expect to work with people who’s own values and beliefs align with ours. This is important, because it’s when our values and beliefs align that we do our best work.

This is not just about working with clients, either. This is about our colleagues in our product teams. Really, it’s about working in any team.

Simon Sinek likes to point out that The Wright brothers didn’t win the aviation race by having the education, funding, public support or big-wigs of the day on their side. They had none of that. They won the race by giving a small, local team reason to believe in what they were doing. They were united under a banner of shared values, beliefs and purpose. The same can be said for the achievements of Dr. Martin Luther King in the civil rights movement, and of Steve Jobs in the triumps of Apple.

Aligned values breed trust, responsibility and accountability in the face of risk. They are the tenets of a relationship that allow hard questions to be asked, assumptions to be challenged and uncharted territory to be explored — knowing that what we find might not fit on a spreadsheet.

But as blanket statements, “content precedes design” and “content first” have long felt inappropriate to me. They counter my belief that it’s the relationship between content and design that result in the best responses. Not what comes first, but how they’re braided together.

Content is the domain of the designer. It is an element of the user experience, and therefore something designers must be aware of if we’re to produce responses that are appropriate. Believing we can deliver when message and form aren’t intimately bound betrays the promise of design as a communication practice.

How we handle the relationship between unwieldy or badly pitched content and overbearing or off-kilter design is what defines us. Our challenge as designers is to explore that relationship early, given what we understand about the intent and those it’s intended for.

Content is the fuel. Design is the vehicle. We’re better off because of the relationship that exists between them.

The prospect of speaking to 650 people inside Nottingham’s grand Albert Hall was more than a little daunting, considering the one time I’ve spoken before was to less than 50 people in a small meeting room. But the experience was fantastic, and I’ve had some incredibly kind feedback.

If you find yourself with forty or so minutes to spare sometime, you might like to watch it. Amongst other things, I talk a bit about machines with souls, why accidents are great, pencils, Ghostbusters—oh, and there’s a video of me doing a crap jump off a balcony and breaking my heel.

If, for whatever reason, you can’t see the video above, you can watch it on Vimeo. You can also view my slides, but be warned: they make little sense without my rambling to accompany them.

Following on from getting the project proposal and contract signed off during Part I, I’ve procured the content and brand assets so now it’s onto planning and design concepts.

Wait, “procured the content”? That sounded easy! Listen, I know. Planning for, authoring and managing content is hard. We wouldn’t be building entire web apps or writing whole books on it if it was easy. But this project is not an exercise in content strategy; it’s a small, single-page site with a very specific purpose: promoting a bi-annual comedy show. The content consists of:

• Site title and description
• Details of next show (Date/time/venue, booking methods)
• Name, photo, profile (55 words), testimonial quote and link to YouTube videos for each of the 4 acts
• Mailing list signup form
• Links to Facebook and Twitter accounts, and sharing links

Getting started

Gathering snippets of visual inspiration and marking up the content in HTML have been the first two steps. I find marking up content early a great way to familiarise myself with the subject matter, at the same time as actually getting the work done. The difference this time has been my “mobile first” mindset.

Knowing that, at the most basic level, visitors will experience a single-column layout has helped me better focus on content hierarchy: most important at the top, least important at the bottom. No decisions influenced by a more “designed” layout. Traditional wireframes have always felt too influential in this regard. When beginning design concepts, I’ve often felt trapped by the wireframe layout that the client has already signed off, when in many cases all the wireframe needed to do was define simple hierarchy.

Branding work was completed by a separate company prior to kick-off on the website, with a creative direction intended to be reminiscent of 19th century circuses. I’ve received logo variations and a colour palette, but little more. This has been a bit of a blessing, as I can help shape an appropriate web presence for such a young brand without overbearing print guidelines.

Building a prototype

With the content all marked up in gooey, semantically rich HTML, I’ve defined styling for typographic and basic layout elements in global.css. Choosing 14px as my ideal text size, my measurements for type and imagery are based on the 2:3 ‘Musical Fifth’ ratio, and resulting modular scale. While I’ll be further integrating this scale into the design as the site progresses, I didn’t want to get too caught up in it at this stage, as I had quick and dirty layouts to prototype.

There is no existing Punchline website from which to deduce statistics on visitor resolutions or devices, so I’ve chosen to use the display areas of common devices as breakpoints for my media queries. These media queries, declared in a separate screen.css file, only get served up to devices with a minimum display area of 480px (iPhone in landscape mode). Devices with display areas of less than 480px, like “feature phones” or common smartphones in portrait mode, simply get served up global.css. From there it’s been a case of choosing the most suitable grids for the given content and display area.

Breakpoints and layouts

Note: The acts featured in my prototype and design are NOT the real acts appearing in the show. They’re simply examples I’ve picked for the purpose of this write-up, to protect the integrity of the real show.

Devices with a display area of up to 479px will see a single-column layout; each content block stacked on top of another. Devices with display areas of between 480px and 599px see a two-column layout; each act assuming a column (with two acts stacked on top of the other two) and the show summary, mailing list signup, social links and footer all spanning the width of both columns. Display areas of between 600px and 767px retain the two-column layout, but receive a couple of extra snippets of content that weren’t absolutely necessary at smaller sizes.

This is where it starts to get a bit more interesting. Display areas of 768px and larger see the header pulled out to the left-hand side, looking more like a sidebar. This element is given position: fixed; to retain it’s position as the document scrolls (it’s kind of important, seeing as it contains the booking information). The mailing list signup and social links are absolutely positioned above the acts to take the place of the header. The headline act assumes the full width of the main content area, with the middle slot and opening act still split into two columns underneath it. The compere appears underneath these two acts, spanning both main columns.

This three-column layout then morphs into a four-column layout for display areas of 1024px or larger, with the compere coming up to join the two other acts in columns underneath the headline act. There is no change for display areas of more than 1200px yet, but I’ll likely progressively increase type sizes to maintain readable measures and eventually set a max-width on the site container.

1. < 479px
   
2. 480px – 599px
   
3. 600px – 767px
   
4. 768px – 1023px
   
5. 1024px – 1199px
   
6. 1200px >
   

Because each layout is liquid, all that’s really happening from one breakpoint to another is the addition (or subtraction) of floats, percentage widths and margins. As a result, it’s been super quick to knock up the prototype.

It’s sure as hell not pretty, but take a look. Resize your browser to see the breakpoints in action.

Static visual mockup

I found my base typographic sweet spot in the process of creating the prototype: 14px Georgia with a 1.5em line-height. I also chose Rosewood Std Fill for both h1 and h2 headings, as it made sense historically; Adobe based it on an 1874 design, which fits nicely into our 19th century bracket. But other than basic typography and layouts, I’d done no visual design work at all.

Though the brand assets riffed off old 19th century circus artwork, I was told specifically that the site should have “a hint of circus”. Take from that what you will, but I heard: don’t design a page that’s meant to look as if it’s inside some god-awful circus tent or staring down a lion’s throat, just drop enough hints and people will get it.

I’ve based my static visual mockup on the 1024px-and-up layout, employing an eight-column grid (960px wide). It’s hardly the greatest thing I’ve ever designed, but as a first-pass concept, it feels developed enough to send off for some feedback. I deliberately didn’t work into it too much; it’ll develop in due course.

Why 1024? It’s the easiest reference point for the client. They’re used to browsing websites of around this width on their desktop anyway, and this layout is, I suspect, likely to be the one visitors see most.

I emailed the client a link to the visual mockup set in a browser, accompanied by a video. In both the email and video, I emphasise the fact that this mockup is an “artist’s impression” of what the final site may look like. In the video (a screencast), I simply take a few minutes to explain my reasoning behind the responsive approach and demonstrate the breakpoints in action. This should help the client understand what is otherwise a potentially lofty concept, or at least a relatively new one. Particularly if they’re not a complete nerd.

Potential issues

Getting to this point has been an interesting (and at times downright fun) process, and though it feels like I’m making good progress, I’m left with more questions than answers…

Q: How will I get around loading large inline and background images across potentially weak data connections (not to infer strength of data connection from device resolution, of course)?

A: Only load large background images past certain breakpoints? For inline images, load smaller versions by default and feed large versions to more capable devices with Filament’s script?

Q: Will browsers, like IE6, 7 and 8, that don’t understand media queries simply get served up the basic linear layout?

A: Without JavaScript enabled, yes, though there is the option of using css3-mediaqueries.js to mimic the work media queries are doing. The idea of having an entirely JS-dependant layout does feel wrong to me, but I’m not ruling it out for these cases. Alternatively, simply serve up the 1024+ layout to IE7 and 8, as they would otherwise get were the site not responsive at all. IE6 will likely get a basic, linear layout.

Q: Will lettering.js and fittext.js work well enough, and how will I avoid all this JS load for small screen users who won’t even get to see the results?

A: My plan is to set the complicated type using lettering.js and FitText. I’m a bit apprehensive, as I’ve never properly integrated them into a site build. As for avoiding JS bloat on devices that can’t even make use of it, people much smarter than me allude to the fact that it isn’t easy. So, yay.

Until Part III…

Two streams of thinking I’ve found fascinating to see develop over the past year or two are “responsive” (or “adaptive“) web design and a “mobile first” approach. Perhaps because I’m never really involved in mobile-specific projects, it feels like responsive web design has generated more discussion and prompted more writing amongst those I know. But however separately these topics have been discussed, it feels as though they share the same ethos: we can create better experiences by embracing the inherent flexibility, power and dynamism of the web.

Hearing Jeremy Keith speak at DIBI last week helped clarify a lot of the thoughts I’ve been having surrounding the topics. To begin creating better experiences, the first step we need to take as designers is to start relinquishing this delusional idea of control we have over our designs as concrete visual pieces. Every time we fire up [insert your graphics editor of choice] and punch in canvas dimensions at the beginning of a project, we’re simply perpetuating this fallacy that the web is some kind of fixed canvas we can design for. It isn’t. It never was.

640×480? 800×600? 1024×768? Basing the width of a website on the resolution of a desktop computer monitor, particularly when we have no idea what the viewport width might be, has never been the right thing to do. But now, finally, the reality of the exploding mobile landscape has brought the inadequacy of our approach into sharp focus.

Design for the web demands an approach further divorced from the visual communication practices of the past. This is not to say we should disregard any of the undeniably crucial work of designers over the course of history; we should must learn from them and carry that awareness with us always. I don’t think it’s possible to reach our full potential as designers of the web without doing so. But the web is a unique medium unto itself, and designing for it should be approached appropriately.

Why all the babbling?

Being a designer for a product, I rarely create websites these days. But I’ve taken on a small project that, in the process of completing, will hopefully help answer some of the questions I have about responsive web design and design for small screen (by doing, as opposed to just reading about).

I’m not claiming that what I’ll be doing is in any way groundbreaking. I personally know people employing the same, or at least similar, techniques in their work right now, and have been for some time. But I know more still who aren’t, so I’m keen to open up my own experience in the hope it might act as some sort of reference. Through comments, it’d be great to build some discussion around the approaches I’m taking as I work through the project.

The project

The website is for a new company hosting bi-annual comedy shows in Edinburgh. It’s purpose is simple: to be the primary source of information for upcoming shows, providing visitors with methods of booking tickets, and encouraging them to sign up to the mailing list.

With the project proposal and contract signed, the first step has been to procure the content.

Part II next week.

Interface = Brand

In ‘The Interface of a Cheeseburger’, Oliver Reichenstein observes that “Shaping interfaces is shaping the character of things. The brand is what transports the character of things.” It’s possible for the gut feeling we have for a product, service or organisation—Marty Neumeier’s definition of brand—to be defined by the interface. Apple, Dyson and Lego are examples of such brands.

Establish a vocabulary

Interfacing with something is a lot like having a conversation. Just as people learn to articulate themselves, so must an interface. Like social etiquette, the language of an interface should be designed appropriate to situation and purpose. Crafting a vocabulary helps mould the senses of an interface.

Context is king

Is the purpose of the interface a serious one? Utilitarian in nature? Perhaps it’s a tool, or simply used for fun? Successful design decisions are made in the context of usage, content and the business. Complicated web apps demand design decisions that not only serve the user, but that scale well and are performant too.

Make it better

Every time you touch your app is a chance to make it better. “Better” does not equate to more features. Seek out weak points, note down issues and set time aside from your schedule to improve them. Consistency of UX, visual improvements, code dryness, whatever. If you’re developing new features without an eye on the larger experience, you can bet you’re making things a whole lot worse in the long term.

Facilitate good habits

Much like a driving instructor and pupil, it’s a designer’s job to facilitate good habits in the user. Prepare them mentally for the task at hand. Set the tone. Use handholding and signposting techniques to ease the introduction to, and completion of, specific activities.

Make it simple, but no simpler

I like to define simplicity of an interface as: allowing the user to concentrate on the task at hand without realising it.  While the quest for simplicity is virtuous, enforced simplicity can be dangerous. Instead, consistency of approach is paramount. It buys you attention, and while it’s important to know how not make the user think, it’s arguably more important to know how and when to make them think.

Small details make a big difference

A/B tests performed on changes to button text, form element alignments and small passages of microcopy have proven that small changes can make a huge difference to a bottom line. Likewise, crafting elements of the user experience that resonate with us as  human beings creates a bond that draws us back. Taking the time to sweat the details is always rewarded.

Design is for humans

Machines are logical and rational, but humans are emotional and irrational. Try to see design as less about solving problems and more about creating opportunities. Theory can be learned, just as execution can be learned. Our real value as designers is our instinct to know how and when to marry them appropriate to the situation.

Download my slides

Update: This article has been translated to Serbo-Croatian by Jovana Milutinovich from Webhostinggeeks.com.