<![CDATA[Mark Boulton]]> / markboulton.co.uk Mon, 23 Apr 2018 00:00:00 +0000 en-us mark@markboulton.co.uk Copyright 2018 3600 <![CDATA[The Fast and Slow of Design]]> https://markboulton.co.uk/journal/the-fast-and-slow-of-design https://markboulton.co.uk/journal/the-fast-and-slow-of-design post Mon, 23 Apr 2018 00:00:00 +0000

Move fast, break things. Fail forward. Fail fast. Always be shipping.

These idioms are all around us in the tech industry. Establishing themselves in small, garage-band startups, they are now deeply entrenched in working cultures of even the most traditional publicly listed companies.

Working fast is alluring for every board-room executive. Especially if, over the course of months, speed (and failure) results in faster product releases, more revenue, bigger and faster growth. Capitalism, right? However, I'm of the opinion that speed – and those arbitrary deadlines – create an unhealthy balance that can eventually lead to the demise of the company. Moving fast and breaking things tends to be at the expense of paying attention to slower, subtle, more stable, 'boring' aspects of a system.

So what happens when we focus on the entire system? How can we create sustainable, balanced design systems that serve our companies and products for the long term?

The Fast and Slow

My family and I moved into our current house about six years ago. At the time, we were living in a modern semi-detached house that we'd spent about ten years making our own. We knew we wanted to move into something older and a bit more characterful. A place we could grow old in. After a year or so, we happened upon the house; a charming farm workers cottage on the edge of town. Having a look around it the next day, we instantly fell for it. It was perfect. Sort of. Just like all old houses, we knew there was some work to do.

Amongst many, many things that required some attention this fireplace was one of them. The house was cold – yes, the central heating was one of those things requiring work – so we needed fires in the winter. Fitting new log burning stoves required enlarging the fireplaces, and in the case of this one, opening up ones that had been blocked up.

My fireplace

The day before this photograph was taken, Dai – our Welsh stonemason – called me at work and asked me not to come home for a while. That sounded ominous. In their wisdom, the builders who had blocked this chimney had thrown the rubble down it. He managed to dislodge about three tonnes of rubble that came down in a small explosion in our living room. We could taste the resultant dust for weeks. This is just one example, over the past six years, where this house has surprised us. When you start peeling back the layers, you start to see what a building is made from. What its story is.

In his book, 'How Buildings Learn', Stewart Brand has a useful concept to explain this.

Building shearing layers

He describes a building having layers that age at different speeds. These 'shearing layers' are very apparent in my house!

In his follow-up book, The Clock of the Long Now, he expands this concept and applies it to our world.

Pace layering from The Clock of the Long Now

On the top layer there is rapid change. On the bottom, change happens at a glacial pace. It's this combination of everything, from seconds at the top, to millennia at the bottom, that give resilience to the system. As he says in this talk:

'The fast parts learn, the slow parts remember'

A key concept to this is that each layer has to respect the pace of another. There are examples of when this has gone wrong in the past in society:

Regime change in Iraq – removal of governance in a system – has resulted in change to all layers. The system collapsed and we are still feeling the effects of this today and into the foreseeable future.

In 2008, as so wonderfully documented in the film 'The Big Short', the housing market in the US failed. The cause was complex, but central to it was the failure of the CDO – the not-so-wonderfully-titled 'Collateralized debt obligation' – and the sub-prime mortgage market. The collapse of both put modern global civilisation on the brink. A decade later, we look set to make the same mistake.

The part of this diagram I like the most is that it forces you to think in time instead of other ways of organising things. As this relates to design, time – or rather longevity – is not generally a consideration. Like much of our lives, modern design gravitates to those upper layers of commerce and fashion. We get paid well to make desirable things that people consume. Once we're done with one thing, we move onto the next.

But how can we apply this thinking to design? How can structure design organisations and systems based on time rather than resources or products?

Why is this hard?

I'm currently just a few months into the job, but already it's clear EMBL (the European Molecular Biology Laboratory) is a special place. Like CERN, and other organisations that provide infrastructure for basic research, the currency of EMBL is science. Not profit. Or shareholder value. But by providing the very best environment for groundbreaking scientific research to happen. And it's precisely this reason that makes design in places like EMBL challenging.

Perched on a hill outside Heidelberg in Germany is the headquarters of EMBL. Like its other campuses in Barcelona, Rome, Grenoble, Cambridge, and Hamburg, the Heidelberg campus is a small gathering of laboratories and supporting buildings. It feels more like a university than a multinational organisation; full of students and young scientists embarking on their career. It's a place of energy.

There's amazing work going on at EMBL. This story recently caught my attention.

In about 40 years, the demand for data storage will outstrip the supply of silicon. Our need to store data will continue to increase, but we will need to focus the usage of silicon on more critical things such as computer chips. To address this, scientists have been working for a little while to encode digital data in DNA. Turns out there's quite a bit of space available but at the moment it's costly. A few years ago it cost about $13000 per megabyte to encode. Like all things, the price comes down as the technology and methods improve, but even this is palatable where long term storage is considered.

Recently, scientists at ETH Zurich did a study into the stability of DNA data storage. The results showed incredible stability. Data would be stable for ~2000 years at 10C and over a 1,000,000 years at -18C. And the additional benefit of DNA is it's really, really tiny. Last year a new method at Columbia University estimated that DNA has a 215 petabyte: 1 gram storage ratio.

The latest instalment on this 40 year deadline, was last year Nick Goldman of EMBL-EBI encoded an encrypted bitcoin into some DNA and gave away samples at a conference with a simple challenge to the attendees: decode it and you can keep it. Recently, someone did just that..

Why am I telling you all of this? Basic scientific research spans the pace layers. From fast. To slow. The field of scientific research is structured to accommodate this; except for senior staff and scientific research group leaders, EMBL employees are not at EMBL very long. The result is a startup-like culture working fast on problems that span decades. Since working with scientific institutions like CERN, now EMBL, it's also the answer to the question I ask myself almost every day: 'Why is this hard?', and why structuring design systems by time may be more useful.

What's in a system

If we look at the constituent parts of a design system, we might see something like this list:

  • Governance
  • Patterns
  • Tokens
  • Logo
  • Typography
  • Colours
  • Icons
  • Content
  • Tooling
  • Documentation
  • People
  • Committees
  • Infrastructure
  • Animation
  • Data entry
  • Data display
  • Layout
  • Localisation
  • Markup and style
  • Messaging
  • Search
  • Navigation
  • Voice and tone
  • Accessibility
  • Grid
  • Image

That's quite a lot. And, if you look at a lot of existing design systems and style guides, this stuff tends to be categorised into large groups such as 'Brand', 'Marketing', or 'Product'.

Typical design system groupings

But if you look at a system more holistically, there are many other things:

More holistic view of a design system

These large, holistically focussed groups can be layered according to their rate of change:

Pace layers view of a design system

Remember, rate of change at the top is rapid, at the bottom, things should barely ever change. If we start to map on top of this our items from our lists...

The layers of a system

Let's look at each one in turn. Starting at the top with 'Tooling'

Tooling

