Clearleft | Blog The latest news from Clearleft en-gb Sun, 19 Sep 2021 14:45:06 +0000 Sun, 19 Sep 2021 14:45:06 +0000 Accessibility testing Tue, 14 Sep 2021 11:06:34 +0000 I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.

While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.

Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.

Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated label element (using the for and id attributes); images that don’t have alt text; pages that don’t have sensible heading levels or landmark regions like main and nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings, alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated: alt text for images; labels for inputs.

Then there’s interactive stuff. If you only use native HTML elements you’re probably in the clear, but chances are you’ve got some bespoke interactivity on your site: a carousel; a mega dropdown for navigation; a tabbed interface. HTML doesn’t give you any of those out of the box so you’d need to make your own using a combination of HTML, CSS, JavaScript and ARIA. There’s plenty of testing you can do before launching—I always ask myself “What would Heydon do?”—but these components really benefit from being tested by real screen reader users.

So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.

If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.

If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.

When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

This was originally posted on my own site.

Engineering a better design test Tue, 14 Sep 2021 11:00:00 +0000 When the tools of our trade have a negative impact on our testing, how do we adapt to give our participants a more realistic experience? And how do we gain better insight for our stakeholders?

The last 18 months of remote testing could be summed up with a handful of quotes.

How do I share my screen?
How do I get back to the chat window?
I’m sorry I’ve not used Zoom, we use Teams.

During a test, these moments of confusion don’t appear too disruptive. But when added together, they reduce the time with a participant by five mins or more. They also break the natural flow of the test. Instructions need to be repeated, incurring further time penalties.

This is also true of testing the outputs of prototyping software.

The text is too big/small/blurry… I would fix that.
I have to scroll left/right to see the rest of the content… I would fix that.
This [interaction] doesn’t work properly… I would fix that.
This doesn’t seem to work on my phone at all… I would fix that.

The research facilitator then responds with reassurance and gives specific instructions to progress through the temporary and unwanted roadblocks.


Is there a better way we could be doing this? Sure, we can ensure we use familiar video-conferencing software with our participants. But what about the prototypes we test?

Ain’t nothing like the real thing

Recently I was fortunate enough to work with James, Katie and Trys on the Malvern Panalytical design system project. The design challenge and team configuration meant that our respective disciplines had context through the entire project.

The close and rapid working relationship of James and Trys meant that the design and development phases were continuously in sync. At the point of preparing for usability testing, it seemed ludicrous to move to any prototyping material other than the one we were already building in. The bedrock of the web: HTML, CSS and Javascript.

Testing this way had a number of advantages:

  • Avoiding the numerous interaction shortcomings of prototyping software.
  • Delivering a realistic and adaptable end-experience for our participants regardless of device and operating system.
  • Showcasing the benefits of responsive design to the client.
  • Demonstrating the value of the design system we were building by using it for rapid prototyping.
  • Making minor content adjustments to the prototype in real-time.
An image of a webpage in small medium and large sizes.
A prototype for any screen size.

These advantages resulted in a more efficient test, more constructive conversations with our participants and more valuable insights for our client.

My highlight was when a participant clicked a download link and the browser’s native dialogue box appeared. It’s that level of detail that encourages the suspension of disbelief for a participant.

Go your own way

This approach isn’t a one-size-fits-all solution by any means. We need to select the right tool for the job. In our case, selecting Figma, or a similar prototyping tool, would have incurred a lot of overhead and offered less value to the client.

One thing is clear though. Closing the gap between the design and development process has shown great value in the work we do at Clearleft. If this kind of work excites you, come and work for us as a Design Engineer.

This was originally published on my own site.

Season three of the Clearleft podcast Mon, 06 Sep 2021 14:21:00 +0000 If you’re not already subscribed to the Clearleft podcast, you should probably remedy that. The third season is about to drop any day now.

Once again, the season will comprise six episodes released on a weekly schedule.

That’s a cadence I more or less picked at random, but I think it’s working out well. Six episodes are enough for the podcast to sustain your interest without overstaying its welcome. And by taking nice long breaks between seasons, you’re never going to end up with that podcast problem of having a backlog of episodes that you never seem to get around to listening to.

That said, if you did fancy going through the backlog, there’s a mere twelve episodes for you to catch up on. Six from season one and six from season two. None of the episodes are overly long. Again, I don’t want this podcast to overstay its welcome. I respect your time. A typical episode is somewhere between 20 and 25 minutes of multiple viewpoints and voices.

You can subscribe to the RSS feed or use whichever service you prefer to get your podcasts from: Apple, Google, Spotify, Stitcher, Deezer, TuneIn, Castro, Pocket Casts, Player FM, or my own personal choice, Overcast.

Or you could just huffduff whichever episodes sound most appealing to you. But honestly, and I may be biased here, they’re all pretty darn great so I recommend subscribing.

If you subscribe now, then the episodes from season three will magically appear in your podcast software of choice. Again, I know I’m biased, but this is going to be an excellent season featuring some very smart folks sharing their stories.

Just to be clear, in case you haven’t listened to the Clearleft podcast before, this isn’t your usual podcast format. Yes, I interview people but I don’t release one interview per episode. Instead, each episode zeroes in one topic, and features different opinions from different people. It’s tight and snappy with no filler. That involves a lot of production and editing work, but I think it’s worth it for the end result.

Can you tell that I’m excited?

This was originally published on my own site.

Principles for Design Principles Tue, 24 Aug 2021 12:29:00 +0000 In my experience creating a useful set of design principles is really, really hard. I was reminded of this recently when I led the creation of a set of design principles to help define the future experience for Citizens Advice. During this process I was reminded of a few key rules to consider…

Be purposeful

Design principles can exist for different reasons. Some are more process driven (e.g. We design in the open, Co-op). Some more value based (e.g. Human, HubSpot). Others are more about defining the characteristics of a service/product (e.g. Smart and personalised, Ebay). Ultimately the type of design principles you create should be dependent on how and why they are being created. What kind of decisions do you want to influence? Process decisions, strategy decisions, or interface decisions?

With Citizens Advice we wanted our design principles to be a tool for making decisions. We wanted the principles to help guide decisions in selecting a new platform. So we created a set that would define the key characteristics of the future experience.

Tip: Before creating your design principles, discuss how they are going to be used and by whom. Then define what “good” looks like for your design principles.

Be yourself

Design principles have been a bit of a buzz technique for a while now. There are now catalogues of them online for you to browse through. There’s a real temptation to start by reviewing others but I’d strongly recommend holding off doing this for the same reason I’m not a massive fan of competitive reviews. Once you’ve seen other people’s it’s very difficult not to be influenced by them (even subconsciously). Since useful design principles are unique to your organisation this can put you on the back foot immediately. Ideally, design principles are inspired by your knowledge, your users, and your business. So try to ground them in your own context.

For Citizens Advice we were in the fortunate position of having done user research to inform the principles. We used these insights to identify key themes to inspire the direction of the principles.

Tip: Where possible, gather insights to inspire your design principles process and embed the user in the process. Avoid looking at other companies, particularly your competitors.

Be actionable

Design principles typically describe how the experience should feel and not what you want it to achieve (outcomes). For example, we want it to feel conversational rather than formal. It’s actually surprisingly easy to forget this and bleed into a more descriptive, perhaps less controversial, ‘what’ statement. So continually ask yourself does this describe how the experience will feel. Will it enable us to make a decision on one course of action over another?

For Citizens Advice we had a design principle titled ‘serve quickly’. On the surface this seems very obvious. But this had massive implications for them. In the case of the phone system, it meant that it was better for any advisor to answer your call than to wait longer for a specific advisor to be available. This in turn would have big implications for the design of the queuing system. It was a good example of how we could think of features that do and don’t facilitate the principle.

Tips: Continually ask yourself if this principle describes how the experience feels and if you can think of examples that do and don’t demonstrate this principle.

Be considered

Creating design principles is a process that you’re unlikely to get right the first time. So iterate and test the principles to make sure you get the message behind each principle just right. For Citizens Advice all our principles went on quite a journey, with multiple iterations over the course of a two-week period with small team discussions.

Consider every single word carefully. Play with different ways of articulating the message. Try to make the principles feel part of one set.

For Citizens Advice each principle consisted of one core message, a description, a set of Do’s and Dont’s, and the user insights that inspired its creation.

Tip: Allow time to iterate the principles and play with the language. Also play with different ways of articulating the principles such as describing why you’ve used specific words or having example do’s and don’t.

Be maintained

Like any design tool, the proof of the pudding is in the eating. Will the design principles be used in practice or simply stuck up on a wall and forgotten about? Making sure key stakeholders are involved in their creation will help to some extent but it’s important to also nominate an owner. This owner is responsible for making key decisions, communicating their value and keeping them as a living reference for teams.

For Citizens Advice we established an owner of their design principles and we plan to check in on them in a few months to see how they’re being used in practice.

Tip: Establish an owner of the design principles responsible for making key decisions and communicating their value.

What’s the difference between coaching and mentoring? Sun, 22 Aug 2021 23:00:00 +0000 This question seems to come up a lot. What exactly is the difference between coaching and mentoring and when should you choose one over the other?

To help unpick this I spoke with executive coach Julia Whitney. She’s led our Leading Design retreats and runs our popular Group Executive Coaching Programmes so she was the perfect person to talk to.

Group sat in front of a glass wall of post-its talking
A group of design leaders at our Women in Design Leadership retreat at the Juvet Landscape Hotel in Norway

Julia explained that there is an important difference between coaching and mentoring. A trainer or mentor will often tell you what to do and how to do it. A coach, on the other hand, serves as your thinking partner.

Mentoring offers you the wisdom of someone else’s experience. But what worked for your mentor may not be right for you. Your context and set of colleagues is different, and so is your unique set of skills and strengths.

Coaching works with the belief that you are the expert on yourself and your context. Coaching supports you to develop approaches that work uniquely well for you. In the process you grow more and more confident of your own resourcefulness.

Coaching increases self-awareness, but also expands your repertoire of behaviours. You take concrete actions back into your workplace. Part of what makes it work so well is the accountability you feel to do the actions you committed to at the last session.

What experiences have you had with coaching and mentoring? What about either of them has worked particularly well for you? I’d love to know your thoughts. Please do get in touch.

If you would like to find out more about our coaching programme and get one of the final places in the September cohorts you can do that here.

It’s okay: Advice for research newcomers Wed, 18 Aug 2021 12:01:00 +0000 I belong to a small community called UXup Brighton, “a friendly group of UX folk who meet monthly, to share skills and experiences, build our network and support each other to grow and develop our careers”.

The group is run and hosted by the brilliant Kate Rickard. Alongside the monthly meetup there is a supporting Slack channel where people can openly ask questions to the group.

A couple of weeks ago I spotted one that I thought I could help to answer.


Rather than leaving my thoughts locked away in the walled garden of Slack, I thought I’d set them free into the world wide web.


It’s okay if you feel overwhelmed trying to run the interview and take notes at the same time. It’s impossible to do both and still do a good job. Instead, try to find someone on your team to take notes. That enables you to focus on the conversation with your participant. Make minimal notes that allow you to come back to interesting parts of the conversation you want to clarify or ask further questions. Find your own preferred method of taking notes. I find using mindmaps useful: branching out from a central topic allows me to track the conversation flow, thinking styles and make connections between nodes. I also capture keywords and timestamps. I prefer analogue over digital capturing during a session. I find it is less distracting for the participant and has fewer points of failure. Another option is to record the session and listen back later but only do that once you gain consent from your participant.

Informed consent

Get consent from the participant before recording, if you have the luxury transcribe through DeScript and search for timestamps and keywords.

Conversation etiquette

It’s okay if you need to wait for the answers to your questions. Give people time to think, don’t rush or interrupt them. The participant should be doing the majority of the talking - think the Pacman rule. They may talk about something that seems entirely unrelated for what seems like an age, but it’s okay, it may lead to a golden nugget.

Pacman principle for user research
The Pacman rule: your participant should be talking for at least 80% of the session, leaving you the other 20%. If you were to represent these percentages as a pie chart it would resemble the shape of Pacman.

Silence is golden

Get comfortable with silence, that’s where the magic happens. You can use it to your advantage during your interview by allowing people to fill it for you. Trailing off and half-finished questions are useful prompts e.g. ”You thought that because…” or “The reason for that is…”.

Building rapport

It’s okay to feel nervous about your interview, but also consider your participant might be just as nervous as you, be aware of their mood and circumstances and adapt accordingly. Be genuinely curious about the person you are about to share the next 60 mins with, the time will fly and you’ll wish you had more toward the end.

Discussion guides are only a guide

It’s okay to deviate from your script and use your intuition, live in the moment and be attentive to where your participant wants to take the conversation. You don’t need to read your script word for word either. There’s a chance you’ll end up sounding like a robot. In my experience robots don’t make riveting conversationalists. Adapt your script based on the first interview. Like pancakes, the first one never turns out perfect and that’s okay.

We all make mistakes

It’s okay if you mess up a question (e.g. ask a leading or future state question). Make note of it and consider whether the response is worth including in the study.

Challenge your own biases

It’s okay to make assumptions, as humans we do it all the time, but get in a habit of challenging yourself when you assume you understand something based on your own world-view and experiences. If you’re not 100% sure, ask “why?”. Don’t settle for surface explanation, dig a bit deeper to understand what’s really going on. It’s okay to be asking lots of questions, you’re doing research!

Every session and participant is unique

It’s okay if you only get a handful of interesting observations during a session. Or if you spend 50 mins building rapport and only start to got on-topic with 10 mins to go. Or if your participant gives you a 20 min answer to an opening question or only gives you yes or no answers. People are messy, complicated and unpredictable creatures. It’s okay if you speak to someone who clearly isn’t relevant for your research, don’t be afraid to omit that data from the study but be prepared to explain why to your team and stakeholders.

This post was originally published on Benjamin’s own site.

Designing for innovation Wed, 04 Aug 2021 08:59:00 +0000 In too many organisations today, design is deployed solely as a conveyor belt to churn out user interfaces and incremental improvements. But how do you get it to be a strategic enabler for radical reinvention or competitive advantage?

Not that long ago we had our own internal design discussion on the nature of innovation. And just last month we held a virtual panel event on designing for innovation. Hosted by our strategy director Andy Thornton, it featured a stellar line-up of industry experts:

Designing for innovation panellists

Defining it

Andy got the ball rolling by asking for a definition of innovation. Janna said:

Innovation is the process of breaking through into something new. In order to get to innovation, you have to be willing to try a wide number of things.

Dorota described innovation like this:

It’s basically creativity in a business context.

Describing IDEO’s work, Matt said:

For us, innovation often just means helping companies tackle challenges, either with new groups of customers that they don’t normally talk to or tackling new problems with new solutions and services that they’re not used to.

So there’s a general consensus that innovation involves doing something new. Doing something new can be risky. Therein lies the paradox of innovation for many companies. Most organisations want to be innovative, but most organisations are also risk averse.

Starting it

Dorota talked about the benefit of having a project sponsor in your corner to help you push innovation through. Akshan agreed:

Something that’s really helpful and really necessary is executive leader sponsorship. If the exec leader—the CEO, the chairman, or whatever—is creating the mandate for the rest of the company, it’s a very top-down thing, but you’re incentivizing innovation. You’re incentivizing people to take risks and you’re making it okay to do that. In fact, you’re rewarding people to do that.

Janna pointed out that design is not the only discipline that has to deal with uncertainty. Other teams have to sell in risky endeavours all the time. The marketing department acknowledges that “half of your ad dollars are wasted; you just don’t know which half.” Similarly, the sales team talks about their pipeline in terms of probabilities: “we’re 70% sure of these deals and 60% sure of those deals.”

Those teams try things out. They run experiments. Some of the experiments are going to fail and some of them are going to be successful. So, as Janna says, it’s not that different for design:

All we’re saying is that there are rewards if you do it. And risks if you don’t. And it’s easy enough to do. Look how others are doing it. Let’s get together and we can do this innovation thing and it should start moving the needle in the right direction.

Selling it

You’ve still got to make the business case for any innovative initiative. Andy asked if anyone had any tips for that situation.

Dorota said she got a lot of value from pushing for an open-ended research project:

It was a legacy product that had a lot of value already, but you obviously had to add new innovations to maintain it. And it was kind of a fresh pair of eyes on what’s actually possible in that space.

Matt talked about the benefits of “show, don’t tell”:

We’re all humans with tangible senses. When we can look at something and hold it and walk around it or click on it if it’s a digital thing, it changes your understanding of what you’re looking at.

As ever, designers also need to speak the language of business. As Janna put it:

We can talk until the cows come home about customer delight and journey mapping and design thinking and all these things. It all sounds a little bit fluffy to our leaders. At the end of the day, they want to know that their bucks are going a little bit further each time. So talk to them about the return on investment that they’ll get.

And you can also show them examples of other companies that have reaped the benefits of investing in innovation. There are plenty of case studies out there.

Matt pointed out that we need to be aware of what we’re asking of people:

They’ve probably got to where they are in the organization by not doing any of the things that we’re asking them to do: embrace ambiguity; trust the process; take stuff to users really early; get stuff wrong. All those things are literally the opposite of what they’ve been taught to do for their whole career.

Maintaining it

Innovation shouldn’t be a one-off event. It should be continuous. But what’s the best structure for maintaining innovation? Andy asked if a skunkworks-style lab was the way to go:

The lab concept is one way of handling innovation as in it’s a siloed self-funded part of the business that’s allowed to make lots of failure, but very often it doesn’t have much communication with other parts of the business. How blended should innovation be within a business?

Dorota described how things have evolved at Southern Water:

Earlier on we probably developed some of the solutions a little bit more in isolation. I think that’s not the case so much now. And it’s definitely visible in the types of benefits and impact that we’re having as a team.

Akshan talked about the importance of co-creation rather than delivery:

The way that I’ve seen innovation labs work really well, in my opinion, is when they’re not actually doing the innovation, but they’re facilitating the innovation.

Pondering it

There was a lot of food for thought in this panel discussion. As always, the time just flew by.

If anything, the discussion raised more questions than it answered but we knew going into this that we weren’t going to “solve” the dilemma of innovation; that fundamental tension between risks and rewards.

But one of the simplest solutions to cracking this conundrum is for us all to share our experiences and our stories. We’re so grateful to Janna, Matt, Akshan, and Dorota for giving their time and expertise.

You can watch the full panel here:

Futures, features and fixes – Setting your product team up for success Mon, 26 Jul 2021 16:11:00 +0000 Successful and sustainable digital products come from a blend of innovation and iteration. Yet most design teams and their digital product roadmaps are out of balance.

Start-ups over-index on big and new ideas at the cost of accumulating design and technical debt. Established organisations play it safe tending to focus on incremental optimisation and in doing so put themselves under threat from disruptors and challengers. Of course, these are generalisations. But ones I repeatedly see working across sectors with businesses of all sizes and at varying stages of digital maturity.

What does your product roadmap look like?

As any Product Owner will tell you, prioritising what to spend time doing is the challenge that gives them sleepless nights. Finding the time to explore potentially bigger and more valuable ideas is not a problem exclusive to digital product management. As many a President will confirm.

What is important is seldom urgent and what is urgent is seldom important

Dwight Eisenhower

The most important thing you need to do [in this job] is to have big chunks of time during the day when all you’re doing is thinking

Barack Obama

Immediate problems tend to shout loudly for attention. Yet making too many knee jerk changes and firefighting one crisis after another quickly leads to a product roadmap that is shortsighted and unstrategic.

Innovative ideas need time to find their voice. Being further away from the frenzy of delivery they can be muffled and easier to ignore.

A way to ensure balance in your product portfolio is to map out the work you have in play. Even better if this is put on display (not hidden in a PowerPoint deck) and updated as a living document.

There are many frameworks for plotting your activities within a product portfolio. The two I most often use are:

The Lean Enterprise innovation portfolio map. This moves the progress of initiatives through four gates (explore, exploit, sustain and retire) with the option to kill any that fails to meet the success criteria.

Lean Enterprise Innovation Portfolio Map

The portfolio map from Stratygyzer. This plots initiatives in two quadrants – explore and exploit – with an axis in each for risk and return.

Portfolio Map from Stratygyzer

If you’re working in a product team that doesn’t have a holistic view of your product portfolio then I’d recommend you run a workshop to create one.

How to get your product teams looking over different horizons?

Product portfolios and roadmaps are ideal for showing the quantity and movement of initiatives through stages of production readiness. But, how do you set up your product teams to work across these different spaces simultaneously?

One way (but certainly not the only way) is to rotate your design squads to give them focussed time on either futures, features or fixes.

Futures, Features and Fixes Innovation Diagram

Let’s look at these three types of design activities and how to set your team up to tackle them.

Futures – finding the next big idea

Companies known for bringing new products and services to market are united by one common trait. They put considerable effort into the research and development of their next big idea. Piloting multiple concepts and placing numerous bets is a proven strategy for successful product innovation.

This is the time to explore big and radical ideas using low risk and low-cost techniques. You want to increase the number of ideas generated to gain confidence as quickly as possible in which ones to pursue.

This is a divergent phase. The number of ideas should trump their fidelity. For the team, a ‘yes and …’ attitude should replace ‘yes but … ‘. You’re looking to initially test ideas for their desirability with viability coming later.

The futures team should have a wide remit. Initiatives should explore unmet customer needs, potential new markets, different business models, emerging technology etc. Techniques such as Google Venture style Design Sprints, Wizard of Oz prototypes, and proposition testing fit into the toolkit for exploring potential futures.

Keep in mind these are learning projects with disposable prototypes. Success comes from finding out what not to spend effort on as much as identifying promising concepts to take forward.

Many organisations consider the skills for successful innovation needing a separate team of superstar designers. I disagree.

Setting up an innovation lab sounds impressive and a powerful marker of organisational intent. Most often, the creation of a separate innovation department divorces it from the realities of the business and leads to an indulgent form of technical and design theatre.

Another common approach is to employ an agency to inject a dose of innovation. The benefits of extra capacity and capabilities should be weighed up against a lack of detailed business context and the ability to see the idea through to fruition. In my experience, it’s much better to have an agency working alongside members of an in-house team where techniques for innovation can be gained through coaching, immersion and practice.

Innovation is exhausting. Moving your team in and out of this space gives them a chance to recuperate and come back refreshed. Having this secondment timeboxed also helps to focus minds on rapid creation and concept testing rather than over-engineering a single solution.

Features – improving the product

The feature team is the production line for your product. Their purpose is to take a brief, create designs that solve the problem outlined, and deliver something new into the interface.

This team is responsible for incremental but sizable changes. Typically the initiatives for this team have enough definition to outline the problem to tackle and the desired outcomes to achieve. A good brief should give space for creativity and be a problem to solve not a solution to implement.

This is the world of backlogs, user stories and user acceptance testing (UAT). Confidence in the designs comes from evaluative methods such as usability testing sessions and multivariate testing (MVT).

A successful features team has an eye for crafting solutions. The work is elevated through polishing the details in the layout, interactions and copy. To help with this the team should be carrying out regular crits and showing their work early and often to stakeholders. Project meetings should include discussions on performance, accessibility and success metrics.

