Monthly Archives: May 2012

A responsive process is a responsible process

Introduction: the responsive design process

Notes from Steve Fishers talk on responsive design process, at the Future of Web Design 2012 conference. Four key takeaways:

  • the web is not fixed width
  • mobile is not a rushed context
  • clarify the why
  • discover, design, develop, deploy.

The web is not fixed width

The web is not fixed width. That's not to say don't use fixed sizes, just remember that the medium isn't fixed. Even the iPhone for example; you may think you're working with 320px, but change the orientation and you've just changed width.

Mobile is not a rushed context

Mobile is not a rushed context. Assumptions can't be made about user intentions or location. There's no denying we see less on a smaller screen. So what? Everyone still needs to access all the information.

Clarify the why

The golden circle is an approach that will drive a designer or developer to deliver higher quality, robust and innovative solutions over and over. The golden circle has three parts:

  • How
  • What
  • Why

It doesn't matter what you do, it matters why you do it. Everyone knows the what. Most people know the how1. Not a lot of people know the why…

If you can concentrate on working out the why, you'll be a lot more successful in the what and how. The why is the question. The design is the answer.

Apple are a classic example of this. People are so absorbed in why they do what they do, they are happy to pay Apple prices.

1I love this way of thinking but it got me thinking… Do most people attempting responsive know the why, but not the how or what? AKA, they acknowledge the multi device issue but struggle with optimised implimentations?

The responsive design process

Steve went into some detail about the 4 stages of his responsive design process:

  1. Discover
  2. Design
  3. Develop
  4. Deploy


Kickoff and project charter

Get to know your client and let them get to know you. Be fully informed. It's so important to understand who you are working with. If someone's not been involved at the kickoff, question their right to chime in with input at a later stage.

Project analysis

What are the business needs, personas, audience profiles? Get to know them.

IA and content strategy

Audit existing content for quality and quantity. Does your content do what it needs to do? Set about gathering content, use sitemaps to ensure you've got everything accounted for.

Search strategy

Look at page structures, URL naming conventions, meta data requirements, hierarchy. Everything you need to consider when building for an SEO'd site.

Strategic direction

All the info found in the discovery phase should now be brought together in one document, to be thought of like a project map. This should cover search, content, technical and creative strategies. This is the point when the full budget and scope should be set. This moment helps define the project. It prevents people coming in with a solution first; telling you what needs built, then constantly changing the requirements on the fly. Stakeholders shouldn't be coming in suggesting solutions. Problems should be discussed together.


Note: it is only now that we look at the design phase. Look at all that planning that came first. Remember that, next time someone asks you for a mockup. It should also be noted don't worry about your toolkit (the actual quote was more like tools are bullshit). Use whatever tools suit you.

UX Sketches

Iterative process to create rough wireframes. It's fine to use paper sketches, but get into the browser quickly.

Page tables

Key to keeping content separate from presentation, page tables identify each content area in order of importance, with the most important messages to be conveyed in each content area. Content should never be dependant on layout to work effectively.

This is the why. This message is what informs the design. Stories are data with a soul. Data should be well structured, in manageable chunks.

Interaction design

In-browser prototyping. This stage allows for easy demonstration of what happens at set breakpoints.

Visual design

Branding, colour, typography, everything that's required for look and feel. Up to you if you choose PSDs or browser prototypes.

Styleguide and documentation

Styleguide that documents the design system as a reference, so the elements can be correctly implemented. Could take the form of a live, annotated prototype, even with code snippets if necessary.



It's down to business. You've got all the strategy, content, design and assets together, now you have to build it on HTML pages ready for testing. This is where your web standards come into play. Steve actually had this section down as "theme build" but I thought templating was a more appropriate heading.

CMS build

Your theme / template has to be ported onto a CMS, probably including the creation of lots of mini page modules.

Browser and device testing

Cross-browser / cross-device testing to check you're providing a coherent experience to many devices. Remember, not all browsers render HTML and CSS the same. This is OK. It's not about making it look near identical in every browser, it's about creating accessible journeys on all devices.


Content migration

A website without content is a black hole of sadness. Define the scope of the content migration phase depending on the discovery / audit phases.

User acceptance testing

UAT helps confirm the objectives and requirements defined early in the project. It's like moving into a new house; this is the learning how everything works and getting comfortable with living here.

Documentation and training

Document things. Share processes. Understand how things will live in the system and write it down. Essentially a potential handover. Document all markup as well as admin functions.