Tooling is fashionable. The way we design, build, deploy and update digital products changes as fast as users consume them. This will probably always be the case, and, you know what, that's ok if your system is built to accommodate it. For me, that means ensuring that the means by which the system is distributed and deployed is in step with your organisation's way of doing things. The moment these two things don't match, tooling becomes an issue.

Patterns

Design patterns are closely linked to product design and user behaviour. As these things change, patterns need to change too. In this layer I'd include the look and feel of design patterns in addition to their code. Admittedly, there is somewhat of a grey area there with tooling – many design patterns are linked to methods of deployment and distribution. According to this model, that isn't a great idea. When tooling – which changes at a different rate – is combined with patterns, it leads to what Stewart Brand calls 'layer turbulence' and often the answer to my question: 'why is this painful?'.

People

The people in a system are seldom acknowledged as a component of a system. Instead, they are people who act on a system. I think this is a mistake. People take work. In most organisations, the people of a system represent continuity and sometimes the only thing stopping it from being rebuilt and redesigned from external HIPPO (Highest Paid Person's Opinion) influence. How I'd define people would be any real person interacting with the system; the team building it, stakeholders, open source community etc.

Documentation

As we move down the layers, things become more stable. There are many things in documentation that require stability. Change needs to be more visible and apparent, such as repo commit messages, or 'last updated' footers on website content. Documentation could also include design principles, brand guidelines, or editorial guidelines. For many systems, this represents the lowest layer of stability, but I think we need to go further.

Governance

Systems need governance. How else is change managed? A key thing to note here is that the work of governance is managed at a higher level in 'People' as it's faster. This layer is concerned with the process and methods of governance; how a system is governed rather than the act of governance.

Foundations

Like the foundations of a building, the foundations of a design system should not change. Examples that I would consider foundational are things like the URL of your design system; elements of the brand; the repository; the design system and brand nomenclature.

With all that in mind, let's have a look at those idioms again:

Move fast, break things. Fail forward. Fail fast. Always be shipping.

These phrases drag us to the top layer and keep us there. They prioritise speed over stability. I'm interested in creating sustainable systems with longevity, so I don't think it's an appropriate way of thinking. What might be more appropriate, but probably more boring, is:

Structure for pace. Move at the appropriate speed.

But I guess that doesn't sound as cool.

Note: This article is a rough transcript of the talk I gave at SmashingConf in San Francisco in April 2018.

]]>
<![CDATA[Write it down]]> https://markboulton.co.uk/journal/write-it-down https://markboulton.co.uk/journal/write-it-down post Tue, 20 Mar 2018 00:00:00 +0000 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.

]]>
<![CDATA[Editorial planning with Trello and Zapier]]> https://markboulton.co.uk/journal/editorial-planning-with-trello-and-zapier https://markboulton.co.uk/journal/editorial-planning-with-trello-and-zapier post Fri, 09 Feb 2018 00:00:00 +0000 As long as I've been working with editorial teams a content pipeline has been a problem. Knowing the state of a story, its context to those around it, and who has done what, when, is vital in managing a content throughput. Generally, this figures itself out in a busy, noisy, physical environment. But, the more remote a team becomes, the more challenging it is to communicate on the state of stories.

When I joined EMBL a couple of months ago, this was a problem we had. Content status was done weekly, but a continually available overview by the entire team was not. Nor was there a tool or process to push stories around. As I said, my experience is this is not unique to EMBL. Almost every editorial team I've worked with struggles with this.

Dan and I got our heads together and worked on a process that would fit with the existing team and tools. The team here use Trello extensively for planning, so we started there.

The one board to rule them all

It was important we didn't interfere with existing processes using Trello. The team all use Trello in different, interesting ways to collaborate and manage their content; from ideas to final copy. We needed to integrate with that best we could. This is what we settled on:

1. A Pre-production Trello Board

Once a story is ready to go into the workflow. Meaning it is agreed, planned, assigned to a priority etc, then it is added to the pre-production Trello board. This board is organised by story type: features, updates, press releases. Once a story is complete and ready to publish, it is moved into a column 'Move to Production'. Zapier then copies the card, with everything in it, over to the Production board. Once that's done, it moves it to an archive list.

2. A Production Trello Board

The production board is not focussed on collaboration or story type, but arranged as a pipeline of approvals, sign-offs, edits and publishing. Once a story moves through these linear stages then published, Zapier goes in again and moves the card entirely over to the archive board.

Some notes about Zapier

I've used Zapier a bunch of times over the years but never really had the time or focus to work on automation that fits within a team environment. It's great, but it requires some wrangling to work if you move beyond the default app integrations.

Zapier integrates really well with Trello. There are a whole bunch of predefined tasks that you can chain together to do stuff with your Trello boards. For the most part, the challenging thing is working out the sequencing of what you want to do. For our 'move to production' task, this is what we ended up with:

  1. Find the Pre-production Trello board
  2. Find a list on that board called 'Move to Production'
  3. Find cards moved into that list (this is the trigger to run the whole zap)
  4. Get information about the card and move it to Production. (In fact, here, I didn't move it but copied it. I wanted a safe-guard in the system so that if something went wrong, there would be a backup)
  5. Once it's moved, confirm by then moving the card into the archive list.
  6. Once all that's done, check the card has actually moved.
  7. Then post to Slack and let everyone know.

The only stage out of all of these that is out of the ordinary is the 'copy' task (number 4). To complete that little task we need to use webhooks in Zapier to POST directly using the Trello api. After a bit of Twitter help Hat-ip @sprawsm, we figured it out. It's probably easier if I just show you in Zapier what the important bits are:

Zapier webhooks fields

You can see from this image that the web hook field has a bunch of form fields. I'll concentrate on the important ones:

URL

When we create a web hook, we need a URL for the api endpoint. For Trello, this is the one we need: https://api.trello.com/1/cards/key=(your key here)&token=(your token here). You can get the key and token from your Trello settings.

Payload type

Set this as JSON

Data

These are the fields of data you are going to pass to Trello via the api. The content of these fields will be populated from the fields earlier in the Zap. It's important each of these field titles is copied exactly for the task to run. Let's go through each in turn:

  1. 'name'. This needs to map to the title of the card to move.
  2. 'idCardSource'. This is the ID of the card.
  3. 'due'. This is the due date for the card if it has one
  4. 'KeepFromSource'. This one is important. It will make sure when the card is copied from one board to another that all the cards contents are retained.
  5. 'idList'. This is the ID of the list we want to move the card to.

Wrap request in an array

No

Unflatten

Yes

And that's it. These are all the changes you need to make below the data fields. When it is run, this little task will take the values from the other tasks before it and populate the data fields, it will then post that to the Trello api, and Trello will copy the card into the Backlog list on the production board.

Broader use

After using this for a little while, I realised I'd really like to use this workflow for managing my simple, personal Trello backlog. I have a pretty standard kanban-style backlog/doing/done Trello board for all sorts of stuff. A mix of personal, side-projects, work, thoughts, writing. It's a dumping ground. Every day, though, I may need to pick some cards out and replicate them on the team board or a project board. Now all I do is replicate this task. I've added a couple of additional lists in my Trello board, and I move the cards into them when I want them copied somewhere else. Zapier watches those lists and copies the cards. I'm finding it a useful way for moving cards around and getting work stuff out of my personal board, and into a work board.

A bit of gaffer tape

Whilst this automation works well for the most part, sometimes either Zapier or Trello craps out a little bit. When that happens, it's normally some snafu with the Trello api and the post. That's why the notification is an important part of the process. Using a quick ping into Slack let's me know a couple of things: that the zap is actually working still, and that there is a new card that has been created.

I'm sure there could be technical improvements to make here to make this a bit more robust. But as a scrappy self-serve solution for an editorial team to manage their through-put of stories, so far, so good!

]]>
<![CDATA[Newish blog]]> https://markboulton.co.uk/journal/newish https://markboulton.co.uk/journal/newish post Fri, 02 Feb 2018 00:00:00 +0000 A new year. A new blog design. The first time I've mucked about with my site in ages, actually. But why the renewed interest?

