Category: process

Write it down

This is a post in defence of process. Yes, I know what you're thinking: 'urgh, process is a thing put in place to make up for mediocre teams'; or 'prioritise discussion over documentation'; or 'I get enough red tape in other parts of my life'. You know the response. You've probably said it as many times as I have.

Conversations are cheap

I am the first person in the room to defend the delights of working in a lightweight, agile (lowercase 'a') way. You make stuff faster, generally better, and you build team or product momentum. The real benefits I see are people benefits: a closer-knit team; shared understanding; less things on fire. The wholesale shift to this way of working – outside of slow-rotting corporations, that is – has many benefits. But the cultural distain of the 'P word' is not one them. Process has a place.

The main issue I see time and time again is that conversations are low effort. Not only that, but certain ways of working prioritise them over slower, reflective, considered decision-making. I use one method that works to counter-act this.

'Write it down'

Whenever someone asks me to do something that I think seems ill-conceived in some way, I ask them to write it down. That's it.
Because writing is high effort. Making sentences is the easy bit, it's the thinking I want them to do. By considering their request it slows them down. Maybe 30% of the time or something, they come back and say 'oh, that thing I asked you to do, I've had a think and it's fine, we don't need to do it'.

This little method isn't about doing less. Well, actually it is. It's about doing less important things instead of important things. It's not about being obstructive. I certainly don't ask someone 'why?' five times (which is a shortcut to being called a smart-arse in my experience). This is about a light-touch way of asking someone to slow down.

Time for reflection

In the UK, medical doctors are required to 'reflect on an aspect of their work' every month. This is time that is monitored as part of their self-development and self-improvement. Doctors are amongst the busiest, pressured people I know and if this wasn't mandated by the British Medical Council, then I'm pretty sure it just wouldn't happen. They have to make time. And we should, too.

We're all running at 100mph. Making things faster and faster. In my own experience, time reflecting on work tends towards sitting in front of screen – like I am now – thinking about the next thing on my todo list, or beating myself up about the latest ball I've dropped. How does that Elbow song go? 'Cramming commitments like cats in a sack'

These days, I welcome being asked to 'write it down'. It gives me permission to take a breath. To pause and reflect on what I'm asking. I'm convinced my heart rate drops a little. You see, in some environments this would be called 'process', or 'red tape'. 'Being asked to write something down is a blocker to my flow'. Those kinds of responses miss the mark. When being asked to 'write something down' it's really shorthand for 'take some time and think about what you're asking'.

Next time someone asks you to do something, try it. I bet 3 times out of 10, they say 'oh it doesn't matter'. You'll have that time back. They'll be a little wiser and have a lower heart rate.

No, aside from the unbelievably hard work of the team, the superb conditions of the track and the humidity of the building, there was one person who was credited as the brains behind the performance; Sir Dave Brailsford. Sir Dave is also credited as instilling a culture of measurement, data, and, ultimately, well-being into the team. A key component of this was a philosophy of ‘Marginal Gains’.

“The whole principle came from the idea that if you broke down everything you could think of that goes into riding a bike, and then improve it by 1%, you get a significant increase when you put them all together.”

This is also something he applied to his job as manager of the Sky cycling team.

When Brailsford formed the commercial cycling team he had one goal: to win the Tour de France. Clean. Within five years. He did it in two. And then again. And again.

The challenge he had was this: cycling has long been a sport which uses performance enhancing drugs. In order to compete against teams using these drugs, Team Sky – and any other clean team – had to bridge a gap of about 16-19%, depending on which source you read. Regardless, that is an enormous distance in performance in any professional sport. And they did it through the aggregation on marginal gains. Looking at every aspect of an athlete’s life – their diet, weight, sleeping patterns, physiology, well-being, the pillow they use at night. Even how they wash their hands – they were able to bridge that gulf.

I’ve been a fan of professional cycling for a long time. Even before I owned a road bike and rode myself. But recently, I’ve become interested in how coaching has created this performance. How Team Sky’s, and before it Team GB, management team has created a culture for riders to succeed by the continued improvement of tiny, tiny little things. But, I’m also interested in the opposite.

Marginal Degredation

Well, you think about it, it kind of makes sense. We’re all made from the same elements. The same star dust. Just arranged in different ways. But, we’re very, very different to bananas.

Let’s talk about design for a second.

What happens if 1.6% of your brand is left unchecked? Or 1.6% of your user experience of your product. Doesn’t seem a lot, does it? How about 32% Again, for some, this is within acceptable margins. Especially if your brand or product is growing quickly, acquiring companies here, there and everywhere.

