Blog Category: design
My Handbook – Environment
I’ve been doing a talk this year called ‘My Handbook’. it’s a rather silly little title for a bunch of principles I work to. They are my ‘star to sail my ship by’, and I’m going to start documenting them here over the coming months, starting with Environment – a post about how, for me, design is more about the conditions in which you work.
I’d describe myself as an armchair mountaineer. I enjoy reading about man’s exploits to get to the roof of the world, or to scale precipitous walls under harsh conditions for no other reason than the same reason George Mallory said he was climbing Everest: ‘Because it’s there’.
In any expedition to a mountain, great care and consideration is taken over the kit, the climber’s skill, the team around them, the communications, the list is seemingly endless. But, the biggest single factor in a successful trip are the conditions of the mountain. Will the mountain let them up. And back down again. Assessing the condition of a mountain takes experience, time and careful consideration; it may be snowing, too warm, too much snow on the ground, too cold, too windy. The list of variables is endless, but the climber considers all of them, and if necessary moves to adjust the route, or simply doesn’t attempt the climb.
Now, let’s shift to design – not necessarily web design, but commercial design of almost any kind. Let’s say you take a brief for a project, you begin the work and suddenly in the project, other stakeholders come on board and start to have comment on your work and direction on strategy that was unknown to you. We’ve all had projects like those, right? Suddenly, your work becomes less about what you may think of as ‘design’, and more about meetings, project management, account management, sales, production work. You know, all of those things that have a bad reputation in design. Meetings are, apparently, toxic. Well, I’ve started to look at this in a different light over the past few years.
As I’ve grown as a designer, like many, I’ve found myself doing less ‘design’. Or, rather, less of what I thought was design. Five years ago, I thought design was creating beautiful layouts, or building clean HTML and CSS, or pouring over typefaces for just that right combination. Now, this is design. But, so are meetings.
Experienced designers spend time making the environment right whilst they are doing the work. Because, frankly, you can push pixels around forever, but if the conditions aren’t right for the work to be created and received by the client in the right way, the work will never be as good as it could be. But, what do I mean by ‘conditions’? Here are a few practical things:
The physical space: I see a large part of my job as making the environment in the studio as conducive as possible for good work to happen. That means it’s relaxed, and up-beat. Happy people make good things.
A Shit Umbrella: It’s my job to be a filter between client and my team on certain things. Someone recently described this as being a ‘Shit Umbrella’.
Politics: Wherever you get people, you get politics – because people are weird. I spend a lot of time on client projects trying to traverse a landscape of people to understand motivations, problems, history or direction. Once you understand the landscape, you can assess, and work to change, the conditions.
People first, process second: We fit the processes to the people rather than the other way around. Our team runs things that works for us, but that’s the result of a lot of trying & discarding. Like tending a garden, this is a continual process of improvement.
Just enough process: I’m a firm believer in working to the path of least resistance. Being in-tune with how people work, and changing your processes to suit, helps create a good environment. But we ensure we impose just enough structure. To much, and it gets in the way. This doesn’t work if you don’t do the previous point, in my experience.
Talk. Do. Talk.: It really is true that the more we talk, the better work we do. We talk in person, on Slack, on Skype, on email. Just like meetings, there is an industry-wide backlash against more communication because the general consensus is we’re getting bombarded. But recently, we’ve been working to change that perception in the team so that talking, and meetings, and writing is the work. It’s tending the garden. Making the conditions right for good work to happen.
Making things is messy: This is actually another point from my ‘handbook’. Since the 1950’s clients and designers have been sold a lie by advertising. Design generally isn’t something that happens from point A to Z with three rounds of revisions. It’s squiggly, with hundreds or thousands of points of change. A degree of my time is spent getting people – clients, internal clients, the team – comfortable with the mess we may feel we’re in. It’s all part of it.
I see all of this as design work. It’s also my view that much of the disfunction from large agencies to other organisations is that this work isn’t being done by designers because they don’t see it as the work. It’s being done by other people like account managers who may not best placed to get the conditions right. Designers need to take responsibility for changing the environment to make their work as good as it can be. Sometimes, that means sitting in a board room, or having a difficult discussion with a CEO.
Mountaineering is so often not about climbing. You may do some if the conditions are right. Design is so often not about designing beautiful, useful products. But, you may do some if the conditions are right.
Creating moodboards is something I was taught from a very early age. In primary school, they were a simple mixed-media way of expressing a form of an idea.
The thing I find interesting about mood boards is not the end-result, but the process of creation. Watching my children make posters from torn up bits of newspaper and magazines is really no different to watching my clients do it. Similar to watching other activities – such as affinity sorting, or depth interviewing – it’s the listening that I find interesting. Every moodboard tells a story, and as a designer, listening to your clients tell that story when they make them can be very insightful.
Making moodboards for you, not for me.
I have to be honest, I don’t make moodboards for myself. Not physical ones anyway. When I familiarise myself with a brand, or make some suggestions for design context, I always try to place those things in a context the client understands. This is where design visuals are important. They are almost unsurpassed in their immediacy of understanding for a client because they show the design in context. Of course, replace that with a high fidelity prototype, and you get the same thing. But, I want to step back a little here, as to when I find creating moodboards valuable.
Let me ask you a question: how many times have you heard this from a client?
‘I’m not so sure I think the design is heading in the right direction’. ‘It needs more pop’. ‘It’s just not us’.
These are all because a client cannot communicate about design at the same level we do. So, it’s abstract. Either that, or:
‘I don’t like that green’. ‘That button is great! But, it needs more pop’. ‘The logo needs to be bigger’.
Then things get subjective and extremely detailed. Why? Because these are approachable things people can comment on. More often than not, these comments are a failing that should rest firmly on our shoulders. We need to give our clients the words and understanding to express their thoughts. Either that, or we tease out these issues earlier in the process, in a way that is abstracted from the design work that will come later. This is where I feel collaborative moodboards work extremely well.
So, why would want to try and run one of these sessions?
When a client’s brand is repositioning, sometimes we’re brought in very early on the back of a strategy. No tactical work as been done. So, it’s up to us to navigate the waters of implementing the branding strategy. Making design work on the back of a few bullet points in a slide deck can be challenging.
Usually in a discover process, I will get a few red flags from speaking with a client. Generally these come through when talking about competitors, or things they like.
When I get conflicting stories from different stakeholders. The homepage team has a completely different view on the branding than the marketing team.
When branding needs evolving. A lot of organisations have mature branding collateral for print and advertising. Not so much for web (still!), so these are useful exercises to start to tease out differences or how they can align to the web in future.
I’m sure there are more, but those are few I can think of off the top of my head for now.
How to run a collaborative moodboard session
- Get the stakeholders in a room. 3-4 is ideal. 9 is way too many.
- Bring with you lots of magazines, newspapers, flyers – just physical paper stuff – that you can all cut up.
- Glue. Lots of glue. One tub each.
- Large (A1) pieces of paper.
The thing about this that I find interesting from a people-watching/behaviour perspective, is that the act of cutting things up and sticking them down is something that most of these people wouldn’t have done since school. The process involves collaborating, getting stuck-in and discussing the work. I find it a great leveller for the client team (hierarchy quickly disappears), and a very good ice breaker.
You set the brief for the morning/afternoon (all day is generally too long for the making part of this process). The idea is to find content that communicates part of the visual story of the product – and that could be anything:colour, type, texture, image – and stick it down.
For the agency team, it’s our job to ask questions throughout the day. To tease out the insights as people are in the moment of choice – before they’ve had chance to post-rationalise. And you know what? Answers like: ‘I just really like this green’ are great, because our next question is ‘Why?’ and it forces rationale. Without us being there, and asking that, almost always post-rationalising and ‘business stuff’ gets in the way of finding the truth behind those choices.
Quite often, just like cave paintings, moodboards are an artefact of a conversation. We often discard them from this point because they have served their purpose. We have the insights. The marketing team are best buddies with the homepage team. We all heading in the same direction.
So, next time you start a project and you need some steer on branding, or reconciling differences of opinion on a client team, try collaborative moodboarding as a way of coming together to try and solve the problem.
Responsive Web Design – Defining The Damn Thing
Unlike many design disciplines, web design goes through cyclical discussions about how to define itself and what it does – anyone who’s ever spent any time in the UX community will know about this.
In 2010, I attended An Event Apart in Seattle. During that show, I saw three or four presentations – from Eric Meyer, Dan Cederholm, Jeremy, and of course, Ethan. All of them, independently, talked about how using media queries and CSS we could change the content using a fluid layout. It was a perfect storm, and indicative of the thinking that led Ethan to write – and A Book Apart to publish – Responsive Web Design a year later. The rest, they say, is history.
Responsive Web Design had a simple formula: fluid grids, media queries and flexible images. Put them all together, and your web product will be responsive. As Jeffrey said:
If Ethan hadn’t included three simple executional requirements as part of his definition, the concept might have quickly fallen by the wayside, as previous insights into the fluid nature of the web have done. The simplicity, elegance, and completeness of the package—here’s why, and here’s how—sold the idea to thousands of designers and developers, whose work and advocacy in turn sold it to hundreds of thousands more. This wouldn’t have happened if Ethan had promoted a more amorphous notion. Our world wouldn’t have changed overnight if developers had had too much to think about. Cutting to the heart of things and keeping it simple was as powerful a creative act on Ethan’s part as the “discovery” of #RWD itself.
The idea of responsive design has taken a few years to go from cubicle to board room. But now it is a project requirement coming directly from there. For the past eighteen months, at Mark Boulton Design, we’ve seen it as a requirement on RFPs. And with that, it brings a whole other set of problems. Because what does it mean? Hence, we have to Define The Damn Thing all over again. And recently, to be honest with you, I’ve stopped doing it. Because, depending on who you speak to, responsive web design has come to mean everything and nothing.
There are some who see it as media queries, fluid grids and scalable images. There are those who see it as adaptive content, or smarter queries to the server to make better use of bandwidth available. There are those who just see it as web design.
Me? I think it’s just like Web 2.0. And AJAX. It’s just like Web Standards (although to a lesser extent) and exactly like HTML5 (in the minds of those of you who aren’t developers) and its rather splendid branding. Responsive design has grown into a term that represents change above all else. To me, responsive design is more about a change in the browser and device landscape. A change in how people consume content. A change in how we make things for the web. And responsive design is just the term to encapsulate that change in a nice, easy solution that can get sold to a board of directors worrying about their profit and loss.
‘Responsive design is forward-thinking and means it will work on a phone, and that’s where things are headed’.
We’ve heard this line time and time again over the past couple of years. You see, responsive design is a useful term and one that will stick around for a while whilst we’re going through this change. How else do we describe it, otherwise? Web design? I don’t think so. No board member is going to get behind that; it’s not new enough.
How we work
I’ve had a few people ask me recently about how we work at Mark Boulton Design. And, the truth be told, it slightly differs from project to project, from client to client. But the main point is that we work in an iterative way with prototypes at the heart of our work every step of the way.
Work from facts AND your intuition
We always start by trying to understand the problem: the users of the website or product, the organisation on their customer strategy, the goals and needs of the project, who’s in charge and who isn’t. There’s a lot to take in on those early meetings with a client. One of the first things we do is to try and put in place some kind of research plan: what do we need to know, and how are we going to get it.
This could be as simple as running some face to face interviews with existing or potential customers coupled with a new survey. Of course, good research should provide some data to a problem, not just ‘what do you think of our website?’. Emma has written some good, quick methods for doing this yourself.
We couple that with trying to extract the scope from the client. I say that because, half the time, we’re given a briefing document – or something similar – and most of the time that document hasn’t been written for us. It’s been written for internal management to sign off on the budget of the project. So, rather than ask for a new document, we run a couple of workshops to tease out those problems:
User story workshop
This workshop is designed to tease out the scope of the project – everything we can think of. We ask the client to write user stories describing the product. Nothing is off the table at this point and our aim is to exhaust the possibilities.
Persona / user modelling workshop
Personas have been called bullshit in UX circles for years now. Some say they pay lip-service to a process, or they’re ignored by organisations. Whatever. I think, sometimes, something like personas are useful for putting a face to that big, amorphous blob of a customer group. Maybe that’s just a set of indicative behaviours or maybe a lightweight pen-portrait of an archetypical user. The tool is not the important thing here, but how you can use something to help people think of other people. To help an organisation to think of their customers, or designers to think of the audience they’re designing for, or the CEO to think in terms of someone’s disability rather than the P&L.
What I find generally useful about running a workshop like this is that it exposes weaknesses in an organisation. If a client pays lip-service to a customer-centric approach, it will soon become very evident in a meeting like this that that’s what’s going on.
This is a vital workshop for me. As a design lead on a project, I need to understand the tone of a company. From the way it talks about itself, through to the corporate guidelines. But, my experience is, that’s only half the story if you’re lucky. So much of a brand is a shared, consensual understanding in an organisation. Quite a lot of that can go un-said. This workshop is, again, about teasing out those opinions, views and arguments.
The first three workshops have the added bonus of finding out who runs the show in an organisation. I make it my business to find out – and get on side – the following people:
- The founders / CEO. This should be a given.
- The people with a loud mouth. It’s useful to find the people who have a loud voice and get them around to our way of thinking. Then they can shout about our work internally.
- The people with influence. Sometimes, these are the quiet, unassuming people, but they carry great sway. If we want things done, these people need to be our friends.
That’s quite a lot of people to keep happy, but if we get these three groups on side, we find projects run a lot smoother.
Prototype your UX strategy
Leisa gave a great talk at last year’s Generate conference in London about prototyping your UX strategy. The crux of this was it is way more efficient to demonstrate your thinking and design, than it is to talk about it. If you can quickly make something, test it, iterate a bit, and then present it, then you can massive gains to cutting down on procrastination and cutting through organisation politics like a hot knife through butter. Showing that something works is infinitely more preferable to me than arguing about whether something would work or not.
Wherever possible, we’ve been making prototypes in HTML. It gives us something tangible and portable to work with. We can put it in front of users, show a CEO on their mobile device to demonstrate something.
The right tool at the right time
I’ve spoken before about designing in the browser, or designing in Photoshop, or on pencil, or whatever. Frankly, we try to use the most appropriate tool at the right time. Sometimes that’s a browser, but a client may respond dreadfully to that because they’re are used to seeing work presented to them in a completely different way. Then, we change tack and do something else. My feeling is the best design tool you can use is the one that requires the least amount of work to use: be it a pencil, Photoshop or HTML.
agile not Agile
I feel that design is a naturally iterative process. We make things and then fix things as we go. Commercial design, though, has to be paid for. And so, in the 1950’s, the Ad industry imposed limits to this iteration – ’you have three changes, then you must sign off on this creative’. Of course, I can understand this thinking; you can’t just get a blank cheque for as many iterations as you like for a project until something does (or does not) work. But, what we gain in commercial control, I’ve found we’ve definitely lost in design quality. It takes time to make useful, beautiful things.
So, from about 2009, Mark Boulton Design have been working in the following way:
We work in sprints that are two weeks long. We never have a deadline on a Friday. Sprints run from Monday to Monday, with a release end of play Monday.
‘Releases’ are output. Sometimes code. Sometimes research. Sometimes design visuals.
We front-load research into a discovery sprint. This is to get a head-start and give the designers (and clients) some of the facts to work around. Organising, running and feeding back on research takes time.
Together with the client, we capture the scope of the project with user stories. These are not typical Agile user stories – for example, we don’t find estimating complexity and points, useful in our process – but they are small, user-centred sentences that describe a core piece of the product. It could be a need, or a bit of functionality, or a piece of research data. The key point here is, for us, they are points of discussion that are small and focussed. This helps keeps us arrow-straight when we prioritise them sprint on sprint.
We conduct research each sprint if it’s required. This is determined by the priorities for that sprint. For example, if the priority for the sprint is focussed on aesthetics, or typography, or browser testing, then usability testing is not going to be of much use for those.
And now for some of the commercial considerations:
Contracts are most often fixed-price, but broken down into sprints. Each sprint has an identical price.
We bill as we go. The client pays a degree up-front, and that is then factored into cost of each sprint.
We explain to prospective clients how we work: each sprint, we work on agreed priorities, with no detailed functional spec to work against.
Points. In the past, we’ve worked on Agile agreements where we would be delivering against agreed estimated points. This was to see if we could make web development agile work in a project environment. It didn’t. We found we were delivering to the points, rather than to the project. Plus, if we didn’t hit the points for that sprint, we were penalised financially.
Coaching our clients through this process is as challenging as coaching through clients of a responsive design project. When the project is in the early-mid messy stages – when client preconceptions are being challenged, the prototype is not being received well by users – it takes a strong partnership to push through it. Design is messy. Iteration, by it’s very nature, is about failing to some degree or another. Everyone has to get used to that feeling of things not working out the way they first thought.
The sticky end. When we get to the final stages of a project, we should be in a good place. The highest priority items should be addressed, we will have buy in and sign off from the right people and we should be focussed on low priority features. But sometimes, that’s not the case. Sometimes, we’ve got high priority things left over which are critical. And that’s the time when we have to go back to the client and discuss how these need to be addressed. Sometimes that’s an extra sprint or two. Sometimes it’s an entirely new contract.
What we don’t do from ‘Agile’
We don’t do:
Estimating tasks. We don’t assign time to design tasks. In our studio, work just doesn’t happen that way. Generally, things are a bit more holistic.
Tracking velocity. For the same reason above, if we’re not measuring delivering against user stories in a numeric way, we can’t track our velocity.
Retrospectives. We don’t run traditional retrospectives on sprints. Maybe this is more a symptom of a close, high-communication level of our team. We’re talking all the time anyway. We have found that retrospectives have been a useful forum for clients to feed back on how they’re feeling about progress in the past, but this has felt like a somewhat forced environment to do it. So, recently, we have points of checking in with a client to see how they’re feeling about things.
So, that’s about it. A whistle-stop tour of how we like to work. As much as possible, we’ve tried to tailor our process to what works for us, built on some useful structures that agile gives us. I guess the most important thing for us is that we’re not wedded to our processes at all. We regularly shift focus, or the way we work, to meet the needs of particular clients or projects. Just as long as we align those processes to how design naturally happens, then I’m happy.
Al Jazeera & Content shelf-life
From speaking at the phenomenal MK Geek Night All Dayer, to launching a project three years in the making for Al Jazeera, the releasing a new design language for one of the oldest university in London, to Mark Boulton Design being nominated in four categories in the Net Awards. It’s been a busy couple of weeks.
Last week, I was up in London visiting a client when I heard that another project of ours was to be launched shortly. It was part of a project we’ve been working on for just over three years: the global design language for Al Jazeera Network digital, with the first two products being launched in Turkey and a beta of the Arabic news channel.
There is so much to talk about on a project of this scale. Here are just a few highlights:
- Spending time with journalists and the newsroom to understand how news is reported.
- Working with Al Jazeera during the Arab Spring; from the uprising in Egypt to Libya.
- Course-correcting throughout the project. Responsive Design wasn’t really a thing three years ago.
- Designing in four languages – Arabic, English, Turkish and Slavic – when the MBD team primarily speaks one.
- Adopting an Object Oriented approach from content through to code. Modular, transferrable and scalable. It required a level of detailed thought right down to how content types were defined in the CMS.
- Working with three development partners across three independent content management systems.
I could go on and on. And I probably will at some point. Needless to say, none of the above could achieved without a patient, smart and agile client-side team. Good job the Al Jazeera team are just that.
There are many buzz words you could label this project with: content-first, responsive, atomic, OOCSS. Again, I could go on. But the one thing that was first, central and always through prototyping and early strategy was good research. It was a research-first project. That probably won’t come as a surprise to some of you given we have our own in-house researcher, Emma. What may come as a surprise, however, is the degree in which that early research led approach laid the foundation for a fundamental shift in how Al Jazeera thought about their content.
Many news journalists think of their content as a few distinct types:
- Rolling news: Typically taken straight from the wire and edited over time to fit the growing needs of the story.
- Editorial: Longer form piece. Still highly topical and timely.
- Op-ed: Opinion piece from a named author.
- Feature: A story. With a beginning, a middle and an end. Long-form content, and not necessarily timely.
These can all be mapped to timeliness; both in terms of how long they take to create and their editorial time-life. The more timely a piece, the shorter it takes to create and the shorter the shelf-life.
- Rolling news: timely, short shelf-life.
- Editorial: timely, long-form, short to mid shelf-life.
- Op-ed: Long-form, mid shelf-life.
- feature: Long-form, long shelf-life.
Publication schedules are often focussed around this creation with journalists having several pieces of the different types in various degrees of completion to various deadlines focussed on different stories. This is a comfortable mental model, one that newspapers have been arranged around for decades. But it isn’t necessarily how users of websites look for content. Users will not typically look for a type of content, but will look for a context of a story first: the topic.
The new information architecture of the Al Jazeera platform has been built around a topic-first approach. But also, the modular content and design allows for the rapid changing of display of the news as a topic or news story moves through the various content types. It’s a design system, connected to a CMS that accommodates what news naturally does. It changes.
The Design System
The whole platform is built on top of Gridset using modular design principles. The content is modular and multifaceted, designed for re-use, as is the design. For years now at Mark Boulton Design, we’ve not designed websites, but an underpinning design system with naming conventions, rules, patterns. This is particularly useful when many CMS software thinks of content objects in this way. Our systematic thinking can applied all the way through CMS integration. Software engineers love designers giving them rules.
It’s funny, we seem to have just discovered this in web design, but many other design disciplines have been approaching their work in this way for decades. Some for centuries. Take typography, for example. The design process of creating a typographic design is systematic thinking at its purest. Designing heading hierarchies and the constituent parts of written language can be approached in an abstracted way. This is exactly the right approach when designing for other languages.
Arabic has obvious challenges for an English-speaker. Not only is it written right to left, but the glyphs are non-roman. To approach this as a English-speaker, we needed to create tools and process to help. Words no longer look like words, but shapes of words. Page designs no longer look like familiar blocks of text, type hierarchy and colour. We saw form more than we saw function.
Just the start
Three years is a long time to work on a project. I’m so delighted to finally see the design system in the wild. For such a long time, we only saw it in prototype form, but you can only take prototypes so far. We needed to pressure-test content types, see where it breaks, adjust a hundred and one small details to make it work. All of this just underpins the fact that now the system is being rolled out, there needs to be changes made every day to evolve the system. This is the web after-all. It’s a feature, not a bug.
In my fourth article for 24ways over the years, I wrote about typesetting the right rag.
One of the first little typesetting trips I was taught – in my internship at an advertising agency – all those years ago, was how to make text fit within a given space, but still read well. This involved a dance of hyphenation, letter-spacing, leading and type-size. But a crucial ingredient of this recipe was the soft-return.
Scanning a piece of text I was looking for certain criteria – or violations – that needed a soft-return (or, in Quark XPress, shift-return). Using those violations, I would typeset the right-rag of the piece of text, and then use hyphenation, and what-not, to tease the rag into as smooth a line as possible. All whilst ensuring the content was pleasurable to read. In a perverse kind of way, I always enjoyed this part of the typesetting process.
My article on 24ways is about how we can apply this thinking to the web, where the inherent lack of control on the medium means we have to apply things in a slightly different (read: clumsy) way.
Emma read the article this morning and pretty much summed up the way I feel when I read text sometimes.
Just like a musician listens to music, I view text in a different way to most people. I just forget that I do it most of the time.
I can hardly believe that 24ways has been running since 2005. In the web years, that’s like 72 years ago. It’s a credit to Drew, Brian, Anna, and Owen. It’s not easy running this year in, year out, on a daily publishing schedule for a month. Hours and hours of work go into this, and we should all be thankful for their time and effort. Oh, and let’s not forget Paul, who has given 24ways a lovely redesign this year (you can read more about that on his blog)
Design Abstraction Escalation
What are we losing by abstracting our design processes? Could it be as fundamental as losing a sense of humanity in our work?
A few years ago, Michael Bierut, wrote about a natural progression in a designer’s career.
“The client asks you to design a business card. You respond that the problem is really the client’s logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client’s business plan. And so forth.”
He calls this Problem Definition Escalation. Where a designer takes one problem and escalates it to a ‘higher’ plane of benefit and worth – one where it will have greater impact, and ultimately, make the designer feel like they’re doing their real job.
Designing in a browser, in your head, on paper, on a wall, on post-it notes. It doesn’t really matter. What matters is the work. Is it appropriate? Does it do the job well? Will you get paid for it? Does the client understand the benefits?
Really. Who cares how you get there? We’re all coming around to the idea that designing responsive web sites in Photoshop is inefficient and inaccurate (if things like web font rendering matter to you).
Let’s look at the arguments:
For those familiar with the tools, designing in Photoshop is just as efficient as designing in code.
I design using the tools of least resistance. Preferably a pencil, sometimes Photoshop, and a lot of HTML. Photoshop is my tool of choice for creating website designs.
Presenting static visuals to clients is different than using them as a tool yourself as a means to an end.
All of that is good news. Good for clients. Good for the work. Good for us.
A natural result of this is abstraction.
Design patterns are everywhere. The often-repeated chunks of content that we find ourselves designing and building time and time again. User’s get used to seeing them in certain ways, and over time, perhaps their performance is hindered by deviating from the norm. We see this all the time on e-commerce websites, or in new user registrations. Over time, we all collect these little bits of content, design and code. They build up, and eventually they need organising.
Why not group them all together, categorise them, and iterate on them over time? Throw in your boilerplate templates, too. Maybe group them together as a ‘starter kit’ with included navigation, indicative content – for different types of sites like ecommerce, blogs or magazine sites?
And… wait a second, you’ve got all you need to churn out site after site, product after product for clients now. Excellent. All we need to do is change the CSS, right? Maximise our profits.
No. It’s not right.
Conformity and efficiency have a price. And that price is design. That price is a feeling of humanity. Of something that’s been created from scratch. What I described is not a design process. It’s manufacturing. It’s a cupcake machine churning out identical cakes with different icing. But they all taste the same.
Documenting things that repeat is an important thing to do. I have my own pattern library that I’ve been adding to for years now – it’s an electronic scrapbook where I take snapshots of little content bits and bobs that I find interesting, and that keep on cropping up. It’ll never see the light of day. I’ll never use it on a project, because what I’m doing is building up a head full of this stuff so that when a problem presents itself, I will have a fuzzy recollection of something – maybe – that is similar. Instead of going straight to my big ‘ol database of coded examples, I’ll try to recreate this little pattern from memory – and that’s when something interesting happens.
Recreating something just slightly differently – from memory – means you end up with something new.
That’s why I wanted to be a designer, after all. To create new, beautiful things.
The Business of Responsive Design
Responsive design affects a lot more than just our website’s layout. From content, and how it’s created, to the structure of teams and organisations can all be affected by the processes responsive web design brings.
I’ve a confession to make. I’m an armchair mountaineer. I’m too much of a coward to actually put myself in the type of risk mountaineers do, but for the last decade or so, I’ve been reading as many mountaineering books as I could get my hands on. And I’d like to start by telling you a famous story of Alpine mountaineering.
This is the North Face of the Eiger in the Bernese Alps in Switzerland. The Eiger (meaning: Ogre) is a staggeringly difficult face to climb. Nearly two vertical miles high of ice-coated loose rock. It’s a treacherous place. It’s also the place I proposed to my wife in 2003. But that’s another story. The story I’m going to tell you starts in 1936.
In the winter of 1936, Andreas Hinterstoisser (pictured), Toni Kurtz, Willy Angerer and Edi Rainer set about tackling the face of the Eiger – then unclimbed. They’d established the rough route, and after a day had reached an impassable, sheer area of rock just underneath the Rote Flüh – a prominent feature on the face.
Let’s leave that story there for now and come back to it later.
Let’s talk about responsive design.
Responsive design has changed my work and, ultimately, how I do business. This talk is about how it’s done that. But before I do that, I’d like to tap about the definition of responsive design.
If you talk to some people, responsive design is just fluid grids and media queries. To other people, it’s that your website fits on a tablet or mobile phone and changes to adopt. To others, it’s the way to save money by consolidating teams. Responsive design – like AJAX, or Web 2.0 – has become a buzz-word to represent a change. A change in our industry. A change in the way people are consuming content. That’s the type of responsive design I’m going to talk about.
I’m going to talk about three specific areas of how it has challenged the way we work at Mark Boulton Design.
1. Structured content
It’s strange to think that there was a time on the web where content was a second-class citizen. As a student of editorial design, I’ve always found this odd. In the past, whenever I heard ‘content is king’, my response was generally ‘er, yes’.
Responsive design has challenged how we commission, create, edit and design for content. I’d like to talk a little bit about how this has affected two clients of ours. Firstly, our work with CERN.
Different content for different people, at different times, on different devices.
I’ve talked about CERN before at conferences, but not really in this amount of detail. When we started working with CERN a few years ago, the whole project was framed in one sentence by the head of the CERN web team…
We have a content problem.
And they did. They didn’t really know who their audiences were, how to talk to them, or what they wanted. Following months of research, it became clear the audience for the CERN site was comprised of students, scientists, the general public and CERN staff. Interestingly, all of those four large groups had a common need: updates. They wanted to know what was going on. But here is the problem: each group of people needs to hear the same update in different ways. Let’s take an imaginary use-case of an announcement for a new particle that’s been discovered.
For the general public, they are generally learning a lot about CERN from elsewhere. Not on the CERN site. So, they are coming to the site from another trigger – either another website, or the TV, or a magazine or newspaper – and their overall comprehension of the work done at CERN is minimal. The update needs to be worded to accommodate that. But that update also needs to appeal to scientists working in high energy physics and associated fields. They want the detail, in the language that suits them. Already, our one update is fragmented. Throw in students and educators, then our update is going to have to work very hard if it’s just one piece of content.
Therefore in the CERN redesign process, the editorial structure of updates needs to be fragmented and structured in such a way to accommodate different words for different audiences. A responsive design challenge that has nothing to do with how something looks, but how it is structured and how it works in the CMS.
This brings me onto my second point on structured content.
We’ve also been working with Al Jazeera for a few years on redesigning their digital platform. Throughout that process, in just that short space of time, we’ve seen the rise of responsive design and how it affects how content is created and viewed. One example of this is just the process of how news works.
We often think of a news story as a page. A useful, familiar construct. It has a headline, a stand first, some paragraphs and maybe an image or a map. But after studying how their editors work, it became clear that this is not what a news story is. News is always moving.
A story starts as a seed. Something that comes down the wire…
There has been an earthquake in Japan.
Nothing more. Not yet.
Then, over time, the story grows and, like a snowball rolling down a mountain slope, more content starts getting attracted to it – maybe a tweet, other articles, images, video, timelines, quotes etc.
Because a news story is not a page. A story is the link between bits of content. The question here is how do we – meaning editors and designers – curate and cajole this content to most effectively tell the story?
The answer does not lie only in design. The answer lies in how content is structured and categorised. Meta-data is the new Art Direction.
Responsive design has been perhaps most visible in its ongoing challenges to process. How we do what we do is coming under increasing pressure, and here are several ways in which I’ve noticed how.
I started out working in advertising. As a student, I was an intern for a couple of years at an agency in Manchester. Other than the work, one of the things that has become clear now I run my own design business.
When advertising agencies talk about work, they talk about it in terms of accounts, not projects. When you win work, you win an account – for a period of time. An account is commitment over a period of time.
We will work with you on all our projects for 12 months.
This means a client will invest in you, and the time it takes you to learn their business, familiarise yourself with the challenges and give you the space (and budget) to do great work.
Projects are not a commitment. Projects are relatively risk-free.
You will deliver this website for this much money in this time-frame.
Approaching work this way leaves little room for any ongoing commitment, from client or agency. It’s like a first (and only) date. And with that comes a distance.
Over the past couple of years, I’ve seen my peers move from agencies and studies move to products and client-side. In doing so, they are closer to the problems. With the space to move in an agile way without the constraints of any binding commercial relationship. This reminds me of a story from Kevin Spacey about his work on the House of Cards
Kevin Spacey recently gave a rousing talk at The Telegraph in which he talked about how TV commissioning works in the US. He went to all the networks in the US to pitch the show. They were all interested, but each one wanted to do a pilot. A pilot which, in 45 minutes, would establish the major plot-lines, introduce the characters, the love-triangle, the cliff hanger.
“It wasn’t through arrogance that we weren’t interested, but we wanted to tell a story that took a long time to tell. We were creating a sophisticated, multi-layered story with complex character that would reveal themselves over time and relationships that would need space to play out.”
The House of Cards was about the long game.
To me, many web projects can feel like a pilot. Relatively low risk, low on commitment to work together without the time and space for the problems to play out. Proximity to the problem – a hand forced by responsive web design’s challenges – comes from working closely, over a long period of time. An account, not a project. A season, not a pilot.
The project rope-a-dope
In 1974, Muhammad Ali and George Foreman fought in the ‘Rumble in the Jungle’ in Africa. Forman was the favourite having beaten Ali three years before. he was strong. Young. And a great boxer. He was sure to win.
Throughout the fight, Ali let himself get hit on the ropes. To give the impression he was tired, lose, and close to defeat. All the while, he was whispering in Foreman’s ear ‘You’ve got nothin”… ‘nothin”. Forman blew himself up trying to knock Ali out. In the dying moments of the fight, Ali knocked Forman out and won the fight. This technique was coined the ‘rope-a-dope’.
Just going back to my last point for a moment. One of the results from being closer to the problem is that you have more exposure to the mess of design. Making things is messy. And to some people – especially clients, who can expect nice shiny things handed to them – may not be expecting to be exposed to that.
Sometimes they will freak out. And it’s our job to sit back on the ropes and take it on the chin. But, instead of goading them, we should offer words of reassurance. We should shift our process to something that may feel more comfortable. You have to break a few eggs to make an omelette, after all.
Where is the design?
Getting in the browser sooner. Looking at content sooner. Iterate. All of these things have a knock-on to design and how it’s received by a client.
For a few years now, I’ve talked about the fidelity curve. A simple graph to explain to clients that over time, we increase the fidelity of a prototype and slowly layer on the visuals. This is so we can fail quickly on low-risk, low-fidelity work. Mostly this is good and works well, but recently, I had an interesting discussion with a client in which they asked where the design was.
It’s an interesting question, because in this process, the design is everywhere. And unless you take the client along every step of the way – knee deep in the mess of design, being closer to the problem – then how do you manage the expectation that, at some point, a client will expect a presentation, or a reveal’ of how the product will look.
3. The Trend
“I want a responsive…”
As I said, responsive design is a trend. Or, rather, an awakening. As such, a lot of organisations and businesses are behind the curve . But one thing many people aren’t asking (and, I know this because I ask) is ‘is it worth it?’ or ‘Do you really?’
In 2011, our first responsive site was a site for World Skills London. It was a fun project, geared around a single event in London in which 200,000 visitors would attend and watch the various activities in the competition. As part of this project, we designed a responsive map. A cool diagram with a responsive image map that would scale and allow users to get from A-Z in the event by using their phone. Cool.
Except, during the project retrospective, it became clear that, actually, only 25 people used it. It was not needed.
Back to Hinterstoisser
Let’s go back to the Eiger and Hinterstoisser and three other men trying to climb the North Face. If you recall, after a day or so, they had arrived at a seemingly impassable face of rock under the Rote Flüh. After much deliberation about trying to re-route, Hinterstoisser decided to have a go at traversing the feature. And he succeeded, and with that, opened the gateway to the rest of the face and rest of their climb.
Today, the same traverse is still used across the same slab of rock.
Last week, I did a survey on Twitter about the business of responsive design. After 500 or so responses, it’s clear that everyone is finding everything hard right now. The change is so big, and so rapid, that we’re struggling to keep our heads above water. And this especially goes for those working in-house or clients.
Breaking new ground is always difficult.
But, just like Hinterstoisser, take heart in knowing that what we’re working on right now is a legacy for designers and developers in the months and years ahead.
There is a storm coming.
For those of you reading this who have experienced a severe weather event know all too well the sequence of events leading up to it. First, there is a warning – either through the media, verbally, or from the old woman in town who can feel it in her bones. Then, there is the sense of it coming, and that can take minutes, hours or days. Either way, there is a feeling of calm before the havoc. Battening down the hatches, preparing your self, property, business and family. Preparation is important in surviving something potentially catastrophic.
I read a post today from the Karen Mcgrane called Responsive Design Won’t Fix your Content Problem. It was nicely validating for me reading what mirrored so many of Mark Boulton Design’s clients, especially over the last eighteen months. The post describes the difficulty organisations are with adapting to their digital content being published across a variety of channels. Reconciling that against existing business and technology structures is hard for big organisations but, in my experience, that’s what’s been happening for the past years.
Responsive design is our storm. Acknowledging the way the web really is, and reconciling it against the plethora of new devices and reading behaviours has been a seismic shift in the creation and reading of digital content. Organisations have been spending the last couple of years coming to terms with it.
Quoting Karen’s article from a recent project she was working on:
Our executives assume that since they made the decision to go responsive, every other decision would just be tactical details. In fact, implementing responsive web design raises issues that strike right at the heart of our business and the way we work. We need to fix our review and approval processes, our content management system, our asset management system, our design standards and governance. We need to clean up our outdated, useless content. But it’s hard to get people to step up to solve these bigger problems, because they don’t think they’re part of “responsive design.”
This exactly mirrors my experience.
What starts out as desire to change for the better, to make a web product responsive, is the start of problem escalation. Before you know it, organisations are talking about needing structured content, but to do that they need a new CMS, but to do that, they have to procure a new CMS and migrate content. Now, that’s not all bad. Organisations have been doing this. Preparing solid foundations on which to create digital experiences for wherever the user may be.
The storm. The critical mass of creating content for an increasingly broad digital space is just around the corner. Are you prepared?
I get the content in Word, copy into the various boxes in the CMS and then see how it looks. Normally I spot a few typos, or it doesn’t appear where I want it to, then I have to go back and find the article again – which isn’t so bad, it’s normally at the top. The real pain is when I have to add another link to that list over there. (whispers) Normally I ask James (a developer) to do that for me, though as I can’t do it.
This was a conversation I had with a person recently about how they use their CMS. A real-life content person. I say content person, not ‘creator’ as you may have noticed she doesn’t write the content. She just ‘gets it’. She’s a piece in the publishing workflow. A cog in a machine. And our tools are failing her and are only going to get worse.
In that workflow, there is a bit that’s a clear trend amongst the people I’ve spoken to about this.
then see how it looks.
And that’s the thing, right there.
Since we’ve been using computers to make websites we’ve tried to make them like print. Of course, early on, that was fair enough. It was familiar. We knew the rules and tried to make the web like it. Even now, with the realisation that the web has changed – or rather, we’re being honest to the way the web is. It never really changed, we just tried to make it something it wasn’t – we’re still enforcing a print-like mental model on it. Not necessarily us designers and developers, though. This is coming from people who write and manage content. Just like printing out an email before they send it, they will want to preview a website to see how it looks.
The problem is this: The question content people ask when finishing adding content to a CMS is ‘how does this look?’. And this is not a question a CMS can answer any more – even with a preview. How we use the web today has meant that the answer to that questions is, ‘in what?’.
Let me first off define what I see WYSIWYG. WYSIWYG is not a limited toolbar for adding semantic value to your document. The kind of toolbar you find on Medium, or on Basecamp. As you can see they are similar. They are used for applying semantics to document structure; giving words emphasis, making unordered lists, or numbered lists, making words headlines. However, they’re not there for the user to get creative. They do not change the colour of a word.
When I think WYSIWYG, I think of the Word toolbar. This type of WYSIWYG is for adding tables, images, forms, type and colour. It’s a toolkit to create pages of content. Just like desktop publishing. And that’s the dangerous thing. Content creators are used to having these tools at their disposal so they can craft their document. Why? Because writing isn’t done in a CMS, it’s done elsewhere.
Times -are changing- have changed
It’s been a turbulent few years for web designers and developers. We’ve had to relearn what we’ve created and finally acknowledge – through the timeliness of Responsive Design – that the web is a fluid and chaotic place, and we should be embracing it and not making it like print. We’ve learnt to deal with the loss of control. The problem is, though, our content people are still thinking of pages. They’re still thinking of previewing. Of designing for the desktop. They’re writing in Word and fine with it.
So, that’s the challenge. How can we help people – just as we have – relearn how the web is now?
Just like when people have a content management problem, a lot of people are turning to technology for the answers. And just like content management problems, my experience is software can’t fix it. Because it’s a people problem, not a software problem.
The three places of content management
There are three spaces * for content people – not creators, because not all content people create loads of content. Some just manage it – push it from here to there. Those places are:
- A space for writing. For writing and structuring.
- A space for management. For adding meta data, workflow, configuration and managing roles and people.
- The website space. Basically your website. A place where you begin the access user journey. Or preview your content. Generally the starting points for lots of little administration tasks.
- There are other spaces, too. The developer space, where the site is administered and created, managed and evolved. Sometimes this is through an administration interface, but not always. Sometimes it’s just through an API.
The problem I see is that the CMS tries to deal with all three spaces equally well. And as such, generally fails to deliver an optimal experience because it’s trying to do too much. What if your content management system was actually three distinct applications designed to work together? Just a thought.
But, back to WYSIWYG.
The issue with WYSIWYG for me is that by using them the content person is considering the content as what they see. But content is more than that. Especially if it has meta data, and is split up and compiled from here and there. A ‘page’ maybe a dynamic template pulling in content from a dozen places. How do you change meta data there?
If we consider the majority use-cases of correcting typos, restructuring slightly, or small on the fly editing, then the smaller toolbars for adding semantic value are useful. But for most use cases, a WYSIWYG is not useful for content people. It’s just familiar.
Inline-access, not inline-editing
One of the other pain points of a complex dynamic website, where ‘pages’ are created with bits of content from all over the place is ‘where the hell do I go to find that bit of content to edit it?’. That is a painful moment in a content person’s daily life. Normally, after watching them, they go off deep into search, or ask someone else who knows better. Accessing these smaller nuggets of logic-based content is problematic. This is why inline-editing and WYSIWYG is coming to the fore – addressing the use case in the live environment.
Why is this a problem?
As I said before, it’s hiding the truth. That being, the content is more than you can see. Instead of inline editing of the content, why not just make the start of that journey a little easier? Why not provide a way of quickly getting to exactly that bit of content with a link? There we will see all of the stuff that is the content but not the words: the display logic, taxonomies, meta data etc. But if we want to change a type, we can do that with our little toolbar.
Not one tool, but many. Not one way, but many.
Structured content is the right way to go. It makes our content portable and malleable. In fact, it makes it much more useful. Slapping a WYSIWYG on top of a form field is not the way to go. That’s not structured. Live WYSIWYG is not the way to go for large-scale websites because it reinforces that content is just what you see. When, in fact, a piece of content could have a whole bunch of other headlines and summaries that would only be displayed in certain contexts, along with meta data and rules. We need access to ALL THE CONTENT and provide simple, little tools to let people make typo changes and apply semantic structure and the like once they’re looking at the content in a staging environment.
‘How does this look?’
should change to:
‘How does this read?’
Device agnostic. Screen size independent and devoid of design. Let’s help content people focus on what the words and pictures are, rather than what the words and pictures look like.Next