Ever since Statamic released version 2 a little while ago, I've been meaning to rebuild my version 1 site. It was more of an exercise in just learning something new than anything. However, about 18 months ago – maybe longer – I tried and then swiftly gave up. There was just too much of a gap between v1 and 2 that I could bridge at the time. Not enough head space. Turns out, it took something going wrong with my head to finally give me mental space to give it a go over new year this year.

In December, one Sunday, I fell off my road bike. I fractured both my hands, cut my eye and gave myself a nasty concussion. Whilst recuperating turns out that learning and building this new website was just the physiotherapy I needed both for my brain and my fingers. Finding myself with a bit of spare time, when I should've been out on my bike, meant I set to work migrating the old stuff from version 1, and, typically, redesigning in the process.

So, what's new?

I wanted a design refresh. In all honestly, I wanted to use fonts that weren't Monotype fonts! So, I have a bit of a thing for Retina from Frere Jones, after trialing it for a project with Conde Nast over the summer. And what better pairing than Exchange which is a beautiful serif.

From a content perspective, I've also got a new section called reading where I pull in Pinboard links that interest me and others might find interesting. I've also been working on a portfolio. Haven't had one of those for a while. I've done some interesting work over the past ten years and it's nice to document it. For my sake more than anything.

So, what's technically new?

Under the hood, quite a lot. Have a read of the site colophon for a swift introduction. The site now runs on version 2 of Statamic. Which brings with it a whole load of advantages and features. Statamic is built on top of Laravel, so locally, I use the nifty Valet. Keeping with the Laravel theme, I use the excellent Forge service to build and manage a server using a Digital Ocean droplet. I used to use Mediatemple, like, forever, but this setup is absolutely fabulous in comparison. Everything Just Works. The sweetener is that Forge automatically deploys from Github. All I need to do to add content, or make a change to the site is commit the changes to my production branch and that's that.

Now, I know to many of you reading this, all that I've just explained has been doable for a million years and what am I getting so excited about? Well, I think that's certainly the case but it hasn't been until recently that there have been a series of interconnected services available for people who are, yes, still, anxious about using the command line.

CSS wise, I've tried using CSS grid. A few things might be amiss as I continue to work on the layout and I get my head around CSS Grid and its possibilities.

]]>
<![CDATA[EMBL]]> https://markboulton.co.uk/journal/embl https://markboulton.co.uk/journal/embl post Fri, 01 Dec 2017 00:00:00 +0000 Today is my first day working at the European Molecular Biology Laboratory - EMBL. I'll be leading digital communications and to say I'm excited by the challenge is probably a bit of an understatement.

I've had nearly a year of working on a few bits and pieces of consulting for a few new clients in addition to several two week design sprints for EMBL on their holistic corporate design. It was during these sprints that I got a growing sense of the work that needed to be done.

Back in 2012, I was knee-deep working on redesigning the CERN website. It was, to date, the most fulfilling work of my career. Not because of the result, or the process, or the commitment of the client and their team, but because of the work being done at CERN. It matters. And I have the same feeling now about EMBL. Fundamental scientific research matters. It matters to the human race, to our understanding of the world around us, and how we might overcome some of life's greatest challenges on this planet and beyond. When I first started my design career, I wanted to work for projects that meant something. After ten years of almost exclusively commercial work, I'm thrilled to be getting my teeth stuck into something meaningful..

]]>
<![CDATA[Defining design principles at EMBL]]> https://markboulton.co.uk/journal/defining-design-principles-at-embl https://markboulton.co.uk/journal/defining-design-principles-at-embl post Wed, 04 Oct 2017 00:00:00 +0000 For a little while, since leaving Monotype, I've been working with the communications team at the European Molecular Biology Laboratory (EMBL) on a holistic corporate design project. It's pretty exciting work.

I'm lucky that the project is being headed by Dan Noyes, who I worked with at CERN, so he and I know how to work together pretty well. There is a fabulous team in place, and we've been tackling some fundamentals of the brand, the strategy to implement the it, all within the context of a complex scientific organisation.

To help keep us arrow straight whilst navigating this problem we defined design principles to do it. Now, I'm sure there are many ways to define principles but here's how I do it and it's really quite simple. I was shown this by Leisa when we defined design principles for the redesign of Drupal 7 years ago. All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.

Throughout the sprint, we defined the following design principles for EMBL:

  1. Make it sustainable

We will create a long-term, sustainable system. Designed for efficiency, re-use, and scale.

Sustainable systems are diverse and productive indefinitely. Being holistically focussed on how EMBL interacts with its audiences internal and external, means we create meaningful, sustainable experiences over the longer term.

  1. Show our work

We will prioritise demonstration over discussion. Through prototyping we will show how these principles and values apply to the work.

We will embrace modern design practices by starting small and iterating quickly. We will avoid big reveals and develop a process of publishing early and often. This requires a change of mindset of the team: to be comfortable with ‘not done yet’; to be satisfied to prioritise function over form; to get the things we make in the hands of our audience so we can understand their needs more quickly.

  1. Keep it simple

We will do the difficult work to keep the things we make simple, approachable, and put the user’s needs first.

EMBL is complex. As are the audiences, services, applications, and communications material that operate within the brand. We will do the hard work to uncover and expose the simplicity of the core.

  1. We are all one organisation

We will cultivate cross-pollination of services, products, ideas, and collaboration.

We will proactively seek out opportunities to collaborate on the design of services across all channels throughout EMBL and invite feedback and new perspectives. We will share and discuss our methods.

  1. Physical, digital, and environmental are in sync

We will ensure a holistic approach for one system for all printed, digital and environmental touch-points.

Design systems across media evolve at different rates. We will ensure systems across all channels are relevant to the media, but also share nomenclature, design patterns, and are built from the same principles. We will think and act as a cross-disciplinary design team.

  1. Pave the cowpath

We will make the design language accessible where people are already working.

Forging a new path is hard. And sometimes a waste of energy. By understanding how the brand is expressed currently, we develop new ways to provide the ingredients of the brand to the people already doing the work, in the place they are doing it. We will invent new ways with which to distribute the brand across a constantly moving, evolving system. We shouldn’t press pause.

  1. Repeat the words we use

Through consistency and repetition, we will create and maintain a design nomenclature that will become part of the EMBL vernacular.

