Clearleft | Blog The latest news from Clearleft en-gb Wed, 21 Aug 2019 13:30:04 +0000 Wed, 21 Aug 2019 13:30:04 +0000 Linear Interpolation Functions Wed, 21 Aug 2019 11:00:00 +0000 Linear Interpolation isn’t just for animation, it’s amazing for data manipulation and a worthwhile tool to have in your coding arsenal.

I wrote a blog post some months back on Linear Interpolation. It was a subject I knew very little about at the time, having not done a great deal of animation work. But now I know a little more, I’ve found it’s been one of those techniques I keep coming back to for most projects.

What I’ve learned is that interpolation isn’t just about animation, or even about visual things—it’s about data conversion.

Aside: that might sound a bit heavy or dry, but it’s how my brain works! I love how different coding concepts ‘click’ for different people in different ways.

Among more traditional animation-y things, I’ve used these techniques to calculate rotary dial positions on the guitar pedalboard, mapped usernames to fallback avatars on Daisie and plotted typographic graphs on a side project I’m currently building.

The four functions

const lerp = (x, y, a) => x * (1 - a) + y * a;
const clamp = (a, min = 0, max = 1) => Math.min(max, Math.max(min, a));
const invlerp = (x, y, a) => clamp((a - x) / (y - x));
const range = (x1, y1, x2, y2, a) => lerp(x2, y2, invlerp(x1, y1, a));

There’s a Typescript version at the bottom of the page, if you’re that way inclined.


A lerp returns the value between two numbers at a specified, decimal midpoint:

lerp(20, 80, 0)   // 20
lerp(20, 80, 1)   // 80
lerp(20, 80, 0.5) // 40

It’s great for answering gnarly maths questions like: “What number is 35% between 56 and 132?” with elegance: lerp(56, 132, 0.35). My maths skills aren’t all that, so it’s great to have these up my sleeve.

Here’s an example that converts a range slider set between 0 and 1, to a hsl() colour with hue degrees of 11 through 60.

See the Pen Lerp by Trys Mudford (@trys) on CodePen.


The clamp method is wonderfully dull. You give it a number and then a minimum & maximum. If your number falls within the bounds of the min & max, it’ll return it. If not, it’ll return either the minimum it’s smaller, or the maximum if it’s bigger.

clamp(24, 20, 30) // 24
clamp(12, 20, 30) // 20
clamp(32, 20, 30) // 30

It’s really handy for preventing absurd numbers from entering a calculation, stopping an element from rendering off screen, or controlling the edges of a <canvas>.

Here’s an example that lets you add or subtract 10 from the current number, but clamped between 0 and 100.

See the Pen Clamp by Trys Mudford (@trys) on CodePen.

Inverse Lerp

This works in the opposite way to the lerp. Instead of passing a decimal midpoint, you pass any value, and it’ll return that decimal, wherever it falls on that spectrum. Internally it also uses a clamp, so you never get unwieldy values back.

invlerp(50, 100, 75)  // 0.5
invlerp(50, 100, 25)  // 0
invlerp(50, 100, 125) // 1

This is great for scroll animations. Questions like “How far through this section has the user scrolled?” can be neatly answered with code like:

