“What we have is bricks. I don’t see a house, yet.”
Don Draper
I started ‘formal’ art and design training when I was about fourteen years old. I took Art as an option at secondary school and progressed to an exam when I was sixteen. For some reason, I then decided I wanted to be a Forensic Scientist and pursued the sciences as a route to doing that. Big mistake. I failed, and went back to Art and Design for the next 7 years; ending up with a degree in typographic design.
In the middle of all that time, I did a one year course called ‘Art Foundation’; a gateway course into University. I went to a good school to do this: one which had a long, traditional history in Fine Art. As part of the course, we were given an project to do over the preceding summer. This was a ‘reinterpretation’ project: taking a familiar work of art and recreating it. I chose to repaint the Madonna dal collo lungo by Italian painter Parmigianino but to recreate it in post-impressionist style similar to Paul Gauguin. I toiled over this painting all summer using oils and just a palette knife. It stood a little over three feet high and in parts was over a centimetre thick in paint. It was a labour of love.
The day came when I started the new course: a Monday in September. It was sunny in Stockport, and my Dad had given me a lift to the college with the painting stuffed in the back of the car. I was nervous. In fact, I felt a little sick.
The intake that year was about sixty five students or so. All of us were of a certain standard as we’d had to be interviewed and accepted onto the course, but standing there I felt crippled by self-doubt. Pinning my painting on The Wall, the lecturers proceeded in walking the length of the wall observing the work like a doctor quietly observes sick patients in a hospital ward. And, as it turned out, the prognosis wasn’t good.
“Hello everyone. Welcome to Stockport Foundation Course.” Said the head lecturer.
“Please come and collect the work you’ve just put up and throw it away.”
You can imagine the looks on our faces. Thousands of hours had gone into this work. There were tears, anger, but mostly just disbelief.
“On this course, we want you to unlearn all you’ve done before. It’s crap. We’re not here to teach you how to draw. Or paint. Or sculpt. We’re here to teach you how to look and how to think.”
And with that, we were divided into groups and sent to various rooms to start the course. Every couple of days – extending to every week – all of us got together in a room, stuck our work up and had it ripped apart by the lecturers. It was like bootcamp. People left (about 20% of the intake). People cried every two weeks. But slowly over the weeks and months, we all learnt the Rules. The public critique (crit, for short) had rules and a framework. It wasn’t personal: everything was about the work. We learnt to take harsh, harsh comment from lecturers and peers alike. We learnt not to take things quite so personally. Our defence mechanisms were tempered.
In Work
My first professional job, whilst at University, was an internship with an advertising agency over summer. I worked in the studio learning what it was like to be a junior designer. I worked in the cutting room inhaling way too much Spray Mount. I learnt what it was like to critique work in a professional environment.
Critique at work is different to what I was used to. All through my design education, critique was a discussion: sometimes harsh, sometimes heated, but was always a multi-way thing involving lecturers and my peers on the course. All with the aim of taking the work as far as you could. And in academia, you had time. In a professional setting, time is at a premium: my time, my Creative Director’s and our clients. Time is, quite literally, money.
Professional critique still operated within the rules, though. It wasn’t personal, it wasn’t dictatorial: it was about efficiency. I lost count of the amount of times my Creative Director looked over my shoulder and immediately zoned into an element of the content that was causing problems.
“That’s not working”, he would say. Sometimes he’d walk off leaving you to sort it out. Other times, on asking why, he’d sit down and go through the problems with you. Design critique from an experienced designer is efficient, clear and without ego.
Over time, I found my academic critique ‘muscle’ atrophying. I find long debates over whitespace, or interaction patterns, or whatever, quite tedious. In my job, I have to do what my old Creative Director did: identify a problem very quickly and steer the design in the right way. Sometimes suggesting, sometimes telling, but always within the Rules of critique.
Web Designers
There are many designers in our industry who have never attended traditional design school. I feel there is a glass ceiling for people who haven’t, and one of the aspects of that is design critique. Design critique is a learnt skill. It’s something you do within an academic environment where you have the time and the space to learn it without the fear of losing your job.
Many web designers have learnt their craft to an exceptional level but lack the personal contact with an experienced designer who can conduct critique in the right way. Distributed teams are a problem, in this regard: your peers are not available in person to attend a crit. All in all, I feel the web industry is not a place where design critique happens. And it’s because most of us are either out of practice, or haven’t been taught in the first place.
In practice
I feel crits are a place where you can fail without the fear of failure. A place where you can explain your work, debate outcomes, and move the work forward. We do them all the time at Mark Boulton Design. We get a comp, prototype or whatever up on a screen. We stand around and we have a proper design critique. Our work is better for it, and we are too.
I’m finding Twitter a great tool for initiating critique, too, because of the constraints (140 chars), it forces brevity. Brevity that is similar to a busy Creative Director who drops the ‘It’s not working’ bomb. The trick is to understand the tweet in the right content. If it’s framed within The Rules, we know not to take it the wrong way. And this brings me onto just that.
#crit
From now on, when I critique design (or a product or something) on Twitter, I’m going to append the tweet with a #crit hash tag. This means I’m saying this within the rules of critique:
1. Listen: Then talk. Don’t interrupt. Don’t judge. Wait.
2. The Work: It’s not personal, it’s about the work.
3. A Conversation. I want you to explain. It’s the start of a conversation, i’m not dropping a bomb and walking off.
4. It’s Public. The benefit is in a shared conversation. You can’t get this in a book, and with many web designers working in distributed teams, they don’t get from a real person, either.
5. What’s said in the Crit, stays in the Crit: Things can get heated. Feeling can get hurt – it’s human nature where you feel emotionally attached to the work you do – but, it’s important to keep those comments in the framework of the crit. Don’t keep a grudge.
This gives us a framework of understanding. Of course:
“This is SHIT #crit”
is not really in the spirit of the thing.
Not kinder, just better
Snark, ill-feeling, trolling. These are things we see on Twitter every day and they have no place in design critique. Design critique is not a place to be mean, but it’s also not the place to be kind. You’re not critiquing to make friends. Kind designers don’t say what they mean. ‘Kind’ is not about the work, and design critique exists to make us better, but mostly, it’s to make the work better. As soon as you throw words around like ‘bullying’, ‘being mean’ etc you are not critiquing design. You’re being personal and defensive. Let’s stop that.
So please join me in starting proper, considered design critique on the web. If you use the hashtag, I’ll know your intent.
When I first worked in a design studio, I was taught that the first thing to do, as part of the project discovery, was to ‘interrogate the brief’, or ‘rewrite the brief’. This normally involved getting a brief from a client, for us to ask questions, conduct research and then write our own brief and deliver it back to the client to demonstrate our understanding of the project and what we’ve learnt about their business. It’s important to note, this isn’t a proposal. This brief did not include the how, it was the what. What is the project.
At some point in my career, I stopped doing that. I still spent time trying to understand audiences and business, but the ‘creative brief’, as we called it, was something that wasn’t produced. Instead, we normally had a plan. This would exist as documents, or conversations, or outcomes from workshops. The point is, they were many things – all collectively known as ‘The Strategy’.
Recently, I’ve been trying to go back to something a bit more formal and create a single, actionable sentence that can be used to guide a project. This started out as a selfish endevour: I had trouble keeping all of this project stuff in my head in a way that could help my design work. It needed to be simpler.
A Make Mantra
Guy Kawasaki wrote about something similar in 2006, calling them a ‘Make Mantra’.
A mantra is three or four words long. Tops. Its purpose is to help employees truly understand why the organization exists.
The examples he cites, if he had his way to create some, were:
- Federal Express: “Peace of mind”
- Nike: “Authentic athletic performance”
- Target: “Democratize design”
- Mary Kay “Enriching women’s lives”
So, in 2006, they could be used by organisations to describe themselves. However, what I wanted to do was something different. The statement I was after was not a description of what an organisation does, or the story it’s telling its customers, or how it talks about itself, but rather a description of what we must do on the project. A Statement of Design Intent. A new Make Mantra for the Maker, not for the organisation.
Why do this?
- It’s a guide. When you meander on a project, it can help bring you right on track
- It’s a springboard for ideas.
- It helps frame an otherwise complex strategy into an easily digestible statement that creates pictures in your head.
- They help communicate change. In big organisations, and big projects, change is painful.
These statements of intent are a tool. Used to communicate, guide, as a springboard for ideas. A central theme on which to build. They’re a star to sail your ship by.
Putting it into practice
Since last year, Mark Boulton Design has been working with CERN in Geneva redesigning the public website and creating a design language to be used throughout all their other websites.
Redesigning the CERN website is a complex project. It involves a lot of discussion, research and laying the foundation to ensure we can do our best work. A key part of that work for me was to distill our design strategy into something I could use daily. So how did we do that?
How?
The important thing about these mantras is they are tools that you should use every day, not just some strategy artefact, to be created, delivered, agreed and then forgotten. How did we use it in practice?
- Research. For CERN, we ran spent a few months talking to people: internal stakeholders, and visitors to the main public website. We gathered a lot of data and then we spent weeks doing the analysis. Really distilling the data to try and define who the audience was and what they want.
- Competitor Analysis. Find out who is doing something similar. How does that apply to your project?
- Understanding the problem. Through the research, we spent a long time learning about CERN, learning about the problems with the existing site and editorial workflows.
- Create a clear strategy and goals. What are you trying to achieve and how you’re going to do it. My experience is this always changes following the research.
- Boil, simmer, reduce. Through a number of workshops and discussions, we reduced the strategy into a single statement of design intent.
Through our research, we know that people are curious, inspired and intrigued by what goes on at CERN. But the content they read on the CERN site does not – in a large part – delivers on the ‘can this user accomplish this task’ success criteria.
We also knew that the different audience groups we identified for the project need to be spoken to in very different ways: the general public needs to be spoken to very differently to high energy physicists.
Through our competitor analysis, we identified NASA as doing similar work on a human scale: the exploration of science. But, you see, it’s really easy for NASA to inspire people visually because they have pictures of space rockets and planets. CERN had pictures of magnets the size of a house and lots of wiring. Cool, but only to a certain amount of people. We needed to show that what NASA is doing with outer space, CERN is doing for inner space. We needed to Create Wonder. To inspire, to inform, to tell the right story. So, that became our simple, two word statement:
‘Create Wonder’.
We use this simple statement in the project every day this way:
- To check that we’re on track with the design language. Even as simple as something like a photograph. Is is doing this?
- To talk about our design strategy in CERN to stakeholders. Not just initially, but as we design new elements of the site too.
- To create pictures in our heads. It is a challenge to us when we’re approaching the work: ‘go on… create wonder’.
- As a scale: The Wonder Scale.
The Wonder Scale
The strategy very quickly morphed into a scale we could apply to different audience groups. The issue was that presenting some content in a wondrous design would not be appropriate for some audiences. For example, the latest research that’s been published by one of the experiments at CERN should not necessarily be highly visual. The content should be clear, legible, easily scannable etc. But it shouldn’t be shiny. And the opposite is true for other content that is designed to inform, inspire and educate the general public. In that case, the wonder is ‘high’, the former, it is ‘low’.
Let’s have a close look at this.
On this diagram, you can see our four audience groups: Scientists, Educators, Students and General Public. We created personas for each of these, and each of them had a comprehension level: how much they understood about the work CERN does. This went from high for scientists, to low for the general public.
We can then map an inverse ‘Wonder Scale’ on this. The more comprehension you have, or closer you are to the science or organisation, then the lower the Wonder.
So, we had this scale based on our statement of design intent. How did we actually use it in the design work?
How does it look?
This is a screenshot of our latest prototype for the homepage of CERN. Let me walk through what we’re trying to do.
The Goals.
- Create Wonder. The CERN homepage needed to show what CERN was doing as well as say what it was doing.
- The main thing that came through time and time again from the research we conducted was that all the different audience groups need updates. They need to know what’s going on. That was probably the largest need.
- Demonstrate that there are more experiments going on at CERN than just the Large Hadron Collider.
- Effectively funnel people into sections of the site that are appropriate for them.
The How
-
Create Wonder. Because the work going on at CERN is subatomic, it’s very difficult to get imagery that is remotely interesting. You can’t photograph these particles, and as such, the default option is to rely on imagery of the engineering. The engineering at CERN is unique, and awesome, but you’d need to know what you were looking at to appreciate it. The level of comprehension required is high. What we settled on was Event Visualisations.
Every 600 million times a second, protons are smashed together at near the speed of light at various points in experiments in CERN. The computer than creates an image of this. Part of our strategy for the homepage (and how we ‘Create Wonder’) was to show what was happening at CERN right now. Demonstrate these collisions were happening in real time.
- All about the updates. We make the updates panel the primary content on the homepage. It’s updated with links to articles, research, press releases, but also includes statements such as ‘LHC shutdown for Holidays’.
- A lot of people think CERN is just the LHC, but the LHC provides the beam of protons and there are many, many experiments that use it. The small panel on the bottom right will rotate through a status update of a selection of experiments.
Throughout this process, ‘Create Wonder’ was an invaluable tool to sense check our progress. Are we on the right track? Is this content appropriate for this audience, and how should it be presented? Are the stakeholders on board with this strategy?
A New Make Mantra
Now, this is an example from a big, complex project, but you can use these for small projects, too. It’s just the time you take to get to it might be shorter. I’d highly recommend giving them a try: stick them up next to your desk, refer to them constantly, use them as a metric to define how you talk to potentially different audiences for your designs.
I’m excited to use these in my work more. They move a Make Mantra from being about the organisation to a tool for designers to use. Moving it from the organisation to the Maker.
Last year, Chris Shiflett — together with a few other people – decided to get behind blogging again and post a series of posts called ‘Ideas of March’. What followed, throughout March, was some exciting and insightful reading. Having an initiative to blog around seemed to help get people away from Twitter and back to blogs again. I did it, too. And it helped.
I’ve been blogging – on and off – since 2003. That’s close to 10 years (!) and I still find it a useful way of capturing my thoughts. The very act of writing something down for other people to read is a process I enjoy: often it means taking disparate pieces of information, thoughts, conversations and compiling it all into some kind of order. But along the way, there’s been a problem for me. Blogging started to be about other people instead of myself.
When I write longer articles, or I get more people reading them, I can very quickly start writing to their expectations. I begin thinking more about an article as a design problem needing to be solved for a particular audience, rather than a simple creative outlet – just for me, nobody else.
Since last March, I’ve blogged the most i’ve done since 2007. I think that’s not only a reflection of me being more selfish with my approach and understanding – finally – that blogging is part of my creative expression. I don’t write because I want to, I do it because I need to. And it’s taken me the longest time to understand that. But also, I’ve blogged more because I feel there’s been more to say. We’re wrestling with some exciting problems right now, and half of the articles I’ve written have been as a direct result of heated discussion in the Mark Boulton Design studio, or from Twitter.
Twitter is no comparison to blogging. That’s not to say it’s not useful. For me, Twitter is the point of fertilisation of ideas, debate or discussion. Brief conversations that happen there are often where ideas are sown, but it’s here – on this blog – where those ideas are nurtured and grown into something more. The very act of considering what I write is what makes my blog an integral part of my design toolkit.
As with all the Ideas of March posts today, this is just a promise to myself. A promise that I’ll continue to understand why I write, and therefore, not stop. For me, writing about design, and the problems I face with it, is as important as the work itself.
Last Friday, Mark Boulton Design announced something we’ve been working on for the past six months or so: Gridset. A tool for creating advanced grid systems on the web.
For a long while now, we’ve been designing tools and frameworks to help us create grids from HTML and CSS. Some of these frameworks give us a lot of flexibility, and some of them tie us down quite closely with the type of HTML markup we have to use. Since about 2007, this has all been very helpful is giving us some code structure to help us understand, and then build, fairly simple grids.
But, then something happened.
Building responsive grids has forcefully jolted us from our 12-column comfort zone. Now, we’re having to think about appropriate grids for different device widths. This in turn is having the effect of making us readdress our needs for desktop. It’s certainly my experience over the past year or so, that this rather cookie cutter approach for designing grids needs re-evaluating, but we’re lacking good tools to help us with the sometimes painful maths and advanced CSS chops.
Gridset will help with this. And more.
I’ve had a few questions since Friday around some of the features we announced. I’d like to address some of those here:
Gridset is a tool, not a generator.
Nothing is prescribed… you build a bespoke grid system for your project.
Gridset is not a bunch of code you download from Github. It’s a browser-based tool to create grid systems.
Create advanced grid systems.
It can create asymmetric grids, golden ratio grids, or completely bespoke arrangements, not just a row of columns. It allows for fine-tuning of column widths.
For the past few years, the grid systems we’ve seem on the web have all been evenly spaced columns (usually either 12 or 16), and that thinking is now being applied to the latest crop of responsive grids. There is simply more to grids than 12 or 16 columns and Gridset is designed to allow the creation of many, many types of grid.
Generate smart CSS.
There is no need to add lots of classes for offsets and margins. It anticipates every possible configuration and styles accordingly, allowing you to focus on layout.
CSS grid frameworks are great if you’re flexible enough to not worry about an extra div here or there, or a particular class syntax in your CSS. If, however, you care about the semantic structure of your markup then this is a problem. We care. So Gridset has been designed to anticipate every column, margin and padding column configuration of your grid and give you the appropriate classes to use.
Designed for your workflow.
Tinker, save, return. Iterate and publish. Your grids are there whenever you need them.
I’m of the opinion that good grid system design can be abstracted from layout design. Layout gets built on a grid. Most good design systems work this way: the grid is designed, locked down and then layouts are used on top of it. Think of Gridset as your library of grids in one place. There for you to create, iterate and publish. To be used with simply the addition of a single line of CSS.
What next?
Gridset is currently in a pre-alpha stage: working with a few people in the industry that represent what we think our core audience will be. We’ll be quickly moving into a closed Alpha and then a semi-closed Beta selected from the people who sign up to the list on the site. We’re shooting for a summer launch.
In the coming weeks, we’ll be talking more and more about what we’re doing. Follow @Gridset on Twitter for more updates.
Last week at the Responsive Summit, we discussed tools a fair bit. Especially in relation to workflow and how it effects a designer and their output.
Since 1997, I’ve been working almost exclusively on the web. Throughout all of that time, the realisation of what the projects would look like are done in Photoshop. That means, yes, I’ve been using Photoshop in a production environment for fifteen years. Malcolm Gladwell said it takes 10,000 hours, or 10 years of repetitive use, to become an expert in something. I guess that means I’m an expert in creating pictures of websites. Photoshop is like an extension of my mind. To use Photoshop for me is as effortless and almost as fast as a pencil. I get stuff done; quickly.
The change in process to Responsive Web Design means we need to get in the browser faster. But please don’t read this as ‘we need to get rid of Photoshop and/or equivalent tools‘. It doesn’t mean that at all. What it means is that we need to be aware and understand our materials. That means we need to understand how — when you’re designing in Photoshop, or Fireworks — you have one half of your mind in a browser. Not necessarily HTML, or CSS, but thinking about behaviour.
There has been talk for a while of designing a tool for the web that is more aligned with our processes than Photoshop. A lofty goal. And I’m not even sure how worthy a goal, to be honest. Because, at this point in time with Photoshop, HTML prototyping and a pencil, my workflow and tools are okay, thank you. I don’t think i’m suffering as a result of having inappropriate tools. That’s because I understand how each of them works, the material they work with, and how they all come together in my mind.
Understanding materials
I think one of the key aspects of a good designer is to understand your material; be it pixels, ink or markup. That doesn’t necessarily mean you have to design in that medium. Print designers don’t design in ink (well, not much anymore). Architects don’t design in bricks and steel. And web designers shouldn’t need to design in HTML or a browser canvas. If you’re any good at your job, you will understand that media, create for it well and then communicate that well to other people.
Our takeaway last week that the tools we have for certain parts of our job could be better. Photoshop could be better. So could fireworks, and the browser and CSS… the list goes on. RWD adds some complexity to the mix, because we need a good way of increasing fidelity of our work over time, in the browser, whilst retaining some of the things that, say, Photoshop gives us.
Last week, I tweeted: ‘You can’t have happy accidents designing in the browser‘. Jeremy corrected me: I can’t have happy accidents in a browser when I’m writing specific rules and then watching the results in a browser. There is too much in the feedback loop. Photoshop is an extension of my mind and my hand. Through 15 years of continuous professional use, the feedback loop is small. My mind is free to explore options whilst my hand (via the mouse) executes them. Rinse, repeat, explore, iterate. For me, writing explicit instructions in code and hitting refresh in a browser is a long, long way from this.
I said during last week’s Summit that in all likelihood a Web Design Photoshop tool is not likely going to solve any problem we have now. Maybe a small suite of tools will where we can extract certain parts of our process: like designing a responsive grid, for example, or defining a colour palette, or iconography. But when it’s a holistic process, then a designer’s own experience, preferences and ability will trump any tool. Each very much to their own.
These are my notes, conclusions and thoughts from yesterday’s Responsive Summit in London.
Last week, Alex Morris – UX Director at Mark Boulton Design, Chris Armstrong, Designer from Front, the company responsible for Typecast, and Josh Brewer, Principle Designer at Twitter, were discussing the idea that – whilst Josh is in the UK – we should all get together and have a chat about Responsive Web Design; the problems we share, the tools and solutions we’re individually developing, and how we can collectively we can get a better understanding of what RWD means for us and our daily business.
Yesterday, the ‘Responsive Summit’ took place in Microsoft’s offices in London. And huge thanks must go to Martin Beeby from Microsoft for not only providing the room and also the tea, coffee and lunch. Oh, and cake.
In attendance were:
In Person
- Josh Brewer, Twitter
- Alex Morris, Mark Boulton Design
- Chris Armstrong, Typecast
- Nathan Ford, Mark Boulton Design
- Mark Boulton, Mark Boulton Design
- Paul Mckeever, Typecast
- Paul Lloyd, Clearleft
- Josh Emerson, Clearleft
- Ringo Moss, Nerv
- Phillip Davies, Nerv
- Lewis Nyman, Freelance
- Katherine Cory, Freelance
- Mark Hurrell, GDS (formerly BBC News)
- Elliot Jay Stocks, Viewport Industries
- Natalie Downe, Lanyard
- Cennydd Bowles, Freelance
- Anna Debenham, Freelance
- Martin Beeby, Microsoft
On Skype
Ahead of yesterday I was a little sceptical as to the format and the practical value from getting 25 people in a room and have them discuss Responsive Web Design. I thought it’d be a bit of a bun fight. But, actually, that couldn’t be much further from the truth. The people who attended represented a broad range of websites, products, agencies and clients. We had people representing websites and products that have issues of massive scale: the BBC and Twitter. Through to individual freelancers working on site designs and builds for primary schools. The range of considerations on the table was therefore also as broad.
Last week when Chris, Alex and Josh decided on trying to make this happen this week, they had the brainwave of putting a form up on a website to gather questions, concerns or comments from the community. We had a hundred responses or so. All of these were broadly grouped around the following topics:
- Workflow
- Layout
- Sensors
- Images
- Advertising
This first blog post of mine is just about the first point. Specifically, these are my thoughts based on the discussions not necessarily the consensus of the day.
Workflow
We broadly agreed that from our experience, Responsive Web Design affects workflow considerably. Speaking personally, Mark Boulton Design have been building all our projects responsively for the past 18 months – typically HTML/CSS templates for handover to clients or development partners. And it affects workflow a lot. Here’s what we used to do:
- Create planning and design artifacts: site maps, wireframes, user flows and journeys, scenarios etc. All of these were up for revision and change by the client.
- Create flat Photoshop comps based on those artifacts, but only when they were signed off. Oh, and typically that would tally with a billing point.
- Build templates from signed off comps.
Typically waterfall process. This doesn’t work well for us with Responsive Design. For the past few years, we’ve been working the following way, but only in the last 18 months or so has it become increasingly crystal clear for me that there has to be a structure of project flexibility to accommodate the inherent fluid nature of RWD.
- Sketch. Get the ideas down *amongst* the requirements. Meaning, we don’t have design specification documents, we dont have lengthy requirements documentation. We have user stories (or something similar) and we combine them with research, thoughts, sketches, ideas to document the scope of the project.
- Prototype. In HTML. This allows us to get the product – in whatever form – in front of the client. The aim is to remove The Big Reveal. It also lets them see how the site responds on different screen sizes. Also, we can start to think about problems that may arise due to a responsive approach *now* instead of when the templates are being integrated into a backend, or at other production sensitive times.
- Design. However you increase the fidelity is up to you. I use Photoshop, other people use Fireworks, some do it in a browser.
- Iterate. Have a project structure that embraces change. That means a focus on priorities.
- Talk. This approach requires much more collaboration with a client. I mentioned The Big Reveal: the thing designers do where they squirrel away for a few days and then come back and go ‘ta da, look what I made!’. That’s just so risky.
Some of you will think I just described an Agile process – and partly that’s right. There are some things from Agile that are useful for us when designing Responsive sites: prototyping working code, iterating based on priorities, increasing the fidelity of your design work in the browser instead of comps.*
* Note: I’m not saying design in the browser. I’m saying increase the fideltiy, or apply a design system, not do it all in there.
Yesterday, we discussed similar issues around this process. How, in large agencies which are crippled by siloing of design and front-end development resources and their own immovable processes, are finding it very difficult to work with RWD. It’s not because RWD is difficult, appropriate for a project or anything else. It’s because their process can’t accommodate it.
One of the issues is to do with the delivery of design ‘comps’ to a client. The old way was easy: we do wireframes, we make comps from those wireframes, clients sees them, signs them off, we build it. We can’t do that now because we’d be delivering comps for every viewport size. We can’t do that. More the point: we shouldn’t do that. This is when RWD comes under criticism for not being commercially viable. It’s because it’s trying to be shoe-horned into an existing, fixed-canvas, inflexible process.
The take-aways for me, based on yesterday’s discussions, were that we’re on the right track. Prototyping in HTML early, showing and involving clients in the process early – so they can see how a site will respond to different viewports – actually showing them in different devices helps mitigate the ‘The Big Reveal’ and the associated risk. It helps clients understand – and this was a great point made by Cennydd – that RWD is sustainable design and a cost effective, future-compatible, approach to building websites for an ever-increasing myriad of display sizes.
The next part of the day was to discuss Layout. But, I’ll leave that for the next blog post.
I’m not usually one for talking about how criticism affects people: either on Twitter, at conferences or elsewhere.
I am of course talking about the community’s reaction to a few of us getting together in London yesterday for the Responsive Summit. Yes, yes. Stupid name.
But today, I’ve had enough.
- Repeatedly attacking someone, or a group of people, for trying to do the right thing is not cool.
- Inferring that a bunch of friends and peers are elitist simply because they decided to get together to talk about something is not cool.
- Expecting said people to ignore personal and professional attacks is not cool.
- Expecting said people to ‘not be defensive’ is not cool. How would you feel?
- Think. Would you really say some of those things to people’s faces?
Attacking someone on Twitter is like a verbal drive-by: it’s at a distance and you don’t stick around to see the consequences.
I’d like to ask you how you would feel? Personally, I attended yesterday’s meeting leaving a sick family in Cardiff – who could really have done with me being there. I went because I felt it was important: not for me, my business, but for this period in time of web design. People have said it before, it feels like just before Web Standards happened. I was there for that, but wasn’t directly involved. I have a chance to be involved in this, and I’m trying any way I can to help. I ask those people: what are you doing?
This isn’t really about me feeling sorry for myself. For once, I’m reacting to being attacked. The notion of ‘not feeding the trolls’ is equivalent to saying to a victim of bullying: ‘oh, just ignore them’. At some point, you have to stand up for who you are, what you believe and defend yourself. Because if you don’t, who’s going to?
To answer some of the concerns that come up again and again about yesterday:
- ‘Summit’: Yes, we know it was a dumb name, and we’re sorry.
- ‘Elitist wankers’: It wasn’t invite only, people asked to attend and they did.
- ‘Why wasn’t I invited?’: It was a small room, so the whole internet couldn’t fit. It was pulled together very quickly.
- ‘What did you talk about?’: We’re going to blog about what we discussed.
- We’re collaborating on techniques and tools.
- We’re not telling anyone how to do stuff and deciding your fate (how could we even do that?)
I’m finishing off a long blog post about yesterday covering some of the things we discussed about workflow, and talking about how we work here at Mark Boulton Design. I’ll post that later today.
Since I saw Ethan’s talk in An Event Apart in Seattle 2010, I’ve been thinking a lot about Responsive Design. Not just the layout techniques Ethan gave name to and wrote the book on: fluid grids, plus media queries and flexible images, but taking a step back from that into the field of responsive architecture and abstracting that into responsive design in general.
Responsive Design is everywhere
As I discussed in my talk at New Adventures Conference last January, Responsive Design is comprised of three things:
- Sensors: Things that sense the environment (not the weather, but the stuff around it – whatever it is)
- Systems: A system that takes the information from the sensors and tells the actuators what to do.
- Actuators: The things that actually do the moving. The motors, the CSS, the cables.
A simple example of this is your central heating. Mapping central heating to those three:
- Sensors: This is your thermostat. It measures the temperature.
- Systems: This is the software in your thermostat, or on your boiler, that you can programme.
- Actuators: This is the thing that turns your boiler on or off.
This is a responsive design system. Now, looking at web design, let’s try and map Responsive Web Design to it:
- Sensors: This is the browser
- Systems: This is our CSS — specifically the @media declarations
- Actuators: This is our CSS too — specifically what falls within our @media queries
You see, in the browser world, it’s not so cut and dry. Using @media queries, the browser detects the width. The browser is the thing that is sensing here. The system — the bunch of rules that tell the actuators to do something — they live in our @media queries. At this width, do this. The actuators are also in our CSS. They are the ‘this’ in the previous statement. eg. At this width, make this button blue. System > Actuator.
For the past year or so, we’ve been getting to grips with the Actuators and the Systems through using CSS and Javascript. What’s proving difficult, is the Sensors.
More sensors, please!
At the moment, all that we can do reliably (well, fairly), and knowably, is use the browser as our single sensor by which to sense. We have one sensor. We need more. Just for a moment, let’s consider what would be useful information for us:
- Network infrastructure
- Device capabilities
- Screen size
- Context
- Content
If we could have sensors that could detect if you are browsing on a particular browser, could detect what screen size, network and context — eg. on your couch, on a train in a certain geo-locale — we’d be going in the direction of Responsive Architecture and Responsive Design generally. As it stands –– and this is fine for now –– we’re changing layouts based on a screen size. We’re capable of so much more.
Now, am I talking about device specificity? Is this the browser detection days gone nuts? I don’t think so. I’m not talking about deviating from standards here. I’m talking about having better tools to monitor the browsing environment, whatever that is.
A Responsive Experience
Responsive Design (the field) changes a thing because of the environment. Responsive Web Design currently changes a layout because of the environment. I think Responsive Web Design will grow into a practice of changing an experience because of the environment. That means: content, layout, behaviour, perception, brand, feel. All of those things are open for change if we have a good set of sensors, and the right actuators to to create them. Our job will then be focussed on designing the systems knowing that all this good stuff is in place.
It does feel that at the moment, we’re very preoccupied with the component parts of responsive design: how do we sense the environment the user is browsing in,? How do we create a system to change the layout? What’s the CSS to do those changes?
That’s all OK. This is still new.
Over the past year, Responsive Web Design has quite rightly shifted the web standards based design community to a new way of thinking. It’s not really just a layout technique. Responsive design –– if you consider the above sensor > system > actuator components –- is a much broader, holistic practice. It involves every step of the design process in determining the outcomes of the actuators, or defining the sensors and then designing systems around those inputs. The whole thing is involved.
I think we’re at the start of this for web design. This is exactly some of the pain we’re feeling with Responsive Web Design workflow right now. And it’s encouraging we’re seeing a focus on techniques and tools to create better sensing, better systems for controlling more sophisticated actuators. However, I’d love to see more joined up thinking. How does Responsive Design effect our content? Our messaging? The story? How can we shape better experiences by using these simple inputs and outputs?
Responsive Web Design is just the start of us challenging and rethinking our perception of what the web could be. We used to think it was like newspapers. Or computer programmes. Now, we’ve had a glimpse of a web that understands us and can adapt to our needs. That could either be incredibly exciting, or bloody terrifying!
We have to start somewhere. Something has to come first.
In 2001, I started working for the BBC in Cardiff. I worked alongside journalists and project managers for four years on all manner of web sites and applications; ranging from small niche content sites about surfing, through to redesigns of the homepage. All of these projects were approached Content First (but not this Content First), but not one of them had the content, first.
Having worked alongside news and media organisations for the past ten years, I’ve absorbed a lot about the editorial processes across three media: television, print and the web (and a bit of radio, too). I’ve rejoiced at the commonalities and grimaced with pain at the differences between how things are done; both in the organisations themselves, and the different output they produce. Some of those things we’ve taken straight to the web with some success. Others, we’ve tried and failed. Like trying to make websites like CD-Roms. Remember those?
The model that we took right at the birth of the web from print – the templated page and publishing system – is now under attack. It’s under attack from the premise that you need to know your content before you can design it. For anyone who’s worked in publishing, or had to design a highly scalable branding system, or a wayfinding system will know that is nonsense. You don’t need Content First. You need Structure First. Then you need Content all of the time.
Let’s be really clear about this. It is unrealistic to write your content – or ask your client to write the content – before you design it. Most of the time. Content needs to be structured and structuring alters your content, designing alters content. It’s not ‘content then design’, or ‘content or design’. It’s ‘content and design’.
Designing a magazine or newspaper system requires the designer to exercise rigorous restraint with a hugely variable melting pot of content. Working directly with an editorial team, you have to define what types of content you need to design for. News articles, opinion pieces, features – all of these require slightly different design treatment to communicate they are a different type of content to the reader. Design variance must be limited. Why? Well, time mostly. Newspapers and magazines run on incredibly tight timescales and content is literally pored into a mould – trimmed and teased a little, but the templates leave little room for movement. This is not bad practice. This is how content lives and breathes in a fast-moving editorial environment. It has to be fluid. It can’t be locked down early. Content First would not work here.
Content as structure
There is an emerging fallacy in our industry recently. The idea that you cannot create good design without knowing your content. Even I said that a while ago. But, that’s only half true. Newspapers, magazines and many other periodicals and publications in different media prove that assumption wrong every day.
You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure. What is your content made from, not what your content is. An important distinction.
So you have to start with the structure not the words. What exactly is an opinion piece. What are the variables? Can we even define them? Images? How many? (to which, the response is always: ‘I don’t know, it depends!’). We can design around fluidity, but it means letting go of control. Again. How do we do that, then? How do we design around the fluidity? Well, we define structure; of our content, and the templates that content inhabits. We define the rules of the system to display the content in different ways (if we can) to help the reader understand the content better. As Erik Spiekermann says: ‘we give content form’.
Designers as Content Directors
Designers have always been involved with content. We’re not just concerning ourselves with what is visual. So how can we help our clients understand that when we say:
‘Content First!’
We don’t really mean:
‘I’m going to sit on my hands right here unless you give me my content. Finalised, proofed and signed off. Thank you very much.’
No, we don’t mean that. What we mean is:
‘We’d really like to understand the type and structure of the content for this project. Don’t worry, you don’t have to write anything yet, just help us understand.’
We can do this any number of ways, but recently I’ve found this broad process works for me:
1. Talking. And Post It notes. Get a room – preferably lock the door – and talk about the website or application. Not the content (yet). As you’re talking, jot down words that resinate. Then after you’ve talked, stick all the words up on a wall and start to make connections between. Some probably some fancy UX term for this exercise, not sure what.
2. Messy Mess. You should end up with a pile of loosly related words (not content at this point) about some stuff. This stuff is the very DNA of the website. The feel, the tone, the brand, the message through to the nitty gritty of content types, taxonomies, tags and technology. Now you need to sort it all out.
3. Iterate. At some point in that sorting, you will need to start tightening up the structure. Again, I’ve found doing this iteratively and collaboratively the most fruitful.
4. Structure. Now you should have some structure. At some point in step three, there will come a point when you or your client will say: ‘Yes, but what is this?’ pointing at a post note with a word on it. At that point, you get into detail and you start fleshing out what it is. This is defining the structure of your content. And it doesn’t stop here.
5. Page tables. A page table is basically a form for your content. Fill it in. Use this one from Relly, as it’s brilliant. This tool can really help your client later in the ‘oh my God, I’ve got so much content to write and I don’t know where to start!’ phase. It helps focus.
Structure First. Content Always.
Let’s stop siloing content, shall we? We did it for a while when we were designing a largely brochureware, templated web. Now, we’re trying to move that silo from one end of the process to the other. Let’s focus on structure to begin with, and think about content all the time. There is a symbiotic relationship between content and design. One cannot thrive without the other.
Let’s start with structure. Let’s know what our content is made from. Not, necessarily, what it is.
Very useful bookmarklet that renders the page you’re viewing in several device sizes. Great for testing responsive designs.
Some proof that I’m actually working on the book. Here’s a little screeny of one of the example projects in Chapter 5.
It’s a compound grid: 6 column and 4 column combined, but on this layout using the asymmetric 5 column arrangement. The grid is a reworking and adaptation of Karl Gerstner’s compound grid used on Capital magazine.
← Older posts