The words we use are important. By repeating these words about EMBLs products and services, they can remind us many times every day what we believe. Changing the words we use can help change the culture of an organisation to be more design and brand aware.

Another important aspect to these is the way they are structured. A design principle is a belief. It's something we promise to do and should be worded as such.

You can read more about the design process on EMBL's communications blog.

]]>
<![CDATA[Moving on from Monotype]]> https://markboulton.co.uk/journal/moving-on-from-monotype https://markboulton.co.uk/journal/moving-on-from-monotype post Fri, 21 Apr 2017 00:00:00 +0000 Last week was my last week working at Monotype. It's been a whirlwind three years and I've learnt a lot. Of course, I'll miss my colleagues and what's left of the team we built at Mark Boulton Design.

But now it's time for other things. But what things? Well, I see two paths in front of me.

We're at a really interesting inflection point in the industry. Organisations are still figuring out how to invest in design. Design leadership is a scarce commodity. The impact of design at all levels – from product and commerce to strategy and research – is having a challenging time to find a symbiotic relationship with business. I can help there.

The other path for me is consulting. Many organisations are either not ready to commit to building design capacity on a full-time basis, or rolling back in-house design commitment after a failure to some degree. Maybe they are just starting out. Or it's simply a matter of budgets and structuring. Regardless, I saw this a lot when I ran an agency. It's why and how we got the work. I can help here, too.

I'll be taking a few weeks off, but then I'll be looking to commit to one of these paths. If you're looking for a design leader, or you maybe have a project you think I could help with, then get in touch.

]]>
<![CDATA[Design systems and Postel’s law]]> https://markboulton.co.uk/journal/design-systems-and-postels-law https://markboulton.co.uk/journal/design-systems-and-postels-law post Tue, 17 May 2016 00:00:00 +0000 I was first made aware of Postel’s law by Jeremy in his fabulous talk about design principles. Incidentally, he’s documenting lots of design principles here.

Postel’s law – or the Robustness principle - states:

Be conservative in what you do, be liberal in what you accept from others (often reworded as “Be conservative in what you send, be liberal in what you accept”). From Wikipedia

Jon Postel was talking about TCP and how implementations should follow this principle. Putting TCP and networks to one side for a minute, you can see how this principle can apply to many systems where there is input and output. Specifically, design systems.

The basic premise of Postel’s law is that what comes into a system can, and invariably, is a mess. Non-Compliant, delivered in a weird way, unconventional.

When thinking about this, I recall some work I did years ago on a ticketing system for a help desk. The single biggest hurdle, in order for the system to be successful was it had to be liberal in what it accepted. Tickets needed to be created from email, phone applications, web applications, voice recognition etc. The hardest part was getting stuff into the system. Only then could a single ticket be created - from various sources, in varying quality of data – in a single useable ticket for use with the large team.

Be liberal in what you accept (from emails, apps, voice, websites) and conservative with what you do (creating a single, well-defined ticket).

I see this same principle being applied to design systems.

Collaborating across an organisation to create a meaningful, impactful design system means you have to be liberal in what you accept from others into the system. Be it code, thoughts, design work, content, or criticism. That input can also come from many different teams, strategy, executives, products, people. You see, it’s a big mess! And the only way, really, to work with a system like this is to be open to all input from wherever it comes, in whatever form takes. To be liberal with what you accept.

This approach does a few things:

  1. Makes people feel involved, consulted, and listened to. This a good thing.
  2. Exposes the system to the dirtiest, out-of-date, horrendous use-cases possible. This is also a good thing. Mostly these use-cases are ignored because they are horrible.
  3. Helps turn a system that is owned, to one that is shared.
  4. Helps identify themes across an organisation.
  5. Helps the design system core team operate at a holistic level.

Policing a design system never works in my experience. It never works because people don’t like rigid systems, being told what to do, and will straight up do the opposite. Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.

So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable. It needs to turn the messiness of a liberal input into a defined, purposeful output that people can easily slot into their workflow and use.

Once again, I find myself in a place banging heads with how work happens rather than what the work is. Someone once said to me that ‘design principles are the stars to sail our ship by’. I’m certainly going to be using Postel’s law to sail my particular ship in the months and years ahead.

]]>
<![CDATA[Design systems in difficult places]]> https://markboulton.co.uk/journal/design-systems-in-difficult-places https://markboulton.co.uk/journal/design-systems-in-difficult-places post Thu, 18 Feb 2016 00:00:00 +0000

A street in Manchester

This is Manchester. I grew up on the outskirts of Manchester. I have memories like this picture. Black and white. Snowing. Wildlings. It’s grim north of the wall.

But what this picture doesn’t show is the rich visual culture that Manchester had throughout the 80’s and 90’s. All that rain and grim weather makes people creative. It’s no accident most of the best music in the world came from the North West of England.

Tony Wilson

This is Tony Wilson. Tony was a journalist in Manchester, appearing on Look North West as a roving reporter. I have lasting memories of his wind-swept hair, stood in a gaudy cagoule talking to a farmer on some moor somewhere. He was on telly every evening at teatime when Look North West was an ‘appointment to view’ (as they call it in telly-land) across the region. But as well as being a journalist, Tony was also involved in Factory Records, founding it with Alan Erasmus in 1978. Factory went on to define an era of music in the 80’s and 90’s signing bands such as Joy Division, New Order, and the Happy Mondays. I’m not a big fan of the music, but of the graphic design produced at the time.

Graphic design from Factory Records

Graphic design from Factory Records

This work was everywhere in Manchester. On every street corner. In every record shop. In every music shop. There were posters, fliers, newspapers, TV adverts. The hum of the city became entwined with the output of Factory. And, without really noticing it, started to take on this DNA. It became Manchester’s design system. It’s visual life-blood.

Imposing order

The challenge with any design system is they normally don’t work, don’t get adopted, don’t grow or get used if they are imposed top-down without an awful lot of consultation. Like any language, they have to be adopted by the masses through continued daily use. The tricky thing for us designers is that is rarely how we’re engaged to create these things.

Normally the brief goes something like this:

We’d like you to design us a living style guide (replace with ‘pattern library’, ‘design language’, ‘brand guidelines’, ‘identity’). We’ll then use that to provide consistency to our entire product range – of which we’d like you to help us.

Now, this works in some circumstances if control is maintained by a marketing department or brand manager. But, it’s my experience, that unless design is valued then control is absent. Nobody has the authority to own this. They just have some budget and see a problem that needs addressing, but do not have the money, authority or organisational environment to make this work succeed. So what do you do then?

Well, you just do it anyway. But over the years – taking some inspiration from my home town – I have a few principles…

1. Repeat yourself consistently

Let’s get one thing out of the way first. Meetings are not bullshit. Suggesting that is actually bullshit. Meetings – where people talk and resolve things, plan, decide – are probably the most important thing you can do to get a design system off the ground in a difficult place.

Remember, you have no authority. Your client, or stakeholder, has no authority. You’re doing this for better, holistic good of an organisation that almost everybody there cannot see. So you have to persuade, provide insight and data, and in my experience you have to do it over and over and over again.

2. Establish a mandate