But, 32% is the difference between a human and a goldfish. Even just 1.6% – probably acceptable margins for almost every brand or product out there – is the difference between a gorilla and a human. Think about that for a second.

Your brand or design is supposed to be a human, but people perceive it as a gorilla. Or a banana.

Applying Marginal Gains to brand or product design

What can you do about this? How do you stop a distributed organisation degrading itself? Well, entropy happens and this is always the struggle with any branding or design work on an ongoing basis. Like any garden, it needs tending.

But, here are some of the things I do to stop the rot:

Keep talking. To everyone. My job is to help create the environment in which marginal degradation doesn’t happen. I do this by talking to everyone across an organisation - so they feel involved, empowered, excited, free to be creative. I did this before working at Monotype too, but with other companies.

‘Show the mess’. Design work is not that scary. Expose people who are not designers to the design process. By doing this you get better buy-in, involvement, and culture.

Maintain a holistic view. It’s so easy to get dragged into the weeds. But sometimes, the weeds is exactly where some delightful little design problem exists. Who knows, maybe I end up doing some actual design work. You know, keeping my hand in. Well, no. Keep above the weeds.

Draw straight lines between design and KPIs. This is a big one. What design and brand do should be measurable. Not by some data Goloms like the Net Promotor Score, but by committing to understanding your customer’s behaviour. You can only make incremental tiny improvements on a foundation of understanding. Measuring against real-world indicators puts design in black and white numbers all levels of an organisation can understand.

Just be consistent. Even if you know it’s not ideal. It’s not something you’d do. Maybe you inherited a design system, or jumped on board half way through it’s creation. Maybe you just don’t like it anymore. That’s ok, you can take your time to get it changed, but in the meantime, be purposefully consistent.

If you do deviate, make sure you do it with a plan. If you plan on being a gorilla, and deviating that 1.6%, then do so with purpose, not just because you are lazy.

Plugging away at this tiny stuff is relentless. It’s the tiny details that, when viewed together, look big and insurmountable. But, taking one tiny improvement at a time, in the bigger scheme of things, you may be surprised at how quickly your product or brand starts perform. Not only that, but now you have a way to measure it.

A Design SDK

A software SDK is a set of tools that allows the creation of applications for certain software, or video games, or a hardware platform. A hit could be as simple as a bunch of APIs or software that talks to embedded or proprietary systems. An SDK is a collection of tools to make something with. It’s a leg-up for development. And they’re needed for design, too.

Guide me, don’t tell me

When working with identity guidelines, pattern libraries, or styleguides, the biggest pushback I hear from designers is ‘I don’t want to be this specific. Point me in the right direction, but don’t be prescriptive’. The chances of a pattern library or styleguide answering every design problem that comes along is slim, but providing an overall understanding of a system is probably the best position you can put a designer in in order for them to do good work. That, and providing them with the right tools.

Giving someone a design SDK may be better than asking people to look for, navigate and understand an entire website dedicated to your design language.

For example, let’s say you work for a large bank in their in-house design team. Your design language is years old and grown organically to become a place of internal collaboration for stakeholders and silos – not really the place for external suppliers. One day, you need to get a very small web project designed and your team is maxed out so you outsource it to a freelancer. Now you’re faced with a problem.

Your design language documentation and collaboration site is housed internally, behind the company firewall, and you can’t give her access. You try to collect some material together for her, but it takes all morning before you even have an idea of what might be needed. And then you can’t find the logo in the right format. All you really need to do is send her what is needed and nothing more.

All of this takes too much time. And a styleguide doesn’t solve the problem. A design SDK is what you need.

A style guide is about providing the right help for every use case all in one place. An SDK is about providing the right help for a specific environment. In software development, APIs may have middleware wrappers like a PHP and Ruby. But regardless of the wrappers, the endpoint is always the same: the software at the end of the API. In the same way, a Design SDK should provide an end-point — a design language — typically via different methods such as HTML and CSS, or Sketch files, or Photoshop files, or text documents, or InDesign swatches.

The key to this is to be where the designer is. Learn where your designers and design partners do their work and provide tools that help get your design language adopted in those tools.

The problem with style guides

Style guides can be great for documenting a design system and providing a way for design to be consistent across multiple projects, products and people. But they can also be a shackle for creativity. A firehose of difficult to navigate content that compromises clarity for brevity. The key thing with style guides is they rely on you going hunting for what you need. They are everything for everybody. They are pull rather than push.