Digital product teams live in a fast-changing world. The growing expectation of your audience, opportunities afforded through new technology and shifts in the competitive landscape all require a nimble delivery focussed unit.

Fixes – polishing your product

Trust from an audience is hard-won and easily lost. In usability testing sessions of existing websites, you often get to witness the death of a thousand cuts. A typo here, a broken link there, inconsistent design patterns and slow loading pages.

Accumulated technical and design debt can unintentionally come to define the experience of your product.

The team doing fixes, maintenance and enhancements should have a focus on velocity and autonomy. In this activity stream, there should be little need for meetings or protracted discussions. Bugs to fix and production debt to remove should be prioritised against set criteria and continually deployed when done.

This is vital work to do but it shouldn’t be the only work you do. It’s easy to fall into the trap of thinking you’re doing lots of work just because your time is filled with activity.

A note on rotation

In the futures, features and fixes diagram there is a suggestion that 50% join and 50% remain in the team for each activity. This is to ensure a level of continuity and handover. It’s most important within the futures and features teams, where work started, may not be finished or will benefit with further iteration.

Rotation allows the team a regular change in pace and exposure to all the activities required to develop and maintain a digital product.

Even small digital teams can use the approach to gain balance in the work they do. You could divide a week between a few days spent on the future and features and a day doing fixes. Or the whole team could do a week of features, then futures, then fixes. The exact slices of time in each activity will depend on your setup. The important thing is to have some time for each activity.

Three activities that benefit from different approaches

Digital products need teams tackling ‘fixes, features and futures’. Over-focusing in one area will be detrimental to another.

Each activity requires a subtly different approach and mindset. Teams gain in productivity when time is allocated to each activity as it provides focus and avoids context switching.

This is one way to approach managing a team’s activities and product portfolio. I’d be interested in carrying on the conversation to find out how you ensure a polished product backed up with a flow of new initiatives?

Integrating content with your design system Fri, 16 Jul 2021 12:40:00 +0000 As part of Content by Design we hosted a panel on the topic of Building Design Systems.

The panel discussion included speakers Amy Hupe and Andy Welfle, plus Amy Thibodeau and our host Rachel McConnell.

Our four content by design paneliists photos

How do you include content patterns in Figma components?

Our attendee Mette wanted to know how designers can easily add content patterns and edit them in their designs to design in a more content-first way. Amy T responds that while she hasn’t seen a great approach to doing this in Figma, it’s really important to integrate content guidance and patterns in component documentation. Often documentation for design systems has a section on content, but no one visits it except for content designers. Consider how you might put language patterns and guardrails where designers and developers are working and learning about components. In Polaris, the Shopify design system Amy T worked on, the documentation for each relevant component includes guidance about how to think about designing the content — this is every bit as important to understand as how the colour system works!

Andy recommended providing a good example of a pattern within the component in Figma, but it doesn’t leave a lot of room for freestanding text. Amy H agreed - use realistic text in component examples and supplement it with guidance that lives with the component, integrated with the technical and design documentation. If you separate it out, you’re leaving a strong chance it won’t get looked at by the people who need it!

How do you navigate a more long-established design system?

This is all well and good when creating a new system. Our attendee Rachael was after advice when you want to improve a well-established design system from a content design/documentation perspective. Amy H recommends asking all the questions. Be relentlessly curious about the system, its users, and the team that supports it.

  • What’s going well?
  • What do they wish they could change?
  • What would they do differently next time?

Design system teams (like any product team) can become bogged down by decisions that were made a long time ago, and this is where fresh perspective can really add value. Is it time to revisit something that didn’t work in beta, if that was two years ago? Plus, starting with questions will help to build trust and show that you care about the system and respect its history (and those who worked on it). This is an important foundation for when you want to start introducing changes.

Amy T also advises to be opinionated. Make your list of questions and things you wish you could change and start making the case for them with anyone who will listen to you. Ask why decisions have been made and what the current structure is optimizing for. You’ve got the benefit of fresh eyes on a system that others on your team have probably been working on for a long time — this is your superpower. Be brave and use it! Andy warns that it matters how you share those opinions - make sure you can clearly articulate why and how words fit into the process, and how you can be just as systematic with words as they are with designs and code. Depending on how content-savvy your content design team is, they may not even realise that! That’s a great way to show your value quickly.

Which skills are most important for a content person who manages the design system?

Amy H has three key skills that any content person involved in a design system should have for our attendee Chris:

  1. The ability to get seriously meta and be able to move between the different layers of content design in a system. Some days you’ll need to be thinking about the content standards you want the system to embody and distribute. On others, you’ll want to be thinking about the content that explains the system - its landing pages, guidance for system users, contribution guidelines etc. You’ll need to get comfortable switching between these different aspects of a system.

  2. The desire to work as closely as you can with the system’s designers and developers, and the people who use it. Content cuts across everything, so developing a strong understanding of what other disciplines need from the content and how to deliver it to them in a way that makes sense to them is critical. To avoid divorcing content, development and design within the system, it has to be built by a collaborative, multi-disciplinary team.

  3. Finally - the capacity to relentlessly challenge the need to use design system industry vernacular. Design systems are an area of specialism and those of us who work in that area have developed a whole language around it which works great as a shorthand for those in the know but can (and does) alienate those who aren’t design system experts - but still very much need to use them. It’s your job to simplify, simplify, simplify. Open it up. Do the hard work to make it simple.

How do you approach content localisation in a design system?

Our attendee Teresa wanted to know about our panel’s experience and thoughts around content localisation best practices in design systems. Andy mentions as always ‘it depends’ - on your company, if you have a localisation team, and whether the design system folks have a working relationship with them. He think it’s important to establish that as early as possible, so if you don’t work with them, set up a meeting and introduce yourselves. Talk about what you do, how you do it, and see how you can help them. Chances are, your scalability can improve their consistency efforts and make sure designs are loc-ready from the start.

Amy T adds even if you’re pre-internationalisation and your product isn’t being translated, one of the ways you can future proof your language is to have a plan for how you’ll deal with colloquialisms and eccentric branded turns of phrases. Having a robust terminology usage list that drives consistent use of terminology is also a good way of future-proofing your content for translation. Amy H warns that components are nearly always built away from specific contexts they’re going to be used in, and so they need to be built flexibly - and that includes making sure they can support text strings, language conventions and content formats for all of the localities they’ll be used in. A final tip from Andy is to listen to any non-native language speakers in your team. They’re likely thinking about localisation and culturalisation from the start — from something as simple as identifying that “this string will truncate when it’s translated into Norweigan” to as complicated as “This icon and colour don’t mean what we intend it to mean in this locale.”

Is an outdated design system better than none?

Our attendee Kristiina shared that one thing that’s discouraging about design systems is how resource-demanding they can be to maintain. Challenging our panellists - is an outdated system better than none? All our panellists agree with Amy T who says no system is better than an outdated one. With an outdated system, it can be really hard for people to trust it as a source of truth.

Design systems don’t have to be expansive. Think about what your team needs most and invest in that — it doesn’t have to be all things to all people. Her second tip would be to federate ownership. It can be very hard to maintain a system with a small centralized team. Instead, put a couple of people in place to create some tools and workflows that make design system maintenance a company-wide sport shared across people. Many hands make light work.

Amy H recommends a plan to maintain and support a design system beyond its initial development should be part of an MVP. There is a graveyard of abandoned design systems leaving teams unsupported, creating confusion and doing more harm than good. In terms of what to keep in mind, consider the maintenance burden as you go. Anytime you add to the system, make sure you know how you’ll continue to support whatever you’ve just added. If you can’t - leave it out. She’s also a fan of staggered rollouts. Start small with something rough and scrappy, and test it continuously as you grow the system and invite more teams to use it.

What's the easiest way to let people suggest improvements to the design system's components?

A great question from Matt, Amy T recommends creating rituals that help them understand how to do it and invite them in. Often when people don’t contribute it’s because it’s unclear whether contribution is even welcomed.

For starters Andy can recommend what the design system team at Adobe does - regular share-outs about what’s new (with a robust Q&A), open and transparent workshops, bookable office hours, regularly syncs with representatives and partners from each product suite plus a bevvy of Slack channels where anyone can discuss or bring up ideas or critique.

Meeting the team where they are and making sure you’re accessible and open in a myriad of channels is a good start! It can often depend on how mature your design system/team is. Amy H adds that in a new design system team, create open forums and touchpoints where people can come along and share their feedback. Keep the process light and focus on open discussion and collaboration. Over time, move towards something more contributor-led, with a documented process to follow and a place to get support if they need it.

All Content by Design ticket holders can re-watch the panel in the On Demand area of the hub until the end of September.

The Benefits of Group Executive Coaching Fri, 16 Jul 2021 09:00:00 +0000 At Clearleft we know the value in bringing together design leaders to enable them to share, collaborate and support each other.

We saw how successful these interactions were at our retreats. However, given the restrictions of COVID regulations we weren’t able to run these retreats at a time when design leaders needed peer support more than ever.

We decided to pilot a remote Leading Design: Group Executive Coaching programme. We were delighted that Julia Whitney came on board to run the programme. She was Executive Creative Director and General Manager of UX & Design at the BBC, and is now an executive coach who helped to lead our retreats.

We designed the Group Executive Coaching programme to draw on some of the key benefits of the retreats: space to think, input from peers, and strategic provocations. Group Executive Coaching gives time and space to step away from the day to day and reflect in a safe, neutral space. As coach, Julia asks powerful questions to provoke fresh thinking. She listens deeply to the answers, and she “holds up a mirror” for participants, so they can see themselves and their context more clearly.

Our pilot Group Executive Coaching programme ran fortnightly over 12 weeks from the start of January until our Leading Design Festival in March. Although our retreats have always been hugely popular, this was the first time we’ve run a remote programme of this kind. We didn’t know what the appetite from our community would be. But the tickets sold out so quickly that we decided to add an extra cohort.

We had a balanced mix of attendees, with people joining us from around the globe from large organisations to small agencies.

We received excellent feedback from the attendees:

“As a new leader, the group coaching programme provided a safe space, every few weeks, to talk & reflect on shared challenges with design leaders from a range of organizations. Breakout sessions were a good opportunity to practice techniques learned in the group; silent coaching - listening and getting comfortable with not saying anything has been useful in all aspects of work & life.”

Teak Miu-Tse, Executive Creative Director of Design Systems & Operations | Sky Design

“I could not more highly recommend Clearleft and Julia Whitney's coaching program. This opportunity definitely provided me with opportunity to practice coaching skills that will be invaluable to my leadership and my team.”

Kristina Lawyer, Design Lead at Goalbook

In fact, the programme was so successful that we have decided to run it again. The next cohort will be starting in September 2021. To keep group sizes small there are only a limited number of tickets available and tickets will be allocated on a first come, first served basis.

If you have any questions about the programme you can get in touch with me or you can find out more and buy tickets here.

Weighing up UX Tue, 08 Jun 2021 08:44:00 +0000 This is the month of UX Fest 2021—this year’s online version of UX London.

The festival continues with masterclasses every Tuesday in June and a festival day of talks every Thursday (tickets for both are still available). But it all kicked off with the conference part last week: three back-to-back days of talks.

I have the great pleasure of hosting the event so not only do I get to see a whole lot of great talks, I also get to quiz the speakers afterwards.

Right from day one, a theme emerged that continued throughout the conference and I suspect will continue for the rest of the festival too. That topic was metrics. Kind of.

See, metrics come up when we’re talking about A/B testing, growth design, and all of the practices that help designers get their seat at the table (to use the well-worn cliché). But while metrics are very useful for measuring design’s benefit to the business, they’re not really cut out for measuring user experience.

People have tried to quantify user experience benefits using measurements like NetPromoter Score, which is about as useful as reading tea leaves or chicken entrails.

So we tend to equate user experience gains with business gains. That makes sense. Happy users should be good for business. That’s a reasonable hypothesis. But it gets tricky when you need to make the case for improving the user experience if you can’t tie it directly to some business metric. That’s when we run into the McNamara fallacy:

Making a decision based solely on quantitative observations (or metrics) and ignoring all others.

The way out of this quantitative blind spot is to use qualitative research. But another theme of UX Fest was just how woefully under-represented researchers are in most organisations. And even when you’ve gone and talked to users and you’ve got their stories, you still need to play that back in a way that makes sense to the business folks. These are stories. They don’t lend themselves to being converted into charts’n’graphs.

And so we tend to fall back on more traditional metrics, based on that assumption that what’s good for user experience is good for business. But it’s a short step from making that equivalency to flipping the equation: what’s good for the business must, by definition, be good user experience. That’s where things get dicey.

Broadly speaking, the talks at UX Fest could be put into two categories. You’ve got talks covering practical subjects like product design, content design, research, growth design, and so on. Then you’ve got the higher-level, almost philosophical talks looking at the big picture and questioning the industry’s direction of travel.

The tension between these two categories was the highlight of the conference for me. It worked particularly well when there were back-to-back talks (and joint Q&A) featuring a hands-on case study that successfully pushed the needle on business metrics followed by a more cautionary talk asking whether our priorities are out of whack.

For example, there was a case study on growth design, which emphasised the importance of A/B testing for validation, immediately followed by a talk on deceptive dark patterns. Now, I suspect that if you were to A/B test a deceptive dark pattern, the test would validate its use (at least in the short term). It’s no coincidence that a company like, which lives by the A/B sword, is also one of the companies sued for using distressing design patterns.

Using A/B tests alone is like using a loaded weapon without supervision. They only tell you what people do. And again, the solution is to make sure you’re also doing qualitative research—that’s how you find out why people are doing what they do.

But as I’ve pondered the lessons from last week’s conference, I’ve come to realise that there’s also a danger of focusing purely on the user experience. Hear me out…

At one point, the question came up as to whether deceptive dark patterns were ever justified. What if it’s for a good cause? What if the deceptive dark pattern is being used by an organisation actively campaigning to do good in the world?

In my mind, there was no question. A deceptive dark pattern is wrong, no matter who’s doing it.

(There’s also the problem of organisations that think they’re doing good in the world: I’m sure that every talented engineer that worked on Google AMP honestly believed they were acting in the best interests of the open web even as they worked to destroy it.)

Where it gets interesting is when you flip the question around.

Suppose you’re a designer working at an organisation that is decidedly not a force for good in the world. Say you’re working at Facebook, a company that prioritises data-gathering and engagement so much that they’ll tolerate insurrectionists and even genocidal movements. Now let’s say there’s talk in your department of implementing a deceptive dark pattern that will drive user engagement. But you, being a good designer who fights for the user, take a stand against this and you successfully find a way to ensure that Facebook doesn’t deploy that deceptive dark pattern.


Does that count as being a good user experience designer? Yes, you’ve done good work at the coalface. But the overall business goal is like a deceptive dark pattern that’s so big you can’t take it in. Is it even possible to do “good” design when you’re inside the belly of that beast?

Facebook is a relatively straightforward case. Anyone who’s still working at Facebook can’t claim ignorance. They know full well where that company’s priorities lie. No doubt they sleep at night by convincing themselves they can accomplish more from the inside than without. But what about companies that exist in the grey area of being imperfect? Frankly, what about any company that relies on surveillance capitalism for its success? Is it still possible to do “good” design there?

There are no easy answers and that’s why it so often comes down to individual choice. I know many designers who wouldn’t work at certain companies …but they also wouldn’t judge anyone else who chooses to work at those companies.

At Clearleft, every staff member has two levels of veto on client work. You can say “I’m not comfortable working on this”, in which case, the work may still happen but we’ll make sure the resourcing works out so you don’t have anything to do with that project. Or you can say “I’m not comfortable with Clearleft working on this”, in which case the work won’t go ahead (this usually happens before we even get to the pitching stage although there have been one or two examples over the years where we’ve pulled out of the running for certain projects).

Going back to the question of whether it’s ever okay to use a deceptive dark pattern, here’s what I think…

It makes no difference whether it’s implemented by ProPublica or Breitbart; using a deceptive dark pattern is wrong.

But there is a world of difference in being a designer who works at ProPublica and being a designer who works at Breitbart.

That’s what I’m getting at when I say there’s a danger to focusing purely on user experience. That focus can be used as a way of avoiding responsibility for the larger business goals. Then designers are like the soldiers on the eve of battle in Henry V:

For we know enough, if we know we are the kings subjects: if his cause be wrong, our obedience to the king wipes the crime of it out of us.

This was originally published on my own site.

You can listen to an audio version of Weighing up UX.

Remote research: Around the world in a day Tue, 01 Jun 2021 09:20:00 +0000 It’s 7pm in the UK. I started my day talking to someone in Tokyo, before moving to Manchester, and I’ve just finished up in San Francisco. Eighteen timezones. 14,645km (give or take). And no jetlag.

World map with lines of travel from the UK.

Over the last few weeks, I’ve been globetrotting to carry out research as part of a design project for UCL (University College London). It’s an institution that prides itself on attracting students from all over the world, and across all the nooks of the UK. It’s important that the work we’re doing is informed by their voices and needs.

For me, honing my remote research skills has been one of the positives of lockdown. Although I was no stranger to remote research my go-to method was always the more controlled environment of a usability lab.

Now I can see the advantages of a blended approach in many more projects. A combination of some in-person and some remote sessions is a way of extending the geographic reach and diversity of the participants we talk to.

I don’t think it’s just me that’s improved my skills. Participants have become noticeably more comfortable using the technology and talking on screens. It’s been a while now since I’ve had to talk someone through how to share their screen or how to open the chat window to find a link to a prototype.

Having done multiple projects and numerous research sessions during lockdown, I’ve been reflecting on what helps to make remote research successful.

Selecting your software

I started counting up the different bits of software we use in most sessions. I soon ran out of fingers. There is no one tool to use, rather a hotchpotch of bits and pieces. Some are free to use, others are available with licences and subscriptions.

Within sessions, it’s common for me to simultaneously be using software to screen share (Google Meet, Zoom, Teams), a way to record the session (OBS studio, plug-in for Chrome, Screenflow) and a way to share stimulus (Figma prototypes, Google docs, Typeform surveys and polls).

Our preference is to have members of the project team and clients observe research in real-time. To ape a participatory backroom of a research lab we livestream sessions on a private link on either YouTube or Vimeo. We then guide those observers to collect structured notes in a shared virtual space such as on a Miro board, in Airtable or a Google sheet.