Over the last 10 years i’ve worked on quite a few, large scale design systems. In all of them, there was a distributed technical system that had grown organically. A few CMS’s here and there. PHP, .net, etc etc. It’s not like you could create a bunch of HTML and it would work everywhere. Far, far from it.

And then, editorially, many of the departments of these organisations were creating content without any joined up thinking. It was common for them to have their own budgets to create their own mini projects (yes, with their own CMS) and they’d hire a little design firm to do it.

From a branding perspective, there was normally a small, internal, over-worked branding team who were constantly and consistently putting out fires that the organisational structure creates. Everywhere you look people were degrading the brand.

In my experience, this is the norm. How do you create a design systems that not only gets adopted, but thrives, in this environment? You have to establish a mandate. An editorial, technical and brand mandate. A troika of disciplines working together to establish order.

3. Be where the creator is

In the case of Manchester, the work of Factory was in front of every young designers eyes. Everybody looked up to the work of Peter Saville and created work to replicate it. So, on every street corner, the inspired work appeared. All of a sudden, Manchester’s visual DNA expanded beyond the world of record shops and club night posters, and made it into plumbing brochures, margarine packaging and pub fliers. The bread and butter for jobbing designers in the North West.

This was because the work was accessible and in the places designers where looking for inspiration.

I like to apply the same thinking for the adoption of a design system: be where the creator is. A few examples:

  • Provide ready-made templates for design tools. Not just for in-house designers, but so external designers (you know, hired by the small department trying to use their budget before the end of the year) can use them too.
  • Provide tools to make things. If you’re building digital things, provide a UI library and maybe prototyping and deployment tools that make consistency easier.
  • Be where they are. If an organisation uses Sharepoint, or some other God-awful intranet software, then put your tools where they are and don’t try to force other documentation if it won’t fit.

How do you know you’ve been successful?

I get asked this a lot. How do you know if your work will stick? You’ve spent a year designing a new design system. How do you know it will really hold? I’ve learnt to look out for a few indicators…

  • The design system becomes how design is talked about in an organisation. It becomes a shared vocabulary. And not just by other designers, but by management and all levels of an organisation.
  • The quality of design (and editorial and technical) becomes self-policing. It’s no longer the responsibility of just one person or team, but ownership becomes distributed. People start to care.
  • Design and KPIs. Clear lines get drawn between good design and measurable outcomes.
  • Lagging and Leading indicators become more apparent. So you can better predict how those indicators affect quality, brand, product roadmap. In this case, design can help indicate the health of an organisation.

What’s Manchester got to do with all of this?

You may well ask. When I was growing up in Manchester, I never really took much notice of the graphic design around me. It was only when I left – or years later – when I decided to become a designer that this stuff leaked out of me. It was stored somewhere deep inside my brain and with it, I like to think, I absorbed some of that taste. By being part of the Zeitgeist.

What you do now for your client or in-house will have an effect that will be felt years later. You will change how people think about design. Change their relationship with the company they work for. All by consistently using Helvetica, or something. It’s not that hard. Is it?

]]>
<![CDATA[The difference between a goldfish and a human]]> https://markboulton.co.uk/journal/marginal-degredation https://markboulton.co.uk/journal/marginal-degredation post Tue, 16 Feb 2016 00:00:00 +0000 In the 2012 Olympics, the UK cycling team dominated the track. Winning 12 medals: 8 Golds, 2 Silvers, 2 Bronzes. They also broke 7 World Records and 9 Olympic Records.

The French cycling team director suggested that the UK team were using ‘magic’ wheels. That was until it was pointed out the wheels were designed and manufactured in France.

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

Here’s a few fun facts… - Gorillas share 98.4% of our DNA - Goldfish share 68% - Bananas share 50%

Bananas. Are 50% the same as us.

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.

]]>
<![CDATA[Designing a good portfolio]]> https://markboulton.co.uk/journal/how-to-design-a-portfolio https://markboulton.co.uk/journal/how-to-design-a-portfolio post Wed, 06 May 2015 00:00:00 +0000 It’s 1998 and I’ve just arrived in Bangkok and it’s 90F at night. I’ve arrived at a small hostel just around the corner from the Khao San Road and, just like everyone else travelling or on a gap year, I’m a walking stereotype. From my flip flops, overly loose trousers, consumption of banana fritters and cheap Thai beer. Oh, and well-thumbed copy of The Beach.

Like I said; a walking stereotype. Except for lugging around the 2kg A3 sized portfolio case rammed into my already weighty backpack.

It’s 1998. The web is still in its infancy, but it’s there and pretty good. Fireworks was on version 1. I used Internet Explorer 5 and Eudora The first iMac had been recently released. Not really the dark ages, but here I am, lugging around an additional 2kg of dead trees for two months around South East Asia. Why? Well, I wanted a good job when I got to Sydney. And, as a designer, a good portfolio – or ‘Book’ as it’s called in advertising – would get me one.

Let me back-peddle a bit to my first job as an intern at an ad agency in Manchester. There worked an Art Director called Tom. Tom was quiet mannered, quick to smile and laugh, and much quicker to point out a small opportunity for improving a design. Together with the other Art Directors, he taught me about hierarchy and how to make type fit on a page (this was a distinct problem when designing plumbing catalogues). But he also taught me the value of a good Book. How to design one; how to tell a story through your work; how to present your work and do enough in the portfolio to get you a foot in the door which is what junior designers needed so much back then.

“Leave your book and pick it up tomorrow”

My experience of looking for a job early in my career was probably quite usual amongst my peers: I never replied to a job advert. Instead, I was encouraged to get together a list of the places I’d like to work and then to sell my portfolio around them. So, there I was; fresh out of school, full of ‘I got a First Class honours degree’ confidence selling myself from agency to agency. It was a baptism of fire. I remember the first day was particularly horrific. Out of the six or so agencies I’d arranged to visit, only one was happy to let the art director see me rather than just leave my Book and pick it up tomorrow. And then, my work was systematically ripped to shreds by an Art Director with too little time on his hands.

Now, this isn’t meant to sound like ‘oh, woe was me and my hard time finding a job’. But, I am trying to recall how my portfolio was the start of a conversation. And, generally, a conversation I wasn’t there for. I didn’t really plan for that so had to adapt the work to invite that second meeting.

Oh, those soft skills

So much of what we do is working with people. Sometimes, though, I think I need to have experience in counselling or negotiation tactics in order to usher through design changes which impact organisations at their core. It’s difficult work. And, if you’re not the type of person who like talking to other people, then the impact of your work will only go so far. The question is, how do you demonstrate this in your portfolio? How can you demonstrate the value of design games, or collaborative moodboard exercises? Or that it took six months of negotiating with dozens of facets of an organisation in order for a content strategy to be adopted? My advice would be to write a story. Show photographs of workshops. Demonstrate how you approach these things. List the methods you’ve used and those that have worked. List those that haven’t and the reasons why.

This may seem odd for a portfolio, but if you think about it, design agencies have been doing this for decades. This is because they have similar problems. A lot of agencies sell the process of design, not the end result. In order to charge money for things like strategy, research, collaboration and what-not, all of which is difficult to show in a piece of design, they have to demonstrate it in other ways; case studies, stories, photographs. Packaging the work to show the full range of what was worked on.

