Mark Boulton Design and Monotype
Today is a big day for me. One of the biggest of days. I’m delighted to announce that Mark Boulton Design has been acquired by Monotype. You can read the full press release here, but before you do, I’d like to take you back a few years…
Eight years ago, Emma and I were driving down from visiting my parents near Manchester. It was a sunny, blustery day in June 2006.
During this time, we both worked for the BBC – Emma in Audience Research, and me in, what was then called, New Media. As a lot of designers do, I was working some freelance work on the side. A couple of weeks prior to that car trip, however, I’d been offered a freelance project that was too good to turn down, but it was big. Bigger than a few hours a night when I got home from the day job. On that car trip, we decided that one of those jobs had to go: my freelance work, or the job at the BBC. I chose the latter, and the very next day, handed in my resignation at the BBC. It was time to head out alone.
Eight years later and it’s time for another change.
Running a design studio has been a fabulously rewarding experience. I’ve worked with some talented people on some great projects for wonderful clients. But, all through this time, there has been a niggling problem, one that I’ve talked about at a couple of design conferences this year. When we’re hired by a company to work on their project, just by the nature of the engagement, we’re not as close to the problem as we need to be. We’re not in-house. We’re not experiencing them day by day. And, quite often, we’re not in the position to help fix the problems in the organisation as we uncover them. Having the opportunity to be closer to the problem really excites me, and that's why this change is such an important decision for me at this time in my career.
We know the web is going through an interesting time right now. This is not so much being felt by us in the industry, but by the myriad of companies who publish content that are struggling to cope with the changes and demands their readership and customers put on their services. Being close to that problem excites me, and that’s just what this opportunity with Monotype represents. We’re going to be working with some of smartest people I’ve met on a broad range of tools and services that cross the boundaries of two fields of design I hold dear: web design and typography. What could be better than that?
Five Simple Steps will also be closing its doors. For five years, Emma and I have been accidental publishers and, together with the team here, and some talented authors, have produced many practical and influential books. Those books aren’t going away, though. As of today, Five Simple Steps is ceasing to trade, but is giving those books back to the authors to distribute as they see fit. We’re also freely distributing our ePub template and process, to help people self-publish just like I did five years ago. And, today, I'm also giving away my book, Designing for the Web. You can freely download it in PDF, ePub and Kindle (.mobi) formats.
Our responsive grid application, Gridset, is currently being considered as how it can sit alongside Monotype’s Typecast product. Since both services launched, I’ve lost count of the amount of people who use the two together and asked us to integrate somehow.
The last eight years has been quite a ride, but as I said, it’s time for a change. And, for me, a great change at that. The team here at Mark Boulton Design will still be working with me. We’ll still be contributing to the community the best way we can. I’ll still be harping on about something or other on Twitter.
Today marks the closing of one chapter and the beginning of another. It's the part in any story that I love the most, because, to my mind, it's the best bit.
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.
The First Website
Twenty years ago today, CERN published a statement that made the World Wide Web freely available. To mark this anniversary, CERN – together with Mark Boulton Design – are starting a project to restore the first website and the associated assets of the World Wide Web project.
I first started using the internet in about 1988. I had a mate whose dad worked for IBM so he had an early PC connected – via the phone line – to a rather sophisticated little modem. The internet wasn't the web back then, it was a mix of bulletin boards, rudimentary email clients and IRC. You may think that it was a primitive, but in reality, the prospect of near live discussions and collaborations with people all over the world was pretty incredible. As friends do, we lost touch, and my connection to the internet was lost with it. I did other things: failed my A-levels, learnt martial arts, chased girls, learnt the guitar and went to art college. My connection with internet picked up again in 1994. And, oh boy, was it a different place entirely. In just a few short years, the web went from idea to proposal to freely available. And the world was changed forever.
As web designers and developers, we spend a lot of time trying to explain the difference on the web. "It's not TV, it's certainly not print" (oh, no, it's definitely not that). The web is its own thing. But unlike other media – ones which have physical artefacts, which get left behind to rot, to be found and stuck on a shelf in a museum – the web doesn't have that. Pixels don't decay, they just disappear. Forever.
Preserving our digital heritage is as important as preserving our physical heritage. There are a few people and organisations in the world who get this: The Long Now Foundation and Archive.org, to name a couple, but I'm not sure that's enough. The need to preserve must come from our desire to learn from the past. I have two young children and I want them to experience the early web and understand how it came to be. To understand that the early web wasn't that rudimentary but incredibly advanced in many ways. Currently, it's impossible to do that. And, together with CERN, that's what we're hoping to provide.
From today, we've started work on the project objectives. The talented web team at CERN have already reinstated the first URL and uploaded a version of the website from about 1992. The restoration has begun.
Eighteen months ago, I blogged that we'd started working with CERN on redesigning their site. A dream project for me. And one that is in its final chapters as the site went live last week. But, as with all great stories, as one chapter draws to a close, another starts.
ATLAS is a collaboration of three thousand physicists, engineers, computer scientists and support staff, in forty countries, in one hundred and seventy institutions from around the world. One big scientific melting pot, who have built one of the most complex machines known to man which is connected to the Large Hadron Collider. They're one of two experiments to independently observe a particle that behaves consistently with the Higgs Boson. In other words, whilst they share similarities with CERN, they're actually quite different.
I'm thrilled to be working with such a progressive, interesting group of some of the smartest people on the planet, working on some of the most historically important work that humans have ever done.