const position = el.getBoundingClientRect();
const howFarThrough = invlerp(,

Here’s an example that tracks the percentage scroll position of a target slab against the viewport.

See the Pen Inverse Lerp by Trys Mudford (@trys) on CodePen.


This final method is ace. It’s a one-liner that converts a value from one data range to another. That might sound a bit arbitrary, but it’s surprisingly useful. We pass in two data ranges and a value that sits within data range one (it will still be clamped).

//    Range 1    Range 2    Value
range(10, 100, 2000, 20000, 50) // 10000

Taking the previous example up a notch, let’s say that as the user scrolls through a section, we want to subtly move an element down the page by 150px. The section is in the middle of the document, starting at 3214px and ending at 3892px, and we want to convert window.scrollY from the big range down to a value between 0px and 150px. That’s a pretty nasty calculation to make, but range() makes it nice and clean.

const position = el.getBoundingClientRect();
const transformY = range(,

If the user is above the section, it’ll be clamped to 0px. If they’re below, it’ll be clamped to 150px. And in all positions in between, it’ll evenly interpolate between the values.

The final example takes the previous Codepen and maps the result against a transform: translateY range of -20% to 20%. Parallax, eat your heart out.

See the Pen Range by Trys Mudford (@trys) on CodePen.

Typescript version

const lerp = (x: number, y: number, a: number) => x * (1 - a) + y * a;
const invlerp = (x: number, y: number, a: number) => clamp((a - x) / (y - x));
const clamp = (a: number, min = 0, max = 1) => Math.min(max, Math.max(min, a));
const range = (
  x1: number,
  y1: number,
  x2: number,
  y2: number,
  a: number
) => lerp(x2, y2, invlerp(x1, y1, a));

This was originally posted on my website.

Practical tips in running your first diary study - pt.1 Mon, 19 Aug 2019 11:00:00 +0000 Trying research methods for the first time can be daunting. While it’s helpful to add new methods to your toolkit, it’s also important not to let the learning curve interfere with the results. Here are a few planning tips to get the most out of running your first diary study.

What is a diary study?

A diary study is a qualitative research method that records aspects of participants’ daily lives and environments over a designated period of time. Traditionally diary studies were recorded in a physical journal, but more recently mobile technology allows us to collect richer and more varied data points - photos, videos, short or long-form text, and geolocation. Typically an exit interview is conducted with a selection of participants at the end of the study to interrogate their entries and gain deeper insight into their experiences. If possible, this happens at their own home or workplace in order to gain further insight and capture additional data points.

Why conduct a diary study?

The success of any research study is underpinned by the methodologies selected to meet the research goals. When your research goals are to gain a deep understanding of people’s behaviours, experiences and surroundings over time, interviews and lab tests will only get you so far.

This is when a diary study is a good selection. It helps to tell the story of how products and services fit into people’s daily lives, and the touchpoints and channels they choose to complete their jobs.

Where ‘true’ ethnographic field studies require researchers to be embedded in the participant’s context making first-hand observations, diary studies require participants to self-select relevant moments and share them remotely through a mobile phone app. As you can imagine, these two methods require different amounts of resources and planning and can generate different results. Here are some reasons you might want to consider a diary study:

  • Remote participation allows for a broader geographic spread of locations.
  • Multiple research sessions can be run concurrently.
  • Costs are significantly lower than in-person field studies.

Diary studies can also be a resource-intensive method to setup and run. Here are some of our most useful learnings so you don’t have to learn them the hard way.

Evaluating tools

Having a reliable and easy-to-use tool for submitting and analysing diary entries is fundamental to a successful diary study. We recommend investigating the options available long before your study begins.

There are many digital diary study tools on the market, most of which offer a free trial or a demo. We highly recommend setting up a 1:1 call to run through the software and answer any questions you might have. Many have an example project to run through that will give you a feel for the study setup, entry monitoring and analysis features on offer. This is also your opportunity to talk about pricing if you are on a restricted budget.

Getting familiar with diary study software over a 1:1 video call

We’d advise getting your hands on a trial version and running a pilot study with your internal team. Doing this helps to weed out any problems you or your participants might have. You might want to consider:

  • Participant onboarding and app setup. How many hoops do your participants need to jump through to get started? Are participants able to get setup unaided?
  • Diary study entry submission. What is the experience like for the participant submitting entries? Does it allow for structured tasks and open entries?
  • Performance issues. What happens when battery saver mode is switched on? Does it work consistently on various devices, on both iOS and Android?
  • Administrator view. How flexible is the backend of the system? Can you layer additional data onto your participant profiles?
  • Analysis features. Does the software allow you to run any analysis? What is the export feature like?

A pilot study also helps to test your hypotheses and assumptions before you commit to the final study design.


Designing the study

With your pilot study complete and the most appropriate tool selected, you’ll be in a good place to design your study.

Designing how your participants submit their entries is a careful balancing act, and will ultimately cause a tradeoff:

  • Too many data points can be overwhelming. Too few can leave you frustrated.
  • Small and frequent entries can provide granular detail. Large infrequent entries can expose relationships and reflective stories, but require work to separate into individual data points.
  • Broad and unstructured entries can expose interesting unknowns but provide a shallow depth of insight. Narrow and structured entries may result in deep but biased results.


One useful technique we’ve used is to reserve a few spot tasks to be completed during the study. These give you a little bit of flexibility during the study to ask deeper questions around themes that begin to emerge. Tasks may involve replying to an email with questions about a particular diary entry, completing an online survey or a specific task or mission.

With your tasks agreed, it’s time to write a guide to onboard your study participants. This should set the expectations of the study clearly, written in a language they understand. Your friendly neighbourhood content writer will be pleased to help here; if your neighbourhood doesn’t have one, go out and find one, they’re awesome and indispensable!

Preparing the participants

With your study guide written and given the seal of approval by your new content buddy, it’s time to brief your participants.

At this point we’re going to assume you’ve properly screened your participants. They are being incentivised for their time and are willing to take part in a follow-up interview. They’ve also received your study guide ahead of the study start date.

Incentives will depend on the length of the study, the number, frequency and type of entries you require your participants to share. A quick way to validate your costs is to work out an hourly rate based on how long you expect your participants to be submitting entries for, over the course of the study. Ask yourself, “Would I go out of my way to contribute to the study for this amount?” If the answer is “no” it’s likely you’re participants will answer the same way. If you are using a recruitment agency they will be able to advise on incentive costs.

Checking in with participants before the diary study starts

The week before the study begins, it’s important to check-in with your participants to talk through the expectations of the research and answer their questions. Depending on your recruitment process this may be the first time you’ve been in direct contact with them, so think of this as the start of your rapport-building. A diary study often involves participants sharing personal aspects of their lives so showing you are trustworthy at this point will pay dividends during the study. With this in mind, we highly recommend doing this face-to-face if you can, or via a video call as an alternative.

Once the study has started, it’s easy to focus on participants that are less engaged, have technical problems or general questions.


We find it useful to write a couple of stock emails before the study begins, one to encourage less engaged participants, and another to reassure participants that are on track. Having these responses in reserve helps to free up time to do research instead of admin.

It’s inevitable that a small number of your participants will completely disengage during the study, so it’s worth recruiting a few extra participants to ensure you meet your target number of interviews. An early conversation with your client or stakeholder about this helps to avoid misunderstandings about the quality of the participants and your recruitment efforts.


Be mindful of when your study will be conducted and whether events around that time may cause unintended or unexpected behaviour.


Depending on your sample size and time constraints, you may want to consider splitting your participants into two or more groups, and stagger the study over a number of weeks. A staggered schedule helps to ease the intensity of monitoring diary entries, enabling you to avoid key dates for all of your participants e.g. public holidays. It also creates an opportunity to learn and adapt the study over a longer period of time.

If you are running staggered start dates, it’s a good idea to group participants by location and ensure they start and end the study at the same time. This will save you the headache later when trying to schedule home-visit interviews across multiple cities.


Diary studies are an effective way to gain deep contextual insight at a fraction of the cost of a true field study. They’re also a lot of fun to run. With the right amount of preparation you can reduce the time spent on admin tasks and participant hand-holding, and refocus your efforts on the research itself.

Here are our top 3 takeaways:

  1. Run a pilot study on the topic you are researching
  2. Design the study based on what you have learned (see 1)
  3. Prepare your participants with concise, understandable instructions
  4. Select the best dates for your study to run

Good luck with your diary study and happy researching!

This article is part of a series. We’ll give tips on what to do once your diary study is in motion in part two.

Tiny Lesson: The 20-second gut test Mon, 19 Aug 2019 10:22:00 +0000 We’ve written about this workshop before, and now you can consume it in video form.

Ah, the sweet smell of exploring a new project’s design direction. Often one of the most exciting parts of a project, it’s where stakeholders tend to show a lot of interest.

The visual side of design is something most people can relate to versus the abstract nature of user flows and journey maps. Yet this can be a double-edged sword. Visual design exploration can uncover strong opinions, yet stakeholders might not have the ability to articulate what they’re looking for in their future product or service.

This subjectivity can quickly eat into a project’s time and throw things off-course. Gaining rapid consensus of what the design style and direction will be is what the 20-second gut test aims to solve.

Keep reading if you need a more detailed breakdown.

What you’ll need

This workshop needs some prep, often up to half a day before you’re meeting your client. It’s important to get all stakeholders in the room for this one, so plan ahead to make sure they’re all present. The risk here is not having everyone’s voice heard, which could derail the design phase later on.

For materials you’ll need a keynote or Powerpoint deck (and make sure you have all the dongles for connectivity), printed score sheets, and sharpies.

The Pre-Prep

The preparation for this workshop involves a lot of hunting and gathering. You’ll need to have a good idea of your client’s industry, competition and aspirations - most of which will have been gathered in the research phases of the project.

Spend your half day collecting various screen grabs or clippings that best represent a broad spectrum of your client’s requirements. If you’re stuck for what to look for take a look at the original brief and start with the biggest brands that come to mind. Then work your way down from there.

Start screen-grabbing the obvious, aspirational designs. We like to aim for 20 strong candidates, but make sure you’re finding design examples that run the full spectrum - from high-end to some jokers. These jokers can provide a lot of insight… if you throw some really off-piste, whacky design styles in there, they’ll elicit a reaction, good or bad.

Try not to show just ‘screen design’ either. Show other things like interior design, architecture or movie posters. This is where your taste and curation abilities come in. What you’re aiming for is a strong range of design styles.

Next, add all 20 screen grabs into a keynote or powerpoint deck. For each slide, assign a letter from the alphabet, so first slide is A, second is B and so on. Make sure this is clearly placed on each slide.

For a nice touch add a 20 second delay to each slide (that’s where it gets its name), and auto-scrolling. This helps stakeholders see the screen grab in context versus just a quick snapshot.

The Workshop

With your stakeholders in a room, introduce what you’re going to do. At this point hand out a score sheets to each attendee.

These score sheets will have as many rows as your slides. Each row is assigned a letter of the alphabet, with a Likert scale showing a range of 1-5. 1 has the stakeholder strongly disliking the screen shown, and 5 has the stakeholder strongly liking.

Play on your deck. Your stakeholders will mark each screen with their preference. The 20 seconds for each slide enforces the most ‘visceral’ or ‘gut’ reaction to the aesthetics shown on-screen. It’s intentionally short and snappy.

Once finished, collect the sheets and quickly calculate the results. Use our handy spreadsheet (links provided below) to provide the average score and heat map for each slide shown.

A trick we do at Clearleft: quickly go back through the slides and change the colour of the top-ranked slides as the room discusses their likes and dislikes, as per the calculated averages. Being able to show the top- and bottom-ranked slides makes it easier to discuss their merits and, of course, why the group collectively ranked these as they did.

The Outcomes

The most important aspect of this workshop is the discussion at the end. The opinions around why the group collectively chose certain styles over others is what you need to establish a clear design direction.

Chances are you’ll be a lot closer to nailing the direction faster than simply exploring from scratch, plus it’s given your stakeholders a way to articulate what they like and don’t like.


Be sure to grab the scoresheet and results calculator to help you when running your next gut test workshop.

Leading Design New York talks Thu, 15 Aug 2019 15:54:33 +0000 We are thrilled to share the talks from the incredible design leaders who joined us on Wythe Avenue for the first Leading Design New York.

After three successful years in London, we decided to bring Leading Design to New York. A sell-out event which quickly amassed a waiting list of over 800. There is such a wealth of incredible content, inspiration and practical tools included in these talks which we know will be of huge value to you all and the wider design leadership community.

Once again a huge thank you to our amazing speakers:

Amélie Lamont on stage at Leading Design New York
Amélie Lamont on stage at Leading Design New York
Todd Zaki Warfel stirring up some honest moments on stage at Leading Design New York where audience are raising their hands
Todd Zaki Warfel stirring up some honest moments on stage at Leading Design New York

Leading Design New York 2019 happened with the support of our amazing sponsors. Many thanks to Google, InVision, Salesforce, Capital One, Mailchimp, Spotify Design and Def Method.

Leading Design London is now sold out, there are a few early bird tickets for San Francisco 2020, they are selling fast so do pick one up soon.

Clearleft launched Leading Design to help design leaders connect, learn and feel inspired by their peers. When working with leadership teams across the world, it became clear that everyone has the same challenges. We wanted to put together a unique programme of events to help tackle some of the most pressing challenges and create an all-too-rare opportunity to meet like-minded design leaders, swap war stories and build relationships to last the rest of your careers.

Have a look around our site to learn more about who we are, what we do and how we’ve worked collaboratively with other design leaders and businesses.

UX London 2019 talks Mon, 05 Aug 2019 14:08:00 +0000 Our 11th UX London saw three days of talks on designing products, designing for people and finally designing the future. There was much food for thought (and food to eat!), we wanted to share some of the talks with you.

Plus early bird tickets for UX London 2020 are on sale now.

Designing products

Day one was centred around designing products that deliver value to customers and your business. Thinking about how best to conceive user-centred products and bring them to market. We are very grateful for our speakers who challenged practice, process and team structure, you can watch most of these again here:

Andy Budd on stage launching UX London 2019
Andy Budd on stage launching UX London 2019

Designing for people

Day two was all about taking your customer experience to the next level and unlocking the power of user-centred design. We unearthed the often overlooked parts of service design and the best ways you and your team can develop powerful empathy with your users. Thank you once again to all our speakers, including these talks:

Erika Hall at UX London

Designing the future

We curated day three to allow us to explore the new tools, tech­nolo­gies, and inter­ac­tion trends shap­ing our future work. Where will the rise of AI take us? Are con­ver­sa­tion­al inter­faces the next fron­tier? How can we adapt to ever-changing consumer expectations? With thanks to our speakers who drew UX London to a close with big thinking, strong ethics and new models for us all to take forward:

UX London 2019 happened with the support of our amazing sponsors. Many thanks to Google, InVision, Balsamiq, Monzo, Futureheads and Spotify Design.

Tickets for 2020 have just gone on sale. UX London is a Clearleft event. Our team of industry-leading strategists, design thinkers, technologists and innovators work inside global brands to help design leaders get the most from their products, services & teams. Human-centred design is, and always has been, central to the Clearleft philosophy.

Have a look around our site to learn more about who we are, what we do and how we’ve helped others.

Principle Thu, 01 Aug 2019 14:36:00 +0000 I like good design principles. I collect design principles—of varying quality—at Ben Brignell also has a (much larger) collection at

You can spot the less useful design principles after a while. They tend to be wishy-washy; more like empty aspirational exhortations than genuinely useful guidelines for alignment. I’ve written about what makes for good design principles before. Matthew Ström also asked—and answered—What makes a good design principle?

  • Good design principles are memorable.
  • Good design principles help you say no.
  • Good design principles aren’t truisms.
  • Good design principles are applicable.

I like those. They’re like design principles for design principles.

One set of design principles that I’ve included in my collection is from government design principles. I think they’re very well thought-through (although I’m always suspicious when I see a nice even number like 10 for the amount of items in the list). There’s a great line in design principle number two—Do less:

Government should only do what only government can do.

This wasn’t a theoretical issue. The multiple departmental websites that preceded were notorious for having too much irrelevant content—content that was readily available elsewhere. It was downright wasteful to duplicate that content on a government site. It wasn’t appropriate.

Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand. Whether it’s task runners or JavaScript frameworks, appropriateness feels like it should be the deciding factor.

I think that the design principle from GDS could be abstracted into a general technology principle:

Any particular technology should only do what only that particular technology can do.

Take JavaScript, for example. It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering. It violates this principle:

JavaScript should only do what only JavaScript can do.

Need to manage state or immediately update the interface in response to user action? Only JavaScript can do that. But if you need to present the user with some static content, JavaScript can do that …but it’s not the only technology that can do that. HTML would be more appropriate.

I realise that this is basically a reformulation of one of my favourite design principles, the rule of least power:

Choose the least powerful language suitable for a given purpose.

Or, as Derek put it:

In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

ARIA should only do what only ARIA can do.

JavaScript should only do what only JavaScript can do.

CSS should only do what only CSS can do.

HTML should only do what only HTML can do.

This was originally posted on my own site.

Behind our recent business award Mon, 29 Jul 2019 15:45:00 +0000 We’ve won SME of the year in Brighton’s business awards! As one of our values is ‘share-learn, learn-share’, here’s an overview of some of the things we talked about in our entry.

We’re very lucky at Clearleft that our work and reputation often precedes us, but every now and then it’s nice to get recognition beyond our work on the way we approach business. When Carden’s Accountants put us forward for the Brighton and Hove Business Awards 2019, it seemed a nice opportunity to reflect on what makes Clearleft tick. We wanted to share this with you.

A bit of background

Since 2005 our purpose has been to advance the practice of design to transform organisations and people’s lives for the better. We’re a multi-disciplined team of designers, technologists and consultants with a worldwide reputation. Since 2005, we have helped over 100 clients in 5 continents embrace digital to become more efficient and competitive.

We use research, design and strategy to enable innovation, deliver products and services, build design capability and transform the design function of organisations. We were the first User Experience agency in the UK and have since grown to work with design leaders across a multitude of sectors including travel, education, healthcare, finance, government, retail and entertainment.

The events side of our business has inspired over 15,000 designers and leaders from across the globe in our London, New York and Brighton-based conferences, workshops and retreats.

Chris running a design sprint workshop in a large glass room at UX London
Chris and Jerlyn running a Design Sprint workshop at our 11th UX London conference

Challenges and change

Design is a serious, often significant investment taken from a capital expenditure budget. The more enlightened organisations are moving design out of cap-ex and into operational expenditure, but along with this comes a big challenge to design agencies – the emergence and growth of in-house design teams. Many of us are still used to a world where work is out there and we compete with other agencies to get it. Now those projects are being kept within the organisation, so, on the face of it at least, we’re also competing with in-house teams for work they might be better placed to do.

We believe that engaging an external agency is often the best approach to achieve effective (efficient) innovation, strategy and change, while in-house teams are best placed for ongoing business-as-usual iteration and improvement. Through our consultancy, we now work alongside emerging and established internal design teams to great mutual benefit.

Driven by a desire to improve and professionalise the design industry, we realised we were often supporting designers newly promoted into leadership positions. In response to this, we started our Leading Design Conference which has grown in a few short years to be a core part of our business, and a vibrant, supportive community in its own right.

A group of clearlefties sat at the board room table smiling
Some of the team at our Monday Morning Meeting

Making meaning

While turnover and profit are important, they are not our main drivers, the impact of the work we do is. We call this ‘meaningful work’ and we assess this as part of an annual staff survey.

The vast majority of our work is repeat business and referrals. This is not by accident, and not because we have a retainer-led business (quite the opposite). While we consider all of our work to be a partnership - we love what we do and we get emotionally invested in our clients’ products and services - we’re about transforming organisations so that, over time, they don’t need us any more.

At 30 people we’re modestly sized, and intentionally so, but we punch above our weight and often pitch alongside huge companies such as Deloitte and McKinsey, meaning we’ve been able to help many household names. We’re ambitious in this regard, but we’re always driven by our purpose of impacting businesses and people’s lives for the better, above any outright desire to maximise profit.

Consequently, we have loyal, motivated staff who love what they do and have the autonomy to do it in the best ways they see fit. We’re a local employer with an international reputation in our field, meaning we’ve invested in local talent, from taking on interns to continually developing our employees.

It’s also important for us to give back to the design and coding community, with our facilities at 68 Middle Street made available for free to grassroots meetups, and encourage staff to participate in and run community events for underrepresented groups, and lecture at universities and colleges.

Ben, Alis and Alex with Caraline Brown, Founder of the Brighton and Hove Business Awards

It was great to see past and current clients as finalists and winners in the audience. The event was a good moment to also reflect on how Brighton is now very much a destination for digital excellence and progressive business. As much as our clients and events span the globe, our HQ and hearts will always be here in Brighton.

Agile and design — How to avoid Frankensteining your product Wed, 24 Jul 2019 07:30:00 +0000 As digital designers these days, it’s typical to be working in an agile fashion.

You know the score: the features get specced. The scope defined. The product owner creates the user stories. You roll up your sleeves and dive in. It’s Sprint 1 and the team are already estimating, the PO is grooming the backlog like a pro. Smashing. If you’re the designer, this is also where you might feel like this:

Jon with his head in his hands text reading 'this is Jon'

Designers thrive on exploration. We aim to find the best creative solution for the problem at hand. Sometimes this exploration takes time… a resource not in great abundance on agile projects. As the project dives into features and stories, it’s easy to get stuck designing details, with no real understanding of the greater picture.


Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. It’s this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.

Exquisite corpse representing the masthead, body and footer of a website
Andy Thornton’s Exquisite corpse for 100 days project

Frankensteining occurs when products or services created using Agile become fragmented or disjointed. The fragmentation can lead to a lack of cohesion and vision, undermining the user’s experience.

Through the keyhole

Frankensteining occurs when products or services created using Agile become fragmented or disjointed. The fragmentation can lead to a lack of cohesion and vision, undermining the user’s experience.

There are many websites today that display this characteristic. You’ve noticed them yourself, consciously or not. Sites with headers that look nothing like the rest of the site. Pages in a booking flow that look and feel different from anything else in the same journey. These and many other examples are symptomatic of teams running agile; delivering continuously but lacking that integral zoomed-out view.

Design debt

One of the more sinister side-effects of Frankensteining is that of Design debt.

Technical debt is a term agilists are familiar with. It happens when developers cut corners to reach a goal or release cycle. They might take an ‘off-the-shelf’ solution to their problem versus doing it themselves. Each cut corner results in more time needed down the line to do it right. That more time equates to more money spent.

Design debt is tech debt’s evil twin. This debt occurs when a product’s design creeps away from its original roots. Like all debt, it will have to be repaid.

7 ways to make design and agile play well together

The fact is, Agile is here to stay. As a method for the efficient and effective delivery of digital products and services, it does the job and it does it well.

According to the 2019 State of Agile report, 97% of survey respondents stated their organisations practiced Agile development methods to some degree. 34% of that group said their organisations have been practicing agile for 3–5 years. 27% stated they’ve been practising for over 5 years.

Yet more than half (53%) of organisations using agile said their use of it was still maturing. This is likely due to design starting to take a larger share in the creation of many digital products and services.

Clearleft has been exposed to hundreds of internal teams, each using their own blend of agile, waterfall or a blend of the two. We’ve collected tips, tricks and insights to inspire other teams when trying to make design and agile play well together.

1. Use Sprint zero

Sprint zeros are common to developers, but designers don’t seem to use this pre-sprint enough. Starting before the actual work, designers can use Sprint Zero to better understand the product and its constraints.

2. Do a best first pass

Often in-tandem with Sprint Zero (or even preceding it), doing a best first pass can pay huge dividends later in an agile project.

Creating a high-level pass of your product allows designers to view the full size and extent of the project. Using all of the knowledge at your disposal at this stage you can better understand how the experience will stitch together. This will let you identify any gaps in the process, early.

A great way to do this: sketch lo-fi first passes of your product’s experience and align them in order on a large floor. Actually standing over your sketches to see how they flow together is highly under-rated!

3. Have a North star

A great way of reducing design debt: have a strong creative direction. This sets your North star, a term that’s apt as it maintains the direction of travel for a product team’s efforts. Setting a strong creative direction in a fast-moving agile project isn’t easy. You need to do just enough design without over-egging it. A great way of doing this is through something called element collages.

Element collage for the first Patterns day
Element collage for the first Patterns day

Element collages are a process we use often at Clearleft. They help kickstart the creative process without creating design debt. Element collages are mood boards of fictional and real-world UI elements. They let designers have free rein, quickly exploring new ideas and approaches. The collages solicit buy-in. They create a shared understanding of a design style and direction… without having to design any actual pages or features.

4. Get your Devs involved early

An under-rated but important tip (but your devs will appreciate it). With agile dependent on speed, there’s every likelihood for design decisions to be made without dev input. As the devs tackle your design approach, things can quickly grind to a halt, impacting the project as a whole.

Including your devs earlier in the design process lets them input into critical design decisions. It reduces risk and surprises, and lessens technical and design debt down the line.

5. Work in swim lanes

At Clearleft we prefer staggered starts for each discipline on a project, moving in parallel, like swim lanes. Keeping UX & Design at least a sprint ahead of development affords more freedom for design.

This staggered approach could be misconstrued as being a bit waterfall-y. And you know what? It is, and that’s not always such a bad thing!

6. Always zoom out

Zooming out at set intervals during a project sounds easy. Yet when you’re in amongst the weeds and designing the small details, it’s easy to forget.

At Clearleft we build zoom out points into each sprint. Similar to conducting a ‘best first pass’ this gives the whole team the opportunity to stop and review where things are and how they fit together.

The login screen designed and developed in Sprint 1 might not look anything like the account screen in Sprint 12. Being able to zoom out and take stock can pay dividends for reducing the Frankensteining of a digital product.

7. Keep 10% time

One of the most important lessons we’ve learnt over the years is to block out (and defend) 10% of every sprint’s time for fixing design bugs.

Building in 10% of time per sprint to seek, find and fix design issues works to improve the cohesion and experience of your product or service. This is where your Project Manager earns their keep. PM’s will need to fight extra hard to ensure designers have the time they need to refactor any design… just as developers are able to refactor code.

pie chart showing many different agile methodologies
No one knows what they’re doing

A post agile world

We’ve already started seeing signs of clients, organisations and agencies using parts of agile that work for them and discarding the rest. The diagram above shows that everyone is, in effect, winging it, using Agile as they need it. Apt, seeing as the agile manifesto always stated that it’s about “people, not process”.

As design gets more embedded into the fabric of the products we use today, as creators we must change our mindset. We need to champion design methodologies and design thinking in agile practice. We need to focus less on ‘shipping’; instead on creating unified experiences that benefit our customers more than our internal processes.

At the end of the day, your customers, your users, the humans who interact with your product or service… they don’t care how your product was made. They only want a great experience that lets them fulfil a task.


This article was originally published at

Patterns Day video and audio Tue, 23 Jul 2019 12:03:00 +0000 If you missed out on Patterns Day this year, you can still get a pale imitation of the experience of being there by watching videos of the talks.

Here are the videos, and if you’re not that into visuals, here’s a podcast of the talks (you can subscribe to this RSS feed in your podcasting app of choice).

On Twitter, Chris mentioned that “It would be nice if the talks had their topic listed,” which is a fair point. So here goes:

It’s fascinating to see emergent themes (other than, y’know, the obvious theme of design systems) in different talks. In comparison to the first Patterns Day, it felt like there was a healthy degree of questioning and scepticism—there were plenty of reminders that design systems aren’t a silver bullet. And I very much appreciated Yaili’s point that when you see beautifully polished design systems that have been made public, it’s like seeing the edited Instagram version of someone’s life. That reminded me of Responsive Day Out when Sarah Parmenter, the first speaker at the very first event, opened everything by saying “most of us are winging it.”

I can see the value in coming to a conference to hear stories from people who solved hard problems, but I think there’s equal value in coming to a conference to hear stories from people who are still grappling with hard problems. It’s reassuring. I definitely got the vibe from people at Patterns Day that it was a real relief to hear that nobody’s got this figured out.

There was also a great appreciation for the “big picture” perspective on offer. For myself, I know that I’ll be cogitating upon Danielle’s talk and Emil’s talk for some time to come—both are packed full of interesting ideas.

Good thing we’ve got the videos and the podcast to revisit whenever we want.

And if you’re itching for another event dedicated to design systems, I highly recommend snagging a ticket for the Clarity conference in San Francisco next month.

This was originally posted on my own site.

What is UX writing and why does it matter Fri, 19 Jul 2019 07:30:00 +0000 It’s hard to talk about UX writing without mentioning content strategy and content design. The roles overlap – so before I go too far, I’ll quickly share my definitions.

Content strategists decide what to say and how to say it in order to help users complete tasks, find information, or make a decision (it might also include when and where to serve the content). This could be anything from defining how we speak (tone and voice), the format, the substance and the structure of the content. They also work out to how we get the content live, govern it, and what best-practice looks like (content creation, roles and workflows, guidelines and tools).

Content designers define how we format, structure or phrase our content in the right way for the user. Content designers may also be defining strategies and frameworks, or they might work to predefined ones (often created by a content strategist).

The terms UX writer and content designer are often used interchangeably because the roles are really similar.

UX writers often focus more on the copy we use to interact with users – and therefore the experience we provide through the customer’s journey. The role is sometimes known as product writing, which stems from the tech world where the software UI often is the ‘product’.

As you’d expect from the job title, they are writing the copy to create the optimum user experience. But this isn’t just in the UI, it could cover emails, web pages and any other user touchpoint. The goal of a UX writer is to make sure an end to end experience feels like it’s in the same voice throughout – the voice of the brand.

Copy might seem like something that could be picked up by a product designer or UI designer. But creating copy that’s concise and consistent, provides support, sets user expectations, and compels users to progress through their journey (while all feeling like it’s from the same brand), is really hard. Even for a UX writer. This also has to be done in as few words as possible – a button label, for example, may be just one word.

A screen asking - how much do you think about content?
How much do you think about content? Is it an after thought?

So what comes first, the copy or the UI?

I’m glad you asked me this. In an ideal world, they’d be co-designed. As Jared Spool said “Our users don’t separate our design from our content. They think of them as the same. So why don’t we?”

Knowing what you need to say and how to say it before creating a user interaction makes sense. UX writers often think about the natural conversation you’d have if no graphical interface existed, in order to determine what the copy should be (and how it might sound from the brand they’re writing for). Here’s an example:

When you need to know someone’s name, in real life you’d just ask “what’s your name?” and you’d get an answer – simple. But for an onscreen interaction there are so many other considerations:

We need a field for the user to supply their name but we also need to think about:

  • Do we capture first name and surname separately or all in one field?
  • Do we also need their middle name and title?
  • Should this be a simple data field or can we maybe capture it inside a conversational form? How would this brand do it to build rapport?
  • If the user doesn’t answer we’ll need a way to prompt a response
  • If they do answer but they provide numbers instead of letters we need a way to tell them that their entry isn’t correct
  • What if there’s a system error and the page submission fails? We’ll need to tell the user what’s happened and what to do next

That’s a lot of copy considerations for just one piece of data, and in fact that’s why UX writing is more akin to design than to copywriting. A lot of what UX writers do is problem-solving. When a UX writer works alongside a UI designer, it means the writer can think about the words in the context of solving this problem, then the designer can focus on what the interaction looks like and how it will work.

When a UX writer and UI designer don’t work together and the words are ‘put in later’, the UX writer becomes restricted by the interaction that’s been determined. The best efficiencies (and end results) come from co-designing.

Two examples of Slack's instantly recognisable brand voice
Your brand voice that should be instantly recognisable as you (like Slack here). But the tone you take will depend very much on the situation.

How UX writers add value to teams

At Clearleft’s recent mini-conference, I spoke a lot on this subject, in fact, I named my talk ‘taking your content from zero to hero’ because the benefits that writers bring are so important. Here are the main ones:

Realistic testing

Often prototypes are built with placeholder copy and then tested with users. Sometimes the purpose of testing is to validate the usability of a design, and sometimes it’s to test a product concept. Either way it’s unlikely that you’ll get realistic results with placeholder copy or copy that might contain typos or mistakes (trust me, participants get really hung-up on typos!).

A UX writer makes sure your copy is accurate and reflective of the product and brand before you run these tests.

Elevating designs

Visual design is always elevated by great content. When the copy reflects the brand values and the brand voice, it builds trust for users as they move through their journey. John Saito from Dropbox explains why this is important.

…if an actor does something that seems out of character, your audience will immediately notice and it breaks the scene. It’s the same way with writing. If your user suddenly reads a line of text that sounds unlike anything else in your product, it breaks the experience and makes your user start doubting you.

John Saito

With UX writers ensuring everything they write reflects the voice of the brand – it’s one less thing for the UI designer to worry about.

Good copy also makes sure you get high quality output – stakeholders reviewing designs don’t get hung up on typos or bad copy, and will actually focus on the design as a whole (you’d be surprised how many stakeholders are frustrated writers and use any mistake they spot as their opportunity to shine!).

Getting the tone right

The tone you use at certain points of the journey is probably even more important than reflecting the voice of the brand.

An error message is no time to dial up your brand ‘voice’, it just needs to be simple and helpful. A welcome message, on the other hand, can be much more enthusiastic and punchy. UX writers know when to dial tone up and down – making sure it’s appropriate to the scenario. Language might seem like a ‘fluffy’ thing, but how a brand makes the user feel can be the difference between a sale or a repeat purchase.

Improving conversion

The final (and some would say) most important role of a UX writer is to make sure that the copy they write sells products or retains customers. They want to build trust, reduce friction, and compel the user to do what’s intended. Often when a company has conversion problems, simple copy tweaks can have a huge impact, avoiding the need for expensive redesign projects.

A framework for deciding how to flex your brand's tone
If your brand has a very distinctive tone of voice it’s good to use some kind of framework to help you recognise when to dial it up or not.

Five quick ways for designers to think more about content

Great brand experiences often come down to how you feel about a brand, and that’s because they speak to you in a way that’s relevant, have simple and easy-to-use digital products, and compel you to buy from them. From AirBnB, to Boden, to Facebook or Headspace, successful companies are those that realise the importance of content and copy. Great content is tricky to achieve, and why it’s so important to employ a UX writer.

If you don’t have a UX writer on your team, here are five quick tips for designers to think more about content:

  • Have a purpose: what are you trying to get your user to think, feel or do?
  • Think about tone: Does your copy sound appropriate to the situation and how your user might be feeling?
  • Consider accessibility needs: make sure your sentences are short, you write in plain English and you format your content simply.
  • Think conversationally before you start designing: if you didn’t have a graphical interface how would you sell your product or service?
  • Consider your word choices: think nouns for navigation labels, and verbs for call to action labels. They should all be clear and unambiguous.

If you have any questions at all about content or UX writing, I’m always happy to discuss a challenge so get in touch.

Service design heuristics Thu, 18 Jul 2019 09:13:00 +0000 In the digital community, with the emergence in recent years of lots of digital product teams, we can sometimes be guilty of losing sight of the fact that nearly all of these ‘digital products’ are part of broader service offerings.

In fact, in 2017, services accounted for 79% of the UK economy. If you think about it, all of us from the moment we wake up in the morning rely on services, for everything. Your water, the gas to heat it, the online bills to pay for it, the bank that looks after your money and the companies which handle those bill payments. To a user, a service is simple. It’s something that helps them to do something - like learning to drive, watching Game of Thrones or going on holiday. But from the inside, it is not so simple. From our experience, here are four principles for successful service design.

Work across multiple touchpoints

So firstly one of the key premises behind service design is that it needs to work across all touchpoints. And by touchpoint we mean any interaction that a customer has with your brand, whether it be via your website, app, person to person or a form of communication. However, In order to provide a joined-up experience, it’s critical that an organisation’s channels are connected and integrated.

Imagine a call centre agent, that is up to speed with last week’s online live chat conversations and that can immediately jump in and help without you explaining the situation. Or a shop assistant, that can there and then, order your items online if they are not available in-store.

So consider…

  • Does a customer have to provide the same info multiple times?
  • Is data and inference carried seamlessly from one part of the service to another?
  • Does the service look and feel like one service throughout - regardless of the channel it is delivered through?

Meet everyone’s needs

Secondly, all these touchpoints need to meet everyone’s needs - and by everyone that we mean everyone that plays a role in that service whether that be customers or employees.

I think we’d all agree that the services and products need to address a real need and the success of any customer engagement is determined by the quality of its customer experience. The role of the organisation is, however, a critical its role is to support the service effectively, with its shape and structure built and adapted to suit.

However, particularly in an established organisation, with large amounts of legacy, it’s all too easy for the organisation and its internal processes to be overlooked, with new services built on top of slightly dysfunctional operations. However, when backstage organisational problems exist, they have frontstage consequences: poor service, customer frustration, and inconsistent channels. Streamlining backstage processes is critical. It improves the employees’ experience, which, in turn, allows them to create a better user experience.

So consider…

  • Does the service support and balance the demands of all user groups?
  • Does the employee experience enable them to support the service and its customer’s needs in the best way possible?
  • Is the organisation’s shape and structure built to suit the needs of the service?
Front stage back stage diagram of service design
All these touchpoints need to be meet everyone’s needs. And by that we mean everyone that plays a role in that service.

Build a lasting relationship

Thirdly once you have customers on the service you need to build a lasting relationship with them, shifting to focus on retention rather than pure acquisition.

There are a number of different tactics that can be used to build these emotional connections:

  • Provide graceful entry and exits: Simply providing flexible, natural entry and exit points to and from the service, enabling users to come back and finish things or update information. For example, when booking a holiday, you don’t need everyone’s passport details to book, you can go back and add the additional passport details at a later date.
  • Encourage interaction: Encourage users to engage with your service and tailor it for their needs. Simple things like building you regular lists in a grocery site or entering your home or work address in Google Maps.
  • Learn, enhance and tailor: Learning about the user usage habits and use this knowledge to enhance their experience. Strava, for example, uses your historical data to show performance trends over time, if you left the service you’d lose all of this data on previous rides and runs.

On a more strategic level, discount-based loyalty schemes have been around for decades. However, organisations are starting to adapt the model to reward the right type of behaviour. Last year, Sainsbury’s shelled out £60m to take full ownership of the Nectar reward scheme and have started to redesign it to give customers points based not just on how much they spend, but also how frequently they shop and how long they have been a customer.

So consider…

  • Can a user come back and update information?
  • Can a customer personalise the service and tailor the experience to their needs?
  • Can the service learn about the user and use this information to enhance the experience?
  • Can the service foster more of an emotional connection with the customer?
  • Can the service consider rewarding loyalty?
Strava dashboard - building loyalty in digital service design
Strava uses your historical data to show performance trends overtime

Aid speedy recovery.

Finally, it is important to consider all scenarios when designing, not only the ideal. One of the key ideas behind service design is that special (abnormal) events are treated as common events. NatWest, for example, have designed a service that allows customers to get money out of a machine even if they have left their wallet at home or if you report a fault with your broadband to BT, they will send you a Mini Hub at no extra cost to use until your fault is fixed. The Mini Hub is also designed to fit through your letterbox so you also don’t need to wait in for it.

So consider…

  • Do the customer know what they should do next if they were unable to complete a task?
  • Does the customer know what to do if there is some sort of disruption or special event?
  • What abnormal scenarios might affect your service, and how might you deal with them?

So these are four key principles, which can be used as both an evaluative tool and a generative tool when thinking about service design. Obviously using these heuristics to identify problems and opportunities is only the first step. Making changes is the next step and this can involve joining up technologies, aligning KPIs, metrics and accountabilities, and forming alliances between departments. It can take a lot of persistence and above all political will. But if you haven’t identified where the problems or opportunities lie, you can’t fix them. So important to take this first step.

Systematised design - glossing over confusion Fri, 12 Jul 2019 09:30:00 +0000 Whilst chatting design with some friends earlier this year I had a moment of clarity (born of confusion) - we were 3 good friends, peers with similar industry experience, talking the same language, about the same things, but our definitions and understandings of those things were quite different.

This got me reflecting on various similar conversations that we at Clearleft have had with clients and the wider community, and that as an industry we use lots of different labels - design system, pattern library, style guide et al - but often there are different understandings and interpretations of these things.

So, what follows is an attempt to add a little clarity to some of this confusion - a glossary of sorts -

Systematised design

When we talk about design systems, pattern libraries, component libraries et al, it’s important to remember that they are all products of and methods of, communicating and delivering systematised design:


There are 2 primary reasons for designing in a systematised way:

  1. To save you time e.g. re-using a component or thing
  2. To make things more consistent e.g. design, content, code

There are plenty of examples of systematised design working well, but no matter how shiny and aspirational the end result, all of these examples are based on the principal of modular, reusable and scalable design - it’s at the core of all systematised design.

Systematised design in the wild


These are the guiding principles for design, content and technology - they define and have the greatest overall impact on the system as a whole. If you were constructing a building, fundamentals would be the base materials and approach that you take - will you use wood, bricks, concrete? What typeface, colours and tone of voice will you use for your product? What’s the purpose of the building - what will go in it? What’s the primary purpose of your product? These are things you want to get aligned as early on as possible.

Fundamentals - the guiding principles for design, content and technology

Stuff in the middle

When you start to combine and extend fundamentals, you get elements & components. I won’t go into too much detail here as there are different ways to approach and break these things down - Brad Frost’s Atomic Design is a good place to start - so for now, let’s call this ‘stuff in the middle’ - the sum of combining various fundamentals in certain ways.

The stuff in the middle is essentially the small parts of a system - these can be assembled and reused anywhere in a system, but they exist independently, of each other and don’t really function until assembled into larger groups. These are the buttons, search forms, headers of your product - the windows, doors, rendered walls of your building. In isolation, these small parts don’t do much, but together they start to have function and meaning.

Stuff in the middle - small objects, groups of elements, based on fundamentals

Pattern library (a.k.a component library)

Granted this seems like a big step from ‘stuff in middle’, but a pattern library is really just a catalogue of components and elements - the warehouse of prefabricated building parts. You can visit, collect the items you need and then combine them into something with a specific function. In the digital world, a pattern library exists in code, in a single location, and is accessible by everyone who needs access to it on a shareable url.

Pattern libraries are living things - they need to expand and grow, adapt and iterate alongside your business, team and user needs. For some organisations, a pattern library is enough - they can contain all the components needed to build a product, without having any more function than simply providing a place in which to organise those components.

But a pattern library crucially does not contain the information on how to combine components - it’s not a blueprint.

Pattern library - an organised collection of components,
 a.k.a Component library

Templates and pages

In order to see the structure and context of how individual components and patterns combine into larger groups, a reference is needed. Enter templates and pages - the individual room blueprints of systematised design.

Essentially a template is an organised container - an arrangement of empty-state components - whereas a page is really a template populated with actual content. Templates and pages are visual and often coded, and they provide relevant examples of the things you are trying to build. Whilst you don’t need templates and pages to have a functioning pattern library, without some kind of reference like this how do you know how everything fits together?

Templates & pages - components assembled into 
structures and larger groups


Styleguides, technical documentation, content guidelines, implementation guidelines - these are the detailed architectural notes of the system. Guidelines use written language and diagrams to define and communicate the purpose of a system.

Amy Hupe, Content Strategist at GDS says that…


This is precisely where guidelines and documentation comes in - these can be used to describe any part or focus of a system, anything to help communicate shared understanding and consistency.

So, what happens when you start to combine a coded library of patterns, usage examples and detailed documentation?

Guidelines - definitions of what goes into our products and how they fit together

Design system

The single source of truth, the holy grail (or not) - this is the entire architectural project. A design system packages up all the previous items and provides a location for anyone involved in a project to go and extract the information or parts that they need, enabling teams to design, realise and develop a product.

Crucially, a design system incorporates the shared language and vocabulary needed for everyone to have context of, and work with, its contents. This is the structure for all of your design, helping to make sense of seemingly nebulous parts.

Design systems are also living things - they need to grow, be refined alongside, and in response to business, user and team needs. In order that this can happen, they need experienced and enthusiastic people to maintain and govern them and to help train others in how to use them. Architects don’t just drop all the plans on the build team, cross their fingers and hope for the best - they work closely with them, shaping, refining, overcoming issues and iterating as the building takes shape.

Design system - the single source of truth which groups together elements that allow teams to design, realise and develop a product

The onion

It’s important to remember that all of the aforementioned are not part of a linear process, and whilst some have dependencies on others, they often don’t happen in ‘order’.

This diagram doesn’t represent size or dependancy, more layers of an onion - peel each layer away and you’ll find related layers, but these are no more or less important than each other - they are all part of the whole.

The onion - layers of systematised design

So, a quick reminder of the glossary (from the middle of the onion):

  1. Fundamentals - the core of any system, the base materials and approach you take eg typography, tone of voice, bricks, wood

  2. Stuff in the middle - the combined fundamentals, the elements and components of the system eg buttons, search forms, windows & doors

  3. Pattern library - an organised catalogue of components and elements, a warehouse of prefabricated building parts

  4. Templates and pages - the reference of how the ‘stuff in the middle’ fits together, the room blue prints

  5. Guidelines - the documentation of how to use a system, the detailed architectural notes

  6. Design system - The package of all of the above - the entire architectural project

Lastly, it’s not about the label

Whilst a good understanding of these labels and definitions can go a long way, it’s ultimately not these that will be the success of any given system or project. Back to the 2 primary reasons for designing in a systematised way - to save you time, and to make things more consistent - both of these reasons rely on a shared understanding and communication, and are label agnostic. It’s about what you can gain by having the most appropriate thing for you, it’s not about what the thing is called.

So, when you’re about to tackle your next project (or are even in the process of assessing your current one), consider this -


Hopefully this little glossary will have ironed any confusion you might have had, but if you’d like to chat about any of this, or about how it might be of help to you or your team, please drop me a line -

Crazy Eights Thu, 11 Jul 2019 09:30:46 +0000 I have a toolkit, a UX toolkit.

Over the years I have collected methods, I’ve used them, tested them and broken them. Depending on where I am in the design process and the problem I am trying to solve I might lean on one to help.

Cue Crazy Eights. Crazy Eights is a core Design Sprint Method. This technique is best used within the ideation stage where ideas should come quicker since you have insights to draw upon. The purpose is to generate a number of different ideas within a short period of time. You ought to end up with one or a small number of ideas which can then be turned into a prototype. In order to find out the best answer or solution to your initial question or problem, it is important to test the idea with real users.

There are certain methods that need design knowledge but this isn’t one of those. This technique can be run individually but it’s also a great tool to get the entire team involved in:

For design to succeed and thrive in an environment of rapid iteration and intense measurability, it needs to involve non-designers intensively.

Here’s how it works if you run it with your team:

  • Stock up on A3 paper, pens, coloured dot stickers or coloured pens.
  • Assign someone to be the timekeeper so you are not distracted by the clock.
  • Fold the paper into 8 different sections.

The facilitator sets a timer for a short amount of time, this is up to your discretion. You can set the timer for six minutes (45 seconds on each sketch) or even four minutes (30 seconds on each sketch). I tend to use eight minutes for this exercise; a minute per sketch.

Silent sketching

It’s important to remind participants that these sketches do not need to be perfect. The sketches should be rough. The purpose of the exercise is to generate a variety of ideas. To put people at ease, show some examples to set the expectations for the quality of sketches.

Sketch example

Set the timer and ask the participants to start sketching. The facilitator should prompt them to start a new sketch every minute. Emphasize that they shouldn’t limit themselves. Make sure they get all their ideas out and approach this with an open mind. At this stage it is about the quantity of ideas, not the quality. It is normal for participants to feel rushed. It’s part of the process.


Time for feedback

When the eight minutes are up, you should have a collection of ideas. Some unexpected, some weird, some that just might work. Each participant then presents their top three ideas to the rest of the team for feedback.

Dot voting is a handy tool where each team member votes for ideas, usually 3 votes each. Together, evaluate the set of ideas. Make sure they don’t judge during this period. Apply a “yes, and…” rather than a “no…” or “yes, but…” mentality.

Dot voting

Depending on time, you could run another round of eight sketches building upon one another’s ideas. Then come back together and select the ideas that answer the design challenge in the most interesting way. The chosen ideas can then be worked on and perhaps made into a prototype to test.


This is a great technique to get team members to work collaboratively in a cost-efficient way. I often use this technique if I have a limited amount of time and want to get all of my ideas out without filter.

Great ideas can come from anywhere, even in under 8 minutes.

Patterns Day Two Tue, 02 Jul 2019 11:08:00 +0000 Who says the sequels can’t be even better than the original? The second Patterns Day was The Empire Strikes Back, The Godfather Part II, and The Wrath of Khan all rolled into one …but, y’know, with design systems.

If you were there, then you know how good it was. If you weren’t, sorry. Audio of the talks should be available soon though, with video following on.

The talks were superb! I know I’m biased becuase I put the line-up together, but even so, I was blown away by the quality of the talks. There were some big-picture questioning talks, a sequence of nitty-gritty code talks in the middle, and galaxy-brain philosophical thoughts at the end. A perfect mix, in my opinion.

Words cannot express how grateful I am to Alla, Yaili, Amy, Danielle, Heydon, Varya, Una, and Emil. They really gave it their all! Some of them are seasoned speakers, and some of them are new to speaking on stage, but all of them delivered the goods above and beyond what I expected.

Big thanks to my Clearleft compadres for making everything run smoothly: Jason, Amy, Cassie, Chris, Trys, Hana, and especially Sophia for doing all the hard work behind the scenes. Trys took some remarkable photos too. He posted some on Twitter, and some on his site, but there are more to come.

Me on stage. Inside the Duke of York's for Patterns Day 2

And if you came to Patterns Day 2, thank you very, very much. I really appreciate you being there. I hope you enjoyed it even half as much as I did, because I had a ball!

Once again, thanks to buildit @ wipro digital for sponsoring the pastries and coffee, as well as running a fun giveaway on the day. Many thank to Bulb for sponsoring the forthcoming videos. Thanks again to Drew for recording the audio. And big thanks to Brighton’s own Holler Brewery for very kindly offering every attendee a free drink—the weather (and the beer) was perfect for post-conference discussion!

It was incredibly heartwarming to hear how much people enjoyed the event. I was especially pleased that people were enjoying one another’s company as much as the conference itself. I knew that quite a few people were coming in groups from work, while other people were coming by themselves. I hoped there’d be lots of interaction between attendees, and I’m so, so glad there was!

You’ve all made me very happy.

Thank you to @adactio and @clearleft for an excellent #PatternsDay.

Had so many great conversations! Thanks as well to everyone that came and listened to us, you’re all the best.

— (@dhuntrods) June 29, 2019

Well done for yet another fantastic event. The calibre of speakers was so high, and it was reassuring to hear they have the same trials, questions and toil with their libraries. So insightful, so entertaining. — Barry Bloye (@barrybloye) June 29, 2019

Had the most amazing time at the #PatternsDay, catching up with old friends over slightly mad conversations. Huge thanks to @adactio and @clearleft for putting together such warm and welcoming event, and to all the attendees and speakers for making it so special ❤️

— Alla Kholmatova (@craftui) June 29, 2019

Had such an amazing time at yesterday's #PatternsDay. So many notes and thoughts to process Thank you to all the speakers and the folk at @clearleft for organising it. ♥️

— Charlie Don't Surf (@sonniesedge) June 29, 2019

Had an awesome time at #PatternsDay yesterday! Some amazing speakers and got to meet some awesome folk along the way! Big thanks to @adactio and @clearleft for organising such a great event!

— Alice Boyd-Leslie (@aboydleslie) June 29, 2019

Absolutely amazing day at #PatternsDay. Well done @adactio and @clearleft. The speakers were great, attendees great and it was fantastic to finally meet some peers face to face. ❤

— Dave (@daveymackintosh) June 28, 2019

Had a blast at #PatternsDay !!! Met so many cool ppl

— trash bandicoot (@freezydorito) June 28, 2019

I’ve had a hell of a good time at #PatternsDay. It’s been nice to finally meet so many folks that I only get to speak to on here.

As expected, the @clearleft folks all did a stellar job of running a great event for us.

— Andy Bell (@andybelldesign) June 28, 2019

Patterns Day is an excellent single-day conference packed full of valuable content about design systems and pattern libraries from experienced practicioners. Way to go @clearleft! #PatternsDay

— Kimberly Blessing (@obiwankimberly) June 28, 2019

Round of applause to @adactio and @clearleft for a great #patternsday today

— Dan Donald (@hereinthehive) June 28, 2019

Big thanks to @adactio and @clearleft for a fantastic #PatternsDay. Left with tons of ideas to take back to the shop.

— Alex (@alexandtheweb) June 28, 2019<

@adactio thanks Jeremy for organising this fabulous day of inspiring talks in a such a humane format. I enjoyed every minute of it #patternsday

— David Roessli (@roessli) June 28, 2019

An amazing day was had at #PatternsDay. Caught up with friends I hadn’t seen for a while, made some new ones, and had my brain expand by an excellent set of talks. Big hugs to @adactio and the @clearleft team. Blog post to follow next week, once I’ve got my notes in order.

— Garrett Coakley (@garrettc) June 28, 2019

This was originally posted on my own site.

Why your design system should include content Mon, 01 Jul 2019 12:35:00 +0000 As people, our voices are as distinctive and unique to us as our appearance. The same is true for brands. Content – or what and how we communicate as a brand – is as important as the look and feel in defining a user’s experience.

The role of content experts in a business (content strategists, UX writers or content designers), is to ensure that all customer-facing content and copy feels like it’s from the same brand. This includes the tone of voice, but also the words and language used throughout the user journey.

Setting out a content design system is one way to achieve this.

A missed opportunity

A design system is an established way to collate replicable elements, patterns, tools and guidelines, to make sure anyone designing for a brand does so consistently. These are becoming common for visual design, but the missing and vital part is often content and copy and how it’s used within the elements, which really is a missed opportunity.

Instead of content design systems and visual design systems existing in isolation, the ideal is one design system that accommodates everything, marrying the content and design together in the way it will actually be used and experienced.

There are many good reasons to do this, not least because the two disciplines will never be used separately.

Combining them ensures that design components are based on realistic content, avoiding constraints later on.

When there’s a limited number of UX writers on a team (the content:design ratio is often at least 1:2), having copy guidance built into a design system also means UI designers can make educated content decisions and work more efficiently.

Taking Thierworld's brand guidelines into content - colourful imagery and colour blocks with hex codes
Taking our client Thierworld's brand guidelines into content

Design systems which have successfully incorporated content:

Polaris by Shopify is probably one of the most comprehensive guidelines I’ve seen. It includes everything from voice and tone, how to name things, and even how to create alt text. Within the visual component library there are also content guidelines on how to write the microcopy that sits within each component. This is no lightweight design system. In fact, it’s epic.

Bulb’s design system Solar is much more lightweight. It includes some good UX writing principles and some specific labelling guidance for CTAs. And it’s a good example of how including some basic content frameworks can empower designers to make better design decisions.

The NHS service manual incorporates a whole section for content, which includes accessibility guidelines, vocabulary, and general writing principles. It doesn’t quite go as far as including actual UI copy guidance on the design component pages, but it feels like this could be their next step – it is still in beta after all.

Google’s material design manual features a section dedicated to communication, and how to create UI copy for the components. It’s a really comprehensive guide to using content and copy in design, even if it does sit slightly aside from the component sections themselves. It’s also worth noting they have separate guidelines for conversational design.

So, where to begin?

The best way to start is by thinking about who already uses your design system, and how it’s used. If your company has a small team and works across just one or two products, then a lightweight version such as Bulb’s would probably be a good starting point.

If you have a bigger company and multiple product teams then serious planning might be required. It’s a lot of work to create a large, comprehensive resource, and even once it’s live it will need to evolve and grow alongside your design maturity. Some companies have design ops or content ops teams who are solely responsible for building and maintaining design systems.

To create your system, your UX writers or content strategists should start by documenting the current ‘best practice’ frameworks and the guidelines they work to (even if they’re currently ‘informal’ guidelines – because remember, a design system is about formalising these).

They’ll also need to document how the brand tone of voice adapts to UX writing. It’s often the case that ‘tone of voice guidelines’ are created by brand or marketing teams with marketing copy in mind, and not for elements such as button labels or error messages.

Integration is key

The next step is to see how these frameworks overlap with the design components, and decide where content guidelines can and should be added into your existing system.

If there is no existing system, then creating one will rely heavily on your content strategists and designers working in tandem. And instead of tackling everything at once, perhaps just work through one small section at a time.

Then you’ll need to stress-test your guidelines with non-writers. The idea of a design system is that it’s easy to use and adapts for almost every scenario. If a UI designer can easily use the content guidelines for the component they’re using and produce the expected output then you’re doing great.

And finally, you’ll need to plan how you share the system and ensure it’s used across teams. A successful design system is one that’s used to speed up the UI design process, and leave your design teams with more time to solve the bigger problems!

The vital key to design impact Thu, 13 Jun 2019 23:00:00 +0000 Our study with 400 designers revealed how research is a vital contributing factor to design achieving the greatest impact.

Earlier in the year Clearleft asked 400 designers from around the world about how design functions within their organisations. We uncovered some fascinating insights around the effectiveness and implementation of design within organisations which we’ll be publishing soon, but here we’ll reveal one vital contributing factor to design being successful.

One of the pivotal opinions we gauged was whether designers thought design within their organisation “has contributed to an increase in sales, competitiveness, and/or brand loyalty”. In other words, is design having an impact on the end goals of their organisation?

Bar chart

We found that 69% of designers agreed that design has had a positive impact towards the success of their organisation. Only 7% felt that design was not having an impact. A quarter of designers weren’t sure whether or not they were making a difference (the not-knowing tells a story in itself, but that’s for another time).

It’s fair to say that designers are self-reporting the impact of their work. Some of this will be quantified and much might be subjective opinion. If you consider that we designers can be a cynical bunch and that, as an anonymous survey, there was no reason to justify one’s position, we can take these results as indicative.

At Clearleft we believe that research has an important role to play in design, so we were keen to also determine how much design research took place in organisations.

Bar chart

We found that the majority (53%) of organisations had little to no design research taking place. Given that all the organisations in question had at least one designer, this was slightly disappointing, although in our experience not entirely surprising. It was heartening to see that over 10% of organisations were doing design research at scale.

Firm in our belief that design research is important, we cross-referenced research with design impact to see if there was any correlation. That was when the true effect of design research was revealed.

Bar chart

Of the organisations where regular design research was being undertaken, 82% agreed that design was increasing sales, competitiveness, and/or brand loyalty. Doing research is one of the main differences between the design teams that impact business and those that don’t.

bar chart

Over half of design teams that have contributed to an increase in sales, competitiveness, and/or brand loyalty do design research regularly or at scale. In contrast, of those organisations where design was not having an impact, 95% are undertaking little to no design research.

The takeaways here are twofold. A design team is likely to contribute to the goals of an organisation. However without regular research to inform design, that work is far less likely to have an impact. Leaving differences aside, there’s still lot’s of room for improvement for most design teams in terms of research practice.

The companies performing the best in this regard have integrated research and design teams, or are set up with research and design distributed throughout the organisation. The work of those disciplines is shared with the rest of the employees so that research and design become fundamental to the decision making and strategy of the organisation.

This was a snapshot of some findings from our Design Attitudes survey. We’re currently compiling a comprehensive report which we’ll release for free later in the month. Check back soon or follow us on Twitter for further announcements.

The schedule for Patterns Day Mon, 10 Jun 2019 11:33:42 +0000 Patterns Day is less than three weeks away—exciting!

We’re going to start the day at a nice civilised time. Registration is from 9am. There will be tea, coffee, and pastries, so get there in plenty of time to register and have a nice chat with your fellow attendees. There’ll be breaks throughout the day too.

Those yummy pastries and hot drinks are supplied courtesy of our sponsors Buildit @ Wipro Digital—many thanks to them!

Each talk will be 30 minutes long. There’ll be two talks back-to-back and then a break. That gives you plenty of breathing space to absorb all those knowledge bombs that the speakers will be dropping.

Lunch will be a good hour and a half. Lunch isn’t provided so you can explore the neighbourhood where there are plenty of treats on offer. And your Patterns Day badge will even get you some discounts…

The lovely Café Rust is offering these deals to attendees:

  • Cake and coffee for £5
  • Cake and cup of tea for £4
  • Sandwich and a drink for £7

The Joker (right across the street from the conference venue) is offering a 10% discount of food and drinks (but not cocktails) to Patterns Day attendees. I highly recommend their hot wings. Try the Rufio sauce—it’s awesome! Do not try the Shadow—it will kill you.

Here’s how the day is looking:

Opening remarks
Closing remarks

We should be out of the Duke of York’s by 4:45pm after a fantastic day of talks. At that point, we can head around the corner (literally) to Holler Brewery. They are very kindly offering each attendee a free drink! Over to them:

Holler is a community based brewery, always at the centre of the local community. Here to make great beer, but also to help support community run pubs, carnival societies, mental health charities, children’s amateur dramatic groups, local arts groups and loads more, because these are what keep our communities healthy and together… the people in them!

Holler loves great beer and its way of bringing people together. They are excited to be welcoming the Patterns Day attendees and the design community to the taproom.

Terms and conditions:

  • One token entitles to you one Holler beer or one soft drink
  • Redeemable only on Friday 28th June 2019 between 4:45 and 20:00
  • You must hand your token over to the bar team

You’ll get your token when you register in the morning, along with your sticker. That’s right; sticker. Every expense has been spared so you won’t even have a name badge on a lanyard, just a nice discrete but recognisable sticker for the event.

I am so, so excited for Patterns Day! See you at the Duke of York’s on June 28th!

This was originally posted on my site.

Designing for friction - thoughts from UX London Sun, 09 Jun 2019 23:00:00 +0000 While it’s all fresh in my mind, I wanted to reflect on the 3 day event. I got plenty of food for thought. Yet there was one standout talk for me and I noted a number of recurring themes across the event. I’m starting to consider how I can embed these into my own design thinking.

Designing for friction - thoughts from UX London

Steve Sezler spoke on Designing for Friction. He really framed the crossover themes at UX London for me. Initially I thought this could be quite the controversial topic. As designers we do our best to remove pain points. But to increase friction …what? Steve provided compelling ideas on the value of retaining friction. He looked at all of your ‘convenience apps’ of the world—the AirBnbs, Amazons, and Deliveroos — as ‘creating a culture of instant on-demand services’. But are we creating a world of too little friction by doing so?

Steve went on to talk about how removing friction can remove opportunities for meaningful connection and personal growth. He used AirBnB as an example, continually designing for a guest experience where the ease and convenience of booking is taken care of. AirBnB hypothesised the ‘designing for friction’ statement —What happens when you encourage guests to contact their hosts for support? Initially thinking the hosts would feel burdened and the guests would receive lower quality support they in fact found this improved the overall level of customer satisfaction.


This made me think back to Jane Austin’s talk on developing your onion of key skills. Personal skills & people skills are at the core. They are the hardest to achieve and they are as important, if not more important, than your craft skills. As designers, if we really want to improve the lifestyle of people and improve these skills, we need to enable these opportunities through design.

UX London Jane Austin Onion of key skills
Jane Austin's onion of key skills. Sketchnotes by Maggie Appleton at UX London

Erika Hall also debunked common design myths with some standout statements:


Just because something is pleasant to use doesn’t mean it is useful! Which again plays back in to the original context of Steves talk. As designers we can streamline products & services to do everything for us hidden behind delightful micro interactions. But are we defining choices on behalf of the user by doing so? Erika went on to add


My takeaways from this is just to be mindful of the power of design and the responsibility we have as designers. Look for these opportunities to provide more than just another interaction but a more human centred value exchange. Start to think about where we will be in the future if we stick to this friction-less environment. While ultimately these services can be useful in the short term, are they robbing us in the long term from greater experiences and memories?

My top 5 reflection points from UX London Thu, 06 Jun 2019 12:59:00 +0000 I’ve been working in Service Design and UX for well over a decade now but had never had the opportunity of attending UX London, until this year. Now, a proud Clearleftie, I had the perk of attending the event for the whole 3 days and it certainly lived up to my expectation.

I always find that conferences provide a space for reflection on your career, your experiences and the industry as a whole - so here are my top five reflection points from UX London.

Design needs to work at every level

One theme from a number of speakers was the broad application of design at both a macro and micro level. Erika Hall highlighted that “design isn’t artefacts its decisions, so every decision maker is a designer” she added “we must widen our view, step out of the detail and consider the broader impact of our work on people and the environment, not just the immediate user.”

Similarly, Molly Nix discussed the need to design at all levels of zoom; from an interaction, to a feature, to a product, to a service and finally to the system. It’s something I’ve always appreciated coming from a service design background but it’s so easy to lose sight of the broader picture when your remit is on the design of one component. It’s important to remember that everything you work on is connected to everything else in the system, and it’s part of a designers job at every level to consider the impact to the individual, the business and society as a whole.

UX London Molly Nix Air BnB design speaking on stage
UX London Molly Nix from Air BnB design

Be aware of different stages of understanding

The industry legend Jared Spool gave a really engaging talk, where he reminded me of the ‘growth stages of understanding’ model. The four-stage model is intriguingly simple, describing a person’s path from ignorance to mastery. The final mastery stage is appropriately named ‘Unconscious Competent’. At this stage, the designer has essentially mastered the skill of design and has internalised all knowledge and intuitively produces good quality outcomes. It made me reflect that whilst I’ve always been against following a structured process/framework, preferring to think on my feet with a constant eye on where I’m going, it has a place for unifying a team with different levels of understanding. Indeed, Jared highlighted the need to work at the lowest team member’s level of understanding.

UX London Jared Spool talking to an attendee in the busy foyer
UX London Jared Spool

Last impressions are lasting

A couple of speakers and workshops highlighted the need to design for endings. Joe Macleod’s talk highlighted a number of good and bad endings and the implications of these on the overall experience. Whilst the Behavioural Design workshop by the Coglode team pointed to the peak-end rule. This rule, grounded in research, states that people judge an experience largely based on how they felt at its peak (i.e., its most intense point) and at its end, rather than based on the total sum or average of every moment of the experience. I also think that considering this rule during your design process will help you identify the moments of truth for your product and where the value lies.

We all design services, just different types

The first two talks on Thursday morning made me reflect on the similarities between the practice of Service Design and UX/Product Design and how the merging of these disciplines is becoming messy as services become more and more digital. Certainly the principles and methodologies that Jamin Hegeman highlighted in his ‘So You Want to be a Service Designer?’ are used at the Clearleft studio daily, but his example highlighted that it’s often the nature of the design problem that differs - with ‘Service Designers’ focused on experiences that have digital and non-digital touchpoints.

The following talk by Katie Koch from Spotify, a purely digital business, interestingly highlighted that Service Design for their business is squarely in the domain of the ‘UX/Product Designers’. I suppose, at the end of the day, we are all designing services just our areas of expertise means we are more suited to different types of services.

UX London Jane Austin Babylon Health on stage
UX London Jane Austin Babylon Health

The challenge of scaling a design team

We had two excellent talks from Babylon Health who are on a mission to leverage the ever-growing power of AI to make health affordable and accessible. Jane Austin gave some excellent advice on how to take control of your own career progression but the most interesting thing to me was the rate in which she had managed to grow the design team, from 8 to 60 in 8 months! I’ve done a little bit of recruitment over the years but can’t imagine what it is like to hire and onboard designers at such a rate. She gave some insight into some of the tools she’d put in place to make this process smoother, as did Emmet Connolly who is responsible for growing the design team at Intercom. The growth of the internal design team is not a new phenomenon, but I’m acutely aware that that challenge seems so much harder than designing the experience of a product or service.

Sponsor Patterns Day Wed, 29 May 2019 13:03:13 +0000 Patterns Day 2 is sold out! Yay!

I didn’t even get the chance to announce the full line-up before all the tickets were sold. That was meant to my marketing strategy, see? I’d announce some more speakers every few weeks, and that would encourage more people to buy tickets. Turns out that I didn’t need to do that.

But I’m still going to announce the final two speakers here becuase I’m so excited about them—Danielle Huntrods and Varya Stepanova!

Danielle is absolutely brilliant. I know this from personal experience because I worked alongside her at Clearleft for three years. Now she’s at Bulb and I can’t wait for everyone at Patterns Day to hear her galaxy brain thoughts on design systems.

And how could I not have Varya at Patterns Day? She lives and breathes design systems. Whether it’s coding, writing, speaking, or training, she’s got years of experience to share. Ever used BEM? Yeah, that was Varya.

Anyway, if you’ve got your ticket for Patterns Day, you’re in for a treat.

If you didn’t manage to get a ticket for Patterns Day …sorry.

But do not despair. There is still one possible way of securing an elusive Patterns Day ticket: get your company to sponsor the event.

We’ve already got one sponsor—buildit @ wipro digital—who are kindly covering the costs for teas, coffees, and pastries. Now I’m looking for another sponsor to cover the costs of making video recordings of the talks.

The cost of sponsorship is £2000. In exchange, I can’t offer you a sponsor stand or anything like that—there’s just no room at the venue. But you will earn my undying thanks, and you’ll get your logo on the website and on the screen in between talks on the day (and on the final videos).

I can also give you four tickets to Patterns Day.

This is a sponsorship strategy that I like to call “blackmail.”

If you were really hoping to bring your team to Patterns Day, but you left it too late to get your tickets, now’s your chance. Convince your company to sponsor the event (and let’s face it, £2000 is a rounding error on some company’s books). Then you and your colleagues need not live with eternal regret and FOMO.

Drop me a line. Let’s talk.

This was originally posted on my own site.

Our intern program is returning for 2019 Tue, 21 May 2019 16:02:00 +0000 We’re looking for three enthusiastic interns with backgrounds across research, design, arts and technology to join our three-month internship program in Brighton, starting in August.

Every few years we run an intern program with a difference. We put together a team of three interns with complimentary skills, give them a broad brief and task them with producing a new product or service with a digital core, that blends their skillsets in new and interesting ways. We provide support and coaching, a space in which to create, a living wage salary, and a small discretionary budget.

By the end of the three months the team will have created some form of working prototype, along with a record of their progress — be that a blog, video diary, case study or similar. We invite them to talk about the product and process to other students, graduates, press and members of the industry.

Crucially the program is run as a project like we would with our clients, with daily stand-ups, regular playbacks and frequent feedback sessions. With the entire Clearleft team at their disposal, we think it gives a great opportunity for graduates to gain vital studio experience and end up with an amazing portfolio piece.

Due to overwhelming demand, applications for 2019 are now closed

Previous Internships

The results of our two previous intern programmes blew us away. Both teams got to flex their creative muscles and we had a blast working with them, learning skills and approaches outside of our own areas of expertise.

2015 - Notice

In 2015 we had a trio of interns who created Notice, a product to help citizens understand what buildings are requesting planning permissions and what they can do about it. The trio consisted of a UI designer, an industrial product designer and a hacking/coding artist. They kept a Tumblr of their progress

The Notice Intern Team: Chloe, Chris and Monika

2013 - Chüne

In 2013 our intern team comprised a roboticist, a communication designer and an industrial designer. They created Chüne, an internet-connected, social music speaker.

The Chüne Intern Team: Zassa, Killian and Victor

Intern Victor Johansson said of his experience:

Clearleft is by far the nicest company and working environment I have come across. All I can say is, if you are thinking about applying for next years internship programme, then DO IT, and if you aren’t thinking about it, well maybe you should start thinking!

Please note that due to overwhelming demand, applications are now closed.

Give your information architecture a three-point checkup Fri, 17 May 2019 08:35:00 +0000 “How do you know your site structure is needing attention before it becomes really broken?”

I’ve recently been asked variations of this question by a couple of clients, a colleague and the attendees of a presentation I was giving.

A great information architecture (IA) tells a story, creates flow and aids discovery for the people using your products or services.

An ailing IA threatens to silence your content, prevent conversion (sales and engagement) and frustrate your users. The good news is a sick information architecture can easily be cured with early diagnosis and painless remedies.

Here are three tell-tale signs to look for and some ways to avoid the problem in the first place:

Warning sign #1. You’ve shipped your org-chart

Be mindful not to conform to Conway’s Law where organisations design systems which mirror the organisation’s structure. You’ll know you’re doing this when the hot project or latest initiative get undue prominence in navigation menus. Or when you can match the words used in page labels with a department or person’s job title in the business.

Shipping the org-chart is often done inadvertently without anyone really noticing until it’s too late.

The way to remedy it is to get out of your building and meet more of your users more regularly. Listen to the words they use to describe what you offer. Open card sorting is the ideal technique to help with this. As a robust, quick and repeatable activity, it helps you find out how the people you want to use your website would organise and label the items on it to make them easy to find.

Warning sign #2. The loudest voice trumps the considered logic

You will know this when you see it. It crops up in navigation menus that seem to have an order with the exception of a couple of prominently misplaced items. You sense it when a page is featured multiple times in multiple menus desperately calling out for you to care enough to click on it.

So many site structures reflect the egos of individuals in the business. To avoid incongruous items getting shoe-horned into your information architecture I’d look to engage stakeholders early on, to help shape their brief rather than just receiving it.

Having the principles and concepts articulated for how the site is organised helps move the request from tactical demands to a more considered strategic conversation. It’s important to change the conversation to focus on desired outcomes rather than the position within a menu. Having your content found is ultimately more valuable than appearing in the primary navigation and easy to measure and report on.

The result of not looking after the health of your IA

Warning sign #3. Your IA is treated as a project rather than a process

Projects feel good. There’s a crisis to deal with and all you need is to call for the cavalry to ride into town and just in the nick of time to save the day.

Your IA should never become a crisis. Unlike a project managing your IA should be an ongoing activity without an end date. After all, a healthy digital product or service never stands still with ongoing enhancements and additions to what you offer.

You know your IA is respected as a critical part of your digital operations when:

  • There is a person responsible for it with defined KPIs to meet
  • The process and logic for positioning and labelling pages is documented
  • Time is regularly scheduled for review and attention

A great IA doesn’t happen by lucky accident. They need to be designed, iterated upon and optimised. Without care and ongoing love they quickly become overgrown and unwieldy.

How to nurture your IA

Hopefully, your information architecture doesn’t exhibit any of these three warning signs. If it does take some action to remedy the problem sooner rather than later.

If your IA is currently in good shape, then make sure you schedule your next check-up, as a thriving website is always in a state of change. To keep it healthy requires considered processes and ongoing attention.

A 'rough guide to UX' workshop Tue, 30 Apr 2019 14:00:00 +0000 After sampling the infamous coffee and sitting in on the Monday team meeting, I kicked off my time at Clearleft with a fascinating ‘Rough guide to UX’ workshop led by Andy Thornton.

It was a fortuitous day to start, not only did I get to learn UX techniques from the very best, I got to know six of my new colleagues in a great environment.

I arrived a little late (the new laptop took a while to set up!); they’d just finished running through the history of UX, and discussing user-centered design. This led on to the first activity, the interview.

Empathy mapping

We interviewed each other to find out more about our holidaying habits, how we decide when and where to go, and what informs our plans. As the interviewer, we categorised answers into four categories:

This empathy map helped disseminate the information, tailor our questions, and sift through the noise. The type of questions were crucial. A ‘closed’ question would often resolve in a yes/no answer, and would run the risk of introducing interviewer bias. “Do you gather holiday inspiration from Instagram” offers little insight. “Do you gather holiday inspiration from Instagram or Pinterest” gives the interviewee two choices, neither of which may be correct.

‘Open’ questions reveal more useful information, but require greater trust between the two parties. Asking the ‘why’ questions is where the real gold lies.

Coming to the table with a beginners mind keeps your interviewing bias to a minimum, even if you are an expert in the field. The whole exercise really brought home what a great skill interviewing is.

Keeping focus on past and current experiences was a theme that persisted throughout the day. Questions about a previous holiday will yield more accurate answers than those about a potential future holiday.

Jobs, pains & gains

We split into two groups and picked a scenario that we wished to improve with UX techniques. Our team chose ‘improving the new starter process’, which was suitably meta on day one! It turned out to be a great choice - I learned a bunch about what’s coming up for me in the next couple of weeks!

The task was to outline the following aspects of the new starter experience:

  • Jobs: Goals, and things one wants to achieve
  • Gains: Opportunities, practical outcomes, and soft feelings
  • Pains: Challenges and obstacles

It was interesting to see how many jobs could also be gains. ‘Doing’ is such a positive thing for a new starter, so many goals blended between the two. We finished by ordering the post-its in each column by importance. The ‘time’ factor made a large difference to the order. Short-term goals tended to place higher, but longer-term goals led to more gains overall.

These two tasks were part of the problem definition phase of the heralded double-diamond.

Story mapping

The next task was to story map the current process for new starters. Again, the onus was still to focus on what’s happening now, not our desired outcomes (yet). We broke it down into a filmstrip:

  • Chapters: high-level themes
  • Scenes: Categories of events
  • Actions: Individual events

The general rule of thumb was if it can’t be broken down into smaller chunks, it’s an action. We started with scenes and worked down to actions and up to chapters. The scenes act as a time-based narrative and help pin down what happens day-to-day.

Again, as we discussed each scene in detail, we found that some scenes became actions, and others became chapters, or even multiple scenes.

The next step was to mark high and low points of the experience. This provoked much discussion on character, introversion and public speaking. Many of the actions initially marked as green by our team’s extrovert were red in my introverted eyes! Clearleft run regular ‘brown-bag’ lunches where members of the team share their experience, or something of interest. This is also part of the induction process, and for those less excited by public speaking, that prospect can be pretty daunting!

The story map can also be extended to become a helpful tool in planning the whole project. Chapters become epics, scenes become stories, and actions become tasks. We can even draw sensible ‘release lines’ across our model!

The peak-end rule suggests that humans remember the highs/lows and the end of an experience, so that’s where we should be focusing our attention. If we identify the lows and mitigate them, we can make a dramatic difference to the view of the overall experience!

Explore ideas

With those lows in mind, it was time to find some solutions.

We began with a task to lower the barrier to sketching. Drawing is often seen as a scary and vulnerable task for those less creative, and a point of pride for those who regularly sketch! Both can get paralysed when asked to create a one-minute sketch in front of others.

This icebreaker came in the form of squiggle birds, yes, you read that correctly. The premise is as follows:

  1. Draw a bunch of squiggles on the page!
  2. Add a beak to one of the edges
  3. Now an eye
  4. And some feet
  5. Maybe a tail if you’re feeling adventurous!

Give it a go - it’s a lot of fun! I’ve also made a little JS squiggle bird to demonstrate, have a click through below!

See the Pen Squiggle birds by Trys Mudford (@trys) on CodePen.

The human brain is brilliant at finding meaning from noise, if we can create birds from squiggles, we can do some rough sketching!

Sketching our squiggle birds


So, to the task itself…

We creased our paper into six sections and had one minute to draw a solution to one of the problems brought to light from our story map. When the timer went, we moved onto the next section and drew another solution to a different problem. Six run-throughs later, and we had six (quite poorly drawn) ideas on paper! We kept those ideas to ourselves and moved onto the next task.

Taking another sheet of A3, we spent 15 minutes on one idea, going into a lot more detail. The previous task, although fleeting, was a great precursor to this activity. I ended up taking two or three ideas from it, and combining it into one main proposition.

If you couldn't tell, I fall into the 'not overly keen on sketching' camp!

Feedback & Critique

Andy then walked through a few stumbling blocks to critiques, including GroupThink, an idea that in a desire to reduce conflict, a group will often reach a compromised decision without properly evaluating the matter. I thought back to attending jury duty. Dropping a group of strangers together and asking them to come to an informed, and ideally unanimous decision, is a tricky task indeed.

To alleviate this problem, we put on thinking hats. Six distinct roles were spread around the table and we were to all assume the respective personas:

  • Blue: facilitator, the individual presenting their idea
  • White: objective, data-focused
  • Red: feelings, hunches and emotion
  • Green: creativity, building upon ideas
  • Yellow: positivity!
  • Black: negativity, ‘devils advocate’ and caution

The simple act of pinning a coloured post-it and becoming that persona took all the pressure out of presenting to the group. We all outlined our ideas and had genuinely good discussions about each one. When the ‘black hat’ brought up issues, the green and yellow were right beside you to defend and build on your idea. It was fun, safe, and productive.

Testing and learning

The final part of the day went through some processes for testing our solutions. It was mostly theoretical, but super interesting.

By structuring our work as experiments, we reduce the cost of failure. It’s a great way to propose new features or ideas to a manager or stakeholder. The key is to only test one thing against your hypothesis.

This fits nicely into a ‘Observe’, ‘Hypothesise’, ‘Test’, and ‘Theorise’ model, and can lead to great, data-driven results. Sounds a little similar to red, green, refactor!


I was so fortunate to kickoff my time at Clearleft with such an informative and interesting day. I learned a ton about UX, how Clearleft go about workshopping, and how the new starter process will work itself out over the next few weeks!

This was originally posted on my own site.

Earth day, API's and sunshine. Mon, 22 Apr 2019 09:25:00 +0000 Here at Clearleft we’ve been taking small steps to reduce our environmental impact. In December 2018 we covered the roof of our home with solar panels.

With the first of the glorious summer sun starting to shine down on us, we started to ponder about what environmental impact they’d had over the last 5 months.

Luckily for us, our solar panels have an API, so we can not only find out that information, we can request it from SolarEdge and display it in our very own interface.

If I lost you at API, it isn’t a type of hipster beer. API stands for application programming interface. A company can make some of its data available to developers by building an API, a set of dedicated URLs that return data responses . This article describes them as little robo-waiters, serving up data to other apps and websites.

I’m always up for a fun side project, so when I saw that Earth day was on the horizon, I grabbed the opportunity. I make a lot of cute web animations and interactive code experiments on CodePen. But I’ve never tried to visualize any data before. So the first step was to find out what was accessible. What data could I get my hands on?

Jeremy and I got up the docs and started doing some investigation. The first thing that jumped out at us was this -

treesPlanted: equivalent planting of new trees for reducing CO₂ levels

Wouldn’t it be cool if over the years we could somehow see the number of trees we’d “planted”? Create a kind of digital forest and watch it grow?

I started scribbling down some rough ideas. I wanted the visual to link to Clearleft and Brighton somehow but there aren’t many forests (or gardens) in central Brighton. A roof garden seemed like a good location for our digital forest.

A rough sketch of the 68 middle street building with trees on roof and wind turbine in the background.

68 middle street has a lot of windows, so that jumped out as a good way to display our current power.

Our peak power is 6.48 kWp and is essentially the rate at which our solar system generates energy at noon of a super sunny day. The amount of energy a system generates is measured in kilowatt hours (kWh). Each of our kWp’s should generate around 800 to 850 kWh per year (if we get a decent amount of sunshine, which in the UK is sometimes rather elusive) By querying our peak power and current power, we can work out what percentage of our overall capacity we’re currently at.

Once I’d worked out what data I wanted, I used the fetch API to get it. This tutorial by Sara Vieira helped me to wrap my head around this.

fetch() allows us to make network requests similar to XMLHttpRequest. The main difference is that the Fetch API uses Promises. A promise object is data returned by asynchronous function. It will resolve if the function returned successfully or reject if the function returned an error.

 .then(response => response.json())
 .then(response => {
   // Do all the fun stuff with the data here!
 .catch(err => {
   console.log("oh no. something went wrong");

First we call the fetch API and pass it the URL we want to get the data from, as we haven’t specified any other parameters, this will be a simple GET request. We also want our data as a JSON object so we add response.json to parse the response as JSON.

If the promise gets resolved, our then function will trigger and do all the fun stuff with the SVG illustration and the API data. And if our promise gets rejected our catch function will trigger and throw an error to alert us.

As for the illustration itself! The illustration is an SVG, or scalable vector graphic. The best bit about SVG that it gives you is the ability to manipulate it’s properties.

SVG has a DOM, much like HTML and when used inline, (by putting the SVG code right into your HTML), you can access this DOM with CSS or Javascript and do things to it.

 <svg class="68middlestreet"... >
   <path class="sky" fill="#91b1bf" d="M9 52.1h813.2v767.6H9z" />
    <g class="clouds">
      <path fill="#d9eafc" d="M-207.6 395.2c14.2..."/>
      <path fill="#f9f9f9" d="M-67.2 389.9s-5.4 3-..."/>
A picture of the illustration being put together in adobe Illustrator

I created the SVG building in illustrator. It was a pretty large SVG with a lot of detail, and the exported code can be pretty unwieldy straight out of a graphics editor. So I ran it through SVGOMG to tidy it up.

When the then function gets triggered, I’m adding a class called animate to the body of the HTML. I’m using CSS for the animations, and I’ve bound the animations to this class.

This ensures that the animations don’t start before the data response has come back from the API, as we require that information to know how many trees to grow and windows to light up.

.then(response => {
.animate .tree {
  animation: grow 0.6s cubic-bezier(0.175, 0.885, 0.32, 1.1) forwards 1s;

@keyframes grow {
  from {
    opacity: 0;
    transform: scale(0) translateY(100%);
  to {
    transform: scale(1) translateY(0);
    opacity: 1;

My personal favourite bit of this project was creating an accurate representation of the number of trees.

If there’s a fractional part to the number of trees. i.e. 2.3 instead of 2, we get to create a cute mini-tree!

I used a modulo operation to find the remainder after dividing by one and then set the tree size to that remainder.

var littleTreeSize;
var isLittleTree = false;

// work out if there's a small tree
var treeMod = treeCount % 1;
// if there's a remainder then set isLittleTree to true
var isLittleTree = treeMod > 0;

if (isLittleTree) {
 // set little tree size
 littleTreeSize = treeMod;

All in all this was great fun. I look forward to a summer full of sunshine so that we can watch a digital forest spring up from our rooftop!

Check out our final data vis here 

Three more Patterns Day speakers Tue, 16 Apr 2019 14:58:57 +0000 There are 73 days to go until Patterns Day. Do you have your ticket yet?

Perhaps you’ve been holding out for some more information on the line-up. Well, I’m more than happy to share the latest news with you—today there are three new speakers on the bill…

Emil Björklund, the technical director at the Malmö outpost of Swedish agency inUse, is a super-smart person I’ve known for many years. Last year, I saw him on stage in his home town at the Confront conference sharing some of his ideas on design systems. He blew my mind! I told him there and then that he had to come to Brighton and expand on those thoughts some more. This is going to be an unmissable big-picture talk in the style of Paul’s superb talk last year.

Speaking of superb talks from last year, Alla Kholmatova is back! Her closing talk from the first Patterns Day was so fantastic that it I just had to have her come back. Oh, and since then, her brilliant book on Design Systems came out. She’s going to have a lot to share!

The one thing that I felt was missing from the first Patterns Day was a focus on inclusive design. I’m remedying that this time. Heydon Pickering, creator of the Inclusive Components website—and the accompanying book—is speaking at Patterns Day. I’m very excited about this. Given that Heydon has a habit of casually dropping knowledge bombs like the lobotomised owl selector and the flexbox holy albatross, I can’t wait to see what he unleashes on stage in Brighton on June 28th.

Emil Björklund Alla Kholmatova Heydon Pickering
Emil, Alla, and Heydon

Be there or be square.

Tickets for Patterns Day are still available, but you probably don’t want to leave it ‘till the last minute to get yours. Just sayin’.

The current—still incomplete—line-up comprises:

That isn’t even the full roster of speakers, and it’s already an unmissable event!

I very much hope you’ll join me in the beautiful Duke of York’s cinema on June 28th for a great day of design system nerdery.

This was originally posted on my own site.

Design Perception Thu, 11 Apr 2019 11:34:00 +0000 Last week I wrote a post called Dev perception:

I have a suspicion that there’s a silent majority of developers who are working with “boring” technologies on “boring” products in “boring” industries …you know, healthcare, government, education, and other facets of everyday life that any other industry would value more highly than Uber for dogs.

The sentiment I expressed resonated with a lot of people. Like, a lot of people.

I was talking specifically about web development and technology choices, but I think the broader point applies to other disciplines too.

Last month I had the great pleasure of moderating two panels on design leadership at an event in London (I love moderating panels, and I think I’m pretty darn good at it too). I noticed that the panels comprised representatives from two different kinds of companies.

There were the digital-first companies like Spotify, Deliveroo, and Bulb—companies forged in the fires of start-up culture. Then there were the older companies that had to make the move to digital (transform, if you will). I decided to get a show of hands from the audience to see which kind of company most people were from. The overwhelming majority of attendees were from more old-school companies.

Just as most of the ink spilled in the web development world goes towards the newest frameworks and toolchains, I feel like the majority of coverage in the design world is spent on the latest outputs from digital-first companies like AirBnB, Uber, Slack, etc.

The end result is the same. A typical developer or designer is left feeling that they—and their company—are behind the curve. It’s like they’re only seeing the Instagram version of their industry, all airbrushed and filtered, and they’re comparing that to their day-to-day work. That can’t be healthy.

Personally, I’d love to hear stories from the trenches of more representative, traditional companies. I also think that would help get an important message to people working in similar companies:

You are not alone!

This was originally posted on my own site.

Split Wed, 10 Apr 2019 14:59:00 +0000 When I talk about evaluating technology for front-end development, I like to draw a distinction between two categories of technology.

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

Personally, I’m much more interested and excited by the materials than I am by the tools. But I think it’s right and proper that other developers are excited by the tools. A good balance of both is probably the healthiest mix.

I’m never sure what to call these two categories. Maybe the materials are the “external” technologies, because they’re what users will interact with. Whereas all the other technologies—that mosty live on a developer’s machine—are the “internal” technologies.

Another nice phrase is something I heard during Chris’s talk at An Event Apart in Seattle, when he quoted Brad, who talked about the front of the front end and the back of the front end.

I’m definitely more of a front-of-the-front-end kind of developer. I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).

As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time. Like I said, from a user’s point of view, it’s irrelevant what text editor or version control system you use.

Now, you could make the argument that anything that is good for developer convenience is automatically good for user experience because faster, more efficient development should result in better output. While that’s true in theory, I highly recommend Alex’s post, The “Developer Experience” Bait-and-Switch.

Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

Historically, it’s been a similar story with JavaScript libraries. They’re written in JavaScript, and so they’re going to be executed in the browser. If a developer wanted to use jQuery to make their life easier, the user paid the price in downloading the jQuery library.

But I’ve noticed a welcome change with some of the bigger JavaScript frameworks. Whereas the initial messaging around frameworks like React touted the benefits of state management and the virtual DOM, I feel like that’s not as prevalent now. You’re much more likely to hear people—quite rightly—talk about the benefits of modularity and componentisation. If you combine that with the rise of Node—which means that JavaScript is no longer confined to the browser—then these frameworks can move from the front of the front end to the back of the front end.

We’ve certainly seen that at Clearleft. We’ve worked on multiple React projects, but in every case, the output was server-rendered. Developers get the benefit of working with a tool that helps them. Users don’t pay the price.

For me, this question of whether a framework will be used on the client side or the server side is crucial.

Let me tell you about a Clearleft project that sticks in my mind. We were working with a big international client on a product that was going to be rolled out to students and teachers in developing countries. This was right up my alley! We did plenty of research into network conditions and typical device usage. That then informed a tight performance budget. Every design decision—from web fonts to images—was informed by that performance budget. We were producing lean, mean markup, CSS, and JavaScript. But we weren’t the ones implementing the final site. That was being done by the client’s offshore software team, and they insisted on using React. “That’s okay”, I thought. “React can be used server-side so we can still output just what’s needed, right?” Alas, no. These developers did everything client side. When the final site launched, the log-in screen alone required megabytes of JavaScript just to render a form. It was, in my opinion, entirely unfit for purpose. It still pains me when I think about it.

That was a few years ago. I think that these days it has become a lot easier to make the decision to use a framework on the back of the front end. Like I said, that’s certainly been the case on recent Clearleft projects that involved React or Vue.

It surprises me, then, when I see the question of server rendering or client rendering treated almost like an implementation detail. It might be an implementation detail from a developer’s perspective, but it’s a key decision for the user experience. The performance cost of putting your entire tech stack into the browser can be enormous.

Alex Sanders from the development team at The Guardian published a post recently called Revisiting the rendering tier . In it, he describes how they’re moving to React. Now, if this were a move to client-rendered React, that would make a big impact on the user experience. The thing is, I couldn’t tell from the article whether React was going to be used in the browser or on the server. The article talks about “rendering”—which is something that browsers do—and “the DOM”—which is something that only exists in browsers.

So I asked. It turns out that this plan is very much about generating HTML and CSS on the server before sending it to the browser. Excellent!

With that question answered, I’m cool with whatever they choose to use. In this case, they’re choosing to use CSS-in-JS (although, to be pedantic, there’s no C anymore so technically it’s SS-in-JS). As long as the “JS” part is JavaScript on a server, then it makes no difference to the end user, and therefore no difference to me. Not my circus, not my monkeys. For users, the end result is the same whether styling is applied via a selector in an external stylesheet or, for example, via an inline style declaration (and in some situations, a server-rendered CSS-in-JS solution might be better for performance). And so, as a user-centred developer, this is something that I don’t need to care about.


I have misgivings. But just to be clear, these misgivings have nothing to do with users. My misgivings are entirely to do with another group of people: the people who make websites.

There’s a second-order effect. By making React—or even JavaScript in general—a requirement for styling something on a web page, the barrier to entry is raised.

At least, I think that the barrier to entry is raised. I completely acknowledge that this is a subjective judgement. In fact, the reason why a team might decide to make JavaScript a requirement for participation might well be because they believe it makes it easier for people to participate. Let me explain…

It wasn’t that long ago that devs coming from a Computer Science background were deriding CSS for its simplicity, complaining that “it’s broken” and turning their noses up at it. That rhetoric, thankfully, is waning. Nowadays they’re far more likely to acknowledge that CSS might be simple, but it isn’t easy. Concepts like the cascade and specificity are real head-scratchers, and any prior knowledge from imperative programming languages won’t help you in this declarative world—all your hard-won experience and know-how isn’t fungible. Instead, it seems as though all this cascading and specificity is butchering the modularity of your nicely isolated components.

It’s no surprise that programmers with this kind of background would treat CSS as damage and find ways to route around it. The many flavours of CSS-in-JS are testament to this. From a programmer’s point of view, this solution has made things easier. Best of all, as long as it’s being done on the server, there’s no penalty for end users. But now the price is paid in the diversity of your team. In order to participate, a Computer Science programming mindset is now pretty much a requirement. For someone coming from a more declarative background—with really good HTML and CSS skills—everything suddenly seems needlessly complex. And as Tantek observed:

Complexity reinforces privilege.

The result is a form of gatekeeping. I don’t think it’s intentional. I don’t think it’s malicious. It’s being done with the best of intentions, in pursuit of efficiency and productivity. But these code decisions are reflected in hiring practices that exclude people with different but equally valuable skills and perspectives.

Rachel describes HTML, CSS and our vanishing industry entry points:

If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.

I think there’s a comparison here with toxic masculinity. Toxic masculinity is obviously terrible for women, but it’s also really shitty for men in the way it stigmatises any male behaviour that doesn’t fit its worldview. Likewise, if the only people your team is interested in hiring are traditional programmers, then those programmers are going to resent having to spend their time dealing with semantic markup, accessibility, styling, and other disciplines that they never trained in. Heydon correctly identifies this as reluctant gatekeeping:

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

This hurts everyone. It’s bad for your team. It’s even worse for the wider development community.

Last year, I was asked “Is there a fear or professional challenge that keeps you up at night?” I responded:

My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.

I’ve described a number of dichotomies here:

  • Materials vs. tools,
  • Front of the front end vs. back of the front end,
  • User experience vs. developer experience,
  • Client-side rendering vs. server-side rendering,
  • Declarative languages vs. imperative languages.

But the split that worries the most is this:

  • The people who make the web vs. the people who are excluded from making the web.

This was originally posted on my own site.

Cotswolds design leaders retreat Fri, 05 Apr 2019 14:53:00 +0000 Earlier this month I had the pleasure of co-hosting a retreat for senior design leaders, at a beautiful country house hotel in the Cotswolds. The group was comprised of Heads and Directors of Design from a range of well known brands.

Most were from the UK and Europe, although a handful had flown the 10+ hours from North America to join us. They were here to spend the next few days exploring their career journeys, improving their leadership skills, and sharing tactics and advice with their industry peers.

It was clear from the off that these three days were much needed. During the opening circle, people talked candidly and honestly about the pressure they were under, feelings of isolation, and an overwhelming sense of imposter syndrome. They also talked about the guilt they were feeling being away from their families and teams. For many, this was their first chance to spend any meaningful time focussing on themselves and their careers, so they weren’t about the waste the opportunity.

We kicked things off with what I called a Leadership MOT. Essentially a series of exercises intended to understand the individual career paths these leaders had taken to get to where they were today, the highs and lows of that journey, and what this could tell them about their own personal needs. Next, we delved into the topic of leadership styles, plotting their approaches and preferences on a series of charts and graphs, before looking at which areas could be improved upon. We did a similar exercise looking at where they currently spent their effort, and how they’d like that to change over the coming months. We used this information to start filling in a personal design leadership canvas, the second half of which we’d come back to at the end of the three days.

Common challenges setting the agenda

Using Open Space Technology, we pulled out all the key issues the group was experiencing and turned these into a detailed agenda. Topics included the challenges of scaling a team, how to go about measuring and demonstrating the value of design, the best way to structure your design team, tips on building a robust design culture, and approaches for dealing with boards, peers from other departments and organisational silos. We also touched on more challenging subjects like managing difficult staff members, dealing with workplace stress, fears around personal and professional failure, and worries about what comes next.

If you’ve been to a Leading Design Conference before, or happen to be a member of our Slack community, most of these topics will be familiar to you. However, our attendees seemed to find it both helpful and cathartic being able to discuss these topics in a safe space amongst a group of peers. One said of the retreat “It was better than I could have ever imagined and will have a lasting effect both professionally and personally. It was introspective and revelational.”


Interspersed between the discussions, we had arranged a number of social events. On one day we got to choose to do a bread making or cocktail making course - an opportunity to get creative and bond with our peers out of the context of our day-to-day roles. The next day we went on a group walk in the Cotswolds countryside. One of our goals for the retreat was to help create a bit of a support network for our attendees, so creating space for people to get to know each other and build lasting bonds was super important.

The merit of a personal leadership plan

While we experimented with a number of different sessions, one of the most popular activities was known–rather cheesily—as a success circle. This involved splitting our design leaders into groups of 4 and giving each person 20 minutes to request help or advice from the other members. Some people asked for help with their recruitment challenges, others delved into the thorny problem of team structure. Some people needed help with a difficult HR issue, while others sought advice on their next career move. The result of this session was that everybody came away with a stack of good ideas for how to solve a knotty challenge that had been bugging them for a while.

As the final afternoon approached, we switched back to our structured activities, asking everybody to fill in the second half of their Design Leadership Canvas. This acted as a helpful way to capture some of the challenges they’d surfaced, the advice they’d been given, and the decisions they’d made. We then set a second activity; to create a personal leadership plan. The plan was broken down into different sections; things you could do to improve your own personal leadership abilities, things you could do to help your team, and things you could to do affect the wider organisations. These sections were divided into three different time horizons; things you could do now, things you could do over the next couple of months, and things you would work towards in the future. We asked everybody to commit to at least three of these as immediate next steps.

design leaders at the leadership retreat

Time for introspection

Even though we were only away for three days it felt like we’d been away for a lot longer. We’d had some pretty intense conversations, and a few tears had been shed along the way. New friendships had formed and we’d bonded as a group. While it would have been too much to ask to solve every problem raised, a good amount of ground had been covered. People left feeling renewed, reinvigorated, and excited for what happens next.

One of the group summarised the experienced best when they said “it has been both a cathartic and delightfully exhausting introspective journey of which I hope to continue and practice with both myself and those of whom I work with.”

Our next leadership retreat takes place on the 16th -20th September, in the forests and mountains of North Norway—the perfect place to escape, recharge and work on your leadership challenges. We’ll be taking applications soon, so follow this link for more details.

Five insights from successful design leaders Thu, 04 Apr 2019 08:00:00 +0000 Last month Clearleft hosted a lively morning of discussion and debate featuring leading industry voices from Spotify, Virgin Atlantic, Google, Deliveroo, Bulb, and Pfizer.

In front of an audience of design leads, two panels explored some of the common challenges facing internal design teams; from understanding and responding faster to customer needs, implementing the right systems internally for driving innovation, and creating a culture of design thinking. These are five key takeaways from the sessions.

Panel discussion and audience

Customer expectations are evolving

Customers are expecting more from the services they use and pay for. Service designers have known this for decades, but the design you do needs to be not just on screen, but before, after and behind the screen experience. User research and testing is a fundamental part of achieving this, and should be a key input into decision making when it comes to the design of services and products. The way to achieve this - and it can be far easier said than done - is to expose your organisation to the experiences of your customers.

Design decisions should be tested, but you need to work out the impact you want to make in order to validate changes, even when those changes are informed by research. Metrics can be an extremely useful guide, but in and of themselves can reduce your impact. Designers can find themselves focussing on a metric as a way of acting more quickly, when greater value could be found by thinking critically and holistically rather than concentrating on local maxima - but those things take time, effort and some political will.

The case for design systems

We designers love design systems - they can give us a grander sense of purpose - while of course providing a incredibly valuable resource to our organisation. Done well, they can (and should) be a significant investment, so putting a case forward to those with the purse strings is vital. The number one reason to state is ‘efficiency’. This is the codeword to use to get buy-in. Good design systems will introduce efficiency into workflows across design and development within the organisation. They also provide consistency to your customer’s experience, and keep the quality at the required level.

A good design system is not just for code (AKA a pattern library). It is not just a design guide or a brand book, and it is not just repeatable UX patterns. It is all those things. But the best ones also integrate copywriting, especially microcopy, but also copy guidelines on a wider scale - even within single brand the tone of voice will need to change with the context.

Your design system is a tool that needs to be communicated and constantly nurtured. As soon as the system’s consumers feel it is out of date, a design system’s use - and all the advantages it provides - will drop off a cliff.

Link design operations to the organisation

Design ops are your way of doing design, including how design links in with the rest of organisation. One good way of getting started on design ops is by specifying your research operations first - getting a system and process for your research ops will inherently describe how research feeds into design and other parts of the organisation (such as sales and marketing). Getting that right will spark getting design ops right.

Ultimately design ops should comprise the CRD trifecta: Content, Research and Design, as opposed to just design. These are typically thought of as different things, and occasionally siloed into different departments, but they all part of the same picture.

Introducing design ops may naturally involve a change in culture. A key part of any successful culture change is about showing people what’s in it for them, and design ops will do that.

Silos get a bad rap

It’s certainly true that large silos, operating independently without interacting with other silos, frequently means the right hand doesn’t know what the left hand is doing. However can be beneficial to consciously create small silos for individuals teams (perhaps these are ‘vats’ rather than silos?) Small silos enable you concentrate expertise - members will get to know, trust and learn from each other.

It’s also true that design works well when it’s integrated throughout the organisation, with content, research, design and even development represented in all departments. If that’s how you’re organised it’s important that the different disciplines have ample opportunity to come together as a team in to share learning and feed into each other’s work (just as pair programming can bring additionsal quality, so two heads are better than one when it comes to design).

Designers should ask permission less

Once design has been elevated from mere styling to problem solving, designers can start to be more influential. By heading down a hypothesis-based approach (with measure and test) you can start to make more substantial improvements. With appropriate design leadership, this can mean venturing into seeking out opportunities based on research and insight. This is real, not pie-in-the-sky, innovation, but you need to innovate efficiently for true impact. When you ask for permission, executives will come in and start directing. Start showing results and you’ll get more leeway.

A closing thought from the panels was that we should all stop talking about how we design, and start talking about the impact of design on the goals of the organisation.

Many thanks to Alla Kholmatova (Former Head of Design & UX, Bulb), Simon Rohrbach (Director of Content, Research & Design, Deliveroo), Nicole Burrow (Design Director, Spotify), Jens Riegelsberger (Product Design and Research Director, Google), Martyn Reding (Head of Digital Experience, Virgin Atlantic) and Nuala Sheerin (UK Digital Transformation Lead, Pfizer) for their generous time.

Join us next time

We’ll be running a similar event in September. If you lead or manage design teams, and you’d like to be in the audience, please let us know and we’ll get back to you with details nearer the time.

Dev perception Thu, 04 Apr 2019 07:30:00 +0000 Chris put together a terrific round-up of posts recently called Simple & Boring. It links off to a number of great articles on the topic of complexity (and simplicity) in web development.

I had linked to quite a few of the articles myself already, but one I hadn’t seen was from David DeSandro who wrote New tech gets chatter:

You don’t hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.

I think that’s a very good point.

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The result is that what’s being written about is not a reflection of what’s being widely used. And that’s okay …as long as you know that’s the case. But I worry that theres’s a perception problem. Because of the outsize weighting of new and exciting technologies, a typical developer could feel that their skills are out of date and the technologies they’re using are passé …even if those technologies are actually in wide use.

I don’t know about you, but I constantly feel like I’m behind the curve because I’m not currently using TypeScript or GraphQL or React. Those are all interesting technologies, to be sure, but the time to pick any of them up is when they solve a specific problem I’m having. Learning a new technology just to mitigate a fear of missing out isn’t a scalable strategy. It’s reasonable to investigate a technology because you genuinely think it’s exciting; it’s quite another matter to feel like you must investigate a technology in order to survive. That way lies burn-out.

I find it very grounding to talk to Drew and Rachel about the people using their Perch CMS product. These are working developers, but they are far removed from the world of tools and frameworks forged in the startup world.

In a recent (excellent) article comparing the performance of Formula One websites, Jake made this observation at the end:

However, none of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.

I think this is very astute. I also think it’s completely understandable to form ideas about what matters to developers by looking at what’s being discussed on Twitter, what’s being starred on Github, what’s being spoken about at conferences, and what’s being written about on Ev’s blog. But it worries me when I see browser devrel teams focusing their efforts on what appears to be the needs of typical developers based on the amount of ink spilled and breath expelled.

I have a suspicion that there’s a silent majority of developers who are working with “boring” technologies on “boring” products in “boring” industries …you know, healthcare, government, education, and other facets of everyday life that any other industry would value more highly than Uber for dogs.

Trys wrote a great blog post called City life, where he compares his experience of doing CMS-driven agency work with his experience working at a startup in Shoreditch:

I was chatting to one of the team about my previous role. “I built two websites a month in WordPress”.

They laughed… “WordPress! Who uses that anymore?!”

Nearly a third of the web as it turns out - but maybe not on the Silicon Roundabout.

I’m not necessarily suggesting that there should be more articles and talks about older, more established technologies. Conferences in particular are supposed to give audiences a taste of what’s coming—they can be a great way of quickly finding out what’s exciting in the world of development. But we shouldn’t feel bad if those topics don’t match our day-to-day reality.

Ultimately what matters is building something—a website, a web app, whatever—that best serves end users. If that requires a new and exciting technology, that’s great. But if it requires an old and boring technology, that’s also great. What matters here is appropriateness.

When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.

This was originally posted on my own site.

A Professional Development Framework for Design Tue, 02 Apr 2019 13:59:00 +0000 Clearleft has been working on a professional development framework to share with the UX Design community. Here’s how, and why, we’ve arrived at something we hope is potentially valuable to you or your design team.

A work in progress

Mindful of the general sense that the design profession has historically been terrible at elaborating on career paths and progression, and inspired by some of our recent speakers at Leading Design and other conferences over the past few years, we’ve arrived at something we wanted to put out into the public domain.

For many years, Clearleft was exclusively a ‘seniors’ only club, where every practitioner had over 10 years experience in the bag, and this badge of honour formed an explicit part of our USP to clients. Over the past few years, as the Clearleft team has grown in size and capability, we’ve naturally hired more junior members of staff. With less seniority has come more appetite and need for mentoring, support and structure to aid and accelerate professional development.

However, on reflection and with the benefit of hindsight, even when we were a shape that was dominated by seasoned veterans, we were often guilty of throwing people in at the deep end, under the naive assumption that those who would swim could ultimately succeed at a company where autonomy and ownership are key characteristics needed to thrive. As an adhocracy, we prided ourselves on our lack of documented processes, ‘can-do’ attitude and ability to improvise under pressure. But we probably all suspected (and ultimately learnt) that regardless of seniority some semblance of structure was required to navigate cultural norms, manage expectations and accountabilities, deliver work productively, and anchor to a deeper purpose that made more explicit everyone’s contribution to the ‘Clearleftiverse’. This was true, even when any imposed structure needed to be experimental and adaptable to change, a core belief at Clearleft.

As we continue to be a relatively small and vociferously anti-hierarchical company, we appreciate the importance of giving all team members a clearer sense of where they can progress, or what they can specialise in. And not just within Clearleft today, but beyond that. Whilst there is an undoubtedly special bond that exists amongst all Clearleft alumni we’re not only comfortable with, but also active supporters of, enabling people to achieve their career dreams beyond their time at the company. Clearleft are just one part of a much bigger individual journey and a broader career path. Our passion for the digital community and our innate collective desire to make a meaningful contribution towards enabling design to thrive beyond our studio is something that continues to excite and motivate us. The success of ex-employees is one part of that which continues to make us all proud.


Measuring what counts

The first challenge of any measurement framework is ensuring there is a focus on what is meaningful. As Drucker (may or may not have) said “What gets measured gets done”. Essentially as we were aware that a measurement framework would have an impact on behaviour, encouraging the right behaviours and discouraging the wrong ones would be critical.

Clearleft is a place where collective values and behaviours are intrinsic to our way of working and continued success as a design studio. And moreso than any other company I’ve worked for or with, IMHO. When deciding on what to measure, and indeed what to ignore, we therefore felt it important to find a way to wrap up an expression of our values into the framework.

Our values

  • Make it great over good
  • Don’t go it alone
  • Own it
  • Be fleet of foot
  • Speak your mind
  • Learn, share
  • Feed your curiosity
  • Work to live, love to work

A number of overarching themes within these values felt appropriate to measure as core skills, namely Communication, Problem solving, and Empathy.



Participate and facilitate collaborative group activities and/or workshops with colleagues or clients.

Speak publicly or present to an audience articulately and persuasively.
Open to seek, receive and give constructive feedback on your work or the work of others.

Problem solving


Pro-actively own and be accountable for solving problems under your own initiative.

Understand, apply and adapt your approach to problem solving.
Shape, coordinate and lead activities on project work with colleagues and clients.

Empathy skills


Build strong relationships with colleagues and clients.

Support & Recognition
Support colleagues when they need help, and outwardly recognise the hard work of others.
Advocate for a shared understanding of the needs and concerns of users, customers or audiences.

CPD Trello board
A section of the CPD Trello board

With these core skills serving as the foundations, we were then readily able to identify a suite of specialist skills across the themes of Strategy, Design and Leadership.



Understand and articulate a clients mission, goals and desired outcomes, analyse their domain, and inform the vision and strategic direction of their products or services.


Diagnose project challenges and opportunities through evidence-based investigation and research.


Map the architecture of the user experience.


Create, adapt or interpret brand guidelines and translate them into tangible artefacts and experiences.



Explore, iterate and improve on a broad range of ideas and potential design solutions.


Produce elegant, usable and responsive user interfaces and user experiences within known technology constraints.


Validate design concepts and solutions with end-users and/or business stakeholders to measure the impact of design.



Lead or manage others to do better work and shape the strategic direction of the organisation.


Support the ongoing professional development and growth of colleagues.


Coach and train others to learn new skills, techniques and ways of working.


Each of the 19 skills are measured on a five point proficiency scale: Beginner, Novice, Intermediate, Expert, Master. The proficiency scale is intended to mirror the likely capability of a population along the lines of a bell curve distribution, with Beginner level typically reflecting a minimum benchmark for graduates or interns, and Mastery being the culmination of many years of hard work or serving as an aspirational, often career-defining, pinnacle of achievement. Most people will exist within the Novice to Expert proficiencies, which are intended to map neatly to obviously recognisable stages of any given career or skillset: from Junior through to Senior.

Where next?

The ambition is to have a universal framework that recognises and expresses the breadth of capability, both individually and across the company. Given the diffusion of skills amongst digital professionals, we’re acutely aware of the risks of putting individuals into explicitly narrow, pre-defined categories that can ultimately harm growth and professional development. As such we’re consciously trying not to design a system that stifles the unique attributes of any individual member.

With 19 measurable categories so far we believe there’s enough flexibility to avoid this. However we’re also mindful to introduce clarity around which roles and seniorities demand which subset of these skills and proficiency levels as essential prerequisites for promotion and salary compensation. Clearly this is a fine balancing act, but one we’re currently in the process of developing and refining further, along with a means by which to measure and evidence the criteria for progression in a more tangible way, that doesn’t inadvertently encourage gaming the system.

The Trello format is an unglamorous and occasionally cumbersome one, but for now is one well-suited to our tool agnosticism and the relative informality and conversational nature of how we manage performance and line management at Clearleft. Each individuals unique and private Professional Development board is fed from a root source of Skill & Proficiency definitions that exist on a shared board. This is something we’ll be looking to develop into more useful, easily communicable visualisations (e.g. Radar Charts), via a more robust and sustainable platform in the coming iterations of the framework. So watch this space.

Explore the framework

View the Professional Development Framework (v0.1)

What is design fiction? And how can you use it? Mon, 25 Mar 2019 14:39:00 +0000 Andy Budd explores how science fiction impacts real designs.

Like me, I’m sure many of you grew up on a diet of science fiction; imagining future worlds through the work of authors like Isaac Asimov, Philip K. Dick and William Gibson. Science fiction, or speculative fiction as purists prefer to call it, has the power to transport us into the future to ask important and difficult questions about the world we’ve created, including where experimental design will take us in the world of tomorrow.

Science fiction novels are where many great tech innovations start life

Of course, the questions posed by science fiction aren’t really about the future; instead they’re extrapolations of present concerns. Think of the Snowden revelations, ad retargeting, or articles like ‘My Roomba tried to eat me’. By projecting concerns into the future, and taking them to their logical — and sometimes absurd — conclusion, authors can create safe spaces to discuss them.

This means that while science fiction can’t be used to predict the future, it can be used to explore current trends. Or as William Gibson famously said, “The future is already here, it’s just not very evenly distributed”. A good piece of speculative fiction can make something new and novel feel almost inevitable.

Can speculative fiction create the future?

While speculative fiction is often used to explore moral conundrums, doing so can have unexpected (and sometimes negative) consequences. For instance, the oft-cited Minority Report primed audiences to expect a future where adverts could literally follow you around.

So when a tech company suggested the City of London used its connected recycling bins to track the MAC addresses of passing phones and target pedestrians with adverts, you can bet that movie was front of the bin designer’s mind. What the director undoubtedly meant as a warning, ended up becoming reality.

Seeing something on screen can have a powerful effect, making a vague concept feel solid and real. This is probably why there were no gasps of awe and wonder when the Oculus Rift came out; we’ve seen examples of VR in countless (admittedly terrible) movies like The Lawnmower Man. It’s a piece of technology that felt like it was 30 years old by the time it arrived — the modern equivalent of the flying car or a personal jet-pack.

In the now-famous documentary How William Shatner Changed the World, the makers argued that the Star Trek communicator was the inspiration for the StarTAC mobile phone, while the first tablet to appear on screen wasn’t in an Apple or Microsoft corporate video, but in the hands of the Next Generation crew.

Today we have seven teams battling for a $10 million XPRIZE to create a working Tricorder. Star Trek seems to be getting less and less fictional every day.

A vintage Star Trek Tricorder by Joe Haupt

Similarly, when a few months ago we passed the date that Back to the Future II was set, a surprising number of predicted inventions — from self-lacing boots to hoverboards — had indeed come to pass.

It would appear that science fiction movies have the amazing ability to imagine future products, free of the typical constraints, then inspire others to work out the details. If only there was some way real product companies could harness that power?

Are we being primed?

I’d always assumed this foreshadowing of future technologies was accidental, until I saw a presentation from a Microsoft executive who practically admitted that they liked to seed early product concepts into movies, presumably to prime the audience for future tech arrivals.

Since then, I’ve been highly sensitive to any brands I see in sci-fi movies, as a way of speculating on what the big technology companies may be working on. I wonder if Google Glass would have been any more successful if we’d seen Ethan Hunt wearing a pair in Mission Impossible 4?

Like many large tech companies such as IBM and Apple, Microsoft has used the field of speculative fiction to explore possible futurescapes for a long time.

A recent example of this is the Microsoft Office Labs vision of 2019 videos, which show lots of smiling people representing a wide-reaching demographic standing in front of giant glowing interactive sheets of glass as they go about their school, office or home life.

Microsoft Office Labs imagines a future filled with glowing transparent screens

It’s easy to mock these glossy corporate videos, not least because of the impracticality of standing for long periods of time with your arms raised, interacting with giant transparent screens.

It’s clear many of these videos draw more upon the storytelling tropes of Hollywood than the skills of the designer. However, while these large companies may have popularised the field of ‘Design Fiction’, small interaction design studios have started using similar storytelling techniques in their daily client work.

Design fiction in the design studio

The first time I saw design fiction from a small studio, it was the work BERG did for the publishing company Bonnier. Its Mag+ video created a rich picture of what a digital magazine might feel like in the future, well before the first iPad was available.

With an approach known as ‘animatics’ — essentially animated storyboards — it used a simple green-screen technique to superimpose UI animations onto a mockup of a tablet, and breathe life into an inanimate product.

Using a video prototype meant the designers were able to do a much better job of communicating the experience than any set of wireframes or clickable prototype, with much less effort. Around the same time IDEO released a similar speculative design project, this time imagining the future of the book.

The team at BERG imagined the future of digital magazine before the iPad launch, using the power of ‘animatics’

The more I started to look at this form of speculative design, the more agencies and individuals I found exploring this technique — usually at the fringes of our industry in ad agencies or physical product companies. One thing they all seemed to have in common was a relationship with the Design Interactions course at the Royal College of Arts led by Dunne & Raby, the recognised leaders in the field of speculative design.

Of course, not everybody has a team of RCA graduates or the After Effects skills to create such realistic renderings, so at Clearleft we often mock up simpler effects using a combination of video, photography and animation in Keynote. It’s amazing how a few simple tricks like this can breathe life into an otherwise flat and lifeless prototype!

Explore your vision with comics

Animation is fast becoming a core skill in the interaction designer’s toolbox, but an even easier way to start exploring the field of design fiction is by using the same techniques you might find in the design of comics.

The team at Lowe’s innovation lab in the US made liberal use of comic book techniques in order to both explore and communicate the vision for its Holoroom concept. It went as far as hiring science fiction authors to help create realistic narratives.

The Airbnb team did a similar thing when it hired Pixar artists to help visualise the future of its customer experience. In the case of Lowe’s, this helped convince its management that an admittedly off-the-wall concept like a Holodeck (another Star Trek invention) could actually be made real.

Lowe’s used a comic book technique to imagine how its in-store helper robot might work

After pitching the comic book idea to his exec board, Kyle Nel from Lowe’s explained, “It was a gamble, but they loved it. They totally got it, and started building on the ideas in the comic.” For Airbnb, the visualisation gave it the insight it needed to double-down on its mobile strategy.

The good news is that you don’t need to hire sci-fi writers and Pixar artists to do this effectively. Kevin Cheng has been using comic books to communicate design intent long before it became fashionable, and his book See What I Mean is a great primer in the field.

Kevin Cheng is known for his comics that explain design thinking

Where does projection end and fiction begin?

We’ve been using prototypes and storyboards to communicate design intent for years, but how is ‘design fiction’ any different? When does something stop being a simple communication tool and start being a work of design fiction?

At the final dConstruct, Nick Foster explained how he broke design down into three categories; now, next, and future. You could argue that any piece of design work that falls outside of ‘now or next’ could be considered a work of design fiction.

As such, you may have found yourselves engaging in design fiction without even realising it; coming up with concepts for pitches or board presentations to give stakeholders a sense of what could be possible.

A few years ago a large, international high street bank asked us to imagine what online banking might look like in the future. We created a rich vision of how online banking could work across a range of devices, without worrying too much about the implementation details.

We knew that the concept would theoretically work, but we weren’t limited by the company’s existing technology stack. This freed us up to be more creative than we may have otherwise been, allowing us to leap over the now and next, and explore what the future of banking could hold.

More recently we created three vision videos for a well-known healthcare start-up, to help them articulate a range of possible futures. The goal wasn’t to deliver these products in 3–6 months time. The goal was to buy into their vision of where the company was heading in 3–6 years time. Off the back of these video prototypes, the company was able to raise millions in additional funding to start them out on the journey.

Near Future Laboratory is a specialist studio dedicated to developing the ideas of the future

Companies like the Near Future Laboratory take design fiction to its natural conclusion by blurring the line between art and design with its TBD catalogue.

Its fictionalised mail order catalogue contains 166 products and services that could potentially exist in the future, sparking both ideas and debate in equal measure. Near Future Lab’s collaborator The Extrapolation Factory also featured as part of the Designers of the Year exhibition at the London Design Museum.

The show was called 99c futures, and it explored the kind of products you might expect to see in a 99c store 20 years from now. Nick Forster calls this the ‘Future Mundane’ and believes the future will look a lot more normal than the sci-fi interface designers would have us believe.

Where to start

Designers might find it difficult to start selling design fiction as an activity to their clients right away. It could seem slightly wacky and off-beat at first, but you could take a leaf out of the Near Future Laboratory’s book and start crafting sci-fi futures for yourselves.

On a smaller scale, design fiction could be used to sharpen your skills at an internal hack-event, or to demonstrate design thinking as part of a possible recruitment task. At Clearleft I’ve used Matt Jones’ concept of Mujicomp to sharpen interns’ design skills.

We set them the task of designing a future product they could imagine being sold in the Japanese lifestyle retailer Muji by allowing them to hack, combine and re-imagine random items bought from the store. This simple MacGuffin provides the opportunity to unlock a wealth of creativity from designers who might be used to getting briefs that focus on ‘now’ or ‘next’.

The Near Future Laboratory created a real catalogue featuring 166 products from the future

Ultimately you could argue that all design is in some way a work of fiction — imagining something that doesn’t yet exist, and then communicating that vision to clients, customers and tech partners. However, by freeing designers up from practical concerns and allowing them time and space to speculate, they may just stumble onto their next big idea.

I believe design fiction is becoming an increasingly useful way to explore and communicate possible design futures. In order to create a better future, designers should be adding techniques for designing fiction to their toolbox today.

Originally published at

Clearleft at CERN: celebrating 30 years of the Web Tue, 12 Mar 2019 11:00:00 +0000 CERN is celebrating the 30th anniversary of the Web today, and we’re proud to play a small part in the proceedings.

In March 1989, while working at CERN, Sir Tim Berners-Lee wrote his first proposal for an internet-based hypertext system to link and access information across different computers. His proposal became the World Wide Web. CERN is celebrating the 30th anniversary of this revolutionary invention with a special event today, and a series of other celebrations around the world.

The Web@30 event at CERN kicked off this morning with a fascinating panel discussion featuring Sir Tim Berners-Lee, Robert Cailliau and other Web pioneers sharing their views on the challenges and opportunities brought by the Web.

The live audience in Geneva comprised a select group of invitees, which we’re very proud to say included one of Clearleft’s cofounders, Jeremy Keith.

As part of a project to preserve some of the digital assets associated with the birth of the Web, Jeremy worked on a project in February to recreate the very first browser using current technology.

Previously, Jeremy also worked with CERN to organise a project to recreate the line-mode Web browser.

On being invited to CERN to join the celebrations, Jeremy wrote:

I’m so excited about this! I’m such a nerd for web history, it’s going to be like Christmas for me. The whole thing will be over by mid-morning. Then, [team member and fellow Brightonian] Remy and I will take an afternoon flight back to England …just in time for the evening event at London’s Science Museum.

Personas aren’t bad, and you’re not a bad designer if you use them Mon, 11 Mar 2019 11:28:00 +0000 With disturbing regularity, my Twitter stream seems to explode with posts demonising commonly used, yet seemingly harmless design tools.

These posts take great pains to document all the ways these tools have failed people in the past (while downplaying or ignoring a situation where they may have helped). Reading one of these threads you’d be forgiven for thinking these tools were actively harmful; some sort of public health nuisance this brave whistleblower was uncovering for the first time. Although they generally read more like the hysteria surrounding MMR vaccines to me, rather than any reasoned or measured debate. Instead, they’re full of personal anecdotes and half-truths, wrapped up in a thin veneer of scientific speak. One such debate I witnessed recently revolved around Personas.

Now the love/hate debate around personas is nothing new; in fact, it’s been rumbling on for some time. I personally have no great love for personas — that would be a little like loving a hammer or a chisel — but I have no great hate for them either. Personas are tools like any others, with their own relative strengths and weaknesses. So while every few months a new tool comes along claiming the previous one is now dead–in this case, Jobs to be Done — I’m much more interested in developing a rich toolbox of tools to draw upon, than engaging in a Battle Royal style deathmatch.


Whenever the vilification of personas pops up its ugly head, it always goes something like this. “Personas are bad because they’re usually made up and therefore have no empirical backing”, “Personas are bad because they try and segment people and people are too unique to be segmented”, “Segmenting people is bad on principal and tantamount to discrimination”, “Personas are just a bunch of demographics and are therefore completely useless”, “Even if personas aren’t just a bunch of demographics, they are so badly used that we should just stop using them”.

While all these arguments annoy the hell out of me, the last one is the worst. The idea that because something is badly used, we should ditch it, is a blatant call for ignorance. Personally, I think if something is poorly or wrongly used, it’s our responsibility as experts, craftspeople and educators, to help people understand how a particular tool or technique works, rather than just throwing it–and the people using them — away like yesterdays garbage.

The misconceptions

So let me address some of these other common misconceptions about personas. The first and most pernicious is the idea that personas are just a bunch of — often made up — demographics featuring a persons age, gender, job, hair colour and little else. Now if this was the main content of personas I could understand the frustration. However, that’s just not the case.

I think this misconception comes from the world of marketing, where marketing personas generally are more focussed on demographics. That’s because marketing personas are generally used to try and capture, understand and categorise fairly broad ranges of preferences, and then understand where people holding those preferences spend their media browsing time, to better focus marketing spend. That’s all well and good for our friends over in marketing, but this sort of approach provides very little value when it comes to Interaction Design.

Instead, the use of demographics in personas is really there to add a bit of background detail, to make these pen portraits a little more realistic and memorable. This is because the true value of personas is a communication tool. As a way of synthesising a large amount of rich and complex data, generated through observations, interviews and surveys, into something that can travel around an organisation, and be consumed by people who weren’t necessarily involved in the conversation, or even have regulated access to customers. In these situations, it’s helpful if the persona is recognisable as a person, with a name, a background story and a set of attitudes and beliefs.

The question then is, if personas are a communication tool, what are they communicating? Well in general, the most useful part of any persona is the User Scenario; the area on the page that describe the sort of problems these users are facing, the behaviours they exhibit, and if you want to use that particular language, the jobs they want to get done.

Personas Vs Jobs To Be Done

I think this is one of the reasons why a lot of people claim that Job Stories and JTBD do away with the need for Personas, and I think in some situations that may be true. If you’re working in a fast moving engineering focussed start-up, servicing an incredibly wide demographic with a similar set of needs, and everybody in the company is very user-centric and in touch with those needs, you can probably do away with the touchy-feely fluff and focus on the core jobs; it’s just a lot of unnecessary distraction.

However, if you’re working in a traditional organisation serving a smaller range of fairly distinct behaviours, and you need to get your stakeholders out of the mindset that all customers think and behave the same, or worse, all customers think and behave the way the executive team do, personas may be of some use.

In some way, you could argue that personas and a useful step on the journey towards JTBD, but if you’re already there, they probably hold little additional value. Personally, I like the ability to reference John, Mary, Prisha, or Joaquin as a placeholder for a set of behaviours, rather than sifting through half a dozen job stories to explain what set of problems we’re solving for today. It’s efficient and travels well, even if there is a certain loss of fidelity.

Understand their limitations

The best personas generally are based on research data. You’ve surveyed hundreds or thousands of customers, you’ve interviewed dozens more, you’ve crunched the data and found certain patterns. Maybe you’re a travel company and have noticed that parents and children tend to travel short haul for a week or two, over the school holidays? Maybe the data has surfaced another cluster of younger travellers who prefer cheap city breaks, anytime other than the school holidays. Maybe you discovered a third cluster of people who travel for business and generally (but not always) fly business class, use the lounge and prefer to be back home for the weekend. This is a fairly trivial example, but I hope you get my drift.

Knowing this information may allow different product teams to tailor different experiences for different clusters of behaviour. This obviously beats treating every customer as the same, but isn’t as good as building up a rich and individual picture of behaviour by acquiring tonnes of data about the user and feeding it into a sophisticated CRM system. Many tech firms have these capabilities, which is another reason why they probably look down on personas and those who use them. However, you’d be amazed how few traditional businesses are able to significantly alter the merchandising offering, let alone the whole user journey, based on detailed data capture.

Now it’s worth pointing out that nobody is saying that you can’t be both a business traveller, a city breaker, and somebody who is looking for a fly-and-flop holiday with their family. Similarly, while the Personas may suggest that city breakers tend to be younger than people travelling with families, the actual data shows considerable overlap. In fact, you may find a cluster of retirees who take their grandchildren on holidays on their own and also like city breaks.

Fortunately, personas aren’t rigid definitions, but rather porous archetypes, so people will move between the two. Something this will happen over years. Other times it will happen in a single session. The key to any successful model is realising that it’s only a model, and therefore has limited scope. Sometimes it’s useful to think about light in terms of a wave, other times in terms or a partial. A good craftsperson understands the strengths and weaknesses of each model and uses it appropriately, while a poor craftsperson generally blames their tools.

Which comes on to my last point, the inevitable cargo-culting of any and all design tools. As a quick recap, cargo cults emerged amongst Pacific Islanders who tried adopting the object and rituals of western colonial power, without realising how things really worked. So they would build wood and reed airplanes, control towers and airport terminals, in the hope that American GIs would return with their cargo, without realising the intricacies of world politics, aviation, and international trade. They basically just copied what they saw other people doing in the hope it’d work. I see this all the time in our industry.


It’s frustrating to see people behaving this way, and if it was just themselves they were hurting, I wouldn’t mind as much. However, when these things blow up, the outrage and misinformation tend to travel much further than a reasoned argument about the pros and cons of a certain tool or technique ever could. The resulting blast radius is huge, and a lot of innocent people often get caught up in the ensuing chaos. After all, if you were a relatively newly minted designer and somebody you trust with 20k followers on Medium, tells you that the thing you were taught as school is no longer useful, and all the smart people are now using something else, what are you going to do? Well, you’re probably going to ditch one tool in favour of the other and may go around telling others to do the same. This is how MMR scares and market panics start.

Foster critical thinking

Fortunately, we’re not dealing with anything nearly as serious here, and at least you’ll end up with a tool in your tool box. However as the saying goes, if all you have is a hammer, everything looks like a nail. Even if you spend most of your time hammering nails into blocks of wood for a living, I think it’s worth understanding what a screw looks like, and when to use it, rather than trying to hammer a screw into a block of wood once or twice and then claiming that screws are rubbish.

As a professional we all benefit from having a variety of tools at our disposal, instead of falling for the hype around silver bullets and one size fits all solutions. We’d also benefit from a bit more critical thinking in our industry. Arguments that go along the lines of “This thing hasn’t worked for me, so it cannot work for anybody” are super reactionary. They stifle intellectual curiosity, rather than encouraging people to expand their horizons and learn new things.

If you’ve discovered a new tool that works for you, by all means share what you think is great about it. Similarly, if you’ve found legitimate weaknesses in existing tools, please share that information so we can all learn and grow. However we live in incredibly polarising times, and debate through opposition is super easy. Just remember that it isn’t always necessary to raise one thing up by knocking something else down. That it’s a large world out there and we benefit more for variety and choice than a limited set of (largely manufactured) binary opinions.

Originally published at

Handing back control Sat, 09 Mar 2019 21:22:00 +0000 An Event Apart Seattle was most excellent. This year, the AEA team are trying something different and making each event three days long. That’s a lot of mindblowing content!

What always fascinates me at events like these is the way that some themes seem to emerge, without any prior collusion between the speakers. This time, I felt that there was a strong thread of giving control directly to users:

Sarah and Margot both touched on this when talking about authenticity in brand messaging.

Margot described this in terms of vulnerability for the brand, but the kind of vulnerability that leads to trust.

Sarah talked about it in terms of respect—respecting the privacy of users, and respecting the way that they want to use your services. Call it compassion, call it empathy, or call it just good business sense, but providing these kind of controls in an interface is an excellent long-term strategy.

In Val’s animation talk, she did a deep dive into prefers-reduced-motion, a media query that deliberately hands control back to the user.

Even in a CSS-heavy talk like Jen’s, she took the time to explain why starting with meaningful markup is so important—it’s because you can’t control how the user will access your content. They may use tools like reader modes, or Pocket, or have web pages read aloud to them. The user has the final say, and rightly so.

In his CSS talk, Eric reminded us that a style sheet is a list of strong suggestions, not instructions.

Beth’s talk was probably the most explicit on the theme of returning control to users. She drew on examples from beyond the world of the web—from architecture, urban planning, and more—to show that the most successful systems are not imposed from the top down, but involve everyone, especially those most marginalised.

And even in my own talk on service workers, I raved about the design pattern of allowing users to save pages offline to read later. Instead of trying to guess what the user wants, give them the means to take control.

I was really encouraged to see this theme emerge. Mind you, when I look at the reality of most web products, it’s easy to get discouraged. Far from providing their users with controls over their own content, Instagram won’t even let their customers have a chronological feed. And Matt recently wrote about how both Twitter and Quora are heading further and further away from giving control to their users in his piece called Optimizing for outrage.

Still, I came away from An Event Apart Seattle with a renewed determination to do my part in giving people more control over the products and services we design and develop.

I spent the first two days of the conference trying to liveblog as much as I could. I find it really focuses my attention, although it’s also quite knackering. I didn’t do too badly; I managed to write cover eleven of the talks (out of the conference’s total of seventeen):

  1. Slow Design for an Anxious World by Jeffrey Zeldman
  2. Designing for Trust in an Uncertain World by Margot Bloomstein
  3. Designing for Personalities by Sarah Parmenter
  4. Generation Style by Eric Meyer
  5. Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
  6. Designing Intrinsic Layouts by Jen Simmons
  7. How to Think Like a Front-End Developer by Chris Coyier
  8. From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
  9. Move Fast and Don’t Break Things by Scott Jehl
  10. Mobile Planet by Luke Wroblewski
  11. Unsolved Problems by Beth Dean

This was originally posted on my own site.

Ghosting Candidates and Marathon Interviews: The Modern Recruitment Experience Fri, 08 Mar 2019 09:30:00 +0000 The digital sector is a talent led industry, and as much as I dislike the idea of the 10X developer, the difference a great hire can make to your business is huge. So I’m always amazed to hear about the shady, sloppy or downright atrocious recruitment practices we inflict on prospective candidates.

There was a time, not so long ago, when you could expect a polite acknowledgement of a job application, an explanation of the process and steps involved, and feedback if you weren’t successful. These days, ghosting candidates seems to be the norm. Hiring managers will claim that they are inundated with responses, so it’s just not possible to acknowledge every application, or inform people when they have been unsuccessful. They’ll also claim that overly aggressive legal requirements and an increasingly litigious environment means it’s no longer possible to provide candidates with feedback. Personally I don’t buy either of these arguments.

The volume of job applications has always been high, and if talking to hiring managers is anything to go by, the challenge they face is having too few qualified candidates rather than too many. While it used to be the case that applicants would apply for jobs via email, a large part of the process has now been automated. So the use of hiring tools with their set processes and templated responses, makes it harder to hide behind the excuse of volume.

I can sort of understand why, if you’ve received over a hundred applications for a specific role, it may not be practical to respond to everyone individually. However if somebody has taken the time to come in for an interview, I think you owe it to them to let them know why they failed to make the cut on this occasion. It’s not only polite—and generally the right thing to do as a human being—but failing to respond with the appropriate level of care and attention can have negative results.

The feedback I’ve heard about interview practices isn’t much better. Overly long, marathon interviews where the candidates are left feeling broken and exhausted by the end. No offers for tea or coffee, no breaks, just a revolving door of stakeholders peppering them with a seemingly random barrage of question. The lack of any coherent narrative makes these team interviews especially torturous. Randomly jumping from topic to topic with no logical segues, or being forced to answer almost identical questions posed by people who weren’t in the room to hear the answer you gave 20 minutes earlier. This unrelenting style of interviewing feels at best like a popularity contest and at worst like a form of interrogation, intended to break the will of an unsuspecting candidate.


While some hiring managers may be impressed by one candidates ability to bullshit their way through a series of essentially random questions, it’s not an especially good indicator of future success.

This brings us nicely around to the issue of interview tasks. Now I’m actually in favour of tasks in certain situations, particularly when you’re hiring junior roles where people have talent, but lack a broad portfolio of work to show. It can also help level the playing field between agency designers with lots of exciting bands in there portfolio, and people who have been in-house for a long time working on a single product. However I also admit that in most cases, tasks are planned and delivered poorly, and can have a negative toll on the recipients.

One big problem with tasks is when they focus on a real problem the company is facing, and end up feeling little more than spec work. Here is a poorly stated problem, and the person who comes up with the answer we like the most wins. Another common problem are tasks that are set a week in advance, and given fairly tight deadlines. Some people will be able to fit this work around their existing work and family commitments, while others won’t. As such, I tend to prefer whiteboard tasks that take place during the interview process itself. Even then, these things are often dropped on candidates without any notice, a process which borders on abusive in my book.

As product people and technologists, we’re meant to have empathy and understand the human condition, yet little if any thought goes into the candidate experience. I guess this wouldn’t matter so much if you had hundreds of qualified candidates knocking down the door, but this often isn’t the case.


Often more so. I’d argue we’re in a supply driven economy at the moment, where the best applicants will be choosing between 4 or 5 employers. In this situation, it’s your job to sell candidates on your company, and no glossy vision deck or lists of aspirational values will subvert a painful and broken interview process.

It’s also worth remembering that the digital industry is highly networked and super tight. If an applicant puts a tonne of work into an application, undertakes a remote task, and comes in for an interview, only to be ghosted by the company, you better believe they’re going to tell their friends. The old marketing adage goes that a happy customer will tell one of their friends, while an unhappy customer will tell ten. The same is true of the recruitment process.

I know a surprisingly large number of influential people who feel aggrieved towards certain, well known companies, because of the way they were treated during their recruitment process. They’ve told their friends over coffee, shared their experience in closed networks, and put dozens of people off of applying in the future. This isn’t where you want your brand to be.

Even if the experience wasn’t so bad as to be noteworthy, a lot of candidates will feel so bruised and battered by the experience they they’ll be put off from applying again. This is a huge loss as, just because the candidate wasn’t right for you now, doesn’t mean they won’t be right for you in the future.


We explain what we liked about the candidates–and what they needed to work on–while making it clear that we really valued their time and would gladly consider them for future openings.

So rather than ghosting or hazing candidates, and leaving a bad taste in their mouths, we need to try and create the best recruitment experience possible. So even if the candidates aren’t successful, they leave thinking that you’d be a great company to work with, will recommend you to their friends, and jump at the chance we a future job opportunity comes along. This isn’t just a case of playing the long game—It’s the fair and decent thing to do.

This was originally posted on my blog

6 Tips for Successful Digital Transformation Tue, 05 Mar 2019 10:00:00 +0000 Digital transformation. It sounds so grandiose, doesn’t it? Like some sort of beautiful metamorphosis: an ugly caterpillar of old tech magically becoming a beautiful butterfly, resplendent in its new digital wings.

If only it were that magical. The reality is that digital transformation is damned hard.

Having worked with clients and companies of various size and shape over the years, I’ve noticed a few commonalities and trends that seem to pop up. If you’re in the midst of a transformation or about to embark on that metamorphosis of pain, these tips are for you.

1. It’s not about the tech stack

Most digital transformations are borne out of a need to re-platform. Companies suddenly recognise, invariably too late, that the technology platforms on which they spent a lot of money back in the day are now rapidly becoming obsolete. Inevitably the company focuses on the technology. But technology doesn’t make the world go round, people do.

The term ‘people’ here is purposefully broad. It refers to people on both sides of the coin: those who provide the new technology, and those who use that new technology.

In the end, digital transformation is just a fancy metaphor for embracing the shift in customer behaviours towards digital. If your customers can’t find, interact, buy or communicate with you digitally, you’re going out of business.


Pro tip
If your product isn’t usable — by real people, — then it doesn’t matter if your new tech platform makes unicorns appear: it will lose money.

2. Get a visionary

Transformation projects without a North Star don’t work. To call it a success you’ll need someone who holds the vision in their heads and a resolve to get sh*t done.

This person (or persons) needs support to see out the business goal, without sacrificing user needs in the process. This mystical, overlapping Venn diagram is not easy. It needs significant corporate experience and political nous to come off. Choose your visionary wisely.

Pro tip
Find someone to lead the charge, and — get this — someone who actually gets digital. This sounds a lot easier than it is.

3. Stop being risk averse

Barrelling headfirst into a transformation strategy without the appetite and ability to take risks is like running a marathon without running shoes. You can do it, but why would you?

Risk is an inherent part of change. You need to try new things and be open to new methods and approaches. You need to know that not all changes will work, but some will. An inability to manage or accept risk will only result in half-baked, unfulfilled projects, because senior stakeholders are too reluctant to try something new.

Sometimes ‘up top’ are too afraid to let ‘digital’ do what they do best. Being prevented from providing digital solutions to a digital transformation leads to a compromised and impaired end product.

Pro tip
Avoidance of risk is borne of fear of the unknown. Stakeholders who act as blockers are often unsure of what digital can (or can not) do. Improving an appetite for risk can be as simple as providing better education as to what’s being done, why, and how the business will benefit.

4. Digital literacy is a must

Having a literacy in digital isn’t as simple as knowing what digital things are called. It’s having a deeper understanding of the methodologies, techniques and strategies needed when dealing with a digital product or service, and how these will work in a business context. Knowing what digital can and cannot do is critical to ensuring a successful transformation strategy across any business.


A great example here is agile. You know, that word everyone uses in large orgs, but rarely do it right. I know agile was never meant to be prescriptive, but come on, having a standup once a day doesn’t mean you’re suddenly an agile organisation.

Agile needs time and oxygen. It needs to be both a top-down and bottom-up approach. Senior execs need to be as wedded to the idea as the practitioners at the coal face. Agile is a mindset, not a line item.

Pro tip
Ironically, language is the common denominator within digital transformation. Try to avoid terms like ‘sign-off’ which are steeped in historical contexts that no longer exist in the digital realm. Similarly, avoid the wonton use of acronyms and jargon when you can explain it using plain English.

5. Double-down on design maturity

Although hearing the phrase ‘design needs a seat at the table’ makes my skin crawl, the struggle is real. Design at most large organisations (those most likely to be undergoing seismic shifts towards digital) is tokenism at best.

Digital transformation is like an iceberg. 90% of the project is backend systems, re-platforming, evolving tech stacks and the plumbing. But the remaining 10% is what makes all that effort worth it. That 10% is where customers meet, interact with your company and buy from you. Be 100% sure it’ll include both digital and design.

If the senior stakeholders in your business still see design as making it look nice, you’ve got issues, my friend.

Design is about problem solving. It’s about reframing the problems and challenges faced by an organisation and alleviating them through design thinking methods. Though very few organisations today are 100% design mature, those that are striving towards it — alongside digital transformation — will reap the rewards.

Pro tip
Want to measure your design team’s outlook on design maturity? Share our Design Attitude 2019 survey.

6. Ship it

For all the hard work done by teams — often over years — in digital transformation projects, it doesn’t mean a thing if you can’t ship what you’ve created.

Large-scale transformation projects include countless moving parts. Stakeholders, technical requirements, Systems Integrators and many more.

That cacophony of voices and agendas can often counter-intuitively grind progress to a halt, rather than turbo-boost a transformation programme. The net result: your transformation has stopped focusing on shipping your best-in-class product. Instead, you’re just shipping your org chart.

According to Forrester Research, companies will never be truly transformed. It will be an ever-evolving dance of sensing and responding. Companies will continually adjust to changing online and digital behaviours.

Pro tip
Delivery or shipping in this context means continuous deployment. Bursts of activity, effectual releases and incremental growth. This is exactly what agile was made for; yet another reason to consider agile as a business-wide methodology rather than confined to development only.

Digital transformation is hard. It takes a long time. It costs a lot of money. Why waste that investment by taking shortcuts or approaching it the wrong way?

This has been a collection of my thoughts, gathered from working with clients during or at the start of a digital transformation. It’s as seen through a designer’s view. If you have a different viewpoint or would like to comment, find me at @aizlewood.

This post was originally published on Medium

What Women in tech means to us Mon, 04 Mar 2019 15:39:00 +0000 Women in Tech is a topic close to Clearleft’s heart all year round. We’re proud to buck the trend in terms of our workforce all the way up to our leadership team. But it’s finding the time to progress our industry beyond their project workload that we want to celebrate.

Gender equality in the workforce brings well known benefits - better communication, better support - but above all, being better at making amazing things happen. This month, as part of Spring Forward (a month-long celebration of the role of women in digital culture) two of our team are doing just that. They’re challenging the very nature of the industry by breaking down barriers.

Ladies that UX

Our UX Designer Hana runs the Brighton arm of Ladies that UX, a monthly meet up for ladies in the UX community to share, collaborate, and build their UX skills. This group is also open to women who are interested in UX and would like to learn in a friendly environment.

On March 6th she is hosting a talk focusing on the basics of UX. Inspired by Paul Adam talk at UX London “The end of naval gazing”. He notes that:


She wants to bring together disciplines, she’s inviting people across UX, Dev, Sales, Project Managers and Marketing to tackle some hands-on UX tools and exercises, to boost shared understanding and deliver a better experience that puts the user at the centre of our universe.

Ladies that UX brighton


Cassie is one of our front-end developers, she also hosts codebar Brighton – a weekly meetup to encourage groups underrepresented in tech to get into coding. Aiming to increase diversity in the tech industry the group cleverly brings together coding newbies with developers from across Brighton to mentor them (over pizza).

Further breaking down barriers she has also just launched codebar talks, where you’re encouraged to leave behind the laptop and attend a friendly evening of progressive chats around digital.

A group gathered for codebar talks Brighton

There are a whole host of other events running throughout March in parallel with Women’s History Month. We’re proud to be one of sponsor the event sponsors and to host many of the inspiring sessions downstairs at 68 Middle Street.

These aren’t just events about and for women, they are changing the way we work as businesses for the better, and that’s what we’ll be celebrating this International Women’s Day.

Patterns Day 2: June 28th, 2019 Thu, 28 Feb 2019 14:05:00 +0000 Surprise! Patterns Day is back!

The first Patterns Day was in the Summer of 2017, and it was a glorious—a single day devoted to all things design system-y: pattern libraries, style guides, maintainability, reusability. It was a lot of fun, so let’s do it again!

Patterns Day 2 will take place on Friday, June 28th, in the beautiful Duke of York’s cinema in Brighton. If you went to the first Patterns Day, then you’ll know how luxuriously comfy it is in there.

Tickets are £175+VAT. The format will likely be the same as before: an action-packed day of eight talks, each 30 minutes long.

I’ve got an amazing line-up of speakers, but instead of telling you the whole line-up straightaway, I’m going to tease a little bit, and announce more speakers over the next few weeks and months. For now, here are the first three speakers, to give you an idea of the quality you can expect:

  • All the way from the US of A, it’s Una Kravets, who needs no introduction.
  • From the Government Digital Service, we’ve got Amy Hupe—she’ll have plenty to share about the GOV.UK design system.
  • And we’ve got Yaili, now a senior designer at Microsoft, where she works on the Azure DevOps design system.

Patterns Day will have something for everyone. We’ll be covering design, development, content strategy, product management, and accessibility. So you might want to make this a one-day outing for your whole team.

If you want to get a feel for what the day will be like, you can watch the videos of last year’s talks

Tickets for last year’s Patterns Day went fairly fast—the Duke of York’s doesn’t have a huge capacity—so don’t dilly-dally too long before grabbing your ticket!

This was originally posted on my own site.

Marty's mashup Mon, 25 Feb 2019 15:05:00 +0000 While the Interaction 19 event was a bit of a mixed bag overall, there were some standout speakers.

Marty Neumeier was unsurprisingly excellent. I’d seen him speak before, at UX London a few years back, so I knew he’d be good. He has a very reassuring, avuncular manner when he’s speaking. You know the way that there are some people you could just listen to all day? He’s one of those.

Marty’s talk at Interaction 19 was particularly interesting because it was about his new book. Now, why would that be of particular interest? Well, this new book—Scramble—is a business book, but it’s written in the style of a thriller. He wanted it to be like one of those airport books that people read as a guilty pleasure.

One rainy night in December, young CEO David Stone is inexplicably called back to the office. The company’s chairman tells him that the board members have reached the end of their patience. If David can’t produce a viable turnaround plan in five weeks, he’s out of a job. His only hope is to try something new. But what?

I love this idea!

I’ve talked before about borrowing narrative structures from literature and film and applying them to blog posts and conference talks—techniques like flashback, in media res, etc.—so I really like the idea of taking an entire genre and applying it to a technical topic.

The closest I’ve seen is the comic that Scott McCloud wrote for the release of Google Chrome back in 2008. But how about a romantic comedy about service workers? Or a detective novel about CSS grid?

I have a feeling I’ll be thinking about Marty Neumeier’s book next time I’m struggling to put a conference talk together.

In the meantime, if you want to learn from the master storyteller himself, Clearleft are running a two-day Brand Master Workshop with Marty on March 14th and 15th at The Barbican in London. Early bird tickets are on sale until this Thursday, so don’t dilly-dally if you were thinking about nabbing your spot.

This was originally published on my own site.

Take the Design Attitudes Survey 2019 Mon, 25 Feb 2019 08:31:00 +0000 We’re on a mission to find out the real state of design in organisations in 2019. To join in, take our Design Attitudes survey.

As a strategic design partner, Clearleft works closely with in-house design teams. We see first hand the huge opportunity that design can bring to an organisation, and the challenges presented in integrating design into the corporate ethos. We want to find out more about the current state of design in organisations, and present our findings in a report for all to read.

To that end, we have created a survey to take the temperature of how designers feel that design is used and understood within their organisations. If you have a design role of any sort, then please complete the survey as best you can.

Take the Design Attitudes survey now

The survey should take no more than 7 minutes. The results will be anonymised and completely non–attributable.

We’ll be publishing our findings soon.

Hack Week Vs Design Sprint? Thu, 21 Feb 2019 16:38:00 +0000 I was in Geneva last week for a week of collaboration on an exciting project.

Our hack week at CERN to reproduce the WorldWideWeb browser was five days long. That’s also the length of a design sprint. So …was what we did a design sprint?

I’m going to say no.

On the surface, our project has all the hallmarks of a design sprint. A group of people who don’t normally work together were thrown into an instense week of problem-solving and building, culminating in a tangible testable output. But when you look closer, the journey itself was quite different. A design sprint is typical broken into five phases, each one mapped on to a day of work:

  1. Understand and Map
  2. Demos and Sketch
  3. Decide and Storyboard
  4. Prototype
  5. Test
Gathered at CERN, hunched over laptops.
Building a reproduction of the world's first web browser.

There was certainly plenty of understanding, sketching, and prototyping involved in our hack week at CERN, but we knew going in what the output would be at the end of the week. That’s not the case with most design sprints: figuring out what you’re going to make is half the work. In our case, we knew what needed to be produced; we just had to figure out how. Our process looked more like this:

  1. Understand and Map
  2. Research and Sketch
  3. Build
  4. Build
  5. Build

Now you could say that it’s a kind of design sprint, but I think there’s value in reserving the term “design sprint” for the specific five-day process. As it is, there’s enough confusion between the term “sprint” in its agile sense and “design sprint”.

This was originally posted on my own site.

Interaction19 - the Clearleft best bits Fri, 15 Feb 2019 17:30:00 +0000 A group of us at Clearleft have just returned from the Interaction 19 conference (“Design in the wild”) in Seattle, Washington.

It’s safe to say that we all had an excellent time - it’s always great to get away as a team, soak up some great thinking, discover new places and revisit old haunts. But rather than try to speak for everyone I’ve gathered together our highlights from the conference below - enjoy.

The Clearleft IxDA team

Scott Kubie

I attended Scott Kubie’s talk - ‘Let’s learn how to get the writing done’. Writing can, in all truth be hard. As a designer writing at times might often be left till last. I hold my hands up, I am guilty of using Lorem ipsum in the past, whether it was out of laziness, lack of content or the excuse of ‘I’ll write it later’. Kubie proposes a new way of thinking about writing; Workflow.


Scott's beautiful hand-drawn slides

He presented a practical approach that I will include in my design process moving forward. If you cannot wait for his talk check his post Writing for Designers.

Hana Stevenson

Tea Uglow

I enjoyed Tea Uglow’s talk “Normality is Stupid: Connecting the Dots Between Inclusion & Diversity and Selective Bias in Machine Learning”.

Tea started by showing us the bell shaped curve of a standard distribution graph, which is used to see where the average sits in a data set. She then shared very personal aspects about herself that easily fit outside of the ‘normal’ part of the curve and invited the audience to consider, that depending on the data used all of us could be excluded as well, “…if you think you are normal, one day you will be old”.

One of Tea's projects "Quick Draw!", which is publicly collecting the ‘world’s largest doodling data set.’

As we use data sets to define what reality is for AI and Machine learning, human biases are becoming a part of the technology we create. This has already shown to have potentially damaging effects when you look at unchecked data being used in AI systems trialed in job recruitment, healthcare and criminal justice sectors.

At the end, her message was simple but valuable. It is important to be critical about the data sets we use and collect and to think about how we represent the parts of ourselves that are not considered typical or normal.

Jerlyn Jareunpoon-Phillips

Nelly Ben Hayoun

I really enjoyed Dr. Nelly Ben Hayoun’s (the Willy Wonka of design) fast paced, energetic and furious talk about designing experiences. She drew upon a bunch of different themes and approaches to the projects she undertakes and reflected them in her delivery of the talk. Thinking Antonin Artuad’s Theatre of cruelty, the concept of “Hammering” and “total bombardment” should give you a good idea of the experience.

It was a great account of all of the good work she’s doing around the International Space Orchestra and the University of the Underground, a tuition fee-less university currently based under a London night club. Education meets Punk.

Tom Jansen

John Maeda

After two days of super varied talks and intense listening John Maeda’s talk on recovering and reinvention really stood out for me. He instantly grabbed the attention of the room with his witty and confident delivery.

He didn’t use slides throughout his talk and he didn’t need to - he prepared by simply sketching out a couple of illustrations that took us on a journey through his experience and stories about his life. He talked about ‘makers’ and ‘talkers’ which was his way of describing people who create and people who talk about creating. He described how he transitioned from a maker to a talker with anecdotes that resonated with everyone in the room.

Maker-maker, talker-maker, talker-talker - what are you?!

Amy Clark

Bryce Johnson & John Porter

There were a number of speakers over the three days that delivered thought provoking talks on the topics of ethics, empathy, inclusion and design; Liz Jackson, Jon Bell, John Lynch, Paul Cohen, Caroline Sinders to name a few.

However Friday’s Beyond Inclusion track included a talk by Bryce Johnson and John Porter – “Recognize Exclusion, Design for Inclusion” – that reframed the way I think about disability and made me question how we design and research for inclusion.

Two quotes from the talk really stood out.

The first defining disability not as a “personal health condition” but as “mismatched human interaction” has changed my perception of disability and the things we interact with.


The second, “the things we create embody the assumptions we have” highlights our responsibility as design practitioners not to be shortsighted of the implications of the things we create.

I left this talk with two questions. How can our testing hypotheses be extended to prevent the creation of disability? Who are the best people to include in our research that will help us prove or disprove these hypotheses?

Benjamin Parry

The obligatory styled Twinkie shot

Jon Bell

Jon Bell provided an enthusiastic glimpse into the world of ethical design considerations from his time in Twitter’s (anti) abuse team. He gave two practical pieces of advice that feel applicable for many designers whatever the scale or nature of the design challenge.

Listen before launching in. His first piece of sage advice was learnt through painful experience. When starting in his new team he turned up as the rock star designer coming to save the day. He soon learnt that complex challenges are better tackled once you have some detailed domain knowledge and your team are a superb source for this wisdom.

Document your learnings. The second takeaway was refreshing to hear from a company famed for its pride in ship fast, fix later. Maybe, it is a sign of silicon valley growing from adolescence to more mature thinking. Jon’s point was on a long, ongoing and nuanced design challenge, like designing to reduce and remove abuse, there is high value for new team members and old hands alike in capturing key insights. Something as simple as a wiki will enable knowledge to be socialised, shared and transferred.

Chris How

Bill Buxton

On my ‘list of favourites’ amongst John Maeda, Nelly Ben Hayoun and Jayeon Kim is Bill Buxton. He did a great job of, almost casually, exposing his depth of experience of the design industry. His talk challenged a lot of preconceived technology milestones and exactly how smart we design today. We may have missed sufficient nuance when the term ‘ubiquitous computing’ was coined, when in fact we were striving for ubeity.

Andy Thornton

Bill Buxton receiving due applause

Jayeon Kim

As well as a collection of stand-out talks by Bill Buxton, Liz Jackson, and John Maeda, among others, I particularly valued Jayeon Kim’s series of daily mindfulness exercise sessions, which offered welcome moments of calm amid the buzz of Interaction 19.


One of a notable handful of speakers whose presence temporarily transformed the atmosphere of the conference, Jayeon’s techniques immediately disarmed a room of ~1,000 people and had us all talking, laughing, and leaning on each other, before taking a few minutes to reverse our attention and be present in the only moment we can ever be: This one.

James Gilyead

Jayeon holding the room & keeping everyone in the moment

In summary

Getting away as a group to learn, experience new (and old) places continues to be something we really value at Clearleft, and documenting the good times for posterity seems fitting (and the perfect excuse to dust off my editing skills). Watch our best bits video (This was originally posted on my own site ).

Should you call yourself a UX Designer? Thu, 31 Jan 2019 14:19:00 +0000 There was a hot debate in the Clearleft studio recently: “Is UX Design dead?” Not the practice, mind you, but the job description.

I surveyed over 500 designers the end of last year.

  • 27% self identified as UX Designers.
  • 25.7% as Product Designers.
  • 9.8% as Experience Designers.

I haven’t had time to do the analysis yet, so don’t know if there are particular geographic, sector, or experience based trends. As this is the first one I’ve done I also don’t know if there are any time based trends. However I wouldn’t be surprised if we see the proportions flip in the next couple of years. But I think it’s safe to say (especially to all those pundits that claim UX isn’t a thing) that a good proportion of practitioners think it’s enough of a thing to identify themselves by …even if (as I suspect) we’ve reached peak UX.

It’s also worth noting that “Interaction Designer” and “Web Designer” were mid single figures, so I’d be happy to claim “UX Isn’t Dead” when UX Designer drops below Web Designer as a saleable job title.

What I’m really interested in understanding is whether there are any practical differences in skills and tool use between UX Designers and Product Designers, or whether the current dichotomy is primarily based on what’s fashionable.

Here’s my personal hot take (not backed up by data):

UX was popularised by agencies, so UX Designers generally require the skills to build new things over and over again.

Product Design comes out of start-ups, so Product Designers are required to optimise and extract value.

UX Designers often work alongside visual designers, so tend to focus more on the conceptual side of the equation. This means an increased focus on IA, formative research, and strategy.

Product Designers often work alongside Product Managers and Researchers, so tend to focus on visual design and interaction design over strategy (which is often set higher up).

That being said, the borders are super fuzzy. Some Product Designers will hop between early stage start-up and therefore share more DNA with UX Designers. Some UX Designers also do UI/Graphic design. So there’s usually more similarity than there is difference.

If you’re working for a tech company or a traditional company with a strong product management function and are mostly focussed on designing or iterating a single product, you’re probably a Product Designer.

If you’re working for an agency or an established company with a project focussed mindset, and are more focussed on the conceptual elements of design than the more traditional graphic elements, you’re probably a UX Designer.

And if you sit in the middle or bounce between the two, you can probably call yourself either.

Of course, at the end of the day you can call yourself whatever you want, and it will depend a lot on where you live, the type of companies you want to work for, how you want to be perceived, your career aspirations and a bunch of other things.

So the main point of this post isn’t to box you in, if you call yourself one thing but I’ve hinted that maybe you should call yourself something else. Instead it’s to help those people who don’t know what to call themselves.

Also worth nothing that I’m not claiming this is the only definition or even the right definition, just the model I’ve personally found most useful based on my own personal experience. Your mileage may vary.

So for all the people saying how confused they feel as a result of pundits saying things like “UX Designer isn’t a job” and “UX and Product Design are the same thing”… I hope this helps.

Building links Tue, 15 Jan 2019 15:55:00 +0000 Further reading for the upcoming talk I’m giving at the New Adventures conference.

In just over a week, I’ll be giving the opening talk at the New Adventures conference in Nottingham. I’ll be giving a workshop the day before too. There are still tickets available for both.

I have to admit, I’m kind of nervous about this talk. It’s been quite a while since the last New Adventures, but it’s always had quite the cachet. I think I went to most of them. It’s quite strange—and quite an honour—to shift gears from attendee to speaker.

The talk I’ll be giving is called Building. That might be a noun. That might be a verb. You decide:

Every new medium looks to what has come before for guidance. Web design has taken cues from centuries of typography and graphic design. Web development has borrowed metaphors and ideas from the world of architecture. Let’s take a tour of some of the most influential ideas from architecture that have crossed over into the web, from pattern languages to responsive design. Together we’ll uncover how to build resilient, performant, accessible and beautiful structures that work with the grain of the materials of the web.

This talk builds upon the talk I gave at last year’s An Event Apart called The Way Of The Web. It also reflects many of the ideas in Resilient Web Design. When I gave a run-through of the talk at Clearleft last week, Andy called it a “greatest hits.” For a while there, I was feeling guilty about retreading some ground I’ve covered in previous talks and writings. Then I realised it was pretty arrogant of me to think that anyone in the audience would be familiar with any of it.

Besides, I’ve got a whole new avenue of exploration in this talk. It’s about language and metaphor—how we talk about what we do on the web. I’ve just finished giving another run-through at the Clearleft studio and I’m feeling pretty good about it. That’s good, because I find that giving a talk in a small room to a handful of colleagues is way more stressful than giving a talk to hundreds of people at a conference.

Just as I put together links related to last year’s talk, I figured I’d provide some hyperlinks for anyone interested in the topics raised in this new talk…




This was originally posted on my own site.

New Year. New Voice. Wed, 02 Jan 2019 12:47:00 +0000 New year’s resolutions. We all make them. We all break them. We even sometimes keep them.

I’ve struggled with public speaking for a long time. I know that a lot of people find it nerve wracking, but I’ve always had massive blocker with the entire endeavour. Maybe it’s partly due to my dyslexia, but truthfully it’s mostly due to me shying away from opportunities that place me in that kind of spotlight.

Fortunately at Clearleft I have been given keys to unlock the block. Firstly, I have the pleasure of working with experts in the field like Andy Budd, Richard Rutter and Jeremy Keith, who travel around the world, delivering and sharing insights from their respective work. Secondly, I attended a Rebel Lectures event that helped open my eyes to the commonalities of others who struggle with public speaking like me. And the event gave me tools to help me work towards speaking with confidence.

I have set myself a goal; a goal that I purposely cannot get out of. This March is the Spring Forward Festival in Brighton and I will be hosting a Ladies That UX event in the midst of it. Instead of the welcome and speaker introductions, I will present for 20 minutes. That’s 20 minutes of people listening to my voice.

But here’s the thing. I’m scared of my own voice. Sure, I can talk to friends, colleagues and clients. But when you’re standing in front of a room full of people, all there is is silence. Silence until you speak.

With this in mind, I signed up for another workshop. Andy Budd’s presentation workshop provided a variety of exercises aimed at getting to the root of the most important components of speaking. Tasked with presenting a five minute talk, I decided to present on the subject of teeth — if I ever get the pleasure to meet you, feel free to ask me about it.

Then we read a poem. It’s funny how reading the words in drastically different cadences got the point across quickly about delivery —monotone, dramatic; slow, fast; using the body, using the space in the room; loud, quiet; with accents, with pauses.

How often should you pause when presenting?

Do you find yourself trying to get your point out as soon as possible? Do you rush through it so fast that afterwards you question whether they understand you?

Take a second. Maybe two. Breathe.


Let what you are saying to your audience sink in. I tend to think about what I am saying continuously but often forget this might be the first time someone has heard it. At first it felt embarrassing to do this, but as I looked around, everyone was in the same boat. Then it dawned on me. It is rare to find someone who wakes up and cannot wait to stand up in front of people and talk, unless they are an actor.

After this exercise Andy asked us to present our talk again. I could tell the difference. I focused on words, I paused. I changed my volume to emphasise my points. I actually enjoyed it. Most people felt the same. It’s obvious but it’s true: it just takes practise. With that in mind, I’ve been looking for opportunities to present, stepping away from my comfort zone and presenting to the whole Clearleft team. The next time I have to present, I will practise and focus on one thing at a time. Starting with my voice.

Thinking ahead to my talk in March, I have a stack of presenting books ready to read and other presenting opportunities. More importantly, I have a talk to write. I haven’t written a 20 minute talk before. There are many approaches, processes and things to consider. Content structure, the audience, the narrative, slide design, technical feasibility, time, presenting style…




Five tips for designing successful business tools Wed, 19 Dec 2018 14:28:00 +0000 Over the years I’ve worked on some complex tools in specific industries. I’ve worked on a weather graphics platform, an automotive data tool and more recently at Clearleft, an inventory management system for an investment bank. In my experience, these challenges come with their own set of demands.

So here’s are my 5 tips for running a programme successfully.

1. You’re never going to become an investment banker, so don’t try

One of the problems you immediately encounter when trying to design one of these tools is the proliferation of acronyms and jargon that creates a fog between you and the design challenge. Many of the users and stakeholders involved will have trained for years to acquire the domain knowledge needed to use these tools effectively.

The best way to approach this challenge is to nominate a subject matter expert up front. This expert literally works alongside the design team on a daily basis. They act as a domain knowledge interpreter and also provide a constant voice for the user, explaining how, when, and why tasks would be completed. As a designer, it’s important to appreciate that you don’t need to understand everything, you just need to understand enough to ensure that the solution you’re proposing is optimal for the task in hand.

2. Don’t cheat; work with real data

We all know the importance of designing with real content and data. Still, it remains tempting (and easier) to work with fake or sample data sets, particularly if you’re working in an unfamiliar domain and don’t truly understand the nature of the data that you’re dealing with. The sooner you work with real data, the sooner you’ll be able to get your head around the nature and scale of the problem, and the sooner you’ll be able to identify a suitable design solution.

3. Don’t let legacy problems define today’s solutions

Many business tools (and the workflows behind them) have been around for decades. Over the years, they’ve been tweaked and added to countless times. The user experience may have been severely compromised. When redesigning a service such as this, it’s important to silo these legacy issues and focus on uncovering the needs of today’s users without being constrained by current solutions.

4. Be prepared for user insights to drip feed into the process

People rely on these tools to complete their jobs. You’ll often find that behind every business tool is an army of some of the most passionate users you’ll ever come across. Opinionated, thoughtful and highly invested in the service’s improvement, they can be the most inspiring users to design alongside. The catch is that getting time with them can prove challenging, since you need to slot into their often hectic and fluctuating work schedules.

I’ve found that the best approach is to be flexible, offering short, often remote, one-to-one interviews at times suitable to them. In reality this means that user insights are drip-fed into the design process in a sporadic manner, in contrast toa B2C programme where you might arrange two days of user research part-way through the design process.

5. Be inspired by real users, rather than fictional ones

The creation of user personas has been a technique used in UX since the mid-90s, as a way to embed users in the design process. Each fictional persona represents a portion of people in the real world and enables designers to focus on a memorable cast of characters, instead of focusing on thousands of individuals. Personas essentially help designers design for a specific somebody, rather than a generic everybody.

In theory, personas are just as valid when designing B2B services as a B2C ones. In reality, however, they are often harder to create. Because every organisation varies greatly,it’s harder to make generalisations in a small sample size. Instead, I’ve tried profiling a handful of real organisations (both existing and potential customers) and the end users within them, and used these as a stimulus for design. While this might be less representative, it’s proven successful.Knowing that this is an actual customer creates more empathy among both designers and stakeholders.

Presenting Marty Neumeier Thu, 13 Dec 2018 15:47:00 +0000 Ahead of our hotly anticipated Brand Master workshop with Marty Neumeier in March 2019 we asked Andy Budd to give us some insight in why we’ve chosen to work with him on our Clearleft Presents series.

We first “discovered” Marty Neumeier through his excellent book, The Brand Gap. It’s in this book that Marty gives the best articulation I’ve ever seen of what a brand is and why we should care. Rather than a densely packed polemic, aimed only at designers, he draws on his immense storytelling skills to frame the gap between business strategy and design in a way everybody can understand. This book feels like you’re watching a well crafted TED talk, rather than a Medium article stretched to the length of a novel. It’s the perfect length for a short plane ride, and over the years we’ve given a copy of this book to more than one client to read over the weekend.

Marty Neumeier
Marty Neumeier

Following quickly on its heels was Zag, after the common marketing aphorism that “When everybody else Zigs, you Zag.” As you can imagine from the title, this book is all about creating stand-out products. It’s a must read for anybody involved in setting business or product strategy.  Another highly graphic (as in design, rather than gory or x-rated) book, Marty does a beautiful job of mixing conceptual images with prose. His style made him an easy choice for a speaker slot at one of our conferences. So in 2010 he came and spoke at our dConstruct conference on the topic of his new book, The Designful Company. As you can imagine, the message resonated with our design loving audience, and became a firm favourite at the event.

At Clearleft we have always seen ourselves as a “designful company”. In fact our mission is to unlock and elevate the value of design, and help all the companies we work with become more “designful”. The majority of our client sponsors feel the same way, which is why they bring us in. But they often struggle to articulate the value of design to more traditional business people. This is where the The Designful Company comes in. There’s just something in the way Marty articulates these challenges that seems to land perfectly with leadership teams. That’s why we’ll often buy copies of this book for our corporate partners. We love seeing the way this changes their relationship to, and understanding of, design.

Marty has written a ton of books since first speaking at dConstruct. Metaskills looks at the skills people will need in a world of increasing reliance on robots and AI—a concept close to my heart. The Rules of Genius builds on the skills outlined in Metaskills, while The Brand Flip does the same for The Brand Gap. If you’re a fan of authors like Seth Godin, I highly recommend you check out some of Marty’s books. You won’t be disappointed.

There’s a clear thread through all of Marty’s books; helping business leaders understand value of design, while positioning designers as the people to help unlock that power. This theme is most evident in his new book Scramble, and its associated workshop series.

Clearleft Presents - Marty Neumeier 14-15 March

This March we are thrilled to be collaborating with Marty on his Brand Master Workshop, a two-day immersive journey into the fundamental disciplines of brand building, held at one of our favourite iconic venues, the Barbican Centre in London. The workshop is designed to empower you with dozens of proven principles you can apply immediately to your business.

This workshop will launch Marty’s latest venture Level C — a new professional development company featuring a progressive 5-tier series of interactive branding workshops. Each tier explores core branding principles and challenges you to apply them to hypothetical and real-world business scenarios, thereby bridging the gap between strategy and design, and earning the formal title of Certified Brand Specialist.

So if you’re a designer, a design leader, a product manager or designful marketing exec looking for tactics and techniques to help harness the power of design in your organisation, this is the workshop for you.

Tickets and more information about the workshop can be found on our events page. Looking forward to seeing you there.

How Readable? Fri, 07 Dec 2018 17:24:00 +0000 When I was younger, my favourite meal was pasta with cheese sauce. Not just any cheese sauce though. It had to be Bisto.

Bisto granules, once dissolved in water, made a gloopy faux-cheese suspension, that coated your entire mouth with delicious chemicals and left a horrible, but strangely satisfying, cheesy film in it’s wake.

One day, I tucked into a big bowl of cheesy pasta and realised that something was missing. They’d improved the recipe. The cheesy film was no more. Someone had decided that it was a bug, not a feature, and had got rid of it. I disagreed. As I pushed my plate of pasta away, I decided it was different, and I hated it.

A lot of what we prefer is subjective. It’s not necessarily better, it’s just what we’re used to or how we’ve always done things.

Last week whilst pairing, Jeremy and I were refactoring some code and discussing whether to use a ternary operator or an if else statement.

I wholeheartedly preferred the ternary operator, I’d learnt about ternary operators recently, so it was new, shiny, concise and writing it made me feel clever. But when Jeremy reframed the question and asked which I found more readable, I had to concede that I preferred the if else statement.

if ( condition ) {
  value if true;
} else {
  value if false;

But why did I prefer reading the if else statement? Was it actually more readable, or was it just familiar? When I broke it down, I liked that it was laid out in the same way as we read, top to bottom, left to right. If the condition is true, do this, else, do that.

condition ? value if true : value if false 

When I read the same code written as a ternary operator, my eyes darted around a bit. I had to look for the “if” in the form of a question mark, then look backwards to find the condition, then follow the line forwards to find out what the result of the condition will evaluate to.

Additionally, I found when the condition or the values were lengthy, having them all on the same line was confusing.

But are these feelings objective, or are they just shaped by my own experience? Do other people feel the same way? Are some things universally more readable than others?

Daniel Berzon is currently trying to answer this with Considering that developers spend more time reading code than writing it, at an estimated ratio of 10:1, it’s definitely an important topic, and a project to keep an eye on.

Prototypes and production Mon, 26 Nov 2018 17:02:00 +0000 When we do front-end development at Clearleft, we’re usually delivering production code, often in the form of a component library. That means our priorities are performance, accessibility, robustness, and other markers of quality when it comes to web development.

But every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping.

There are plenty of non-code prototyping tools out there, and our designers often reach for them to communicate subtleties like motion design. But when it comes to testing a prototype with real users, it’s hard to beat the flexibility of HTML, CSS, and JavaScript. Load it up in a browser and away you go.

We do a lot of design sprints, where time is of the essence. The prototype we produce on the penultimate day of the sprint definitely won’t be production quality, but it will be good enough to test.

What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.

So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It’s almost like I have to flip a switch in my brain to change tracks.

When a prototype is successful, works great, and tests well, there’s a real temptation to use the prototype code as the basis for the final product. Don’t do this! I’ve made that mistake in the past and it always ends badly. I ended up spending far more time trying to wrangle prototype code to a production level than if I had just started from a clean slate.

Build prototypes to test ideas, designs, interactions, and interfaces …and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

Of course it should go without saying that you should never, ever release prototype code into production.

And yet…

More and more live sites seem to be built with a prototyping mindset. Weighty JavaScript frameworks are used regardless of appropriateness. Accessibility, if it’s even considered at all, is relegated to an afterthought. Fragile architectures are employed that rely on first loading and then executing JavaScript in order to render basic content. Developer experience is prioritised over user experience.

Heydon recently highlighted an article that offered this tip for aspiring web developers:

As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like span and how they differ from block ones like div.

That’s perfectly reasonable advice …if you’re building a prototype. But if you’re building something for public consumption, you have a duty of care to the end users.

This was originally posted on my own site.