Our toolkit for remote research is not limited to just the sessions. Calendly has become indispensable for inviting participants to book days and times that fit their schedule. Its automated calendar invites (in local timezones) with screen-share links is a huge timesaver. Incentives can be conveniently sent as Amazon vouchers. Then there’s the sense-making. Automated transcription software (Descript,, and collaborative cloud-based tools for synthesis and analysis have made this part of the process a collective—if still distanced—activity.

When it comes to technology and remote research, I’ve found success mostly comes from two factors:

  1. Playing around with different tools to find the ones that best fit the budget, timeframes and needs of the project. With new features and updates appearing regularly it’s useful to keep an eye open for opportunities to expand the tools you use.

  2. Having a practice run to iron out the gremlins. The more tools in play, the more potential for hiccups. You want to be concentrating on the participant in the session, not worrying about the technology being used to run it.

Putting participants at ease

It’s not a huge leap from facilitating in-person to remote research. There are some small changes to be mindful of to make the sessions easier for the participants and yourself.

One big positive change I’ve noticed is that participants seem more relaxed and open by being in their own environment using their own technology and at a time that better suits their lifestyle.

Even so, it’s still important for the facilitator to make the participant feel comfortable. A free-flowing conversation is harder when there’s a screen between you.

In tackling this I make a point of always being on a call five minutes early so that a participant is never left waiting in a digital void. Then in the introductory chat, I acknowledge the technology might let us down and I tell them what to do if either of us freezes on screen, has distorting audio or connection issues. Being upfront about potential issues helps participants know chaos is to be expected and embraced.

As I’ve done more remote sessions I’ve come to accept that I’ll get through fewer tasks and questions than in an in-person session. Pauses for blips in technology and asking for clarifications because the sound temporarily dropped out are all part of the medium.

Hello world!

The great thing about remote research is it’s more convenient for a wider cross-section of your audience to take part in sessions.

You’ll likely need to elongate the duration for research. Don’t expect neatly timetabled back-to-back sessions. And you’ll need to be more flexible with your working hours to fit the lifestyles and locations of your participants. But broadening the conversations beyond who’s available on a set day in a set location can only improve the insights you gain.

The choice shouldn’t be between doing remote or in-person research sessions. A blended approach is often viable and desirable and gives you the best of both worlds.

Right, I’m off to prepare for tomorrow’s travels to Buenos Aires, followed by Newcastle and Seville.

5 themes from Leading Design Festival Fri, 21 May 2021 08:00:00 +0000 In March 2021 we hosted Leading Design Festival. Themes started to emerge throughout the month. We were joined by Andy Budd, the curator and host of this year’s festival to discuss the main themes he saw emerge.

1. The Importance of Individual Contributors

A theme that we explored throughout the festival was the importance of the Individual Contributor (IC). Peter Merholz talked about the importance of these designers, claiming that they have the most important role in the team.

A lot of talented designers get promoted to leadership, with the expectation that they will inspire their team with their exceptional craft skills. However management is a full time job, and player coaches are often the first to burn out or become a bottleneck. So in most cases, these designers step away from craft, creating a gap in inspiration and mentorship. This is a gap that very experienced practitioners can fill. But only if they are allowed to remain individual contributors. We shouldn’t automatically force great designers to become mediocre managers in order for them to be able to progress in their careers. And if you are going to jump tracks from an individual contributor to a manager then you need support.

Key takeaways from this theme:

  • Leadership is different to management.
  • Great designers don’t always make great managers.
  • Design leaders need to have teams made up of Heads, Directors, and Senior ICs.

2. Managing People

We heard how challenging it can be to manage teams. One of the best ways to support your team is through effective 1-2-1s, something Abi Jones talked about in depth. They are an opportunity for leaders to support their teams. If you treat 1-2-1s like status updates you end up being a project manager instead of a design leader. You need to invest in your teams and their success, which takes time and deliberate practice.

We also explored the importance of clear communication. As leaders we have to over-communicate. Having some kind of team mission statement or charter can help align teams to the wider company mission. Take a company-wide mission and turn it into a manifesto for your team.

A few speakers talked about the concept of having some sort of “readme” or “manual of me” file, explaining your motivations, working preferences and idiosyncrasies to your team.

Key takeaways from this theme:

  • 1-2-1s need to be a deliberate practice, not a to-do list.
  • You need to make sure that as a leader there is alignment between the input you are getting from your executives and peers and what you share with your teams.
  • Know your own idiosyncrasies.

3. Getting The Support You Need

One recurring theme was just how physically and emotionally taxing leadership can be, and this past year has been no exception. There is often an assumption that gaining status in an organisation makes your life a lot easier. But it can also be isolating.

Alistair Simpson talked about the loneliness of leadership. This theme was echoed in several other talks, including Lola Oyelayo Pearson’s talk about leading in hostile environments. Lola talked about how hard it is being the only one of your kind in an organisation. For instance being the only design leader in a company full of engineers. And how in those sorts of situations you find yourself constantly having to justify your own presence. That’s something your cross functional peers rarely have to do.

Alistair talked about the importance of getting external support, be that friends, coaches, therapists or a personal trainer. While Aaron Irizzary talked about developing your own personal board of advisors.

Key takeaways from this theme:

  • Being a design leader can be very lonely. Often you are the one of your kind.
  • If you are burning yourself out then you are doing your team a disservice.
  • You need a robust support network to help you manage a high-stress, high-profile role.
  • Sometimes you need space to work on yourself, not always for your team and company.

4. The (Temporary) Cessation of Abundance

One of the reasons the past year has been so hard for many leaders is it’s the first time they’ve had to deal with large scale redundancies.

While this is a fairly common part of the business cycle in traditional organizations, many start-up founders, design leaders and team members are experiencing this for the first time. We got so used to operating in a world of abundance—ever increasing markets, funding and headcount—that a lot of us were unprepared for the opposite situation to happen.

We heard from Audrey Liu, Christine Pizzo and Stuart Clarke-Frisbey about how they were forced to let some of their teams go. Audrey talked about our tendency to over-index on the people who are leaving, but reminded us that we also have a duty to those who are staying. Stuart touched on how this reduction in staff numbers forced him to redesign his org, and how he started sharing scenarios with his senior team in order to get them comfortable with a range of possible outcomes.

It’s worth noting that when you’re forced to make cuts to your team, this will have a dampening effect on morale, and in all likelihood will lead to more team members leaving. You may find yourself having to recruit shortly after a round of redundancies.

At Clearleft we’ve noticed an increased demand for agency design services as teams have shrunk, recruitment has temporarily been paused, but work is backing up that needs to be done.

Key takeaways from this theme:

  • Downturns can be part of the natural business cycle and shouldn’t be seen as a failure.
  • Experiencing a temporary lack of abundance can be tough but it is also an important opportunity for your growth.
  • You can use this as a period to resettle and refocus.

5. Earning Your Seat at the Table

Lastly we heard from a whole range of leaders about how design isn’t owed anything. Design leaders need to earn their seat at the table.

We heard from Stuart Clarke-Frisby about how he raised the profile of design inside by proving design was a profit center rather than a cost center. But it doesn’t have to be all about profit. We heard how Doug Powell encourages his leaders to share other metrics like the ratio of designers to developers, open head counts, etc. This maps nicely with some of the things Stuart was saying about scenario planning and the importance of managing executive expectations.

We heard how Katie Dill asked her CEO for an executive position, and was told that she wasn’t ready because she hadn’t invested enough in building relationships with her cross-functional peers. So she set about doing just that. She explained her view that there were three types of leaders. Design Leaders, Product Leaders, and Business Leaders. In order to earn a seat at the table you need to level up from one to the next.

Once you have a seat at the table, your attitude needs to change. Rather than being there to “fight the corner for design” you’re now there to run the business. You might have to make decisions that aren’t in the immediate best interest of the “design team”, something Lyndsey Thornton from Shopify explained.

Key takeaways from this theme:

  • A seat at the table can be a political statement: we should be treating design leaders the same as engineering leaders.
  • The drive to have a seat at the table can represent the drive to be recognised and legitimised.
  • A seat at the table has to be earned.
  • When we have a seat at the table we need to think about the needs of the business, not just the needs of the design team.
  • When you’re at the table your first team is the executive team.
  • At the exec level your role isn’t to surface all of the needs of the design team, but to lead the business through design.

A huge thanks to everyone who played a part in the festival’s success. A special thanks to all of our contributors and to our sponsors: Google, Amazon Design, Salesforce, Sketch, and Mailchimp.

You can also watch the full video of our conversation with Andy

Maturing design in a pandemic Mon, 17 May 2021 23:00:00 +0000 During Leading Design Festival we had a panel discussion about how the COVID-19 pandemic has changed the culture and maturity of design within organisations.

We have created a framework for mapping design maturity here at Clearleft, it has five key areas: impact, purpose, trust, empathy, and collaboration.

We invited a discussion on these core areas between Andy Thornton and Jon Aizlewood from Clearleft, plus special guests Andrea Ong, director of product design at Loopio now but formerly at Loblaw Digital, Robert Fransgaard, head of experience design at H&M Group, and Michelle Morrison, head of design operations at Dropbox.

The Design Maturity Assessment showing the five factors and a circle for the score out of 100
A template from our Design Maturity Assessment we use with clients

Andy kicked things off by asking the group of these five factors for design maturity, how may they have shifted over the course of the last year with the disruption of the pandemic.

Talking to new starters at Loblaw Digital, Andrea found that the company has actually managed to keep a sense of collaboration intact. A lot of that is down to everyone very intentionally staying connected, especially in Slack. Interestingly, a lot of people connected through pets, for example. Andrea believes that the old way of thinking about keeping work life and home life separated no longer works. Michelle described the big shift that took place at Dropbox. Before the pandemic, the culture there was centred on in-person interactions in their lovely offices. They’ve had to shift their culture quite a bit. Again, Slack really helped.

Andy brought up the subject of empathy. Usually, we talk about having empathy for our users, but the pandemic has really made everyone think about empathy for the people we work with. Perhaps we’re all treating one another as human beings first and foremost rather than as resources. Andrea pointed out that the distancing effect of having everything mediated through a screen can actually mitigate the rawness of some tough interactions for some people. Michelle described how well-being has been a core feature of Dropbox’s strategy during the pandemic. Crucially, the leaders there were very open and demonstrated empathy. Robert emphasised the importance of that kind of behaviour modelling. It’s not enough for the company leadership to say that people can work in a certain way, they must also demonstrate it themselves.

The group wondered whether the pandemic has been something of a leveller in terms of impact. Robert mentioned that the pandemic was actually somewhat useful for getting people at H&M used to remote work—something they had already started trying to do. Whereas before perhaps the designers in the central office had more visibility, now everyone, regardless of location, was able to contribute equally. Jon agreed that the pandemic has been like a forcing function for digital transformation in many organisations.

The question of trust also came up. But interestingly, most people felt that the issue wasn’t around whether the leadership trusted their employees to work effectively from home. It was more about whether the employees trusted that the leadership would value remote work. As Robert put it, “Do I trust my manager to trust me?” Michelle talked about trust manifesting itself in calendars. People need to feel that they can put blocks of their domestic life into their work calendars. Above all, communication is key to establishing and maintaining trust. That was true before the pandemic, but it’s even more important when people are working remotely.

All the panellists agreed that in terms of collaboration there needs to a balance between asynchronous work and synchronous communication. You need to be able get your head down and really dig into something, but you also need to come up for air and check in with your team. Before the pandemic, the heads-down work was often hard to do, especially in an open-plan office. But you’d also get plenty of communication at the water cooler. Remote work favours alone time, but you really have to work at trying to get those water-cooler moments.

Everyone recognised that time tracking effectively went out the window during the pandemic, and that’s not a bad thing. After all, it’s the outcomes that matter, not the hours spent sitting at a desk. Michelle described this as a shift from busy-ness to impact.

Thank you so much to our paneliists. You can watch the full panel here.

Introducing Content by Design Fri, 14 May 2021 11:37:00 +0000 Often businesses fall into the content trap: content is under-resourced, content designers aren’t brought in early enough. It’s hard for content designers to think strategically or influence the wider business. The business then fails to invest because it can’t see the value…it’s an endless cycle.

Breaking this cycle means understanding what good content design looks like, fostering better collaboration, and scaling up the role of content.

Everyone from content designers and designers, through to product and team leads, has a part to play if we’re to master the marriage between design and content, so this conference is aimed at all these roles. At Content by Design we’ll hear from those who’ve built and led teams, influenced large orgs to value content design, and inspired a whole generation of content designers to create better content.

Your host

We’re thrilled to have ex-Clearleftie Rachel McConnel curating and hosting Content by Design.

Rachel long felt the UK needs its share of content design conferences. There are a few content conferences but those focused on content within product design tend to happen stateside. So in 2019 Rachel started approaching her content heroes around the globe, asking them to assemble in London for a two-day conference. Bringing together their collective experience to give attendees an amazing chance to hear their practical tips and advice. Since then lock-down happened and we’ve all had to re-schedule and re-format our 2020 event.

However, we’re beyond thrilled to announce that Content by Design will be going ahead in an online format on the 6th and 7th July 2021.

A conference putting content at the heart of design

Why join us online in July?

This will be an engaging and practical conference, for both content designers and UX writers, or anyone producing content as part of product design. Our expert speakers will help you to

  • Create more strategic, inclusive product content
  • Achieve effective collaboration with designers
  • Become a more rounded content designer
  • Sell your UX writing skills
  • Approach integrating content into design systems

Plus all the talks from the conference will be captioned and available to you on-demand for three months after broadcast - so you don’t have to miss a thing no matter where in the world you are, or what life throws at you next.

Because great design needs great content, so let’s make it happen.

Early bird tickets!

Choose the ticket type that suits you - we have two days of talks from our content and design superheroes. Plus an afternoon of deep-dive workshops to get your teeth into. You will leave with your heart full of inspiration, and your notebook full of practical tips.

Grab an Early Bird ticket here (ends 21st May)

Parts of this post were originally published on Rachel’s Medium.

On Design Engineering: Systemised design foundations Wed, 12 May 2021 09:29:00 +0000 A phrase James and I like to use is “Designing design”.

We like to start a project by creating a foundational set of instructions to govern the project, covering:

  • Typography
  • Space
  • Colour
  • Grids

These instructions are created and validated collaboratively through our two mediums: the design tool™ (currently Figma) & and the web browser. Implementing immediately in the browser allows us to:

  • Check colour contrast on real screens
  • Test site wrappers, gutters and ‘standard’ grid layouts at different widths
  • Ensure the fluid typography feels harmonious, and scales to sensible sizes on small devices
  • Deploy something to staging right away, testing our build system in the process

Are these design tokens?

Depending on your definition of design tokens, you might view these as tokens or not. I view them as foundational values that might drive design tokens. These foundations are very much ‘responsive web focused’; and being honest, I’ve never worked on an Android/iOS application that required a shared token system, so can’t speak with any authority on that.

While they are named and application-agnostic, they are not language agnostic so I’m still on the fence as to whether they are design tokens or not. Anyway, that’s semantics.

Systemised design foundations

It’s tempting to lift foundational values (font sizes, hex codes) from Figma, and drop them straight into your code. But we’ve found it far more efficient in the long run to mimic the ‘system’ that comes up with the final results in code.

Take colours as an example. One way to create tints and shades of a base colour is to overlay white/black with differing percentages of opacity. This is pretty easy to do in Figma with two circles:

Two overlapping circles

To translate this into code, we could use a colour picker on that central lighter colour and grab the hex code directly. If there’s only one colour in play, that might be an appropriate amount of effort. But what happens when there are more tints, and more base colours? What happens when you decide the base colour is too dark, or your overlay tints should be at 30%, 65%, and 95%?

Colour function grid


Fortunately, it’s possible to automate these sorts of tasks with SCSS:

@function colour-mix($background, $mixer, $percentage) {
  $percent: alpha(rgba($mixer, $percentage)) * 100%;
  @return mix($mixer, $background, $percent);

$brand-blue: #0C3E63;
$brand-blue-tint-1 colour-mix($brand-blue, white, 25%);

This isn’t to advocate this exact way of working, that should be decided by your own design process. This is to suggest:

  1. Automate where you can
  2. Start thinking in systems from the smallest atomic size; structure and logic will follow you through the project

Why systemise your design foundations?

Building a small system for the four foundations, over a hard coded config file of magic numbers is helpful for a number of reasons:

1. Creating a palette of named foundations produces a positive ‘friction-point’ Let’s say an engineer has been handed a design with a minutely different font-size to the last template. If they’re new to the team, or hold the design team decisions as gospel, they might well add the new size to the site, despite the fact that that could’ve been an honest design mistake slipping through the cracks.

But with shared foundations and explicit names for each size, not only does the system provide the grounds and confidence to push-back and check, it more importantly provides the common language between the developer and the designer to prevent it from happening in the first place.

One rule that has held us in good stead is:


This sense check helps to keep things consistent and prevents sporadic additions to the system. The smaller the system, the easier it is to hold in your head and utilise.

2. You can tweak the system to generate interesting new possibilities, inspiring new design. Testing for colour contrast, grid efficiency and font-sizes across devices is best done on real screens, and the quickest way to come of those decisions is to tweak them live in the browser.

This idea of tweaking the system, not the outputs fed into Utopia, where you’re able to change the type scale, base unit and viewport sizes, and let the system create the values. Being declarative and ‘letting the computer decide’ is a fundamental part of how CSS works. Build upon tools that embrace this mindset.

3. It empowers developers to design The most exciting part of being a design engineer on a project is the truly fluid design & development process. The shared system has allowed me as a ‘developer’ to design full page templates in the browser, and see them pulled back into Figma as the design source of truth.

Tip: Try out utility classes for prototyping. I find it helpful to start working in one file (HTML) to sketch out the broad strokes of a component using utility classes. Then, when the design is converging, take the time to refactor back into encapsulated CSS.

4. Engineers are ‘systems thinkers’ - built them a system Creating this backbone of logic will go a long way to bridging that gulf between the subjective and objective1. I believe that the more ‘system-y’ your design is, the more accurately an engineer will recreate it. If you can explain the logic that goes into a design decision, other designers and engineers are more likely to apply the same pattern for similar use-cases.

The power of common language

There is huge power in a common language between design and engineering.

Common language creates unity, and sense of shared purpose on a project. It brings consistency to the user interface, and to the codebase. It prevents wasted effort generated from needless duplication. It reduces doubt around the understanding of design intention.

If you were to take all the components away from a design system, and leave only the foundational common language, I believe it would still be a very helpful tool—in my opinion, a design system is way more about the ‘team benefits’ as it is about making the interface consistent. As Jeremy considered in the first episode of the Clearleft podcast:

Let’s say your company has a design system manifested in the designs code and documentation for all your product’s interface elements. Now, what would be worse: if everyone in your company suffered collective amnesia about your company’s processes and priorities, but your design system remained intact? Or would it be worse if everyone retained that knowledge but your library of components disappeared in a puff of smoke?

Jeremy Keith

How to document design foundations

Each pillar deserves it’s own page of documentation. This could be in a Wiki, in Figma, or ideally, in your design system. For each concept, cover three topics:

1. Implementation: How would we use this? The specific implementation details are project-specific. You could manage space with a SCSS mixin, Custom Properties could hold your colour calculations, a JSON file might hold your type scales. But here’s an example of some short documentation on a SCSS function:

SCSS function
The color() function takes two arguments, one for the colour and one for the shade/tint. The full list of brand colours, tints and shades can be found here.

.c-component {
  background: color('blue', 'tint-3');
  color: color('green');
Utility classes
You can also use utility classes to apply colour, with one set for the color property, and another for background-color:

<p class="u-blue">Blue text</p>
<p class="u-bg-green-tint-1">Green tint 1 background</p>

2. Demonstration: What does the result look like? Demonstrating these principles is key to adoption. A live example is usually clearer to understand, then a purely theoretical one.

For colour, that could be a swatch:

Colour principles chart

For typography, that could be a type scale visualisation:

Type scale visualisation

3. Rationale: Why did we come to these decisions? Finally, describe how you got to this point. Were there any user testing or analytical insights that led to this decision? For example:

“The colour palette is based on the existing brand colours with tints and shades available for backgrounds, borders, increasing contrast etc. Colour contrast ratios should be checked with a tool like the webAIM contrast checker to ensure all text meets WCAG AA requirements.”

This post was originally published on Trys’s website - you can find the introduction to Design Engineering as a term here and all the articles from Trys’s incredible series here.

Introspection as an initiative Fri, 07 May 2021 08:44:00 +0000 I find it second nature to question myself. Often I’ll reflect and analyse in an endless loop, eventually introducing doubt into my own decisions.

If you’ve ever watched The Good Place, I often joke to my wife when I’m ‘pulling a Chidi’, the character who tangles himself into logic and philosophy knots, leaving him unable to make decisions in many circumstances.

THE GOOD PLACE -- "Jason Mendoza" Episode 104 -- Pictured: William Jackson Harper as Chidi -- (Photo by: Justin Lubin/NBC)
THE GOOD PLACE -- "Jason Mendoza" Episode 104 -- Pictured: William Jackson Harper as Chidi -- (Photo by: Justin Lubin/NBC)

Though an introspective nature can be paralysing at times, it can also be incredibly powerful given the right opportunity. For example giving and receiving feedback at a design agency is expected. I’ve found design reviews incredibly rewarding as they helped push me into understanding where I could improve as a designer. Unfortunately, at many companies design reviews or similar sessions where feedback is encouraged tend to be siloed within certain disciplines or project teams and miss an opportunity of including a wider culture.

At Clearleft we’ve recently introduced an experiment to try and maintain ‘continuous improvement’ across the company, practitioners and admin staff alike. The goal: to establish a more open and feedback-driven culture, driving introspection and creating a triple win situation by surfacing what we can improve in order to progress ourselves, our careers and our company.

Up to now the only method for feedback outside our project teams or disciplines came about once every 6 months, to include all staff. Unfortunately 6 months is a long time to wait, and experiences during a project or otherwise will have faded from memory. Any feedback received half a year later can be diluted, inadequate or without evidence.

Black box

This act of gaining continuous improvement echoes the takeaways from Matthew Syed’s Black Box Thinking, a book and premise I’m a huge fan of and on which I based my talk on Learning from Failure and most recently shared at Mobile UX London. The premise: that feedback can act like a plane’s black box for our professional and personal growth. The notion of continuous improvement at Clearleft is for now an experiment, but a worthwhile one to see if we can foster a culture of more open, candid and constructive feedback that results in stronger design, a supportive culture and a desire to know what can be improved.

Having already received peer feedback as per the experiment, I can attest that the experience hit the right balance between painful and productive.

Though welcome, feedback that’s platitudinal and positive isn’t actionable. It may help you maintain a course but it doesn’t tell you that you’re off-course, or provide insights into how to fix it. Painful feedback might be uncomfortable and at times harrowing, but it’s providing home truths. Within those truths is real growth.

This post was originally published on my own site

The state of UX Thu, 08 Apr 2021 13:49:00 +0000 There is much introspection and navel-gazing in the world of user experience design. More than usual, I mean.

Jesse James Garrett recently said:

I don’t think I know anyone that’s been in UX more than a decade who’s happy with how it’s going.

In a recent issue of the dConstruct newsletter—which you really should subscribe to—I pointed to three bowls of porridge left out by three different ursine experience designers.

Mark Hurst wrote Why I’m losing faith in UX. Too hot!

Scott Berkun wrote How To Put Faith in Design. Too cold!

Peter Merholz wrote Waking up from the dream of UX. Just right!

As an aside, does it bother anyone else that the Goldilocks story violates the laws of thermodynamics?

Anyway, this hand-wringing around the role of UX today seemed like a suitably hot topic for one of our regular roundtable chats at Clearleft. We invited Peter along too and he was kind enough to give us his time.

It was a fun discussion. Peter pointed out that whenever he hears an older designer bemoaning the current state of design, he has to wonder what’s happened in their lives to make them feel that way (it’s like when people complain about the music of today and how it’s not as good as the music of whatever time period I was a teenager). And let’s face it, the good ol’ days weren’t so good for everyone. It was overwhelmingly dominated by privileged white dudes. The more that changes, the better …and it needs to change far, far more.

There was a general agreement that the current gnashing of teeth isn’t unique to UX. It’s something that just about any discipline will inevitably go through. Peter’s epiphany was to compare it with the hand-wringing around Agile:

The frustration exhibited with the “dream of UX” is (I think) identical to the frustration the original Agile community sees with how it has been industrialized (koff-SAFe-koff).

Perhaps the industrialisation of what once a cottage industry is the price of success. But that’s not necessarily bad, as long as you industrialise the right things. If UX has become the churning out of wireframes at scale, then something has gone very wrong. If UX has become the implementation of dark patterns at scale, then something has gone very wrong.

In some organisations, perhaps that’s exactly what’s happened. In which case, I can totally understand the disillusionment. But in other places, I see the opposite happening. I see UX designers bringing questions of ethics to the forefront. I see UX designers—dare I say it?—having their proverbial seat at the table.

Chris went so far as to claim that we are in fact in a golden age of user experience design. Controversial! But think about it, he said. Over the next few days, pay attention to interactions you have with technology, and consider the thought and skill that has gone into them.

I had Chris’s provocation in mind when I wrote about booking my vaccination appointment:

I just need to get in, accomplish my task, and get out again. This is where the World Wide Web shines.

Maybe Chris is right. Maybe the golden age of UX is here. It’s just not evenly distributed. Yet.

It’s an interesting time for the discipline of user experience design. I’ve always maintained that the best way to get a temperature check for your chosen field is to go to a really good conference. If you’re a UX designer and you want to understand the state of the UX nation, you should get a ticket for the online UX Fest in June. See you there!

This was originally posted on my own site.

Join us for UX Fest in June Wed, 07 Apr 2021 09:22:00 +0000 UX London would have been 13 this year! So we’re thrilled we still get to bring the community together (albeit virtually) in June. UX Fest has six themed conference days packed with talks and Q&A’s with design leaders at Twitter, Spotify and more. Plus a host of masterclasses for you to choose.

UX Fest June 2021

Why you need to join UX Fest this June.

For practitioners…

  • Discover how design leaders, experts, authors and founders have shaped and adapted the UX, design and product teams of our industry’s most influential brands to tackle one of the most challenging years of recent times.
  • Sense-check your bias as design leaders - share how to design at the forefront of accessibility and inclusion.
  • Take some much-needed development time-out to level-up your skills (with a selection of masterclass covering + masterclass themes for google sheet tab))
  • Learn to speak more business. In this new world, designers need to better understand the business landscape. UX Fest will give you a host of shortcuts to stakeholder buy-in.
  • Learn from your peers in networking sessions designed to fast track meaningful conversations about shared challenges.
  • Find your next mentor or mentee relationship from outside your existing circle of contacts.
  • Reconnect with your industry and get excited about the future. Because fresh input leads to better thinking.

For leads, senior ICs, managers and principals…

  • UX Fest will give you on-the-ground insight into how your fellow team leads are navigating this new world. You’ll hear stories of innovation and growth that can truly educate, and inspire fresh thinking from your team.
  • Take a moment to zoom out and look at the big picture; be challenged and ensure the design culture we’re fostering is industry standard by hearing the latest thinking on design and strategy, culture and ethics.
  • Get an industry temperature check so you can evaluate where you’re at right now and where you need to be aiming towards.
  • Boost team spirit. Nothing cements a team better than learning together. While we have to be apart, UX Fest is the best way to share an experience and level up as a team. Plus we have group discounts built-in (more on that below).
  • Meet potential candidates and collaborators via our Festival Miro board. Our event job board is the perfect spot to fill your recruitment pipeline at UX Fest.

Customise your UX Fest experience

Get access to the conference days that suit you best… or go large and book one of our Combo passes. You can level-up your UX Fest experience with a choice of over a dozen masterclasses too.

The Conference pass: 1, 2 & 3 June Three days centred squarely around interaction and product design - this is for designers of all levels. There will be talks on everything from user research and product strategy— through to UX writing, multi-variant testing and growth design. Find out more

The Festival: 10, 17 & 24 June We’ll be zooming out to cover big picture topics including ethics, culture and design in business. The Festival days are perfect for more senior practitioners, design managers, senior ICs and product owners. Or anyone who has their eyes on the design horizon. Check out the programme

Masterclasses: 8, 15, 22 June These individually bookable, 90-minute sessions are led by industry experts and will cover some of the hottest topics in our field. This is an opportunity for you and your team to learn a host of new skills, like strategic thinking, growing your impact, designing better workshops and more. Explore the topics

On demand access

All the sessions from the Conference and Festival days will be available to pass holders on demand for three months after broadcast. So you don’t have to miss a thing no matter your time zone.

We’re committed to accessibility, so all the talks will be captioned or live transcribed.

Bring your team

There are built-in discounts for groups of five or more so your whole team can get the benefits of participating.

**Grab your pass here or masterclass spot here*

Season two of the Clearleft podcast Mon, 29 Mar 2021 16:07:00 +0000 Season two of the Clearleft podcast is in the can. Taking a step back and looking at the six episodes, I think it turned out very well indeed.

Episode One

Design Leadership. Lots of smart people in this one. And I like that the source material is a real mix: conference talks, a roundtable discussion, and an interview.

Episode Two

Employee Experience Design. More of a deep dive than a broad overview. It’s pretty much a two-hander from Chris and Katie.

Episode Three

Accessibility. This one got a lot of attention, and rightly so in my opinion. It’s got three excellent contributors: Laura, Léonie, and Cassie. My job was to get out of the way and string their knowledge bombs together.

Episode Four

Prototyping. I had three good stories to work with from Benjamin, Lorenzo, and Trys. Then at the last minute I was able to add an interview with Adekunle which ties the whole thing up nicely.

Episode Five

Diversity and Inclusion. I think this might be the highlight of the season. Again, it’s got a mix of source material from conference talks and interviews. The quality of the contributions is exceptionally good. Once again, I found my job was to mostly get out of the way and line things up so they flowed well.

Episode Six

Remote Work. I wish I could see that it was my perfect planning that led to this episode being released exactly one year on from the start of lockdown. But really it was just a very fortunate coincidence. It did give this episode some extra resonance though. And I like that the final episode of the season has the widest range of contributors. It’s like the whole cast came back for the season finale.

I also wrote a bit about what I did behind the scenes for each episode of this season:

  1. Design Leadership
  2. Employee Experience Design
  3. Accessibility
  4. Prototyping
  5. Diversity and Inclusion
  6. Remote Work

My sincerest thanks to everyone who contributed to this season of the Clearleft podcast, especially everyone outside Clearleft who kindly agreed to be interviewed: Temi, Laura, Léonie, Adekunle, Rifa, and Elaine.

The Clearleft podcast will take a little break now and so will I. But I’m already thinking about topics for the next season. I feel like I’m starting to get a feel for what’s working so you can another six-episode season down the line.

To make sure you don’t miss the next season, I recommend subscribing to the RSS feed, or you can subscribe on Apple, Spotify, Google, and anywhere else that dispenses podcasts.

This was originally posted on my own site.

One year on and what next for remote working? Fri, 26 Mar 2021 17:51:00 +0000 A year ago this week the UK went into its first lockdown. Like most savvy businesses, Clearleft had already closed our studio and started working from home. Also like many businesses, we’ve yet to reopen our office.

I remember clearly the looks on people’s faces when I announced we’d be working remotely until the end of April. There was a combination of surprise, disbelief, resignation and even horror (perhaps due to the looming spectre of home-schooling). Just as everyone’s experience has been different over the past year, so everyone’s initial reaction was different too.

We didn’t have to make a huge cultural shift in order to work remotely. We’re a small enough company that we all know each other and what’s expected of us. We’d built up enough trust, and working from home was already allowed without question. That said, working from home was an occasional thing: to let in a plumber, deal with some childcare, and frequently - presciently perhaps - to get stuff done. And it was working from home - it wasn’t remote working, which as we’ve all come to realise is a different beast entirely.

We managed to adapt to the situation fairly quickly. A culture of autonomy and generally mucking-in helped, as did an assurance that everyone’s job would be safe for the coming months even if it meant us losing money in the short term (we didn’t). All this meant we could get on with the job of supporting our clients, who were certainly nowhere near close to working remotely when lockdown happened, and needed all the help they could get.

We knew we were doing something right in terms of remote working when one of our staff, who had been on sabbatical in South America when the pandemic struck, managed to make it back to Europe. While everyone else worked from home in or around Brighton, Tom found himself working from Spain initially, and then from London. And no-one really noticed, apart from a surprising change in decor. And that’s the point - you can remote work from anywhere provided you can negotiate timezones.

The UK is now in its third lockdown, but with a successful rollout of the vaccine, a way out and a change is approaching. Once lockdown is lifted, hopefully in a few months, will we become fully remote? I doubt it. Remote-first, whatever that means? Perhaps. We’ve certainly loosened our hiring policy - we no longer require people to permanently work from our Brighton studio. This enabled us to hire Christianne, our fantastic new head of events, who is currently based in London. That said Brighton is within commuting distance of London, so it’s certainly near enough to pop down every now and then, which will probably be beneficial.

For now our beloved 68 Middle Street stays closed, but we’ll be partially reopening in June as a broadcast studio for UX Fest and as an early test of Covid precautions and an assessment of everyone’s appetite for being in relatively close human proximity. Come July, by which time hopefully all Covid restrictions will be lifted, we’ll open more fully.

But how will we be working come July? We don’t exactly know, but that’s fine because we can try things and quickly adapt to changing needs. After all, we managed to go from studio-based to fully remote in a matter of days.

A few things seem certain. We’ve regularly talked and periodically surveyed staff about how they are coping with remote work, and their attitude to returning to the office. People’s circumstances and feelings all differ. These are difficult times - at some point we’ve all felt sad, lonely, claustrophobic or tired. But there have also been plenty of rays of light, with working from home being liberating, productive and flexible. What we do share is a common inclination to be in the same space as other people, at least for some of the time.

That may be a general reaction to being cooped up during so many weeks of lockdown after lockdown, but there’s a keen desire to talk and work face to face, if not permanently. We’ve all had the time and some budget to get set up for remote working, and we’ve come to appreciate the benefits it can bring. We definitely don’t want to lose those. But we’re all human, which means we’re sociable creatures at heart. Furthermore Clearlefties are - by design - a nice bunch of people. We’re the kind of people we want to spend time with, so it’s only natural we’d want to come into the office together.

All of which points us towards a hybrid way of working. Part remote, part in the studio, with all of us in one or other mode part of the time, but probably at different times and differing amounts. The key to getting this to work will be to ensure that neither mode of working advantages one person over another. We’ll need to ensure that while working remotely, someone isn’t excluded from decisions or collaboration, and minimise the fear of missing out on informal conversations. We’ll need to improve our setup to better enable remote people to participate in meetings where multiple attendees happen to be in the studio. Likewise we need to ensure that if you’re in the studio you can participate fully in remote discussions and activities - right now we have a large open plan studio that can get pretty noisy. And we’ll need to track and assess this so we can keep making improvements in working practice and environment.

Meanwhile our clients will be asking themselves similar questions. Perhaps some will go back fully into the office; some may go fully remote. But one great thing that has happened is they - and we - now have 12 months hard-earned experience of working remotely. As designers and consultants we won’t have to travel as much as we used to in order to research and collaborate, which is great for many reasons including productivity, work-life balance and the environment.

In light of the ongoing tragedy that is the coronavirus pandemic, it would be trite to trot out an aphorism such as ‘never let good crisis go to waste’. However with the vaccine presenting a light at the end of the tunnel, we have an opportunity to emerge in a better place than 12 months ago. If we get it right, we can take advantage of the collaborative and social spaces in our studio, as well as the peace and convenience of working from home (or indeed a villa in Spain). In doing so we’ll improve both our working practices and our home life - small victories in the grand scheme of things, but worth grabbing while we can.

Tiny Lesson: How to set up an inexpensive remote research session Tue, 02 Mar 2021 11:30:00 +0000 Making remote research accessible these days can be hard. There are off-the-shelf solutions but they come with a hefty price tag. Here’s how we’ve tried to make remote research more economical for our teams and clients.

Live streaming to the rescue

A usability lab is typically a space where teams come together to observe research sessions. In a remote context what can we do to bring these sessions to the team?

The good news is that almost all remote meeting software can be livestreamed using YouTube or other streaming-enabled services. We typically use Zoom and YouTube together because the initial setup is quick and generating the livestream link during a session is a couple of clicks.

Live streaming allows you to:

  • maintain a 1:1 ratio of participant to researcher avoiding the atmosphere becoming intimidating,
  • share the meeting in real time with every member of the project team,
  • discreetly manage additional questions via a separate channel e.g. Slack.

Top tip: Don’t forget to add live streaming to your informed consent form before the session.

Create a base for participation

As well as offering a means of watching a session, a usability lab would usually have a backroom for teams to collate observation notes and discuss what they learn. In a remote context what can we do to recreate this hub of learning?

We’ve recently been using Airtable bases as an all-in-one solution for capturing session observations. It has very powerful data-inking capabilities and is extremely customisable. Airtable also has a feature that enables you to make a simple web form from the structure of a database. We use the form view to match the main sections of our discussion guide. This allows all observers to contribute to a single repository of observations.

How we structure our Airtable base:

  • Participants: a list of anonymised participants including profile attributes.
  • Team: a list of team members and their contact details.
  • Study: a discussion guide split into main sections and some additional reflective questions.
An example of an Airtable base and the shared web form view.

Steal and adapt

Once you get a feel for this process and adapt it to suit your own way of working you’ll never look back. Why not have a try during your next study?

Design engineering and development at Clearleft Wed, 17 Feb 2021 09:00:00 +0000 There’s a growing gap between design and development, as the products we make, and the technologies we use to create them have become more complex.

JavaScript frameworks are the main culprit, with more and more business logic being moved from the back end to the front. Once covered by HTML, CSS and JS, the front end is now flooded with build chains, tooling, type-safe languages, integrations, state management and CSS modularisations. In a sentence: the front end is complicated.

Laying aside fundamental views on whether this is the right direction for the web or not, this degree of complexity isn’t an issue in an of itself. In the same way back-end systems tend to have layers of redundancy and more thorough testing processes, If the front end is now doing more work, it stands to reason that it also needs more ‘process’ to prevent it from falling over when things go wrong.

However, as the roles of the front-end developer have stretched into the realms of ‘engineering’, it has created a split:

  1. Front-of-the-front-end: UI focused
  2. Back-of-the-front-end (referred to as ‘Engineering’ from now): Integration focused

(Terms coined by Brad Frost)

Again, this isn’t a bad thing. It gives folks the choice to specialise in what they’re good at. It can, however, become a problem when:

  1. Either party are forced to build in each others domain specialism
  2. It is assumed that the front-of-the-frontend can be bypassed

The latter issue is the one I’m going to focus on. It’s becoming increasingly more common for organisations to jump straight from “design” to “engineering”, missing out the front-of-the-front-end altogether. After all, if the engineer codes, and the phase after design is code, so why not let the engineers build the UI?

Well, by jumping straight between the colossal gulf spanning the two functions, a huge wealth of design intention can disappear out of sight. The nuance of a design is built from layers of knowledge passed from Research to UX to Content to Design. The tiny details and systemised thinking that go into design all add up to a make great interface, and scalable front-end codebase.

The language that converts from a ‘picture of a design’ to a website is CSS. CSS is seen as such a contentious language because it’s where design and engineering meet.

There needs to be a way to bridge the gap…

Design engineering

This is a quote taken from the excellent design engineering handbook, published by Invision:

Design engineering is the name for the discipline that finesses the overlap between design and engineering to speed delivery and idea validation. From prototyping to production-ready code, this function fast-tracks design decisions, mitigates risk, and establishes UI code quality. The design engineer’s work encapsulates the systems, workflows, and technology that empower designers and engineers to collaborate most effectively to optimise product development and innovation. Natalya Shelburne

In a team where there is friction between design and engineering, or even design, front-of-the-frontend, and back-of-the-front-end, a design engineer’s job is to smooth the translation process between the disciplines.

A design engineer may be involved in:

  • Idea validation
  • Rapid prototyping
  • Production code
  • Ensuring UI code quality
  • Creating useful tools
  • Encapsulating systems
  • Setting up project groundwork
  • Empowering effective collaboration

In essence, a design engineer’s primary aim is to be helpful. Helping UX come to sound decisions, helping research get the most useful insights from their testing, helping designers generate sound & deliverable ideas, and helping engineers understand the design intention. But the primary focus is on doing anything they can to help translate the design for the engineering team.

We talk of ‘creators’ and ‘maintainers’: those who do the work, and those who keep it running well. But I think it’s a spectrum. Design engineers sit firmly in the most ‘creationy’ part of the creator camp, building rapidly, failing early and clearing a way through the bad ideas so the other creators can follow smoothly.

What does this mean at Clearleft?

As an agency, every project we undertake is different, so we know this function as a formal role may not be appropriate for all projects. However, the mindset of translating effectively between ‘who designs it’ to ‘who builds it’ is.

Although we’ve been practicing this way of working for a while; building with prototypes, collaboratively creating out design foundations, and helping clients build design systems, we’ve not formally dubbed it ‘Design Engineering’ till now.

We’re going to continue to utilise this role on future projects, monitoring to see how it improves the overall design process.

This post was originally published on Trys’s website - you can find his next post on Design Engineering foundations here and all the articles from Trys’s incredible series here.

Authentication Mon, 08 Feb 2021 09:00:00 +0000 Two-factor authentication is generally considered A Good Thing™️ when you’re logging in to some online service.

The word “factor” here basically means “kind” so you’re doing two kinds of authentication. Typical factors are:

  • Something you know (like a password),
  • Something you have (like a phone or a USB key),
  • Something you are (biometric Black Mirror shit).

Asking for a password and an email address isn’t two-factor authentication. They’re two pieces of identification, but they’re the same kind (something you know). Same goes for supplying your fingerprint and your face: two pieces of information, but of the same kind (something you are).

None of these kinds of authentication are foolproof. All of them can change. All of them can be spoofed. But when you combine factors, it gets a lot harder for an attacker to breach both kinds of authentication.

The most common kind of authentication on the web is password-based (something you know). When a second factor is added, it’s often connected to your phone (something you have).

Every security bod I’ve talked to recommends using an authenticator app for this if that option is available. Otherwise there’s SMS—short message service, or text message to most folks—but SMS has a weakness. Because it’s tied to a phone number, technically you’re only proving that you have access to a SIM (subscriber identity module), not a specific phone. In the US in particular, it’s all too easy for an attacker to use social engineering to get a number transferred to a different SIM card.

Still, authenticating with SMS is an option as a second factor of authentication. When you first sign up to a service, as well as providing the first-factor details (a password and a username or email address), you also verify your phone number. Then when you subsequently attempt to log in, you input your password and on the next screen you’re told to input a string that’s been sent by text message to your phone number (I say “string” but it’s usually a string of numbers).

There’s an inevitable friction for the user here. But then, there’s a fundamental tension between security and user experience.

In the world of security, vigilance is the watchword. Users need to be aware of their surroundings. Is this web page being served from the right domain? Is this email coming from the right address? Friction is an ally.

But in the world of user experience, the opposite is true. “Don’t make me think” is the rallying cry. Friction is an enemy.

With SMS authentication, the user has to manually copy the numbers from the text message (received in a messaging app) into a form on a website (in a different app—a web browser). But if the messaging app and the browser are on the same device, it’s possible to improve the user experience without sacrificing security.

If you’re building a form that accepts a passcode sent via SMS, you can use the autocomplete attribute with a value of “one-time-code”. For a six-digit passcode, your input element might look something like this:

<input type="text" maxlength="6" inputmode="numeric" autocomplete="one-time-code">

With one small addition to one HTML element, you’ve saved users some tedious drudgery.

There’s one more thing you can do to improve security, but it’s not something you add to the HTML. It’s something you add to the text message itself.

Let’s say your website is and the text message you send reads:

Your one-time passcode is 123456.

Add this to the end of the text message: #123456

So the full message reads:

Your one-time passcode is 123456. #123456

The first line is for humans. The second line is for machines. Using the @ symbol, you’re telling the device to only pre-fill the passcode for URLs on the domain Using the # symbol, you’re telling the device the value of the passcode. Combine this with autocomplete="one-time-code" in your form and the user shouldn’t have to lift a finger.

I’m fascinated by these kind of emergent conventions in text messages. Remember that the @ symbol and # symbol in Twitter messages weren’t ideas from Twitter—they were conventions that users started and the service then adopted.

It’s a bit different with the one-time code convention as there is a specification brewing from representatives of both Google and Apple.

Tess is leading from the Apple side and she’s got another iron in the fire to make security and user experience play nicely together using the convention of the /.well-known directory on web servers.

You can add a URL for /.well-known/change-password which redirects to the form a user would use to update their password. Browsers and password managers can then use this information if they need to prompt a user to update their password after a breach. I’ve added this to The Session.

Oh, and on that page where users can update their password, the autocomplete attribute is your friend again:

<input type="password" autocomplete="new-password">

If you want them to enter their current password first, use this:

<input type="password" autocomplete="current-password">

All of the things I’ve mentioned—the autocomplete attribute, origin-bound one-time codes in text messages, and a well-known URL for changing passwords—have good browser support. But even if they were only supported in one browser, they’d still be worth adding. These additions do absolutely no harm to browsers that don’t yet support them. That’s progressive enhancement.

This was originally posted on my own site.

Getting to know you. Getting to know all about you. Mon, 25 Jan 2021 14:25:00 +0000 Starting a project with a new client is both exciting and daunting, especially in a sector you haven’t much experience of. I’d like to share my client immersion checklist.

One of the joys of working in an agency and across many sectors is the exposure you get to organisations and industries that sit outside of your current experience. This also creates a challenge. How do you gain a deep understanding of a new domain and at speed?

At the start of a project I like to throw myself into the client’s world. I like to dig around and see what I uncover that I find interesting and surprising. The treasure trove of information I amass provides lines of questions to pursue and sparks of ideas to explore. The client immersion checklist is what I use at the outset of a project to help make the unfamiliar more familiar.

Regardless of how much information you consume, it’s always good to remind yourself you’re still the newbie on the scene. The purpose of a deep dive is to have more insightful conversations with your new client, their colleagues and the organisation’s customers.

Visual of the checklist on a blue background
Screenshot of the shared client immersion checklist

Over the years I’ve collected and curated a checklist of information to gather. It’s a mix of places to look and information to ask for. All of which helps to accelerate my understanding of the organisation and how digital and design fit into delivering its strategy.

I use the client immersion checklist as a prompt for what to look for. I can’t think of a project where I’ve ticked everything off the list. It’s a guide to focus your limited time on uncovering and discovering a wide range of stimuli.

What do you look for?

In sharing my approach. I’m interested in yours. What are your go-to sources of information ahead of the project kick-off and discovery period?

If you use the checklist do let me know how you get on and what improvements you’d suggest. You’ll find contact details in the checklist.

The client immersion checklist is free to use and regularly updated.

Letters of exclusion Mon, 25 Jan 2021 11:44:00 +0000 I think my co-workers are getting annoyed with me. Any time they use an acronym or initialism—either in a video call or Slack—I ask them what it stands for. I’m sure they think I’m being contrarian.

The truth is that most of the time I genuinely don’t know what the letters stand for. And I’ve got to that age where I don’t feel any inhibition about asking “stupid” questions.

But it’s also true that I really, really dislike acronyms, initialisms, and other kinds of jargon. They’re manifestations of gatekeeping. They demarcate in-groups from outsiders.

Of course if you’re in a conversation with an in-group that has the same background and context as you, then sure, you can use acronyms and initialisms with the confidence that there’s a shared understanding. But how often can you be that sure? The more likely situation—and this scales exponentially with group size—is that people have differing levels of inside knowledge and experience.

I feel sorry for anyone trying to get into the field of web performance. Not only are there complex browser behaviours to understand, there’s also a veritable alphabet soup of initialisms to memorise. Here’s a really good post on web performance by Harry, but notice how the initialisms multiply like tribbles as the post progresses until we’re talking about using CWV metrics like LCP, FID, and CLS—alongside TTFB and SI—to look at PLPs, PDPs, and SRPs. And fair play to Harry; he expands each initialism the first time he introduces it.

But are we really saving any time by saying FID instead of first input delay? I suspect that the only reason why the word “cumulative” precedes “layout shift” is just to make it into the three-letter initialism CLS.

Still, I get why initialisms run rampant in technical discussions. You can be sure that most discussions of particle physics would be incomprehensible to outsiders, not necessarily because of the concepts, but because of the terminology.

Again, if you’re certain that you’re speaking to peers, that’s fine. But if you’re trying to communicate even a little more widely, then initialisms and abbreviations are obstacles to overcome. And once you’re in the habit of using the short forms, it gets harder and harder to apply context-shifting in your language. So the safest habit to form is to generally avoid using acronyms and initialisms.

Unnecessary initialisms are exclusionary.

Think about on-boarding someone new to your organisation. They’ve already got a lot to wrap their heads around without making them figure out what a TAM is. That’s a real example from Clearleft. We have a regular Thursday afternoon meeting. I call it the Thursday afternoon meeting. Other people …don’t.

I’m trying—as gently as possible—to ensure we’re not being exclusionary in our language. My co-workers indulge me, even it’s just to shut me up.

But here’s the thing. I remember many years back when a job ad went out on the Clearleft website that included the phrase “culture fit”. I winced and explained why I thought that was a really bad phrase to use—one that is used as code for “more people like us”. At the time my concerns were met with eye-rolls and chuckles. Now, as knowledge about diversity and inclusion has become more widespread, everyone understands that using like a phrase like “culture fit” can be exclusionary.

But when I ask people to expand their acronyms and initialisms today, I get the same kind of chuckles. My aversion to abbreviations is an eccentric foible to be tolerated.

But this isn’t about me.

This was originally published on my own site.

A farewell to Andy Wed, 20 Jan 2021 16:19:00 +0000 It’s been an eventful time for Clearleft. As well celebrating our fifteenth anniversary, 2020 was the year that saw Clearleft become an employee-owned agency. It’s a year of change, and now we’ve got one more to share with you.

Clearleft co-founder Andy Budd is stepping down from his day-to-day role as Chairman at Clearleft. Andy will remain a shareholder and a non-exec board member. The current board remains in place, along with fellow co-founders Richard Rutter and Jeremy Keith.

Andy founded Clearleft with Rich and Jeremy in 2005. His drive and vision helped build and shape Clearleft into the world-renowned design agency it has become. Andy’s influence has enabled us to help hundreds of clients across five continents, including household names we never thought possible back in 2005: Virgin Atlantic, Burberry, Natural History Museum, JP Morgan, World Wildlife Fund (WWF), Channel 4, not to mention many local governments and eight different universities.

Andy brought his entrepreneurial spirit to the creation of ground-breaking events, including the first d.Construct conference only three months after Clearleft started up. Three years later he would have the vision and ambition to launch UX London as one of the world’s foremost design conferences, not just once but year after year since. As a serial entrepreneur, Andy was the brains behind Silverback, the usability testing tool, which counted Nasa and the Obama campaigns as its customers.

Right from those initial months Andy imbued Clearleft with a philosophy of improving the practice of design. We’ve since helped over 15,000 designers, including leaders from across the globe through our Leading Design series, which Andy brought to life in 2016.

Over the past two years Andy has been instrumental in establishing a new leadership team, who earlier this year oversaw the sale of Clearleft to its employees thus securing both the company’s future and the values Andy and his co-founders established over the past 15 years. With management having successfully navigated the worst of the Covid crisis, now was an opportune moment for Andy to seek out his next entrepreneurial calling.

The leadership team Andy leaves in place is formed from a highly experienced group of practitioners who know Clearleft inside out. Richard Rutter, as a co-founder, heads the team since taking on the mantle of managing director two years ago. Jessica Jebari, Jon Aizlewood and Andy Thornton were brought onto the board early in 2020 as operations director, design director and strategy director respectively. Between them, they have decades of experience in the industry, including a combined 20 years at Clearleft. The team brings a people-centred approach to management emphasising the company’s values of autonomy and collaboration; a strongly human-centred philosophy of design; and commitment to delivering a world-leading experience for our clients and customers.

Andy will still be an integral part and host of Leading Design Festival this March. Before his departure, he has worked hard to ensure he leaves an events team ready to take the events he’s built to the next level. The expanded team includes Christianne Beck as Head of Events and Rebecca Groves as Programme Manager who will be championing not only the Leading Design conference but turning it into a programme of events to support the design leadership community even further.

Speaking of their co-founder, Richard said “During his tenure at Clearleft, Andy was instrumental in forming and maintaining Clearleft’s world-renowned reputation, followed by the continual development of our portfolio of international events aimed at all levels of the design industry. Andy has helped forge a great path that we will continue to develop and grow. I want to thank Andy for his dedication and drive, and wish him all the best for his future.”

Jeremy remarked “It feels like the end of the first chapter of Clearleft’s story. I can’t wait to see what the future holds for Clearleft and for Andy—I just know that he’ll continue to spread the spirit of Clearleft in all his future endeavours. It’s been an honour and a pleasure working with Andy for fifteen years.”

Tiny Lesson: A simple technique for defining boundaries Wed, 20 Jan 2021 13:45:09 +0000 Over my 15 years of being involved with the early stages of the design process, there is one technique that I use time and time again.

It’s a technique that hones in on the characteristics of a concept by not only defining the things it is but also the things that it isn’t on the same continuum. I often don’t run this as an explicit workshop exercise but simply let the characteristics fall out by facilitating a discussion around purpose.

The end result is often a very simple table which contains a series of sets of characteristics, with each set being on the same continuum.

Top tips:

  • Ensure these characteristics focus on the unique things about the service and the things that really differentiate it.
  • Keep it to a short list in order to keep it more memorable.
  • Include a rationale to explain the reason behind each statement, as this helps to capture the conversation that led to this definition.
A chart showing it is and it isn't statements for a travel client

More recently I used this technique to define scope by defining the things that we are doing but also the things that are not doing.

A chart showing we are and we are not statements for a finance client

It’s incredibly simple but in my experience capturing the isn’t terms is so powerful in really reinforcing the things that it is. So give it a try!

How to test a Content Management System that doesn’t exist yet Mon, 18 Jan 2021 14:06:14 +0000 When we were designing the prospectus of a world-leading university, we created designs that satisfied our users’ requirements. But what about the content creators?

As part of our redesign we asked ourselves what we thought were key questions around these users:

  • Who is managing the content that populates the design?
  • Is the content easy to produce?
  • Is the content easy to source and to edit?

We knew their editing process. Coincidentally, an upcoming redesign of their tools and workflow gave us an opportunity to identify user needs and requirements for the new system, and do so with a user-centered approach. Our goal was to ensure our design could be populated, and also that their new optimised pipeline could help them provide a better service to their users.

We started a 3-week content design sprint. The university writers and editors would create the content for the design. We wanted them to do this in a realistic way. This would involve some kind of Content Management System (CMS). The challenge was clear: how do you test a Content Management System that doesn’t exist yet?

Building a CMS, database and front-end integration in three weeks wasn’t realistic. We turned to other options.

Finding the right prototyping tool

Most UI design tools nowadays have very clever plugins that allow designers to show designs without using dummy content. Imagine a product gallery with the same product card repeated over and over. Syncing plugins allow you to drag and drop Excel or TXT files into your UI and, like magic, replace your grey boxes with actual content.

Sounds good? Not really.

The design we were testing was not just a gallery of repeated cards. Most components were completely different. It would have been quite the task to create dozens of sheets and link them all. Even worse, a bunch of spreadsheets doesn’t look even vaguely similar to a CMS.

Our current design software at Clearleft is Figma. Amongst the many plugins available, we found the Google Sheets Sync plugin that could populate any component from a single spreadsheet. We had found half of our solution. We still had to find a quick and easy way of prototyping a CMS.

Prorotyping tool spectrum: finding the balance between high- and low-fidelity
Prorotyping tool spectrum: finding the balance between high- and low-fidelity.

The solution was hiding in plain sight: Google Forms. What is a CMS if not a big form? Google Forms was ideal. It’s familiar. It’s free. It can be synced with GSheet (which can then feed into Figma through the plugin). An additional benefit was that we could gather insights on the CMS requirements without polluting the research data with feedback on the temporary CMS we were using.

So how does it work?

We looked at our design and listed all the different types of content (mandatory, optional, pre-filled).

We then translated those into fields for Google Forms.

We exported a link for the form and filled it with initial content (remember to make the responses editable so that at each pass the content creator would find the content written the previous session). By linking the form response to a Google Sheet (this can be done in Form’s Responses panel by clicking on the Sheet icon), the submitted form will populate a spreadsheet.

The form questions become the table column label. This label is what you use to connect your design with your Sheet. In Figma, rename every component you want to sync with “# + question/column label”. This is probably the most time-consuming part. But take your time as it’s easy to make typos or mistakes and break the syncing.

Then the fun part: run your plugin in Figma and you’ll see your design populated with the content from Google Form.

Thanks to Figma’s Auto Layout feature, every design element is pushed down accordingly to the length of the new content. This maintains consistent spacing and avoids overlap between items in your design.

The plugin at work: with just one click the plugin will replace all Figma elements marked with the # notation (in this case, both desktop and mobile elements were linked to the same spreadsheet column, and update simultaneously).

And a fake CMS (or, as we call it, duct-tape CMS) is born.

This works in real-time with the Figma design preview, which makes it even more realistic to the content creator. If our content creators had Figma preview open, they would see the design updating, creating the illusion of a real CMS.

Other delighters

Not only text sync but images too:

The plugin works not only with text but also with images (pulled from a URL provided in the form). In addition to respecting the placeholder crop and aspect ratio, the new image also inherits any style and effect applied to the placeholder.

Make your CMS look even more real by adding a timestamp

Every form submission will record a timestamp in the spreadsheet. This can be used to populate the timestamp in our design and adding yet another detail to sell the illusion of a working CMS.

The not so good:

This solution ticks a lot of boxes, but it’s an unorthodox way of using various tool together, and being a hacked solution, there are some issues and limitations.

  1. Set up takes time, and there are many elements to orchestrate;
  2. It’s a very manual process - you need to sync the design each time a response is submitted, and if you want version control you need to save every response in a separate document;
  3. It’s a prototype: it could (and it will) break. Always be on your toes for when that will happen.

However, with a bit of setup and oversight, this method can be a robust and incredibly useful way of using up-to-date, real content for your design.

Why do it?

It can be easy to focus all attention and efforts into designing the best possible front-facing product, but their success is heavily influenced by what’s going on behind the scenes. This sprint, and this prototype, gave us an opportunity to research, test and evaluate our design from the stakeholders’ point of view and ensure our new design would fit into their processes and workflows. As Katie Wishdale said in her recent blog post:


This tool allowed us to not only work with real content but also test our understanding of the content creation process, and shed light on underlying issues and opportunities. In turn, the results have been used to create a handbook that will allow the client to autonomously repeat -and improve- the process itself.

Whether you want to do the same, or simply experiment with a shared tool for your design and content team, the fake CMS can become a useful and lightweight tool to improve the services and designs you’re working on.

Saying what we do, and doing what we say Tue, 15 Dec 2020 10:24:00 +0000 The past nine months have been a blur, haven’t they? Following Brexit and the political turmoil of a general election here in the UK, we thought things would start looking up. Haha! COVID-19 hit and the world seemed to stop.

Like many companies we parked almost everything to react to the coronavirus situation. We put measures in place to weather the storm financially. We maintained our high level of client services (albeit remotely). We adapted to the world of virtual events by putting on Sofa Conf.

On the precipice of another wave (or another lockdown), the only certainty is uncertainty. Instead of fixating on how difficult things are now, we’ve adapted and dusted ourselves off. We’ve revisited many of those things we parked before coronavirus struck because, as the old adage goes, the show must go on.

A strong pedigree

Being around for 1.5 decades as a digital agency is no small feat. We recently celebrated our 15th birthday twice, like the queen. First internally, as a remote team during summer lockdown. Then externally, in September, with our future postcards and timeline. Rich eloquently sums up the landmark in his recent post.

To herald that 15 year milestone, we took the brave step of moving to an Employee Ownership Trust (EOT). Andy and Rich started the ball rolling back in 2019, and announced the decision to the Clearleft team just before lockdown.

Moving to an EOT is fitting for an agency like Clearleft. We’ve always been big on autonomy and flat structures. We’ve always prided ourselves as trailblazers. It felt only natural to give more ownership back to the staff. Andy does a much better job describing the EOT and what it means for Clearleft in his post.

Yet before the EOT, before coronavirus and in the lead-up to our birthday, we started to ask ourselves something. Are the things we say we do in fact the things we do? As a world-renowned UX & Design studio we’ve always had a reputation, but for what exactly?

After some soul-searching before, during and after coronavirus we’ve come to some conclusions that we hope better articulate what we do, and why.

Growing up

For the past 15 years Clearleft has been at the forefront of all things digital design. We were in the trenches during the web standards movement. We helped organisations better understand UX and how it can transform their businesses for the better. We led the charge on modular, systematic design. Recently we’ve fostered a growing design leadership community through our events, retreats and meet-ups. At Clearleft we’ve always put a lot of effort into sharing back with our community. We run world-renowned events to bring speakers from other countries and skill sets together, to share their knowledge and their expertise.

For the most part, our purpose and vision have remained the same over the last several years. In my opinion that’s a great thing. Sticking to our purpose means we haven’t wavered from our larger goals, and we’re still (cue the cliche klaxon) following our North Star:

We believe in advancing the practice of design to transform organisations and impact people’s lives for the better.

We really do believe deeply in design. Past, present and future Clearlefties know that design can have incredible effects on people’s lives. Working with purposeful brands on meaningful projects is what gets us up in the morning. Similarly our vision has stayed the course:

We want to be the most influential and respected independent boutique design consultancy in the UK.

Our heritage, pedigree and experience blend into something unique. We’re known for being highly collaborative which, in its own right, is nothing exceptional. But when paired with our ability to ask tough questions and challenge the status quo, we bring a bold curiosity to our clients and their thorny problems. When partnering with clients we always strive to make them champions. We make them the heroes, not us. As committed allies we form long-term partnerships and friendships with our clients to create change.

A slide summarising Clearleft's purpose

We realised that though our core mission and vision hasn’t changed, our core proposition has changed. In some quarters Clearleft are still seen as a web development agency or a website design studio. Neither of these things are bad; they just don’t reflect what we actually do today.

As teenagers tend to face identity crises, so have we. In truth we’re far more grown up than we realised. The services we’ve been providing our clients have gone far beyond websites for some time. Though we might have been hired to redesign a website years ago, the effects we had on our client’s organisations were long-lasting. We were agents for creating change, helping our clients maintain momentum. Over the last several years we’ve been doing that and so much more. So we asked ourselves what a grown-up Clearleft looks like. What had to be done to make that change known?

Closing the gap between strategy and delivery

Time and again our clients have procured the services of large consultancies to help them devise ‘a strategy’. Lots of stuff happens in those engagements. Hand waving, talking, promising and dreaming. But nothing material gets created, except a fancy slide deck of ideas.

Over time that deck collects virtual dust. Nothing gets done because the client wasn’t given any support to make their new vision a reality. Instead, they’re left to their own devices. Other priorities and initiatives crop up and compete for their attention. Before long that slide deck is a very expensive artefact. This is the strategy-delivery gap.

A slide summarising Clearleft's ability to close the gap between strategy and delivery

The above scenario isn’t a one-off. It’s a pattern we’ve recognised many times. As an agency we’ve always been purveyors of our craft: from web standards and development to great UX & design. But we’ve always provided strategic design thinking to help our clients think differently. By closing the gap we combine strategic and creative design thinking with great skill and execution. We help make our clients’ visions a reality by working with them to act—not talk—with user-centred design practices and quality techniques.

Connecting with the best in the industry

Ever since the first dConstruct back in 2005, we’ve lived one of our core values: to learn and share knowledge with all. From those humble dConstruct beginnings we’ve built a portfolio of world-renowned events, from UX London and Ampersand to Leading Design. Though coronavirus created an obstacle for all in-person events, we’re still providing fantastic opportunities for learning and sharing knowledge. In June we launched Sofaconf, our first fully-online conference. In March 2021 we’ll be putting our fantastic Leading Design brand online with the new LDFest, followed closely by UXFest, a month-long version of UXLondon.

A slide summarising Clearleft's ability to connect clients with the best in the industry

We have a unique connection with the industry’s leading provocateurs, thought leaders and respected experts. We curate and create conferences that help people improve their skills, their careers and the industry as a whole. Using those same connections, we provide our clients with access to respected industry experts who would otherwise be out of reach. Whether it’s specialists in agile and product development that’s needed, or leaders in training and learning, we can form ‘super teams’ to provide specialist services for our clients that help them achieve their vision.

Meeting in the middle (of the double diamond)

For those already familiar with the double diamond approach to design, Clearleft has historically been spread across the second diamond: helping to design the thing right by delivering or making something.

As we have evolved we focus more on the middle of the two diamonds, with a strong emphasis on strategy and design. That mid-diamond pinch point is precisely where we work best with our clients. We help explore turning insights into ideas, and turn those ideas into a reality by exploring and shaping potential solutions. We thrive in that messy middle area, where things aren’t often clear, nor are they foregone conclusions. We ask tough questions to feed our appetite for thorny problems and work with our clients to help solve them.

A diagram of the double diamond, with Clearleft in the middle of the two

To make our new approach a reality, we’ve also made some changes internally. Alongside the new EOT structure (that installs both a trust and board), myself and Andy Thornton have taken on new roles to help our clients bring their ideas and insights to life.

Strategy services

As Strategy Director, Andy will identify and explore new opportunities with our clients. Digital transformation has been rapidly accelerated by coronavirus, so now more than ever companies are recognising that design can offer a genuine competitive advantage. Andy will explore how we can help our clients advance the practice of design by changing behaviours, workflows, approaches and culture.

Design services

As Design Director I’ll help our clients bring world-class products and services to market, or improve existing experiences by advocating and demonstrating the power of a human-centred, design-led approach. From digital-first branding and rapid prototyping to systematic and modular design and user experience, we’ll always imprint a Clearleft way of working with the product teams we partner with.

Across both services we’ll continue to provide training and coaching for product and design teams and executives, to grow their capabilities and ensure design is better represented in their organisations.

Stay tuned

We’re all still experiencing the effects that coronavirus, Brexit and more are having on us and our clients. Adaptability is the name of the game. We’re here to help like-minded and purposeful brands thrive in these strange times. So if you want to have a (virtual) coffee and a chat, get in touch.

Lists Mon, 14 Dec 2020 14:47:00 +0000 We often have brown bag lunchtime presentations at Clearleft.

In the Before Times, this would involve a trip to Pret or Itsu to get a lunch order in, which we would then proceed to eat in front of whoever was giving the presentation. Often it’s someone from Clearleft demoing something or playing back a project, but whenever possible we’d rope in other people to swing by and share what they’re up to.

We’ve continued this tradition since making the switch to working remotely. Now the brown bag presentations happen over Zoom. This has two advantages. Firstly, ifyou don’t want the presenter watching you eat your lunch, you can switch your camera off. Secondly, because the presenter doesn’t have to be in Brighton, there’s no geographical limit on who could present.

Our most recent brown bag was truly excellent. I asked Léonie if she’d be up for it, and she very kindly agreed. As well as giving us a whirlwind tour of how assistive technology works on the web, she then invited us to observe her interacting with websites using a screen reader.

I’ve seen Léonie do this before and it’s always struck me as a very open and vulnerable thing to do. Think about it: the audience has more information than the presenter. We can see the website at the same time as we’re listening to Léonie and her screen reader.

We got to nominate which websites to visit. One of them—a client’s current site that we haven’t yet redesigned—was a textbook example of how important form controls are. There was a form where almost everything was hunky-dory: form fields, labels, it was all fine. But one of the inputs was a combo box. Instead of using a native select with a datalist, this was made with JavaScript. Because it was lacking the requisite ARIA additions to make it accessible, it was pretty much unusable to Léonie.

And that’s why you use the right HTML element wherever possible, kids!

The other site Léonie visited was Clearleft’s own. That was all fine. Léonie demonstrated how she’d form a mental model of a page by getting the screen reader to read out the headings. Interestingly, the nesting of headings on the Clearleft site is technically wrong—there’s a jump from an h1 to an h3—probably a result of the component-driven architecture where you don’t quite know where in the page a heading will appear. But this didn’t seem to be an issue. The fact that headings are being used at all was the more important fact. As Léonie said, there’s a lot of incorrect HTML out there so it’s no wonder that screen readers aren’t necessarily sticklers for nesting.

I’ve said it before and I’ll say it again: if you’re using headings, labelling form fields, and providing alternative text for images, you’re already doing a better job than most websites.

Headings weren’t the only way that Léonie got a feel for the page architecture. Landmark roles—like header and nav—really helped too. Inside the nav element, she also heard how many items there were. That’s because the navigation was marked up as a list: “List: six items.”

And that reminded me of the Webkit issue. On Webkit browsers like Safari, the list on the Clearleft site would not be announced as a list. That’s because the lists’s bullets have been removed using CSS.

Now this isn’t the only time that screen readers pay attention to styling. If you use display: none to hide an element from sight, it will also be unavailable to screen reader users. Makes sense. But removing the semantic meaning of lists based on CSS? That seems a bit much.

There are good reasons for it though. Here’s a thread from James Craig on where this decision came from (James, by the way, is an absolute unsung hero of accessibility). It turns out that developers went overboard with lists a while back and that’s why we can’t have nice things. In over-compensating from divitis, developers ended up creating listitis, marking up anything vaguely list-like as an unordered list with styling adjusted. That was very annoying for screen reader users trying to figure out what was actually a list.

And James also asks:

If a sighted user doesn’t need to know it’s a list, why would a screen reader user need to know or want to know? Stated another way, if the visible list markers (bullets, image markers, etc.) are deemed by the designers to be visually burdensome or redundant for sighted users, why burden screen reader users with those semantics?

That’s a fair point, but the thing is …bullets maketh not the list. There are many ways of styling something that is genuinely a list that doesn’t involve bullets or image markers. White space, borders, keylines—these can all indicate visually that something is a list of items.

If you look at, say, the tunes page on The Session, you can see that there are numerous lists—newest tunes, latest comments, etc. In this case, as a sighted visitor, you would be at an advantage over a screen reader user in that you can, at a glance, see that there’s a list of five items here, a list of ten items there.

So I’m not disagreeing with the thinking behind the Webkit decision, but I do think the heuristics probably aren’t going to be quite good enough to make the call on whether something is truly a list or not.

Still, while I used to be kind of upset about the Webkit behaviour, I’ve become more equanimous about it over time. There are two reasons for this.

Firstly, there’s something that Eric said:

We have come so far to agree that websites don’t need to look the same in every browser mostly due to bugs in their rendering engines or preferences of the user.

I think the same is true for screen readers and other assistive technology: Websites don’t need to sound the same in every screen reader.

That’s a really good point. If we agree that “pixel perfection” isn’t attainable—or desirable—in a fluid, user-centred medium like the web, why demand the aural equivalent?

The second reason why I’m not storming the barricades about this is something that James said:

Of course, heuristics are imperfect, so authors have the ability to explicitly override the heuristically determined role by adding role="list”.

That means more work for me as a developer, and that’s …absolutely fine. If I can take something that might be a problem for a user, and turn into something that’s a problem for me, I’ll choose to make it my problem every time.

I don’t have to petition Webkit to change their stance or update their heuristics. If I feel strongly that a list styled without bullets should still be announced as a list, I can specificy that in the markup.

It does feel very redundant to write ul role="list”. The whole point of having HTML elements with built-in semantics is that you don’t need to add any ARIA roles. But we did it for a while when new structural elements were introduced in HTML5—main role="main", nav role="navigation", etc. So I’m okay with a little bit of redundancy. I think the important thing is that you really stop and think about whether something should be announced as a list or not, regardless of styling. There isn’t a one-size-fits-all answer (hence why it’s nigh-on impossible to get the heuristics right). Each list needs to be marked up on a case-by-case basis.

And I wouldn’t advise spending too much time thinking about this either. There are other, more important areas to consider. Like I said, headings, forms, and images really matter. I’d prioritise those elements above thinking about lists. And it’s worth pointing out that Webkit doesn’t remove all semantic meaning from styled lists—it updates the role value from list to group. That seems sensible to me.

In the case of that page on The Session, I don’t think I’m guilty of listitis. Yes, there are seven lists on that page (two for navigation, five for content) but I’m reasonably confident that they all look like lists even without bullets or markers. So I’ve added role="list" to some ul elements.

As with so many things related to accessibility—and the web in general—this is a situation where the only answer I can confidentally come up with is …it depends.

This was originally published on my own site.

Innovation: a design discussion Thu, 10 Dec 2020 10:04:00 +0000 At Clearleft, we have regular design debates where we gather together to discuss a design-related topic. One of those discussions was quite contentious…

It all started with a hot take on Medium from Mark Wilson of Wilson Fletcher, where Katie used to work: Customer-led design won’t lead you somewhere new.

Katie didn’t entirely agree with that article, even if parts of it rang true. Her take is that there are different types of design. Some are more customer-led and some are more business-led. So it’s true that customer-led design isn’t the right fit for everything. As always, it depends.

Jon didn’t read the article—he smacked head-first into Medium’s reader-hostile paywall—but he assumed that the keyword would be innovation. And sure enough, if you’re being led by what your customers want, it’s unlikely to lead to something new or innovative.

Chris disagreed. He thinks you can innovate “around” customers. You’re not there to blindly follow what they suggest. You’re there to listen, dig deeper, synthesise. That may very well led to something new.

Andy pointed out that what Chris said chimed with what’s in the article:

It’s not the customer’s job to invent what they’ll want instead of what they have today, it’s ours — the people responsible for making big leaps happen.

Although that sentence is preceded by this bit of clickbait:

Customer-led design sterilises the innovation process.

Jeremy made the connection with the cliché about Henry Ford: “If I asked people what they wanted, they would’ve said faster horses.” Though Jeremy pointed out that a genetically engineered superfast horse would’ve been awesome! His point is that innovation isn’t necessarily always appropriate. If anything, we have a bias towards trying to be innovative, sometimes at the expense of a tried-and-tested boring solution that works. There’s nothing innovative about writing clear copy, yet often that’s a far more effective solution than a brand new interface paradigm.

Lorenzo went deeper and asked “what is innovation?” He talked about the difference between design and fashion. Design is structural. Fashion is cosmetic. Fashion should be innovative. But design should be appropriate.

Chris said that a crude definition of innovation could simply be anything you haven’t done before. He also admitted that the article made him kind of angry because it perpetuated the myth of the genius designer—no room for co-creation with customers.

Katie pointed out that if the article made Chris angry, then that’s mission accomplished. She also agreed that people tend to over-use innovation. But she pointed out that innovation is different to Research and Development. With R&D, you’re playing with a technology, trying to unlock its potential. It’s more technology-led than customer-led.

Rich agreed, pointing out that the R in R&D is crucial: research. Research is also critical to human-centred design.

That’s exactly what Katie was talking about when she spoke about different types of design. If you’re experienced, then you know that the type of research you do is highly dependent on the type of design problem that you’re solving. Pick the right tools for the job. Some of those tools are more customer-focused than others like, say, A/B testing. If you pick a customer-focused tool for every kind of problem, then it’s true that you’ll never get real innovation.

Jeremy agreed, mentioning the infamous case of Google’s 41 shades of blue. They used a data-driven customer-led hammer on everything.

Going back to the original article, Rich thought that there may have been a bit of a misunderstanding in it about what human-centred design is. Human-centered (or customer-led) design isn’t about finding out what your customers want and then giving them exactly that.

Katie thought it’s not so much a misunderstanding, as it is a matter of audience. That article isn’t aimed at an experienced design agency like Clearleft. It’s aimed at designers who think they’re doing customer-led design but are really doing little more than market research, optimising for a local maximum.

Jon made that point that while Wilson Fletcher might be guilty of fetishising innovation, Clearleft are probably guilty of fetishising human-centred design.

Everyone agreed that it’s not an “either/or” situation. If you know what you’re doing, then innovation and human-centred design happen in harmony.

Being a Player Coach: Is it the best or the worst of both worlds? Mon, 30 Nov 2020 16:22:58 +0000 At some stage in your design career, you may find yourself at a bit of a crossroads. One path is the path of the craftsperson; a path you’re very experienced and comfortable with. Down the other path is the lure of management, and all the power and riches that entails.

If you’re lucky enough to work at a cool Silicon Valley tech company, there’s a clear process for choosing either path. You can decide to be an individual contributor (IC) or a manager, and — in theory at least — the choice you make won’t have an effect on your earning potential or career prospects. For everybody else, management typically means a higher salary, a higher status and more upwards mobility. However, it also means doing a job you have no previous experience in, and will probably suck at for the next few years. So rather than a crossroads, it can often feel like a precipice.

As a designer transitioning into management, it feels like the sensible thing to do is to find a middle path; a role where you can still be doing day-to-day design, while looking after a handful of designers. This is often described as being a player-coach; somebody who leads their team from the pitch rather than the sidelines. So you look around for roles and end up joining an exciting-sounding company as their first design leader. Happy days. Or so you think. Jump forwards 6 months and you’re wondering if you’ve made some terrible mistake. Maybe design leadership isn’t for you, and life would be better if you admit defeat and go back to being an individual contributor?

This is an all too predictable story I see repeating time and time again, so what went wrong?


I see three major challenges — and one big benefit — of becoming a player coach, so let’s start with the benefit. These player-coach jobs are easier to land for people transitioning into management because they generally don’t require prior management experience. The world is full of companies looking to build out their design teams, but lack the understanding to know what skills are needed. So rather than paying for an experienced manager, they try and get two people for the price of one. This results in them hiring somebody to be both a designer and a design leader, presuming they can do the management bit in the gaps between shipping.

Sadly this is rarely the case and leads us to our first challenge. It turns out that it’s super hard to hold down two jobs, especially if you’re good at one and have no experience at the other. So you either over-index on the design work, and end up being a negligent leader, or you focus on the leadership stuff and quickly become a blocker for your design work. As you’re in meetings all day, you decide to take some of your “real work” home, rationalising that everything will be OK as soon as you get over the current hump.

However, rather than getting better, things are about to take a turn for the worse. You’ve been tasked with growing your team, and there’s headcount to fill. However, as the companies first design leader, none of the infrastructure is in place. There are no pre-existing job descriptions, guides for running successful job interviews, or processes for on-boarding new designers. Similarly, there’s no process for running 1:1s or performance reviews, and don’t get me started on the lack of a progression framework. If you’d come from a previous management role, you’d probably have some of these things already, but as this is your first position, you need to create everything from scratch. So you do a tonne of reading, scour online forums, and start building your processes from scratch, often in your own time. Very quickly you find yourself with a third, hidden job; that of design operations manager.

This is where our third and final challenge comes in; a general lack of organisational support and understanding for your role. As a new design leader, you don’t know what you don’t know. In ideal circumstances, you’d have support from more senior and experienced design leaders, but because you’re the only one of your kind in the organisation, you have nobody to turn to. Furthermore, your probation period is starting to run out and the bosses are wondering why you’re not performing at a higher level. Design work is backing up, the team aren’t feeling supported, and you still haven’t filled those open roles. This is the point where imposter syndrome take holds, and you wonder if you’ve bitten off more than you can chew, and would be better off going back to being an individual contributor.

I’m here to tell you that this is a perfectly natural experience, and you’re not alone. It happens to a lot of first-time leaders who follow a player-coach model. In my experience, it is possible to navigate through this situation successfully, but you’re going to need a lot of spare time, resilience, and a strong support network — preferably with the addition of an experienced coach.

Far from being the easy option, this route is more commonly a baptism of fire. You’ll put everything you have into the role, and will learn a lot along the way. However, it’s a hard slog and many people run aground after 18 months. So it’s quite common for a companies first design leader to move on to a more dedicated — and arguably more sustainable — management role before too long. Ironically the person who comes after you will have a much easier time, as you’ll have cleared the pathway, laid down a trail, and set them up for success.

Fortunately, your second leadership job will almost certainly be better than your first. You’ll have experienced the challenges of starting something from scratch, you’ll understand the need to double down on doing one thing well, and you’ll appreciate the value of working with somebody who has been leading design teams for a while, and can support you in your own career journey.

Of course you can skip this painful learning process entirely, and attempt to land your first leadership role in a company with an established design practice, run by an experienced design leader. But that’s often easier said than done, and sometimes we have to make our own mistakes in order to properly learn from them.

This post was originally published on Medium

Static sites, slack and scrollytelling. Wed, 18 Nov 2020 13:23:00 +0000 Since I started at Clearleft, I’ve had my eye on our timeline…

Scrolling through the timeline for the first time, I thought it was shame that such an impressive list of achievements was just tucked away, gathering dust. Over the last 15 years Clearleft’s had such an impact on the web and design industry, but according to the entries on the old timeline we all stopped working mid 2018. (We didn’t, we promise)

The timeline design also got in the way of the content. There was no way to navigate to a specific year and a good proportion of the text was illegible on image backgrounds.

So when I got the chance to redesign our new timeline for our 15th birthday I had two main goals.

  • Ensure the timeline was kept up to date by enabling everyone at Clearleft, no matter their level of tech-savvy to edit our timeline.
  • Create something modern and enjoyable to explore.

The tricky thing about those goals in tandem is that if you’re not careful, modularising and CMS-ing something can hamper your creativity.

So in order to give myself as much creative freedom as possible, I chose to use Eleventy. Eleventy (11ty) is a simple static site generator. Basically, it gets out of the way and allows you to focus on the fun stuff!

11ty enables us to grab remote data and make it as accessible to our templates as super speedy static data, which is a big win for performance.

In our case the remote date is coming from a base on Airtable, which is not your average spreadsheet – it’s like google docs with rocket boosters.

a screenshot of an airtable database

It’s great for our purpose though, as now anyone at Clearleft can update the timeline, just by adding an event to a spreadsheet!

The one minor little hiccup in this plan is that the “static” in static site generator means that you have to rebuild the site when content changes.

Luckily Netlify allows you to trigger a build via a post to a webhook – we can do this via slack integrations! My colleague Trys wrote about this

I love this bit. It feels like magic! Plus, it’s a tool everyone at Clearleft uses, so no more waiting for one of the devs to press the magic button.

a screenshot of a slack conversation, the messages are all from Cassie, they read 'launch-timeline' 'wooo!'

The fun bit

I don’t know if you’re aware, but I really like SVG animation.

The bit I enjoyed making the most was this little hover interaction, it’s using an SVG mask and Greensock’s quickSetter to performantly update the mask position as you move your mouse.

The rest of the animation is largely handled with a new Greensock plugin called scrollTrigger. It was announced a few weeks before starting the timeline rebuild, and I knew this would be the perfect place to try it out.

ScrollTrigger has great browser support, plays nicely with Greensock timelines (obviously) and can do all sorts of things that would be tricky and time-consuming to handroll yourself.

Here’s a little reduced test case showing how I was animating the background graphics on scroll.

See the Pen Timeline scroll by Cassie Evans (@cassie-codes) on CodePen.

Check out our new timeline, and while you’re there, why not send us a postcard?

Dashboards: a design discussion Thu, 12 Nov 2020 13:03:00 +0000 We have regular design debates here at Clearleft. A few months back, we had a provocation prompted by a tweet.

Our friend Jared Spool tweeted:

Dashboards are often what customers ask for.

They are rarely what customers need.

If you’re building a dashboard, it’s likely your user research wasn’t finished.

We’re a curious bunch here at Clearleft, always encouraged to ‘Ask the question’ so we thought this was perfect debating ground. But before that, we needed to get our definitions straight. What exactly is a dashboard?

The UX of LEGO Interface Panels
George Cave The UX of LEGO Interface Panels

Chris put forward his definition. A dashboard, he said, comprises three things:

  1. A visual display of data that
  2. monitors conditions and
  3. informs actions.

That last point is where Chris sees most dashboards falling down. They’re showing data but the data they show is whatever’s easiest to gather. Think of those displays in the reception area of a company’s lobby. They give the impression of a data-driven company because there’s a chart with numbers moving. But those numbers could be anything. Some beautifully generated digital art would do the same job.

Richard pointed out that the audience matters too. For instance, internally at Clearleft, we’ve created a new company dashboard (as part of growing transparency following becoming employee owned). The leadership team use this for forecasting and decision-making. But the same dashboard can be used to give everyone in the company a general sense of where we’re at. He warned to ale always ask ‘why’ we’re providing that information? And what do we expect our teams to do with it?

Andy agreed that you need to be strategic about what to include on a dashboard so that it informs some intelligent decision-making. But don’t expect a dashboard to pre-emptively suggest solutions for you. You need to apply a heavy dose of interpretation.

So if a number is going up or down, do you have enough information to judge whether that’s a long-term trend or a short-term blip?

Remember there is a fundamental difference between data and metrics. Data only becomes a metric when you’ve got something to judge that number by. Dashboards can help, but you need to be aware of our bias towards pattern-matching.

Jeremy agreed that dashboards can be a useful guide, but he warns against mistaking the map for the territory. When it comes to metrics, he said, you need to consider the McNamara fallacy. Reducing success to a measurement can backfire. You end up giving too much weight to what can be measured and not enough weight to things that are hard to measure. There’s Goodhart’s law too:

When a measure becomes a target, it ceases to be a good measure.

Done well, there’s no doubt a dashboard can help you fight through the noise to get a really clear synthesis of information.

When we mentioned in our newsletter that we were discussing dashboards, our friend Brian Suda—informatician and author of Designing With Data—chimed in with his thoughts:

I think dashboards are great, it is just that most dashboards fail on their purpose.

A car’s dashboard are not vanity metrics; most corporate ones are. Most dashboards you see in any office will have either vanity metrics, or some metric which is not actually actionable.

Katie warned that in her experience designing business tools there’s a risk to mitigate, that the longer they’re around the more they are abused and everything begins to lose meaning. The sweet spot for her is designing for power users, customisable dashboards that users use every day. They work well for those users who need operational oversight.

Perhaps we’re all in agreement here. Most dashboards aren’t good. But that doesn’t mean that all dashboards are bad. Or, as Katie loves to say …it depends.

Service Designers don’t design services, we all do Wed, 11 Nov 2020 12:04:00 +0000 Sometimes I wonder if the design industry—and particularly the digital space—has over-complicated things.

There are all these flavours of design practice: service design, customer experience design, user experience design, content design, product design. They probably have more commonalities than differences and the fact that we need to explain them to each other is worrying!

And this list grows and morphs year after year. In the last few years, we’ve seen the advent of the product designer within digital teams. More recently I’ve seen a growth designer pop up. That’s surely not the last new discipline beating its drum. The ultimate goal of each of these disciplines is the same — to satisfy a user’s need or goal and to drive the organisation forward. The difference is often around focus and remit.

In the digital space, we talk a lot about products rather than services. Many organisations have product teams with product owners supported by product designers working on fulfilling their product strategy by progressing through their product backlog. This, in my opinion, might limit our remit and do us an injustice. It’s something I’ve written about previously where I highlight that products are often vehicles for service provision.

Whether you are designing a ‘product’ or a ‘service’ it’s vital that everyone comes together to ensure that it works across both of its service dimensions.

Pushing service design from end to end and front to back diagram

Service dimensions

There are two critical dimensions to a service; end to end and front to back.

  • From end to end - All services comprise multiple moments that enable a user or customer to achieve their goals. The key to creating a compelling user experience is understanding the relationships between these moments digital and non-digital and designing across and between these moments.

  • From front to back - The concept of the front-stage and back-stage experience is well defined within the service design world. You can’t create exceptional service experience without looking at the process that delivers it.

In today’s world, the only logical approach is to start with the customer-facing service and its experience and then work inwards, engineering the optimal organisation to support the service. The role of the service organisation in the backstage is to support the service effectively, with its shape and structure built and adapted to suit. All too often the back-stage processes are overlooked, with new services built on top of dysfunctional organisations. But when back-stage organisational problems exist, they have front-stage consequences: poor service, customer frustration, and inconsistent channels. Streamlining back-stage processes is critical.

iPad showing the cityclean app

Pushing the service dimensions

As a designer, regardless of your remit you are in a unique position to push against these dimensions, to not only ensure that all touchpoints are well connected but also to shape the service organisation that supports them.

When designing a specific moment, it’s absolutely critical not to lose sight of where this moment sits within the broader service:

  • What is its role?
  • What is its relationship with other touchpoints?
  • How might your design decisions influence other moments?
  • Where does the content come from and what are the workflows that create it?

We did just that at Clearleft on a recent project with Brighton and Hove City Council. We were helping a department called Cityclean who are responsible for rubbish, recycling and street cleaning in the city.

Initially, we were asked to look at the form that citizens use to report issues such as graffiti, fly-tipping and broken glass. There was a feeling in the council that the form was difficult to use and that it was putting people off. They weren’t wrong. But by asking the right probing questions, we began to identify a much bigger service opportunity that we really enjoyed tackling:

  • Who will use this information?
  • What decisions or action will be taken based on the information collected?
  • How will issues be tracked and monitored?

So when you are designing anything, no matter how small or how broad, consider all dimensions. Even if you don’t initially have the remit, push to the outer edges by asking probing questions around context. Then quickly build momentum by visualising the opportunity and making it real.

Good luck everyone in pushing those dimensions.

Accessible interactions Thu, 29 Oct 2020 09:49:00 +0000 Accessibility on the web is easy. Accessibility on the web is also hard.

I think it’s one of those 80/20 situations. The most common accessibility problems turn out to be very low-hanging fruit. Take, for example, Holly Tuke’s list of the 5 most annoying website features she faces as a blind person every single day:

  • Unlabelled links and buttons
  • No image descriptions
  • Poor use of headings
  • Inaccessible web forms
  • Auto-playing audio and video

None of those problems are hard to fix. That’s what I mean when I say that accessibility on the web is easy. As long as you’re providing a logical page structure with sensible headings, associating form fields with labels, and providing alt text for images, you’re at least 80% of the way there (you’re also doing way better than the majority of websites, sadly).

Ah, but that last 20% or so—that’s where things get tricky. Instead of easy-to-follow rules (“Always provide alt text”, “Always label form fields”, “Use sensible heading levels”), you enter an area of uncertainty and doubt where there are no clear answers. Different combinations of screen readers, browsers, and operating systems might yield very different results.

This is the domain of interaction design. Here be dragons. ARIA can help you …but if you overuse its power, it may cause more harm than good.

When I start to feel overwhelmed by this, I find it’s helpful to take a step back. Instead of trying to imagine all the possible permutations of screen readers and browsers, I start with a more straightforward use case: keyboard users. Keyboard users are (usually) a subset of screen reader users.

The pattern that comes up the most is to do with toggling content. I suppose you could categorise this as progressive disclosure, but I’m talking about quite a wide range of patterns:

  • accordions,
  • menus (including mega menu monstrosities),
  • modal dialogs,
  • tabs.

In each case, there’s some kind of “trigger” that toggles the appearance of a “target”—some chunk of content.

The first question I ask myself is whether the trigger should be a button or a link (at the very least you can narrow it down to that shortlist—you can discount divs, spans, and most other elements immediately; use a trigger that’s focusable and interactive by default).

As is so often the case, the answer is “it depends”, but generally you can’t go wrong with a button. It’s an element designed for general-purpose interactivity. It carries the expectation that when it’s activated, something somewhere happens. That’s certainly true in all the examples I’ve listed above.

That said, I think that links can also make sense in certain situations. It’s related to the second question I ask myself: should the target automatically receive focus?

Again, the answer is “it depends”, but here’s the litmus test I give myself: how far away from each other are the trigger and the target?

If the target content is right after the trigger in the DOM, then a button is almost certainly the right element to use for the trigger. And you probably don’t need to automatically focus the target when the trigger is activated: the content already flows nicely.

<button>Trigger Text</button>
<div id="target">
<p>Target content.</p>

But if the target is far away from the trigger in the DOM, I often find myself using a good old-fashioned hyperlink with a fragment identifier.

<a href="#target">Trigger Text</a>
<div id="target">
<p>Target content.</p>

Let’s say I’ve got a “log in” link in the main navigation. But it doesn’t go to a separate page. The design shows it popping open a modal window. In this case, the markup for the log-in form might be right at the bottom of the page. This is when I think there’s a reasonable argument for using a link. If, for any reason, the JavaScript fails, the link still works. But if the JavaScript executes, then I can hijack that link and show the form in a modal window. I’ll almost certainly want to automatically focus the form when it appears.

The expectation with links (as opposed to buttons) is that you will be taken somewhere. Let’s face it, modal dialogs are like fake web pages so following through on that expectation makes sense in this context.

So I can answer my first two questions:

  • “Should the trigger be a link or button?” and
  • “Should the target be automatically focused?”

…by answering a different question:

  • “How far away from each other are the trigger and the target?”

It’s not a hard and fast rule, but it helps me out when I’m unsure.

At this point I can write some JavaScript to make sure that both keyboard and mouse users can interact with the interactive component. There’ll certainly be an addEventListener(), some tabindex action, and maybe a focus() method.

Now I can start to think about making sure screen reader users aren’t getting left out. At the very least, I can toggle an aria-expanded attribute on the trigger that corresponds to whether the target is being shown or not. I can also toggle an aria-hidden attribute on the target.

When the target isn’t being shown:

  • the trigger has aria-expanded="false",
  • the target has aria-hidden="true".

When the target is shown:

  • the trigger has aria-expanded="true",
  • the target has aria-hidden="false".

There’s also an aria-controls attribute that allows me to explicitly associate the trigger and the target:

<button aria-controls="target">Trigger Text</button>
<div id="target">
<p>Target content.</p>

But don’t assume that’s going to help you. As Heydon put it, aria-controls is poop. Still, Léonie points out that you can still go ahead and use it. Personally, I find it a useful “hook” to use in my JavaScript so I know which target is controlled by which trigger.

Here’s some example code I wrote a while back. And here are some old Codepens I made that use this pattern: one with a button and one with a link. See the difference? In the example with a link, the target automatically receives focus. But in this situation, I’d choose the example with a button because the trigger and target are close to each other in the DOM.

At this point, I’ve probably reached the limits of what can be abstracted into a single trigger/target pattern. Depending on the specific component, there might be much more work to do. If it’s a modal dialog, for example, you’ve got to figure out where to put the focus, how to trap the focus, and figure out where the focus should return to when the modal dialog is closed.

I’ve mostly been talking about websites that have some interactive components. If you’re building a single page app, then pretty much every single interaction needs to be made accessible. Good luck with that. (Pro tip: consider not building a single page app—let the browser do what it has been designed to do.)

Anyway, I hope this little stroll through my thought process is useful. If nothing else, it shows how I attempt to cope with an accessibility landscape that looks daunting and ever-changing. Remember though, the fact that you’re even considering this stuff means you care more than most web developers. And you are not alone. There are smart people out there sharing what they learn. The A11y Project is a great hub for finding resources.

And when it comes to interactive patterns like the trigger/target examples I’ve been talking about, there’s one more question I ask myself: what would Heydon do?

This was originally posted on my own site.

Is the future of design work distributed? Thu, 22 Oct 2020 11:27:12 +0000 We’re all remote workers now. But is this just a brief blip or is it the shape of things to come? That was the question that dominated our fifth design leadership panel.

The panel was moderated by Clearleft co-founder Jeremy Keith and featured a fantastic line-up of panelists:

  • Emma Boulton, Director of Design Research at Babylon Health
  • Holly Habstritt Gaal, Design Director at Duck Duck Go
  • Jean Laleuf, Executive Director of UX and Product Management at J.P. Morgan Chase
  • Lola Oyelayo-Pearson, Director of UX at Shopify

The topic of discussion was the future, but Jeremy began by asking about the past. Specifically, one year ago. How much has changed in that time?

For Jean and Holly, work life hasn’t changed all that much. They were both working remotely anyway, Jean in the US and Holly in The Netherlands. Duck Duck Go’s workforce is entirely remote, but Holly pointed out that regular get-togethers were an important part of their culture. She misses those. Similarly, Jean used to travel a lot for work. Now that he hasn’t travelled all year, he really misses it.

Emma used to divide her time between remote work in Wales and on-site work in Babylon Health’s London office. Now her work is entirely remote. For Lola, everything has changed in the past year. One year ago, she hadn’t yet started at Shopify. Now she has not only started working there, she has also travelled across the Atlantic to move to Canada …just in time for Shopify to declare that they are now a permanently remote company.

Jeremy asked the panelists whether the move to remote work has been a blessing in disguise. Are there some kinds of work that are more suited to being alone and uninterrupted?

Jean pointed out that what you miss with remote work is the serendipity of seeing other people’s work: “It’s the walking by somebody’s desk and looking over, just glancing at their screen and going, “Wait, what? Let’s chat about that!” Lola agreed that the heads-down nature of remote work comes at a cost: “We’re having to create a lot of rituals to try and introduce those moments. And it’s actually much harder to engage people in them. And so you get more deep work, but you actually end up being less excited sometimes by the work. We’re trying to figure out what are the right sets of rituals and activities to bring some of that serendipity and energy back into the design work.”

Emma also misses some of the spontaneity of the office: “Those times where you just want to go for a walk and have a chat or take someone for coffee and not have the proper one-to-one. Something’s up with them and you can’t figure out why, and they just need a bit more pastoral help. That’s what I missing.”

That leads to another point that Jeremy asked about. Given everything going in the world, and how stressful it is for everyone, has the focus at work shifted from productivity to well-being? Lola has been investing a lot of time in connecting with her teams. But she doesn’t see that as being at the expense of productivity: “I don’t see that I’ll get productivity unless those connections are made. And I’m actively always investing that time because I think the reward is unquestionable.”

Were able to hire the best people all over the world, with diverse needs that can be supported" Emma

Despite the challenges, everyone was in agreement that the future of design work is distributed. As Emma points out: “It means we can have more diverse teams, people in my team have a chronic illness, for example. But also now I’m hiring, I’m able to talk to people all over the UK, all over the US and hopefully when we go back to normal, I won’t have to ask them to relocate to Austin or London, because that way we can hire the best people rather than the best people that live in a particular city.”

Looking at the trajectory of design, it seems like design may have finally earned its seat at the table. Holly said: “I’ve been fortunate enough to work at a lot of places that trust us, love us, want us involved. It doesn’t mean they understand what we do. So we still have to be super visible about where we can be a part of the conversation.”

But this doesn’t necessarily mean that designers need to become business people: “Just because you’re involved in the business doesn’t mean it has to be so commercial.” Jean said: “It’s not just about speaking business. It’s more about understanding the goals that your business is working towards and understanding how humans fit into those goals. For me, design is the process of reconciling the constraints of the business goals and the constraints of the human goals.”

“Design is reconciling the constraints of business goals and the constraints of human goals."

Lola agreed: “If I define “commercially minded” in my mindset, I think people think that we mean “profit driven”. And it’s not. The way I define it is you need to understand how money works in your company.” Emma added: “Money is time. We’re always trapped in the line between scrappy quick-and-dirty research and rigorous research. But commercially we have to think about how quickly can we deliver good enough insights that help us de-risk the decisions that the teams are making.”

Playing devil’s advocate, Jeremy asked if design systems might make designers obsolete—are we creating the tools of our own destruction? Holly started the defence: “No, I think we’ve started to position ourselves more upfront in the strategy piece and less on production. I always make sure that the strategy problem-solving skillset that we have is seen and valued and used in the right conversations at the right time. Then I think we’ll have no problem.”

“I always make sure that the strategy problem-solving skillset we have is seen at the right time.”

But looking further ahead to ten years from now, might a robot be doing your job? Emma doesn’t think so: “As designers, we should also be doing research or listening and talking, and I think you just really can’t replicate that with a robot.” Lola acknowledged: “There are many, many jobs that no longer exist today that our parents would have felt were permanent as recently as 30 years ago. So that’s a human problem, not a design problem.”

Jean added: “I don’t know that we’ll ever get completely made obsolete as designers, but I think our roles may shift and our roles have shifted already and they’ll continue to shift. And it may be that we become the trainers of the engines, that we define the framework or the rules within which the AIs function to meet certain goals and design certain products. But I think there’s probably always some sort of a problem-solving goal-setting job there for us.” Lola warned: “The one thing that I think is speeding up our lack of value is our lack of willingness to engage with future tech. If we become the resistance, we make ourselves irrelevant. But if we are able to continue to be a bridge between the tech and the individual, then there’s a role for us in all futures.

If we continue to be the birdge between the individual and the tech then we have a future" lola

Finally, Jeremy asked where the panelists might see themselves in 15 years time. This is when the conversation doubled-back to remote working. Holly said: “I hope that we can see this as an opportunity, that we’ll think of it as normal maybe 15 years from now, shifting away from having to hire people in expensive cities and thinking about other parts of the world where there’s also very talented people. Maybe we’ll be able to be a little more inclusive and ethical as a result.” Jean concurs: “I think this greater degree of flexibility that we’re seeing; I’m really hoping that that will stick. It may enable people to work later on into their years because there will be a better ability to live where you want.”

Emma also pointed to the happy confluence of two trends: remote work and an ageing population: “This sort of more remote distributed working will enable people to maybe dial down work if they’re getting to the age where they want to think about spending less time at the work and maybe be able to enjoy their lives more.”

Where do you see design heading in the next 15 years? We’d love to hear from you. Head over to the Clearleft timeline and send us a postcard. Let’s imagine it’s 2035… How do you hope the practice of design will have changed for the better?

Introducing Leading Design Festival Wed, 21 Oct 2020 12:32:00 +0000 We’ve all spent the last six months living on Zoom, and it’s frankly tiring. So when we started thinking about bringing Leading Design online, the last thing we wanted to do was force people to sit through a never-ending series of back-to-back talks.

Instead, we’ve decided to spread our event across a much longer period and turn it into the first Leading Design Festival. So we’re going to have practical masterclasses, talks, panel discussions, and a host of other sessions peppered throughout the month. This will hopefully allow our busy community of design leaders to pick and choose what to attend (much like a real festival), and catch content they’ve missed on replay.

Logo and Leading Design Festival on a deep purple with a broken out the box pattern

This sort of asynchronous time and place shifted content is fast becoming the norm. However, there’s still something magical about bringing a group of peers together for a shared experience. So we’ll be kicking things off with a mini-conference. Spread over three afternoons (or mornings if you’re in the US), it’ll be a combination of over a dozen short talks, Q&As, and panel discussions, with plenty of breaks to make sure folks can fit things around their schedule, and not get fatigued.

Want to keep the insights coming? Then why not join us for The Rest of the Fest, an extended series of talks, panel discussions, mentoring sessions and networking events throughout the month of March. Perfect for the busy design exec working to take their leadership to the next level.

If that’s not enough, we’ve also arranged a series of 90-minute Masterclasses with some of the most influential design leaders in our field. These practical, hands-on sessions will help you grow your leadership toolkit, and be the best leader you can possibly be.

To make things even easier you can choose to attend just the conference, pick specific masterclasses, or buy a pass that gives you unlimited access to the whole festival. The choice is yours.

The tickets have just launched and early-bird tickets won’t hang around long. I really hope you can join us in March 2021.

Meet the new owners of Clearleft Mon, 12 Oct 2020 09:15:00 +0000 You know how these articles go. You’ve read a dozen of them before. Maybe too many for your liking. A well-known and well-respected design agency like Clearleft announces its sale to some giant company you’ve never heard of.

The announcement is full of platitudes. “It’s been a wonderful journey so far” the founders will explain, and “this sale marks the next exciting chapter in our history”. The founders will take great pains to explain how much “synergy” they have with their new owners, and how the purchase will “secure the future of their agency and their wonderful employees”.

“This is an amazing opportunity for our agency”, the founders will be at pains to point out, “allowing us to have an even bigger impact than we had before”. This sounds great, but you can’t help feel like the founders are laying it on a little thick. Like they are trying to convince themselves as much as anybody else. You’re happy for the founders, but you can’t help but be left with a sinking feeling in your stomach. Another independent agency is about to bite the dust.

Well, I’m sure you can see where this article is heading (I mean the title was a bit of a giveaway), but after 15 years of running Clearleft, it’s our time to begin to walk down a similar path. We’ve had an amazing journey and have done some pretty cool things along the way. We’ve been working with our new owners for some time now and they really do get us. If you know Clearleft you may already have an inkling of who they may be.

A montage of some of the Clearleft team from a Zoom call

Say hello to our new owners

So who are the new owners of Clearleft, if not some international consultancy? Are they a well-known tech company looking to build their talent pipeline in the UK through a high-profile acquihire? Or maybe a bank, airline or utility company looking to embark on a programme of digital transformation. Well no, not in this case.

Our new owners are Alex, Chris and Tom. They’re James, Helen and Cassie; Lorenzo, Trys and Maite. I could go on but you see where we’re going here. The new owners of Clearleft are the people who power Clearleft and who make Clearleft so special. It’s our whole team, in the form of an Employee Ownership Trust.

That’s right; Clearleft will be run for—and on behalf of—all our team, now and in the future. So rather than working for a company where the benefits go to a handful of individuals, they will be shared evenly amongst the team.

For those of you with a libertarian bent (which I hope isn’t too many of our followers, although we do a fair amount of work in the Bay area) you may be wondering, what sort of socialist hell is this? Have we lost our minds?

Well, no. The truth is that for the entire history of Clearleft we’ve made decisions with the benefit of the team in mind. It’s one of the reasons we’re able to hire such great talent and keep them retained for two or three times longer than most other agencies. We’ve always put our team’s well-being before our own, so we’re simply making it official.

Now’s the time

The timing (in the middle of a global pandemic) is a little unusual and probably wouldn’t have been our first choice. But it’s also strangely fitting.

In times of financial hardship, it’s common for company owners to put themselves ahead of everybody else. During the last downturn a well-known agency founder was caught bragging about his brand new company Audi on Twitter the same week he let a third of his team go. Other founders we know have emptied their coffers in advance of a downturn, or have been tempted by a low-ball offer from a third-party buyer.

I’m not saying these decisions were wrong, as everybody’s circumstances are different. What I do know is that this isn’t something we’d ever consider, so we wanted to make it official; to send a strong signal that while others claim to be “In it together”, we really mean it.

While there are a lot of practical benefits of being employee-owned—like improved happiness, health and productivity—for the most part life at Clearleft will remain unchanged. We still have the same leadership team and board structure, it’s just they are now obliged to act in the interest of our new majority shareholder, the Employer Ownership Trust.

If you’ve worked with Clearleft over the years, you may be wondering what this means for our clients. In truth, you’ll get the same amazing service as you’ve come to expect. Maybe even better, because rather than working with employees, you’ll be working with company partners. So they’ll be even more focussed on providing you with a great experience, as their names are above the door (so to speak). It also means that the money made will go to benefit the team you’re working with, rather than a handful of wealthy shareholders. There’s a good argument to make that working with an employee-owned company like Clearleft is an ethical choice.

So yes, it’s been a long and exciting road. We’ve found some amazing new owners, and are excited to embark on the next phase of our journey. However, unlike the majority of these articles, I hope this one leaves you feeling genuinely happy for our team, our clients, and the future of Clearleft.

Engineering Neon Wed, 07 Oct 2020 13:10:00 +0000 EngineeringUK is a non-profit on a mission to inspire the young people of today to become the engineers of tomorrow.

Clearleft had the great pleasure of working closely with EngineeringUK on their latest project: Neon:

Bringing STEM to life through real-world engineering

The design is beautiful (and aren’t the hover animations in the navigation just lovely?) but what really stood out on this project was, well, the engineering.

This was a three-way engineering partnership between the team at EngineeringUK, the developers at Clearleft(Cassie and Trys), and our friends at Umbrella. We designed the experience and were responsible for the front end development, Umbrella built the back end, and the team at EngineeringUK were responsible for getting the whole thing live with excellent content.

You could picture Umbrella as the bridge between Clearleft and EngineeringUK. They received front-end code from Clearleft on one side, while getting the content from EngineeringUK on the other. Using both of those inputs they could then put the back-end system together.

Crucially this wasn’t a waterfall process. It was quite fluid and there were course-corrections throughout. On the Clearleft side, we might have an idea for how a particular component could behave and tell Umbrella “It would be great if this kind of data stucture were available.” They could then work on providing that data structure. Or, in the other direction, based on the content from EngineeringUK, Umbrella might say to us “This is how the data will be structured—can you work with that?” and we could adjust our front-end components accordingly.

Often we’ll deliver a library of these components to the client as the output of a project. In this case though, the components weren’t a deliverable—they were a means to an end.

Working in a component-based way ensured that the front-end code would be robust. Each component was like a reduced test case. Best of all, Umbrella provided API endpoints that we could use to populate the components with real data. That really helped to take the guesswork out of the process.

How to engage the right people when recruiting in house for research Mon, 05 Oct 2020 12:42:00 +0000 Engaging the right people is key to the success of a research project. The quality of the insights that you get depends on the relevance of the people you invite to participate in a study and the information they provide. That is what makes recruitment such a fundamental part of any research study.

During the recruitment process you search for, identify and invite the right individuals to take part in your study. Organisations can do this with the support of a professional recruitment partner or do it themselves if they have the right conditions and resources in place. For those new to recruitment, it sounds like a quite straightforward process. It’s actually a highly demanding and time-consuming task.

Here’s a list of key things to take into account if you’re considering in-house research recruitment for the first time.

Stakeholder research Miro board template with a number of questions and post its to capture responses
Stakeholder research Miro board template

Identify relevant characteristics of your participants

Once you know what you want to learn, you should be able to identify the appropriate research methods and the characteristics of the people who are best suited to provide you with relevant information. It’s important to keep a balance. It’s very easy to go too vague (because everyone is your potential customer) or too specific (making it extremely difficult to reach participants). Define your priorities in case you need to adjust any criteria as you recruit. You should review your goals and plan accordingly.

Double-check your ability to contact people

The fact that your organisation has contact information of people that are relevant for your study doesn’t mean that you can use it to invite them to participate. You should always consult with legal experts first to understand if you are allowed to use your customers’ personal data and how.

Define incentives and delivery

Your organisation will benefit from doing research. You need to also consider how your participants should benefit from taking part in it. You can define incentives or compensations if appropriate. If you do, you should know in advance exactly how you’re going to deliver them and set the right expectations.

Identify key gatekeepers and their involvement

There might be people who can facilitate or interfere with your access to potential participants. For instance, there might be account managers, executives or similar roles that are responsible for the relationship with your target group. Many times and for different reasons, we’ve seen these gatekeepers blocking access to certain people or briefing participants if they feel threatened by the project (even if you see no reason for them to). Consider if you need these gatekeepers’ support and if they might perceive any risks or reasons not to cooperate with the project, and how you will deal with that scenario.

Prepare a communication and contact plan

You will have to communicate with your research participants at different times and for different reasons. Depending on your context, you should consider in advance the most appropriate way to communicate. Create a plan and combine different channels and approaches at different times to make it more effective. Craft the communication experience and approach people in the most personalised way you can.

Screen your participants

You need to make sure that the people you invite to the study fit the criteria that will help you meet your research goals. Prepare a set of questions that will help you identify the right participants. You should always ask these questions and document the answers before sending people any formal invitations. This can also help you get a sense of their personality and how interested or engaged they might be in the process.

Prepare for rejection

Unfortunately, it’s quite likely that most people will reject your invitation to take part in your study. Also, some of those who accept your invitation will not turn up. Take this into account in your planning as you might need to invite way more people than your goal. You might need to schedule more sessions than you expect as well.

Define metrics of success and corrective actions

Track and assess recruitment progress. Define metrics to understand how the process is going and where you might be struggling. It can also be a good idea to plan corrective actions if certain goals are not met.

Don’t take shortcuts

Recruitment is a fundamental step in the research process and it can easily (and painfully) become a full-time job when you do it yourself. It’s tempting to take shortcuts and skip steps when things become challenging. But don’t let short-term thinking get in the way. Recruiting the wrong people is extremely detrimental to the quality and relevance of findings and it compromises any decisions where they are used as an input.

Performance and people Mon, 28 Sep 2020 16:01:15 +0000 I was helping a client with a bit of a performance audit this week.

I really, really enjoy this work. It’s such a nice opportunity to get my hands in the soil of a website, so to speak, and suggest changes that will have a measurable effect on the user’s experience.

Not only is web performance a user experience issue, it may well be the user experience issue. Page speed has a proven demonstrable direct effect on user experience (and revenue and customer satisfaction and whatever other metrics you’re using).

It struck me that there’s a continuum of performance challenges. On one end of the continuum, you’ve got technical issues. These can be solved with technical solutions. On the other end of the continuum, you’ve got human issues. These can be solved with discussions, agreement, empathy, and conversations (often dreaded or awkward).

I think that, as developers, we tend to gravitate towards the technical issues. That’s our safe space. But I suspect that bigger gains can be reaped by tackling the uncomfortable human issues.

This week, for example, I uncovered three performance issues. One was definitely technical. One was definitely human. One was halfway between.

The technical issue was with web fonts. It’s a lot of fun to dive into this aspect of web performance because quite often there’s some low-hanging fruit: a relatively simple technical fix that will boost the performance (or perceived performance) of a website. That might be through resource hints (using link rel=“preload” in the HTML) or adjusting the font loading (using font-display in the CSS) or even nerdier stuff like subsetting.

In this case, the issue was with the file format of the font itself. By switching to woff2, there were significant file size savings. And the great thing is that @font-face rules allow you to specify multiple file formats so you can still support older browsers that can’t handle woff2. A win all ‘round!

The performance issue that was right in the middle of the technical/human continuum was with images. At first glance it looked like a similar issue to the fonts. Some images were being served in the wrong formats. When I say “wrong”, I guess I mean inappropriate. A photographic image, for example, is probably going to best served as a JPG rather than a PNG.

But unlike the fonts, the images weren’t in the direct control of the developers. These images were coming from a Content Management System. And while there’s a certain amount of processing you can do on the server, a human still makes the decision about what file format they’re uploading.

I’ve seen this happen at Clearleft. We launched an event site with lean performant code, but then someone uploaded an image that’s megabytes in size. The solution in that case wasn’t technical. We realised there was a knowledge gap around image file formats—which, let’s face it, is kind of a techy topic that most normal people shouldn’t be expected to know.

But it was extremely gratifying to see that people were genuinely interested in knowing a bit more about choosing the right format for the right image. I was able to provide a few rules of thumb and point to free software for converting images. It empowered those people to feel more confident using the Content Management System.

It was a similar situation with the client site I was looking at this week. Nobody is uploading oversized images in order to deliberately make the site slower. They probably don’t realise the difference that image formats can make. By having a discussion and giving them some pointers, they’ll have more knowledge and the site will be faster. Another win all ‘round!

At the other end of continuum was an issue that wasn’t technical. From a technical point of view, there was just one teeny weeny little script. But that little script is Google Tag Manager which then calls many, many other scripts that are not so teeny weeny. Third party scripts …the bane of web performance!

In retrospect, it seems unbelievable that third-party JavaScript is even possible. I mean, putting arbitrary code—that can then inject even more arbitrary code—onto your website? That seems like a security nightmare!

Remember when I did a countdown of the top four web performance challenges? At the number one spot is other people’s JavaScript.

Now one technical solution would be to remove the Google Tag Manager script. But that’s probably not very practical—you’ll probably just piss off some other department. That said, if you can’t find out which department was responsible for adding the Google Tag Manager script in the first place, it might we well be an option to remove it and then wait and see who complains. If no one notices it’s gone, job done!

More realistically, there’s someone who’s added that Google Tag Manager script for their own valid reasons. You’ll need to talk to them and understand their needs.

Again, as with images uploaded in a Content Management System, they may not be aware of the performance problems caused by third-party scripts. You could try throwing numbers at them, but I think you get better results by telling the story of performance.

Use tools like Request Map Generator to help them visualise the impact that third-party scripts are having. Talk to them. More importantly, listen to them. Find out why those scripts are being requested. What are the outcomes they’re working towards? Can you offer an alternative way of providing the data they need?

I think many of us developers are intimidated or apprehensive about approaching people to have those conversations. But it’s necessary. And in its own way, it can be as rewarding as tinkering with code. If the end result is a faster website, then the work is definitely worth doing—whether it’s technical work or people work.

Personally, I just really enjoy working on anything that will end up improving a website’s performance, and by extension, the user experience. If you fancy working with me on your site, you should get in touch with Clearleft.

This was originally posted on my own site.

Clearleft turns fifteen Thu, 24 Sep 2020 14:52:00 +0000 2020 marks Clearleft’s fifteenth birthday. A milestone like this is cause for celebration, and celebrate we must especially amid what is a desperate year for many. This week in particular is momentous, especially for those of us who have been on the journey since the very beginning.

Early in 2005 Andy, Jeremy and I decided to take the plunge and start our own company. We announced our plans for Clearleft in March at South by Southwest and incorporated the company in May. But this week back in September 2005 is when it all began in earnest - we’d quit our full time jobs and started working together for our first clients.

Right off the bat we were an international company - our first project being a social photography platform for a company in Slovenia (thank you EU). We also commenced work on two separate university projects, for Lancaster University Management School and London South Bank University. This was something which has proved a theme throughout Clearleft’s history - so far we’ve worked for at least nine different universities, and continue to do so.

It’s been fascinating looking back through our early clients. We worked with a lot of exciting new dotcom start-ups - they were still a thing in the mid-2000s - as well as many third sector organisations. Charities and the public sector were a feature of our first business plan, and ever since then we’ve strived to work with organisations where we can make a difference to both the outside world and within the company. Another source of pride is just how many household names we’ve worked with over the years - and in really significant ways - Spotify, WWF, BBC, John Lewis, 3M, Gumtree, Channel 4, Penguin Books, Virgin Holidays and the Natural History Museum to name just a few.

Our first business cards stated that “we make websites better”. This modest goal deliberately hinted at our dedication to user-centred design and forward-looking front-end development. That commitment still stands, but a significant difference is that we now look to improve things from the inside: working closely with in-house design teams, we try to make them better too. In hindsight this is an approach we’ve long recognised makes a longer term impact, as demonstrated by our pioneering approaches to design systems and what is now known as design ops.

Right from those first months together in 2005, we’ve had improving the practice of design at the forefront of our minds, from Jeremy’s early Ajax workshops to Andy’s curation of the first d.Construct conference only three months in, and with UX London just three years later (a huge gamble at the time).

Ask anyone who’s worked with, or for, Clearleft and they’ll say it’s all about the people. While growing from three people, to a team closer to 30, we’ve managed to attract and retain the very best. Not just the most experienced and skilled, but the most dedicated and nicest people to work with. If we’ve done anything right over the last 15 years it’s been that.

And as we negotiate our way through this tumultuous year, it’s the strong relationships we’ve made with our clients and their people, which are seeing us through what could otherwise be tough times.

Fifteen years of Clearleft beerleft brew which we sent to all the team to celebrate
Our special 'Fifteen' Beerleft brew we sent round to the team

On that note I would like to raise a glass to friends and colleagues from the past 15 years, and to the next 15 years of Clearleft as we move towards a new phase in our history.

Tiny lesson: Netlify redirects and downloads Mon, 14 Sep 2020 10:39:00 +0000 Making the Clearleft podcast is a lot of fun. Making the website for the Clearleft podcast was also fun.

Design wise, it’s a riff on the main Clearleft site in terms of typography and general layout. On the development side, it was an opportunity to try out an exciting tech stack. The workflow goes something like this:

  • Open a text editor and type out HTML and CSS.

Comparing this to other workflows I’ve used in the past, this is definitely the most productive way of working. Some stats:

  • Time spent setting up build tools: 00:00
  • Time spent wrangling the pipeline to do exactly what you want: 00:00
  • Time spent trying to get the damn build tools to work again when you return to the project after leaving it alone for more than a few months: 00:00:00

I have some files. Some images, three font files, a few pages of HTML, one RSS feed, one style sheet, and one minimal service worker script. I don’t need a web server to do anything more than serve up those files. No need for any dynamic server-side processing.

I guess this is JAMstack. Though, given that the J stands for JavaScript, the A stands for APIs, and I’m not using either, technically it’s Mstack.

Netlify suits my hosting needs nicely. It also provides the added benefit that, should I need to update my CSS, I don’t need to add a query string or anything to the link elements in the HTML that point to the style sheet: Netlify does cache invalidation for you!

The mp3 files of the actual podcast episodes are stored on S3. I link to those mp3 files from enclosure elements in the RSS feed, which is what makes it a podcast. I also point to the mp3 files from audio elements on the individual episode pages—just above the transcript of each episode. Here’s the page for the most recent episode.

I also want people to be able to download the mp3 file directly if they want (or if they want to huffduff an episode). So I provide a link to the mp3 file with a good ol’-fashioned a element with an href attribute.

I throw in one more attribute on that link. The download attribute tells the browser that the URL in the href attribute should be downloaded instead of visited. If you give a value for the download attribute, it will over-ride the file name:

<a href="/files/" download="">download</a>

Or you can use it as a Boolean attribute without any value if you’re happy with the file name:

<a href="/files/" download>download</a>

There’s one catch though. The download attribute only works for files on the same origin. That’s an issue for me. My site is but my audio files are hosted on—the download attribute will be ignored and the mp3 files will play in the browser instead of downloading.

Trys pointed me to the solution. It turns out that Netlify can do some server-side processing. It can do redirects.

I added a file called _redirects to the root of my project. It contains one line:

/download/*  200

That says that any URLs beginning with /download/ should redirect to Everything after the closing slash is captured with that wild card asterisk. That’s then passed along to the redirect URL as :splat. That’s a new one on me. I hadn’t come across that terminology, but as someone who can never remember the syntax of regular expressions, it works for me.

Oh, and the 200at the end is the status code: okay.

Now I can use this /download/ path in my link:

<a href="/download/season01episode06.mp3" download>Download mp3</a>

Because this URL on the same origin, the download attribute works just fine.

This was originally posted on my own site.

SofaConf 2020 talks are now live Wed, 09 Sep 2020 13:16:00 +0000 This June we brought together 18 speakers from the world over with 1000 attendees, for five days of incredible content, entertainment and a good number of impromptu pet photos for SofaConf.

SofaConf was our first foray into online events and we were delighted by the positive feedback we had from attendees and speakers. Amidst all the challenges 2020 has presented to our communities it felt great to be able to bring folks together and share amazing content from industry leaders directly from their living rooms to ours…

We’re now able to publically share all the talk videos and live Q&As from SofaConf. Whether you are interested in product design, content design, research, service or interaction design we’re sure you’ll find these brilliant talks and discussions inspiring and full of valuable learnings you can action.

We’d like to extend a huge thank you to all our speakers and our wonderful compères, Rachel McConnell and Andy Budd for such a great show. We’d also like to thank our wonderful sponsors, Google, InVision and Intercom for their support in making this event happen.

Day 1: Product Strategy

We kicked off on Monday with Product Strategy - our four stellar speakers gave tips and techniques to get the most from your product teams, prioritise and plan effectively, and achieve consistently great outcomes.

Melissa Perri, The Secret Weapon To Finding Focus

Josh Seiden, Outcomes Over Output

Haroon Aslam, Advanced Facilitation: Using a Designer’s Toolbox to address Organizational Strategy

John Cutler, Healing The Designer/Product Manager Divide

Day 2: Research

Day Two was all about Research, an area with particular relevance in this era as we increasingly move our work online. Remote research techniques aren’t new, but now we’re reliant on them, how do we make them even better? Our speakers were on hand to share their learnings and case studies.

Leisa Reichelt, Things We Learned About Ourselves And Our Research Practice From Our Internal COVID-19 Surveys.

Kelly Goto, Fieldwork From Home

Rachel Price, You’re on the Air, I’m Listening: Facilitating Remote Research

Quote from Leisa Reichelt reading "Half of the company has no idea what the research does and how it contributes value"

Day 3: Service Design

Our third day brought together experts in Service Design who explored creating simpler experiences across fast-moving organisations and embedding behaviour change and scale service-design thinking. They shared stories from their experience as well as actionable tools and insights.

Lou Downe, Good Services: Building User-Centred Organisations At Scale

Marc Stickdorn, 20 Tips - How To Embed And Scale Service Design In Organisations

Akil Benjamin, AK Experiments

Dr Sarah Drummond, Full Stack Service Design

Day 4: Content Strategy

Day four was curated by ex-Clearleftie Rachel McConnell and was all about Content Strategy. Whether you’re a designer, team lead, product owner or content expert, if you are interested in taking your content to the next level, these talks and discussions are for you! The Content Strategy day brought together world-class content designers and strategists to show how they create impact, integrate content into the design process, and scale the role of content. It’s worth saying we were so sad not to be able to hold Content Design in 2020 (it would have been on the date we held SofaConf) and although we couldn’t bring together the brilliant line up we had in store, it was great to be able to bring these three incredible content experts together with Rachel at SofaConf.

Amy Hupe, Designing Content For Emotionally Distressed Users

Jonathon Colman, How We Destroyed Content Design

Kristina Halvorson, In conversation with Kristina Halvorson

Day 5: Interaction Design

Our fifth and final day focussed on Interaction Design. Whether you’re creating new experiences, or optimising existing ones, you’ll find great tools and insights from these talks and discussions as our speakers share their advice for problem-solving, testing, and effective design.

Ross Chapman, Remote Sprints

Simeon Wishlade, How To Lose Less In AB Testing

Richard Banfield, Organisational Underwear: How To Successfully Collaborate With Cross-Functional Teams

Lex Roman, Practicing Growth Design

Quote from Richard Banfield saying "Trust is like a bank account, you have to make small deposits"

And then some...

We shared some of our favourite talks curated from past conferences which we thought would be interesting and relevant. These included Director of User Experience Design at Google Magaret Lee’s talk from 2018 ‘Insights from a Reluctant Leader’. And Farai Madzima, UX Lead at Shopify talk from 2019 ‘Cultural Bias in Design(ers)’.

Some of our speakers across the event joined us to answer a few questions about themselves, their role and their talk topic before the event which you can read on Medium.

SofaConf wasn’t all talks, we also had social sessions, entertainment and some yoga classes from the lovely Jeff Phenix especially designed to help counteract the effects of sitting at a desk all day long. We’ve shared his two short classes, one which is designed to be done seated and the other more of a vinyasa flow class.

Finally, we have had all these films closed captioned as part of our ongoing commitment to improve the accessibility of our events.

We hope you enjoy the content from SofaConf, we are currently plotting and planning our next online event so do join our mailing list if you’d like more information.

Tiny lesson: Project Canvas Thu, 03 Sep 2020 11:19:00 +0000 Miro has changed the way we work. It seemed logical to convert our much-loved Project Canvas template from 2015 into an open-source board and share a short Tiny Lesson on how we use it.

What's a project canvas?

Being able to concisely articulate the purpose, audience, vision and goals of a project is crucial. Yet it’s harder than it sounds. Other well-known canvasses can feel too large and grandiose, or far too granular. This project canvas — like Goldilocks’ porridge — is just right. It provides key information that is summative, visible and, crucially, relational. Through open dialogue and collaboration, the canvas helps to create a shared understanding around the brief and goals of the project, aligns the entire team, exposes unknowns and assumptions and provides a strategic purpose to the project at hand.

Project Canvas Miro board
Our Project Canvas Miro board

When should I use it?

A project canvas is a great kick-off exercise, as a collaborative and remote workshop. The canvas highlights and makes visible the relationships, dependencies and intentions that are often intangible or muddy at the start of many projects.

However, the canvas shouldn’t be used once and thrown away. Using a Miro board makes it revisitable at any time. Ideally, the canvas should be updated as and when needed, with new project intel, stakeholders or if the scope changes.

Sounds good. So how do I start?

There is no linear method for using the project canvas. It is laid out in three separate altitudes that provide varying levels of strategic detail, and four pillars that address the purpose, audience, vision and goals for your project. You might want to start with the ‘known knowns’ such as the audience, stakeholders and team. Or you might want to start large and uncover the proposition and vision. It’s entirely up to you.

Here are some tips to get the most out of your project canvas:

  • Involve the widest team possible - get your team and stakeholders involved.
  • Look to uncover and unpack assumptions.
  • Use as a way to create alignment and reduce opacity, build a shared understanding.
  • Treat it as a summative, high-level view of your project at hand.
  • Show the meaning and intentions behind the project, it helps provide the bedrock for a successful outcome.

To learn more read our original blog post on canvassing a project.

Start using the Miro board here

When the going gets tough, the tough get training Mon, 17 Aug 2020 10:32:00 +0000 Just because your training budget has stopped doesn’t mean your training should. Instead of making cuts to staff training, I want to suggest some alternative and cost-effective ways to achieve similar results.

In times of economic uncertainty, one of the first things to get cut and last to get reinstated is the training budget. Upskilling staff is often perceived as an unjustifiable expense. A luxury, an extra, a perk only to be rolled out during the good times.

Yet team members who feel invested in with up-to-the-moment skills are likely to be the catalyst for the growth of your business.

Make learning a habit

Whether you are a military unit, a dance troupe, a sports team, or a rock band, training is the way to become match fit or performance-ready. For any team, the results you achieve have a direct correlation to the practice you put it.

At Clearleft we have a long-standing culture of learning. It’s one of the things that personally appealed to me before working here and has carried on since.

One of our values is ‘Learn and share. Share and learn’. This gets lived out in numerous ways:

  • We put on prestigious conferences from the recent remote SofaConf to UX London, Leading Design and dConstruct.
  • Our practitioners coach students on digital design courses, this year running sessions pre-lockdown at Ravensbourne University London and remotely at the University of Greenwich.
  • You’ll find us involved with and regularly talking at meetup groups such as Codebar, Ladies that UX and nUXers Brighton.

So what can you do when training budgets are frozen and your team are working remotely?

Here are three ideas for some cost-efficient but still effective ways to engage and upskill your digital team.

School room Photo by Nathan Dumlao on Unsplash
Photo by Nathan Dumlao on Unsplash

1. Start with a list

There’s no shortage of useful training materials online, much of which is free. More often, the challenge is narrowing down what to learn and then finding quality resources to use.

To give yourself focus, ask your team for a long list of their learning objectives. Get them to review their development plans and to plunder any bookmarks and lists of topics they have identified. Go broad and go big.

Once you have a longlist ask the team to prioritise a selection. It’s useful to get the team to think about the skills to polish up on now that will be useful to improve the quality of their upcoming work. Don’t think too far into the future.

We recently ran three remote training sessions for a global software company. The first two sessions covered product design and research techniques which had been identified as areas for training. However, we purposefully left the agenda for the third session unspecified so the participants could decide what they wanted additional coaching in. Giving the team a say was a powerful way to empower them in the development of their skills.

Armed with your list of potential training topics, start to curate the resources to use. Now, this doesn’t have to be as daunting as it might sound.

Three ways to quickly find quality content are:

  • Ask for recommendations from the team, your network and from the hive mind on social media.
  • Think about who you know who you could offer to do a reciprocal skills swop with.
  • Pay a person or company to curate a list of bespoke material for you based on your requirements.

Creating a calendar of training sessions will help your staff develop the habit of training and for you to ensure there is a variety of both topics and delivery styles.

2. Training together but apart

Going to a conference, sitting in an auditorium and listening to a speaker was as much about being part of a shared experience with the audience around you.

To (almost) replicate this remotely, set a time and place for your team to collectively watch or listen to a presentation and then discuss it afterwards. This is most effective when everyone is consuming the media at the same time and even better if the follow-on discussion or activities have some structure. Zoom, Meet, Teams are all ideal for streaming talks and collectively conversing afterwards.

As a starting point, if you want some inspiration dive into the Clearleft video archive.

On Clearleft’s Vimeo channel, you’ll find 178 videos from the conferences we organise. You’ll find amazing talks covering a vast swathe of topics from Leading Design, UX London, Patterns Day and Ampersand.

Alternatively, the audio archive from 10 years of dConstruct is an audio treasure trove of 3390 minutes of insightful thinking from the brightest minds in the digital design industry.

3. Give some training

Another idea is instead of receiving training why not give some training? Every project team I’ve worked in – both agency colleagues and client’s teams – have such untapped potential to teach something useful to their teammates.

At Clearleft we have a range of formats for sharing tips and advice.

At the end of the week wind-down, people are encouraged to show and tell project work, demo tools and share techniques that they’ve been using. It’s informal, short and requires little preparation.

Up a level from this, we regularly hold brown bags. These have continued even whilst working remotely. The format is simple. Over lunch, someone will talk through something of interest. The eclectic nature of the talks keeps the format interesting.

Some examples of sessions include project teams giving highlights of their projects, Cassie recently walked through the rebuild of her SVG animation rich website, we had clients from the Natural History Museum talk about what goes on behind the exhibition halls and a designer from OpenTable showing us their process for A/B testing.

Getting a little more formal we also do longer form training sessions within the team. These provide the opportunity for someone to provide a more considered or in-depth presentation on a topic. Recent subjects have included facilitation skills for running remote workshops, and a run through by Katie of a talk she gave on service design at Future London Academy.

The value of training

Ongoing training is vital in maintaining and developing a highly-skilled team. The rate of change in how digital products and services are delivered benefits teams who adopt a culture of continuous learning.

Training doesn’t need to be expensive to provide value to both staff and the business.

In the current climate of forced remote work, and the potentially isolating effect this can have, training offers an opportunity to bring your team together to collectively and collaboratively develop skills together.

Season one of the Clearleft podcast Thu, 13 Aug 2020 14:38:00 +0000 The Clearleft Podcast has finished its inaugural season.

I have to say, I’m pretty darned pleased with the results. It was equal parts fun and hard work.

Episode One

Design Systems. This was a deliberately brief episode that just skims the surface of all that design systems have to offer. It is almost certainly a theme that I’ll revisit in a later episode, or even a whole season.

The main goal of this episode was to get some answers to the questions:

  1. What is a design system exactly? and
  2. What’s a design system good for?

I’m not sure if I got answers or just more questions, but that’s no bad thing.

Episode Two

Service Design. This is the classic topic for this season—an investigation into a phrase that you’ve almost certainly heard of, but might not understand completely. Or maybe that’s just me. In any case, I think that coming at this topic from a viewpoint of relative ignorance is quite a benefit: I have no fear of looking stupid for asking basic questions.

Episode Three

Wildlife Photographer Of The Year. A case study. This one was a lot of fun to put together.

It also really drove home to just how talented and hard-working my colleagues at Clearleft are. I just kept thinking, “Damn! This is some great work!

Episode Four

Design Ops. Again, a classic example of me asking the dumb questions. What is this “design ops” thing I’ve heard of? Where’d it come from?

My favourite bit of feedback was “Thanks to the podcast, I now know what DesignOps is. I now also hate DesignOps”

I couldn’t resist upping the ante into a bit of a meta-discussion about whether we benefit or not from the introduction of new phrases like this into our work.

Episode Five

Design Maturity. This could’ve been quite a dry topic but I think that Aarron made it really engaging. Maybe the samples from Bladerunner and Thunderbirds helped too.

This episode finished with a call to action …with the wrong URL. Doh! It should’ve been

Episode Six

Design Sprints. I like how the structure of this one turned out. I felt like we tackled quite a few angles in less than 25 minutes.

That’s a good one to wrap up this season, I reckon.

If you’re interested in the behind-the-scenes work that went into each episode, I’ve been blogging about each one:

  1. Design Systems
  2. Service Design
  3. Wildlife Photographer Of The Year
  4. Design Ops
  5. Design Maturity
  6. Design Sprints

I’m already excited about doing a second season …though I’m going to enjoy a little break from podcasting for a little bit.

As I say at the end of most episodes, if you’ve got any feedback to offer on the podcast, send me an email at

And if you’ve enjoyed the Clearleft podcast—or a particular episode—please share it far and wide.

This was originally published on my own site.

Using your status as a speaker to promote others Thu, 13 Aug 2020 11:59:00 +0000 Being invited to speak at a conference is a privilege, and we can use that privilege in a number of ways.

For newer speakers, the most obvious benefit of speaking is to advance your career. Speaking at an event confers a certain amount of legitimacy and status. The fact that you’re on stage and other people are listening to you implies that you’re somebody who deserves to be listened to. That your ideas hold value that the other people in the audience will benefit from them. This is a great thing to have in your back pocket at interviews, and is sure to impress the person doing the interviewing.

Speaking at a conference also helps raise the status of the company you work for, which is why so many companies are keen to encourage their staff to speak. If you say smart things, the audience will naturally ascribe those thoughts to both you and the company you work for. They’ll think “company X hires really smart people” or “I like the way folks from company X think”. This leads to tonnes of ancillary benefits for the company like finding new customers, attracting new talent, and generally raising the brand even further.

If you come from a recognisable brand, this works the other way around as well. While folks may not have heard of you, they may have heard of the company you represent. This will create a bit of a halo effect around you as a speaker, and confer some of the company’s brand value on to you. “I like the work company X does, this person is from company X, so I’ll probably like them and their work too”. In truth, this is often the way new speakers break into the speaking circuit—by utilising the value of their employers brand.

New speakers (as well as more experienced ones) also get to benefit from the connections they make—especially with other speakers. They may also get exposed to new job offers from employers in the audience who were impressed with their spiel. As such, there’s a lot of very good reasons why individuals can benefit from this sort of exposure.

Of course it’s not all about the person speaking.

The very best speakers will usually have something important they want to say. Something they feel really strongly about, and wish to share with their peers in order to make their lives better. Maybe they’ve just come up with a clever technique that makes folks’ lives easier and want to share it with as many people as possible? Maybe they’ve seen people making the same mistakes over and over again that’s easily avoidable if they just do this one small trick? Or maybe they’ve been the brunt of some sort of challenge or injustice and are looking to highlight these problems and drive a deeper systemic change. Whatever their motivators, making a platform is a powerful thing, and something not to be squandered.

As a result of the Black Lives Matter movement, a lot of experienced speakers are looking for ways to do more with their privilege; to use the power, connections and opportunities they’ve been given to raise others up. One simple way to do this is to pepper your talks with references and quotes by peers from under represented groups. I’ve seen this done a number of times and it can be super effective.

However the more obvious solution is to step aside and recommend speakers from underrepresented groups who could take your place. This is a wonderful, altruistic thing to do. To offer up your place to somebody else who you know would value it more than you. This approach works, but maybe not as often as it should. Unless the people we recommend get picked, we haven’t made any significant change; we’ve just made ourselves feel good. Fortunately there are a few small, simple things we can do to improve our hitrate here.

The first thing to do is to understand why the conference organiser has reached out to you in the first place. Was it because of a specialism you hold, a talk you’ve done in the past, or a project you worked on; or was it simply down to the company you work for and the position you hold?

Many conference organisers—especially smaller ones— may simply be looking for a speaker from a well-known brand to help them sell tickets. In this case, it’s really easy to suggest an alternate speaker. You simply say something along the lines of “Unfortunately I’m not available but my colleague X would love to speak”. If you’re lucky, that’s all you need to do.

However, these pesky conference organisers probably want to make sure that the person you’re recommending is actually a good speaker and not just a report who mentioned wanting to do more public speaking in their last evaluation. As such it’s usually a good idea to send a link to a recent talk from that person, rather than just a list of names. If it comes with a personal recommendation, even better. Something like “I’m afraid I’m not available but I saw X do an amazing talk at Y recently. I think they’d be perfect for your event, so would you like an intro?”

Sometimes conference organisers aren’t just looking for any old speaker—amazing I know. Sometimes they’re looking for somebody with a specific angle to talk about a specific topic. In these instances, it’s helpful to understand what role the organisers were wanting you to fill, and recommend a speaker you know can do similar. “I’m afraid that I can’t make this event, but I saw X give a really good talk on the same subject as me at Y recently, and I was really impressed. In fact, I was thinking of using some of their ideas in my next talk. Want me to make an intro?”

From a conference organisers perspective, this is probably the perfect recommendation. You’ve had personal recommendations from somebody you trust. They’ve seen the person speak, can vouch for them, and have shared a link to see for yourself. They’ve even said that they’ve been so inspired by that person that they’re going to use some of their ideas in future talks themselves. This person is somebody I definitely want to speak to.

This is great, but what if the people you want to recommend aren’t as established as you?

Maybe they haven’t even spoken before. You have an inkling that they’ll be good, but you don’t really know.

If you have somebody on your team who wants to speak at a conference, before giving up your seat and thrusting them into the limelight—or under the bus—it may be worth investing a little more time in their development. Consider spending some time in your one-to-ones to pull out the topics they’d like to speak about. I can’t tell you the number of times I’ve had folks tell me they’d like to speak at one of our events, but then have no clue what they’d speak about (TOP TIP: “Oh, whatever you want me to speak about” isn’t a good answer). Once they’ve got some ideas starting to develop, help them write a talk description, help them put together an outline, help them write a first draft and give them feedback. Find opportunities inside the company for them to speak first, and try and record their sessions if you can. Many a great talk started life as an internal brown-bag session, got honed at community meet-ups, and only then found its place on a conference stage.

You see, developing one of your team as a new speaker is more than just throwing out their names in an email. It’s about investing in that person and helping to transfer some of the skills that have made you such a good speaker over to them.

Another great way to develop new speakers is to suggest that you do a joint talk. The conference still gets to have you on the bill for all the reasons they reached out in the first place, but now they get a second amazing speaker as a result. You get to confer some of your legiticancy on them, and they’re going to learn a tonne about being a great speaker from you in the process. This effectively takes ALL—or at least most—of the risk away form the conference organiser, while using your platform to raise somebody else up. As such it’s a win-win for everybody involved.

This works especially well if the conference is looking for you to talk about a specific project. Sure you may have overseen the project—and claimed much of the Kudos from that Medium article you wrote about it a few months ago—but you know that your team put the hard work in. So suggesting a joint talk where you frame the project, and then have your colleague jump into the details, can work really nicely. In fact I know several well established speakers who started their speaking careers in this way. Very soon they’d eclipsed the person that got them on stage in the first place, and had developed their own stand-alone speaking career.

It’s often harder if the people you’re recommending don’t work for you. However it’s worth thinking about why exactly you’re recommending them. Maybe you haven’t seen them speak, but you read a really smart article they wrote a few months ago. Or maybe you’re aware of the work they did on a specific project. Any background you can give about why you’re suggesting them as a potential alternative is better than a list of unqualified names. If you’re unable to confer a sense of equivalence to the conference organiser—that you’re confident that the person you’re recommending would do an equally good job as you—the chance of that person being selected is fairly slim. So the more evidence you can supply to underpin your recommendations the better.