A design SDK I’m talking about is push rather than pull. It’s given to you, and it contains just what you need and nothing more.

What would be in a design SDK?

The key here is to provide just enough for someone to get going with their work. For some projects, this may be all of the following, but for others, it could just be a couple.

Moodboards and inspiration

HTML boilerplate

CSS or Sass snippets

Template assets

Suitable example images

Icons in various formats

Licensed typefaces or links to the correct typefaces

Branding identity guidelines

It would be ideal for me if an SDK could be created on the fly for different people based on project needs. So, for example, for freelancer ‘A’, I don’t want to send them HTML or CSS as I know they’re not building anything, so I just send them mood boards and inspiration, image assets and branding guidelines. For freelancer ‘b’, a front-end developer, I send boilerplate, CSS, template assets and icons. I mix and match and provide the design SDK, rather than send along a URL and expect them to know what they need and how to use them.

‘Isn’t this just for big, in-house teams and projects?’

No, I don’t think it is. There were plenty of times when I ran my design agency that we could use a design SDK as a deliverable for a client. Because, after you have finished working with them, chances are they will need other people to take forward your design in one way or another. And maybe the client isn’t the best person to determine what is needed to do that. A design SDK would be a great deliverable to ensure design integrity is maintained after you move onto other projects.

I’ve had a lot of comments from people since then – either agreeing or disagreeing (y’know, the web) but over the past six months or so I’m coming around to the idea that Visual Design might actually be a thing. It’s just incredibly rare and is dependent on a number of rarely addressed factors.

Following the problem

Michael Bierut explains in his piece ‘You’re so Intelligent’ that graphic design has long suffered from what he calls ‘Problem Definition Escalation’:

Like many designers, for years I used a tried-and-true tactic to hoist my way up the respect ladder, a technique I will here call Problem Definition Escalation. If you've listened carefully to the lyrics to "Gee, Officer Krupke" in West Side Story you already know how this works. 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. One or two steps later, you can claim whole industries and vast historical forces as your purview. The problem isn't making something look pretty, you fool, it's world hunger!

This behaviour is everywhere I’ve looked and worked for my whole career. From designers to content strategists, product managers to researchers. Almost always though, unlike Mr Bierut, I don’t think this is a need to elevate ones self through any sort of professional low esteem. I like to look at this a different way.

This is a result of people trying to find the problem. It just so happens the problem is rarely the logo.

From board room to your users and everywhere in between

If you think of Visual Design as being on top of a stack of other activities and functions, it might look something like this:

Visual Design

Stuff

Customer needs / Value proposition

Board of Directors / Leadership

Organisation environment / culture

‘Stuff’ of course is a big, fat catch-all for all other tactical product design and development.

Customer needs have to be balanced with the product value proposition and opportunity. This is built up on a capable and supportive leadership team. But the bottom layer is probably the most important of them all. The environment.

The environment has to be right for all of the other things to happen. Unfortunately, ‘environment’ or company culture is hard to define and replicate. But how we use processes – such as agile, or defining market opportunities, through to how you refer to customers and evaluate designs - is probably the most important of them.

The Problem Story

It wasn’t until I saw Leisa Reichelt talk through how the UK Government Digital Service team work – from the Creative Director through to the developers and researchers – that I saw a corporate culture and structure where Visual Design could be a thing. Why? Because the problems had been defined, researched, worked through, solved, iterated upon in the layers below. Doing this means that probing the problem results in answers quite quickly. And the more the problem is probed, instead of it all unravelling, it builds into a cohesive narrative. The problem has a story that can be easily tracked back.

Visual Design might be a thing

If the problem has a story that can be traced back, the environment is supportive, and answers are available, then I can certainly see instances where designers learn not to go hunting for the problem. And, thinking about it, I wonder if this behaviour is more probable in in-house work, rather than agencies? Why? Because agency designers are used to clients coming to them with bigger problems than they initially present. This is how agencies generally get more work from larger clients – we follow the problem and, together, make projects to address them.

But, anyway, back to visual design.

If the problems are solved. If the designer is used to not going hunting for the real brief. Then, and only then, I think visual design could be a thing. When a designer has the right information, is working on the right graphical problem where she can focus on, what Michael Bierut describes as:

our miraculous fluency with beauty, our ability to manipulate form in a way that can touch people's hearts… the gifts that matter, and the paths through which we create things that truly endure.

Yeah. Maybe that’s when visual design might well be a thing.

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.

Collaborative Moodboards

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.

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.

Brand workshop

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.

Bonus!

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.

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.

My Do Lecture

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 Lull

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?