A few pointers Tom gave me (and a few of my own)

Let me take you back to Manchester in 1995. I think it was early in a week in July. It was probably raining, as is usual in my home city. Anyway, Tom and I are discussing university and where I’d like to work and doing what. I start talking to him about my final year and the projects that await and he begins to advise me on not leaving my portfolio work too late. That I should be working on it throughout my final year and how I shouldn’t under-estimate the amount of work it will take. A year! Surely it couldn’t take a year, I said. It’s just a dozen prints after all. ‘No’, he said. ‘It’s probably the most important piece of work you’ll do in your final year, and one you won’t get marked on until you try and find a paying job’.

Over a nice hot cup of tea, he and I chatted for an hour or so about what makes a great portfolio and all of the things he considers when a dozen or so would land on his desk every single week. At the time, this was for a print portfolio, but looking at these now, you could easily see how they’d apply to all types of portfolio, including those for a small studio or agency.

Here are the highlights…

Snapshot

Who was the client? When did you work on this. What was the Date? What was your role? What was the value to the client? But keep this brief. This meta data way-finding is important when skimming through a portfolio.

Show a progression

Show work that didn’t cut it. Demonstrate your ability to change and iterate and show variance to get to a solution. This also demonstrates your graphic design capability, copywriting, and visual thinking.

Be honest

If you worked under a senior, say so. Talk about why projects might not have been completed. Honestly, if you bend the truth, it’ll catch up with you at some point.

Breadth

If your work is just a bunch of posters, of a certain type of client or work, then it’s easy to pigeon hole you. If you just design icons, that’s the type of work you’ll get. Demonstrate breadth, even if it means working on your own side projects or setting yourself your own briefs.

Fewer and better

Be very, very picky about what you show. If you only done three projects you are really proud of, then just show them. Talking passionately about how it went, what your contribution was, and what happened after it was finished will shine much brighter than ten single pieces of work. It’s easy to spot things made with care and love, even those commercial projects that fell short of the mark (and it’s ok to say that if you know the reasons why).

Walk the walk

If you can code, then demonstrate it. If you can’t, be clear about why you don’t think that’s applicable for your role and growth. Either way, conviction in your own abilities or not will tick boxes.

Work is more about pictures

The big difference between junior designers on the web and print is quite stark, but the more experienced you become, the roles become similar. It becomes less about pretty pictures, and more about facilitating a process from beginning to end. Think about how you can convey something before hand that isn’t a picture. This is where writing about your work trumps showing pictures. Because sometimes there just aren’t any pictures to show.

And, the last point I think nicely rounds off this post.

It’s the start of a conversation

This was applicable when I started my first job, when I ran a small agency, and now I work in-house at Monotype. Any portfolio is the start of a conversation. It needs to invite discussion, further questioning, and that all important call-back.

Going back to that stereotype traveller type, wandering around Asia with an extra 2kg in his backpack… Well, I arrived in Sydney. I had a very short list of studios I wanted to work for and proceeded in doing what I’d done before: making myself a nuisance until I had the opportunity to either leave my Book, or talk it through with someone. I managed to get the job I wanted with a great little company in Sydney called Spike. It was my first web design job. All thanks to Tom and his advice. And a sturdy rucksack.

]]>
<![CDATA[A Design SDK]]> https://markboulton.co.uk/journal/a-design-sdk https://markboulton.co.uk/journal/a-design-sdk post Mon, 16 Mar 2015 00:00:00 +0000 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.

]]>
<![CDATA[Visual Design might be a thing]]> https://markboulton.co.uk/journal/visual-design-might-be-a-thing https://markboulton.co.uk/journal/visual-design-might-be-a-thing post Mon, 02 Feb 2015 00:00:00 +0000 If you recall, a few years ago, I wrote about my belief that the term ‘visual Design’ was propagating through the UX community and the potentially damaging effect that was having on the problem-solving roots of graphic design practice. This was swiftly followed up by a longer piece for The Manual.

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:

  1. Visual Design
  2. Stuff
  3. Customer needs / Value proposition
  4. Board of Directors / Leadership
  5. 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.

]]>
<![CDATA[Adventures with Plex]]> https://markboulton.co.uk/journal/adventureswithplex https://markboulton.co.uk/journal/adventureswithplex post Fri, 10 Oct 2014 00:00:00 +0000 I've written before about going completely digital for our home entertainment. To recap: I have a big, shared hard drive attached to an iMac that two Apple TVs share to using ATV Flash This was fine for a while, but, frankly, ATV Flash is a little buggy over our network and the Apple TV struggled with any transcoding (converting one file type to another) and streaming – especially in HD. So, we needed something better. In steps a few things: Netflix, Plex and a Mac Mini.

Plex has been on my radar for a few years and up until recently didn't really make much sense for me. But as ATV Flash was becoming more unstable as Apple updated their OS, then Plex started to look like a good alternative.

The hardware

As you may have read from my older post, I did have shared hard drive with all the media on hooked up to an iMac which the Apple TVs shared into to browse the media. The issue here became network and sharing reliability. Quite often, the shared hard drive was invisible because the iMac was asleep, or the network had dropped. Sometimes this happened in the middle of a movie. Not ideal.

The new setup is almost identical, but instead of using the Apple TVs as hardware to browse the library, they are now being used just as a device to Airplay to. I barely use the Apple TV UI at all. Browsing from my iPad and then air playing to the Apple TV. What's cool here is that the iPad just acts as a remote, the file itself is being transcoded on the server and just pushed to the Apple TV directly.

What about a standalone NAS (Network Attached Storage)?

Plex does run on a NAS , but the issue there is most consumer NAS boxes don't have the hardware grunt to do the on-the-fly transcoding. So, I finally decided to ditch my iMac in favour of a headless Mac Mini to run as a decent media box, running Plex.

Getting started with Plex

  1. Download it. Get the Media Server on your computer or NAS of choice (Plex has huge device support). Also, get hold of the mobile apps. Once you're done there, download Plex for your connected apps: from Chromecast, Amazon Fire TV, Roku, Google TV or native Samsung apps and, now, the Xbox One, too. The app support is really quite incredible.

  2. Plex Pass. Even though the software for Plex is free, there are some additional things that are left for a subscription that you have to buy. The good thing is, you can get a lifetime subscription and the cost is very reasonable at $149.99. For that, you get early access to new builds, syncing content remotely, things like playlists and trailers. But the killer feature of the Plex Pass is the ability to create user accounts for your content. Now this is something I've been after for ages on the Apple TV, and even more important now my eldest daughter regularly watches films on it. I need the ability to filter the content appropriately for her.

  3. Setting up a server is a breeze. Once you've installed the server software, get yourself a user account on the Plex website and set up a server. This launches some web software for you to start adding files to your libraries and fiddle away to your hearts content with all the settings.

  4. If you did get the Plex Pass, I'd recommend creating multiple user accounts and playlists with the features Plex Pass gives you. The way I did this was to have email addresses and user accounts for server-plex, parents-plex and kids-plex. server-plex is for administering the account and has all the libraries shared with it. 'parents' for Emma and I, and 'kids' just has the 'children's' library shared with it. Now, by simply signing in and out of the iPad, I can access the appropriate content for each user group.