Launch plan and release

Archive current website. Prepare new website for release. One last quality checklist. Go through a publication checklist, check meta data and title tags etc. Set up all analytics.

Start of operational plan

For many people the website would be alive in some form for a while now, but only now does the website really come to life on its own.

A responsive process is a responsible process

Responsive techniques can be tricky, but if we approach it content first the whole design can be simpler than what we're used to. Responsive is all about the content. It's about rethinking content creation, and getting unification from fragmentation.

The first website ever built is fluid, because the web has always been fluid. Make things easy for future devices, and accessible to all. Create once, publish everywhere. A responsive process is a responsible process.

Developing government web accessibility guidelines

How User Vision built a web accessibility culture in Abu Dhabi

Last night I attended the Scottish Usability Professionals Association monthly seminar for a keynote by Chris Rourke of User Vision, on "Developing government web accessibility guidelines and a web accessibility culture." Having recently authored a web standards document which focused on web accessibility, I was keen to learn of their process and identify parallels and pitfalls in both our approaches.

The presentation centred around a project undertaken by User Vision for the Abu Dhabi government in the Middle East, who were keen to improve the accessibility standards of government websites across the estate. Accessibility standards were identified as poor to average at best, with varying levels of understanding of what web accessibility is.

Part of the increase in awareness and interest in accessibility could be attributed to the UN Convention on the Rights of Persons with Disabilities which Chris cited as a driver for the Abu Dhabi government to take action.

Six phased approach

User Vision split the project into six phases to establish the accessibility guidelines:

  1. kickoff and background info
  2. develop the guidelines blueprint – high level outline based on proven better practice, existing international standards and needs of major disability groups
  3. identify the baseline of current landscape
  4. development of guidelines
  5. implementation and support materials
  6. evaluation of sites and development plan.

During the development of the guidelines blueprint, it was noted that existing international standards (eg WCAG2) would be difficult to understand in their natural form. Whilst these guidelines are excellent in their own way, the concept and explanations around "Perceivable Operable Understandable and Robust" are tricky enough for English speaking accessibility consultants in the West, nevermind translated to Arabic for an audience new to accessibility. It was decided to develop an easy to understand guide at two conformance levels: mandatory and optional. These guidelines would be ordered by element type (images, colour, navigation, forms, tables, audio, video etc) and more aligned to the technical reference of WCAG1.

For implementation and support two key documents were delivered: a Technical Implementation Guide and How to Assess Accessibility Guide. The former would detail the hows and whys of implementing HTML, CSS, JS and related front end presentations whilst the latter explained how to measure how accessible a website is.

As well as the government website estate, supplier agency skills were also evaluated though a series of site audits (were their sites accessible? did they have an accessibility policy?), questionnaires, and face to face interviews. The approach and attitude to accessibility were recorded and reported back to the government with ratings that would eventually make up an approved supplier list for future developments.

With the hows explained, we took a look at why a whole region should have such a poor history of accessibility.

Understanding the accessibility ecosystem: East and West

The accessibility ecosystem is made up of 3 parts:

  • people with disabilities
  • companies, service providers and government bodies
  • suppliers.

Each part brings it's own difficulties in understanding the market. For example, because many families take care of their disabled relatives in some extent of secrecy, it is very difficult to obtain accurate stats on numbers of disabled members in society. Perceptions of disabled people have only been changing in recent years.

…people with disabilities in this region still face obstacles in being included in society alongside people without disabilities.

World Bank on disability in the Middle East and North Africa

This is in stark contrast to the West where you have a tradition of activism amongst the disabled communities. It's been over 20 years since the ADA was passed in the USA.

Companies and service providers may be ill equipped to cope with new requirements due to a lack of exposure in an accessible culture with local legislation. In a region with no laws to govern the accessibility of a website, what consequences are there to not following requirements? Contrast this with the West, where suppliers may face scrutiny from pressure groups such as the RNIB or legal action such as that taken against the Sydney Olympics website in July 2000 (A Cautionary Tale of Inaccessibility: Sydney Olympics Website).

In the West government bodies would come under pressure if particular groups were discriminated against. In a democracy, you'd be voted out. If there's no democracy, not much is going to come of not complying.


It's fantastic news that the Abu Dhabi government are taking steps to improve accessibility in the region through its own websites. The realisation that a lot of sites in the East are inaccessible is just an observation, not a criticism. Having a plan in place to tackle the issues is the first step to creating an accessible culture.