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.
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.
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.
Being nominated in these awards is like a nice pat on the back for all the hard work my team do. From trying to help communicate one of human-kinds most important discoveries, to building a tool to help us make websites a little bit easier, to making books for our community. It makes the nomination for Agency of the year, for the second time, that little bit more special.
2013 brought with it more work in and amongst editorial processes for Mark Boulton Design. And with it, some challenges designing systems that can react to the speed of the story.
News happens quickly and therefore needs to be captured quickly. This is why news organisations have latched onto the immediacy of publishing platforms like Twitter, blogs, Instagram and the like. The flow from story to pixel is dramatically reduced compared to incombant editorial processes. Sure, journalists will cry of the death of proper journalism; story-telling will suffer at the hands of snippets of information drip-fed to hungry millenials. We’ve all heard the horror stories. The truth is that these services allow for a story to happen in near real-time, and as such, the emphasis on an editor’s work is no longer writing, but on guiding, the story. Creating connections between content to build a bigger picture in the reader’s mind, but, certainly, in a near-live environment, many news organisations are not authoring this content; it’s being created elsewhere by other people.
I’ve had a long-standing professional interest in content management systems. I’ve designed a few along the way, and almost without exception, the project has started as a software design project, and ended up a process design problem. The problems lie with people, not with user interfaces or technology.
So much has changed in the ‘electronic publishing’ landscape in the last year. For every month of 2013 there was a hot new writing application, hip new publishing platform or collaboration silver bullet for writers, newsrooms and media organisation to run through the mill. Tools and applications for content publishing had matured in such a short period of time, individually they lacked the cross workflow power to be of complete use to a newsroom like The Guardian’s, but collectively it was starting to look a lot more interesting.
He goes on to say:
The software requirements for a modern, paper producing newsroom, are vast. The needs of the newsroom are increasingly difficult to define due to the nuances in production processes across desks, publications and offices, a moving target that is getting faster by the day.
In my experience, the faster and more important a story was, the less likely it was to follow established processes – especially where convoluted and difficulty to use software was concerned. It quickly devolved into Post-it Notes, hushed whispers and hurried editing. News journalists are human, and sometimes the speed of the story is just too fast for software. It gets in the way.
Given the change in how this type of content is created, curated, edited, processed and published, more and more organisations are finding they need new tools. New content management systems to help solve their publishing problems. My fear is, they’re looking in the wrong place.
Last year, I spoke at Handheld conference about how content is created over time. How a story moves from being a snowflake to a snowball; gathering pace, other content, debris. Before an editor knows it, the story is no longer a page, but a bunch of different things: links, images, words, video, other articles, tweets, blog posts. The list goes on. But they all share two things in common: the topic of the story, and the link between them. This is where I feel we need to focus our attention.
The hyperlink is at the very core of what the web is: an interconnected hyperlinked bunch of resources. The hyperlink is everything to the web, yet it is the thing we take the least care of. URLs die. Links rot. This isn’t a post about digital preservation, or a rant about how we should be taking care of these links for future generations, but that we should be taking care of them now!. As I hope I’ve demonstrated, the link between content is going to become increasingly important as we create more fragmented and modular content for display in multiple contexts. If we don’t look after these links, the story will be lost. Because the story isn’t a page anymore. The story is the link.
Modern content management systems should be focussed on exposing links between content. Making it easy for editors and journalists to make connections between things and not just when a story is created; stories live over many days, weeks, months or years. Modern content management systems should allow for constant editorial iteration and creation by showing the links between things.
It’s interesting to me to see this happen in a parallel industry. Just as designers and developers are struggling to adapt to the increasingly rapid changing web, writers and journalists are, too. Creating news content for the web is no longer about writing a page and hitting publish. It requires a fastidious approach to content curation over a longer period of time. It means being where your readers are; Twitter, Facebook, the TV. It requires pulling together all the various fragments of a story into a cohesive narrative. Now, does that sound like your CMS is designed to help? No. I thought not.
I was going to do a usual year-end wrap up for this blog post as I have done in previous years. But, as it’s the start of the new year already, I thought set my stall out for the coming year. What do I want to do, rather than what have a just done.
A couple of days ago, I was reminded of a video I watched a while ago about Free Enterprise via my friend Andy Rutledge.
“Don’t Eat Your Dog: The Surprising Moral Case for Free Enterprise. Based on his best-selling book “The Road to Freedom,” AEI President Arthur C. Brooks explains how we can win the fight for free enterprise by articulating what’s written on our hearts.”
I’m always interested in how other country’s politics, viewpoints and economics work, and this was no exception. Rather than to bat down things like capitalism, I’m making a concerted effort to understand the nuance in such things.
As someone who runs a design studio, a publishing company and a web-based design tool, you could count me in the group of people who work hard for what I get. And I’m rewarded for that. I don’t expect a free ride. I don’t expect anything beyond the realms of what is offered in the country I live in (such as state health care and education etc. In fact, I pay for that through my taxes – the NHS is not free). But before I disappear into a politics hole, I want to bring this back to design.
Running a design company, we charge clients for the work we do and for the customers who use our products and buy our books. In doing so, we create jobs, and more tax revenue for the government. But one thing I don’t agree with from the video above is that what i’m doing is a purely selfish exercise. I’m not just doing business to pay the bills, design great products for clients, and give people work to do. To me, there is more to making things than just making things.
I believe my job is not only about doing work for clients but that I have a social responsibility to make the world a better place through the work I do. Design is a powerful tool to affect social change. However small.
Let me give you an example.
You’re out for a walk at lunchtime. You come at a road crossing and there is a family by your side waiting to cross the road. The crossing indicator is counting down the seconds, but you spot a small gap in the traffic for you to cross. You just skip across the road, running in between cars and carry on. The family is left waiting for a safe gap in the traffic.
Think that what you did was fine? It was safe for you to cross. No problem.
Do you think that you should’ve waited next to the family to build upon the good example the parents were trying to show to their small children that they should wait for a safe gap in the traffic to cross?
It’s a small but important thing. And this is social responsibility. A responsibility to help the community around you, and not through just helping yourself. Next time you take on a design project, just stop for a second and think:
“beyond getting paid for this, and making my client’s business better, what is the benefit in doing this work? What is the social good?”
In addition to the work itself, ask them if you could blog about the process, or speak about the work at a conference. If it’s something you really believe in, could you offer do it pro-bono, or heavily discounted? Could you open source the code produced? How about aspects of the design – such as icons? Could you have one of their team members sit with your team for the whole project to soak up your skills? How could you benefit the web design and development community and still get paid well?
We’re in an incredibly fortunate position as designers to create change in the world. Many people can’t. Or simply won’t. Through our products, our work, and how we talk about it, we can have a much greater benefit to society that just lining our pockets.
This is exactly what I plan on doing in 2014. Happy New Year!
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.
“Another article by @markboulton which gives me a glimpse into how broken the world looks through his eyes” – Emma Boulton
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)
I’ve written about being at the Do Lectures before; it’s a special place, an intimidatingly smart audience, and generally freezing. This video doesn’t do justice to how cold I was there up on the stage. Should’ve worn my coat.
The democracy of the Vale of Glamorgan planning process is absent and favours wealthy developers over citizens.
My house is situated between a narrow country road leading into an old village and farmer’s fields. In April this year, we were sent a letter by the Vale of Glamorgan planning department that a housing development of 115 houses was planned and we have just a few weeks to register our objections.
Now, it’s understandable we’d object; we live next to the proposed site. But, there are some issues that have some serious cause for concern:
A public right of way crosses the site and over an unmanned railway crossing of a line soon to be electrified.
A pond is proposed to capture the water from the often-waterlogged field. The town has a history of flooding and this field acts like a large sponge safeguarding this part of the town.
The roads leading to and from the development are designed for sheep and horse carts. Fifty percent of them are unpaved, single-carriage and pose a risk to pedestrians.
You can read more about this application, if you like, on our website and the planning department website. But, this journal post is not just about documenting the history and problems of the site (that could last a while). This is a journal post about the sickeningly undemocratic process that the Vale of Glamorgan council has undertaken, and I’m sure, it is somewhat similar throughout the country.
As a citizen of the England and Wales (Scotland and Northern Ireland have different planning laws) I am not entitled to appeal against a planning application directly. However, a developer can appeal.
The Vale of Glamorgan undertook no independent review of reports commissioned and presented, with questionable findings, might I add, by the developer.
The Vale of Glamorgan are recommending the development despite Network Railobjecting on the grounds of safety with the un-manned right of way over the railway line.
The vale of Glamorgan undertook no independent risk assessment of either the open pond or unguarded railway crossing. Both of which are a grave concern for me having two small children.
The Vale of Glamorgan undertook no independent review of the flood risk assessments despite the developer’s reports showing multiple failed percolation tests.
I could go on about the deviations from what I’d view as an independent and democratic process. There have been many, but these pose the greatest dangers in my view.
As a father of two small children, I worry about them. My children are beautifully curious. Wonderfully full of energy. But, despite my best efforts, woefully oblivious to the danger they put themselves in. Just like every other child out there. The Vale of Glamorgan planners, and planning committee – who we elect into those positions, let’s not forget that – has a social responsibility for the well-being of the citizens of this country. Instead, throughout this process, I saw the opposite.
I saw an over-worked, under-resourced council making bad decisions.
I saw an undemocratic process that favoured negotiation with the developers over hearing the concerns of local residents.
I saw a council under pressure to meet housing quoters by paving over the green fields rather than the more difficult option of brown field sites.
And I’ve had enough of it.
Many people locally have been saying that the building of this development will result in more flooding in the village. It will result in more congestion on roads designed for horse carts and sheep. With the dangers of the railway line and open pond, it may result in the injury or death of one of the new residents. Is that when the planners would sit up and listen? Maybe verify the developers reports with independent review?
I know we need more, and affordable, houses in this country. But new developments need proper, independent scrutiny from experts. And this proposal has not had that.
The proposed development goes before the planning committee on Thursday 19th December. It is being recommended by the overworked planning officer – despite the points above. A copy of this journal post is being forwarded to the local councillors; the members of the Vale of Glamorgan planning committee; the Vale of Glamorgan planning department; my local Welsh Assembly Member and Member of Parliament, in addition to the BBC and local newspapers.
Just as local government has a duty to behave in a democratic way, I have a duty to act as a citizen of the UK and to stand up and say when something is not right.
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.