Next up: streaming, or 'How do I watch the film on my telly!?'

There are a few options:

  1. Native apps (Samsung, XBox One etc) These are apps installed directly on your TV or Xbox. To watch your content, simply fire up the app and away you go. Yesterday, I installed the Xbox One app and was up and running in less than three minutes.

  2. iOS and Airplay This is what I described earlier. Simply download the iOS apps and hook up to your plex server. Once you're done, browse your library, press play and then airplay to your Apple TV.

  3. iOS and Chromecast Exactly the same as above!

Now, there are some disadvantages and advantages to streaming.

Disadvantages: From what I understand, adding Airplay into the mix does have a slight performance hit. Not that I've seen it, though. I'm only generally streaming 720 rather 1080 resolution, so the file sizes are coming up against network limitations. I do expect this to change in the coming years as resolution increases. Advantages: It's a breeze. I use my Plex app on my iPad, choose a film or TV show I want to watch and then just stream it via Airplay. When I'm travelling, I take a Chromecast with me to plug into the TV and stream to that (more on that in another post).

'Hacking' the Apple TV

Currently there is no native app for the Apple TV, but there is a way to get around this by 'hacking' the Trailers app to directly browse your content on your plex server using PlexConnect or OpenPlex. Now, there's a lot to read to get up to speed on this, so I'd recommend a good look through the plex forums. I followed the instructions here to install the OSX app, add an IP address to the Apple TV (to point to the plex server) and, so far, so good.

To be honest, though, I tend to just Airplay these days. The iPad remote / Apple TV combination is quite hard to beat. It's fast, flexible and stable.

Is this it for my digital home needs?

For a good few years now I've been looking for the optimum solution to this problem. My home media centre needed the following:

  • Multi-user accounts
  • Full-featured remote
  • Large file format support
  • Manage music, photos and movies
  • Fast transcoding and streaming (minimum 720)

Both iTunes, ATV Flash, Drobo (in fact, any domestic NAS) fail on all or most of these points. Plex not only ticks every single box (if it's run on a decent machine for transcoding), but provides very broad device support, an active developer community and a really good UX for the interface.

Who knows how long I'll stick with Plex as I do have a habit of switching this around as often as I change my email client (quite often!). But, for now, it's working just fine!

]]>
<![CDATA[It's not you, it's me]]> https://markboulton.co.uk/journal/notyoubutme https://markboulton.co.uk/journal/notyoubutme post Sun, 07 Sep 2014 00:00:00 +0000 Dear web conferences, It's not you, it's me. Something's changed and it's not your fault. I'm just on a different path to you. Maybe we'll be friends in a while, but at the moment I just want some space to do and try other things. I still love you. But we just need a break. Love, Mark


I'm taking next year off speaking at web conferences. It's not that I don't have anything to say, or contribute, but more that I have better things to do with my time right now. Speaking at conferences takes about two weeks per conference if it's overseas once you factor in preparing and writing the talk, rehearsing, travel, and the conference itself. That's two weeks away from my wife, my daughters, my new job and a team that needs me.

Two conferences the world over

What I've noticed this past year or so is, largely, we have two different types of web conference running the world over: small independents and larger corporate affairs. The former is generally run by one person with hoards of volunteers and is community-focussed (cheap ticket price, single track). The latter is big-budget, aimed at corporations as a training expense, maybe multi-track and has A-list speakers.

As well as these two trends, I see others in the material and the way that material is presented. 'Corporate' conferences expect valuable, actionable content; that is what corporations are paying for. Schlickly delivered for maximum ROI. 'Community' conferences have their own trends, too. Talks about people, empathy, community, and how start-ups are changing the world. Community conferences are frequently an excuse to hang out with your internet mates. Which is fine, I guess.

My problem with both of these is I'm not sure I fit anymore. I'm not what you would call a slick presenter: I 'um' and 'ah', I swear, I get excited and stumble on stage in more ways than one. Some would say I'm disrespectful to the audience I'm talking to. I'm lazy with my slides, preferring to hand-write single words and the odd picture. I've never used a keynote transition. I'm not really at home amongst the world's corporate presenters who deliver scripted, rehearsed, beautifully crafted presentations. They're great and everything, but it's just not me. Not for the first time in my life, I don't quite fit.

And then there's the community conferences. I feel more at home here. Or at least I used to. This year, not so much. A lot of my friends in this industry just don't really go to conferences that much anymore. They have family commitments, work to do, and – frankly – just aren't that into getting pissed up in a night-club after some talks with 90% men. Younger men at that.

Time for something different

All of that may sound like I'm dissing the conference industry. That's not my intention, but more like a realisation that, after nearly ten years at speaking at events, I think it's time I had a little break. Time away to refresh myself, explore other industries that interest me like typography and architecture. Maybe an opportunity to present at one of these types of conferences would present itself; now that would be cool.

I know it's a bit weird me posting about this when I could quietly just not accept any invitations to speak. To be honest, I've been doing that for a little while, but not for the first time, writing things down helps me clarify my position on things. For a while I was angry at web conferences in general. Angry at the content, disappointed with speakers, disappointed at myself. Then I realised, like so many times before, that when I feel like that it's just that my 'norm' has changed. I'm no longer where I used to be and I'm getting my head around it.

It's just this time, I'm going to listen to my head instead of burying it two feet in some sand.

Laters.

]]>
<![CDATA[A Purple Princess]]> https://markboulton.co.uk/journal/purple https://markboulton.co.uk/journal/purple post Thu, 12 Jun 2014 00:00:00 +0000 When I told my eldest daughter, Alys, about Rebecca Meyer passing away, she wanted to draw her a purple picture. Rebecca was the same age as Alys and she knew ‘exactly what she’d like’. So, here it is:

A purple princess for Rebecca Meyer from Alys Boulton

A Purple Princess for Rebecca Meyer from Alys Boulton, Age 6

In memory of Rebecca, whose favourite colour was purple.

]]>
<![CDATA[My Handbook – Environment]]> https://markboulton.co.uk/journal/my-handbook-environment https://markboulton.co.uk/journal/my-handbook-environment post Thu, 05 Jun 2014 00:00:00 +0000 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.

]]>
<![CDATA[Ingredients]]> https://markboulton.co.uk/journal/ingredients https://markboulton.co.uk/journal/ingredients post Tue, 13 May 2014 00:00:00 +0000 Jeremy wrote something special yesterday. That’s not unlike Jeremy, but this blog post in particular struck a chord with me.

A couple of weeks ago, Google Chrome has toyed with the idea of removing most of the URL because it’s a “power user” feature in favour of a simple, easy to understand signpost of where the user is. Jeremy’s point is there is a deeper warning here of ease of use.

… it really doesn’t matter what we think about Chrome removing visible URLs. What appears to be a design decision about the user interface is in fact a manifestation of a much deeper vision. It’s a vision of a future where people can have everything their heart desires without having to expend needless thought. It’s a bright future filled with seamless experiences.

I read Jeremy’s post and kept re-reading it. My instant thought was of food.

I enjoy cooking – have done for a decade – and the more I do, the more I care about ingredients. Good produce matters. Now, I’m not talking about organic artisan satsumas here, but well grown, tasty ingredients; in season, picked at the right time, prepared in the right way. The interesting thing is most people who eat the resulting dish don’t think about food in this way. They experience the dish, but not the constituent parts.The same way some people experience music – if you play an instrument, you may hear base-lines, or a particular harmony. If you enjoy cooking, you appreciate ingredients and the combination of them.

But ingredients matter.

And they do of websites, too. And the URL is an ingredient. Just because a non-power user has no particular need for a unique identifier doesn’t mean it’s any less valuable. They just experience the web in a different way than I do.

Without URLs, or ‘view source’, or seeing performance data – without access to the unique ingredients of websites – we’ll be forced into experiencing the web in the same way we eat fast food. And we’ll grow fat. And lazy. And stop caring how it’s grown.

As Jeremy says: Welcome aboard the Axiom.

]]>
<![CDATA[A new beginning for Five Simple Steps]]> https://markboulton.co.uk/journal/fss-new-beginning https://markboulton.co.uk/journal/fss-new-beginning post Thu, 08 May 2014 00:00:00 +0000 I'm so happy to tell you that Five Simple Steps has been acquired by Craig Lockwood and Amie Duggan. The dynamic duo behind Handheld conference, The Web Is, FoundersHub and BeSquare. Before I tell you again how thrilled I am, let me take you way back to 2005...

Next year, it will be ten years since I wrote a blog post called Five Simple Steps to better typography. The motivation behind the post was simple: the elements of good typesetting are not difficult, and, with a few simple guidelines, anyone could create good typographic design. That one article became part of a small series of five posts: five simple steps, with each article containing five simple steps. It was a simple formula, but it turned out pretty well.

Soon after that initial post, I wrote Five Simple Steps to designing grid systems for the web, then the same for colour theory. This was now 2006 and I'd just left my job at the BBC. It was a dreary October day and, whilst sat in a coffee shop in Bristol after just visiting one of my first freelance clients, I was talking over email to the Britpack mailing list about compiling my posts into a book. In 2008, Emma and I hired my brother to help me design it and in early 2009, we finally released it. And with the release of that first book, Five Simple Steps Publishing was born. But we didn't know it at the time.

Over subsequent months and years other authors saw what we produced and wanted us to publish their books. Before we really knew it, we were a publisher with a catalogue of titles and providing a uniquely British voice to the web community. But publishing is tough. As we found out.

All over the world, publishers' profits are being eroded; from production costs to cost-difference in digital versions. And – except for a couple of notable companies – you see it in the physical books that were being produced for our customers by competitors: terrible paper quality, templatised design, automated eBook production. Everywhere, margins are being squeezed, and the product really suffers.

Our biggest challenge was that Five Simple Steps started as a side project, and always stayed that way. Over time, we just couldn't commit the time and money it needed to really scale. We had so much we wanted to do – there was never any shortage of great authors wanted to write a book – but could never find the time and energy when we had to run a client services business. Oh, and also during this time, Emma and I had two children. Running and growing two businesses is somewhat challenging when you're being thrown up on and have barely four hours sleep a night.

So about a year ago, Emma and I sat in our dining room and faced a tough decision: wind down Five Simple Steps, sell it, or give it one more year. We chose the latter. It was a tough year, but Emma, Nick and the team worked to make the Pocket Guide series a great success. So much so, it required tons of work and compounded the problem we had: Five Simple Steps needed to take centre stage rather than be a side project.

A month ago today, Emma and I announced that Five Simple Steps was closing. The team were joining Monotype, and Five Simple Steps could no longer be sustainable as a side project. The writing had been on the wall for a while, but the stop was abrupt for us, the authors and the team. We tried to find the right people to take the company forward before the sale, but we couldn't find the right people. Luckily, immediately following the announcement, a few people got in touch about seeing if they could help. Two of those people really said some interesting things and got us excited about the possibilities: Craig Lockwood and Amie Duggan.

Craig and Amie live locally in Wales. They run conferences: Handheld conference and The Web Is conference later this year. They also run a co-working space in Cardiff called FoundersHub. They have a background in education and training, and together with their conferences and BeSquare – a conference video streaming site – they have the ecosystem in place to take Five Simple Steps to places we could only dream of. As you may gather, we're chuffed to bits that Five Simple Steps is going to live on. Not only that, but it's in Wales and in the competent hands of friends who we know are going to give it the attention it deserves.

Emma and I can't wait to see where it goes from here.

]]>
<![CDATA[Conference speakers, what are you worth?]]> https://markboulton.co.uk/journal/what-are-you-worth https://markboulton.co.uk/journal/what-are-you-worth post Fri, 02 May 2014 00:00:00 +0000 Over the past couple of days, there have been rumblings and grumblings about speaking at conferences. How, if you're a speaker, you should be compensated for your time and efforts. My question to this is: does this just mean money?

I've been lucky enough to speak at quite a few conferences over the years. Some of them paid me for my time, some of them didn't. All of them – with the exception of any DrupalCon – paid for my travel and expenses.

When I get asked to speak at a conference, I try to gauge what type of conference is it. Is it an event with a high ticket price with a potential for large corporate attendance? A middle sized conference with a notable lineup. Or, is it a grassroots event organised by a single person. In other words, is it 'for-lots-of-profit', 'for-profit', or 'barely-breaking-even'. This will not only determine any speaker fee I may have charged, but also other opportunities that I could take for compensation instead of cash.

Back to bartering

When I ran a design studio, speaking at conferences brought us work. It was our sales activity. In all honesty, every conference I've spoken at brought project leads, which sometimes led to projects, which more than compensated me for my time and effort if it kept my company afloat and food on the table for myself and my team. The time away from my family and team was a risk I speculated against this. Conference spec-work, if you will.

In addition to speculative project leads for getting on stage and talking about what I do, I also bartered for other things instead of cash for myself or my company. Maybe a stand so we could sell some books, or a sponsorship deal for Gridset. Maybe the opportunity to sponsor the speaker dinner at a reduced rate. There was always a deal to be done where I felt I wasn't being undervalued, I could benefit my company, product or team, but still get the benefit of speaking, sharing, hanging out with peers and being at a conference together.

It's about sharing

If every speaker I knew insisted on charging $5000 per gig, there will be a lot less conferences in the future apart from the big, corporate, bland pizza-huts of the web design conference world.

My advice to anyone starting out speaking, or maybe a year or so in, is have a think about why you do it. If you're a freelancer, let me ask you: is speaking at a conference time away from your work, and therefore should be calculated as to how much you should charge based on your hourly rate? Or, is it an investment in yourself, your new business opportunities, and the opportunity to share. Of course, the answer to this is personal, and – for me – depends on what type of conference it is.

This community is unique. We share everything we do. We organise conferences to do just that. Most of the conference organisers I know come from that starting point, but then the business gets in the way. Most speakers I know, get on stage from that starting point, but then the business gets in the way.

There's nothing wrong with valuing yourself and your work. If speaking is part of your work, then you should be compensated. But next time you're asked to speak by a conference, just stop for a moment and think about what that compensation should be.

]]>