Clearleft | Blog The latest news from Clearleft en-gb Fri, 24 Jan 2020 16:14:58 +0000 Fri, 24 Jan 2020 16:14:58 +0000 Web standards, dictionaries, and design systems Thu, 23 Jan 2020 19:50:46 +0000 I’ve noticed a trend. It all starts with web standards.

Years ago, the world of web standards was split. Two groups—the W3C and the WHATWG—were working on the next iteration of HTML. They had different ideas about the nature of standardisation.

Broadly speaking, the W3C followed a specification-first approach. Figure out what should be implemented first and foremost. From this perspective, specs can be seen as blueprints for browsers to work from.

The WHATWG, by contrast, were implementation led. The way they saw it, there was no point specifying something if browsers weren’t going to implement it. Instead, specs are there to document existing behaviour in browsers.

I’m over-generalising somewhat in my descriptions there, but the point is that there was an ideological difference of opinion around what standards bodies should do.

This always reminded me of a similar ideological conflict when it comes to language usage.

Language prescriptivists attempt to define rules about what’s right or right or wrong in a language. Rules like “never end a sentence with a preposition.” Prescriptivists are generally fighting a losing battle and spend most of their time bemoaning the decline of their language because people aren’t following the rules.

Language descriptivists work the exact opposite way. They see their job as documenting existing language usage instead of defining it. Lexicographers—like Merriam-Webster or the Oxford English Dictionary—receive complaints from angry prescriptivists when dictionaries document usage like “literally” meaning “figuratively”.

Dictionaries are descriptive, not prescriptive.

I’ve seen the prescriptive/descriptive divide somewhere else too. I’ve seen it in the world of design systems.

Jordan Moore talks about intentional and emergent design systems:

There appears to be two competing approaches in designing design systems.

An intentional design system. The flavour and framework may vary, but the approach generally consists of: design system first → design/build solutions.

An emergent design system. This approach is much closer to the user needs end of the scale by beginning with creative solutions before deriving patterns and systems (i.e the system emerges from real, coded scenarios).

An intentional design system is prescriptive. An emergent design system is descriptive.

I think we can learn from the worlds of web standards and dictionaries here. A prescriptive approach might give you a beautiful design system, but if it doesn’t reflect the actual product, it’s fiction. A descriptive approach might give a design system with imperfections and annoying flaws, but at least it will be accurate.

I think it’s more important for a design system to be accurate than beautiful.

As Matthew Ström says, you should start with the design system you already have:

Instead of drawing a whole new set of components, start with the components you already have in production. Document them meticulously. Create a single source of truth for design, warts and all.

This was originally published on my own site.

Exploring DesignOps Thu, 23 Jan 2020 10:32:00 +0000 Late last year we hosted our second Design Leadership Breakfast, with two panels debating in front of 70 design leads.

While the first panel dived into the role of research and the rise of ResearchOps, the second panel shifted into DesignOps, with candid input from Samantha Fanning (Head of Digital, University College London), Dan Saffer (Product Design Lead, Twitter), Daniel Souza (Design Operations, Babylon Health) and Andy Budd (Clearleft).

Four panellists and Jeremy comparing in front of a blue screen

What is DesignOps?

We first started talking about DesignOps back in 2017, and since then the function has evolved and matured. At Twitter, Dan sees it as ‘the religion and rituals around design practice which support design’. Similarly Andy Budd often refers to Dave Malouf’s excellent analogy:

DesignOps are the grease, rails, and engine that make design’s processes, methods, and craft as valuable as possible.

Dave Malouf

For more traditional companies like UCL, centralising some of the ‘less fun’ processes has cultivated a belief that designers are freed up to do the ‘more interesting stuff’. At rapidly-scaling companies such as Babylon Health, DesignOps has transitioned from a buzz word into the very core of what they do. As Daniel put it, ‘…organisations at scale have many different people working in different ways, across different design teams, DesignOps at Babylon

  • enable visibility
  • enable workflows
  • support design, content, research and branding teams to design at scale with clarity.’

It was interesting how DesignOps is now its own stream of onboarding at Babylon, with DesignOps tailored to each discipline alongside the company and team onboarding. This has ensured new team members start working with a clear understanding of standards, their design system, and cultural processes like how to join and participate in design critiques.

According to Andy ‘…as teams scale, things slow down. A lot of things that design leaders hate doing emerged. The need to create a role to own things like performance reviews, onboarding and recruiting became clear. Without a DesignOps function, 80% of their work was becoming recruitment.’


Globally distributed teams result in even more complexity. With people in various offices, there is a high level of noise. The challenge is trying to maintain the cohesion. At Babylon, DesignOps delivered more mental space and freed more available time to allow for deeper innovation.

How embedded is DesignOps?

Embedding DesignOps doesn’t happen overnight. UCL introduced a DesignOps mindset via training, by paying for everyone to have whatever research/UX/design training they need. For UCL it’s not about forcing people into that role but to increase understanding and respect of the processes across the business.

For digital-first companies like Twitter where research, design and developers sit together in teams. The product team lead/manager remains responsible for collaboration needs between teams, whereas the DesignOps function is focused on the individual and organisational needs (such as design systems). For Babylon, their design system has been a practical way of delivering the value of having DesignOps in the first place. This has not only helped them make sure the right resources and energy are in place but has also played a role in building a community around it.

Are we really there yet?

One thing that has become clear through our work and events at Clearleft: there are constant improvements to be made. It’s not about the destination, it’s about the journey.

Looking at our engineering partners, we can learn a lot from the VPs and CTOs in tech who’ve implemented successful DevOps functions. We can strive to apply their learnings to the growing DesignOps movement within the teams of our clients.

Ironically, the design industry itself has created a few blockers to DesignOps. Twenty years ago design was craft-based, operating at a human-scale and through emotion. We’ve since industrialised it as a way to scale design for the sake of conversion and KPIs. The processes and outcomes allow us to take small 1 or 2-pizza teams and turn them into high-functioning design outfits without sacrificing quality or consistency.

However, are we de-skilling people through the desire to scale? Are we creating a sense of learned helplessness? Are we forcing a senior designer — working in an optimised and systemised environment due to DesignOps — to no longer worry about divergent, problem-solving? Do they now focus only on their ability to ship? Is DesignOps effectively neutralising a designer’s skillset?

A message often shared at our Leading Design events and retreats: design leaders have felt like they’ve hit a glass ceiling. All the power they thought design once had has now been lost to the VP of Marketing, or Product, where design increasingly becomes a delivery function. At Twitter, Dan found that Product has a lot of power, and Product and design often wrestle around the overall product vision (traditionally called design strategy). Who controls what, who defines the problem space, and who plots the direction of travel is often a source of contention.

The benefit of DesignOps

DesignOps allow us to take away all of the administrative, operations-based work designers find themselves doing, and systematising it. It allows them to focus more on the actual design part of what they do. It’s about getting as much value out of the design team and designers as possible while minimising waste and maximising scale, consistency and efficiency.

If you’d like to discuss how we could help you scale design get in touch.

You can sign up to find out about our next Design Leadership Breakfast panel here

11 things I know to be true Thu, 02 Jan 2020 16:49:00 +0000 Here are some things I’ve come to believe over the years…

1. You are not your user

Stop designing for yourself. Understanding what your users need and communicating that around the organisation is super important.

However research doesn’t tell you what to do, so don’t rely on it too heavily. Otherwise you can get stuck down rabbit holes and paralysis sets in. So focus on getting just enough research to inform decision making.

(By the way, I’m aware that “user” is a contentious term, so have mostly used it here for the sake of brevity. Feel free to substitute it with whatever term you feel most comfortable with.)

2. It’s often easier to break big problems down into smaller problems

This is one of the benefits of the agile process.

However if you break things down too much, you lose the big picture view and entropy sets in. As such, you need to think both big and small.

3. Sometimes you need to slow down to speed up

However we can also spent a lot of time over analysing problems that are intellectually unanswerable, so other times it’s better to think by making and learn by shipping.

Knowing which approach to take when is tricky, and most people tend to default to one or the other.

4. Design can provide a huge amount of value to business

However designers often take this for granted and get frustrated when business people who have been extremely successful without worrying about design, don’t immediately drink the cool aid.

The most effective designers become advocates for design, form alliances, and pick their battles sensibly. However they also realise it’s impossible to change hearts and minds overnight, so are in it for the long haul.

5. Designers and technologists need to stop seeing themselves as separate from “the business”

However it’s bloody hard to do. Especially if you feel unsupported and marginalised by your company.

6. The key role in any design or technology team is the lead role

They set the standards others follow, act as coaches and role models to juniors, while having the trust and ability to influence business stakeholders.

However leads are all to often hired into management positions, and get sucked into an endless round of recruitment, budgeting, and planning meetings. They stop being effective role models, the team atrophies and attrition and dissension starts to rise.

7. Everybody is largely trying to do the right thing

However when your right thing gets blocked by somebody else’s right thing, you almost always end up writing that person off as difficult or ignorant.

Rather than trying to convince the other person of your opinion, it’s better to understand their opinion, get agreement on the problem you’re trying to solve, and find a middle path.

This is one of the reasons why working with people is hard, why decisions take so long, and why the results are often mediocre.

8. It's better to design the right thing than design the thing right

As designers we often get stuck down rabbit holes that nobody actually cares about, and end up producing a beautifully designed and engineered product that nobody wants.

9. It’s easier to sell a well designed product than a poorly designed one

As such, more of the money you were going to spend on marketing should be diverted into design.

In short, marketing should support product. Not the other way around.

Much as I believe this to be true, history is littered with the corpses of well-designed products that failed to capture the attention of the market, while there are plenty of crappy products out there that have gained huge success because of superior marketing.

10. Product management is the hardest job in tech

You have all the responsibility but none of the power. Everybody thinks they know better than you. It’s impossible to satisfy everybody. When things go well somebody else will get the credit. When things go wrong, you’ll get the blame (even if you flagged it up from the start).

11. The reason most projects go wrong is because of a lack of shared understanding from the outset

Everybody sitting around the table has a picture in their heads of what they want. They think its the same picture that the person sitting next to them have, but it’s not.

The ability to visualise thoughts, beliefs, concepts and decisions is a super power. It gets everybody on the same page, or at least highlights where things unexpectedly diverge. It also prevents people from hiding behind ambiguity.

How to move fast without breaking things Thu, 02 Jan 2020 09:45:00 +0000 Over the last few years, I’ve worked on various product teams at different levels of velocity, but I’ve noticed that moving quickly is not the same as moving effectively.

Effective teams don’t just get things done — they also know why they’re doing things, and how what they’re doing feeds into a longer-term vision.

Rachel's sketch of two superheroes
Product superheroes aren’t born, they’re made

Effective teams are flexible, they can pivot when they need to. And finally, effective teams realise that each of them has a specific role to play.

Here are eight things I think contribute to creating a fast, effective product team:

1. Creating strategy together

One of the best product managers I’ve worked with understood that to get the team invested in the product strategy and vision, they had to be part of creating it. We collectively created a ‘North Star’ for the product, and each quarter we would — together — look at our business targets, then explore what opportunities we had to improve the product experience to achieve those goals. This meant our backlog was shaped and defined by the team. We also had the opportunity to add things to the backlog that maybe weren’t contributing towards our immediate goals, but that we thought would get us towards our North star. These could be picked up from the backlog when we had time in between the more business-critical items.

Understanding how our work directly contributed to business goals meant we all knew the purpose of our work, and kept us fully aligned.

2. Collaborating

Anyone who’s worked in a full multi-disciplinary team will appreciate how much more efficient you become when you have the right skills in place. It’s really hard doing things outside your area of expertise, so if for example, a designer has to also think about the copy, it’s going to take them a lot longer to get the job done. Enabling equal collaboration and leveraging different skills not only makes the team super-effective, but it also makes team members feel their contribution is valuable and gives them confidence.

Confidence is essential for a team to push forward innovative ideas and take considered risks.

Rachel's sketch of a team climbing a mountain

3. Having a stepped process

Effective teams understand that it’s virtually impossible to go from zero to hero overnight. Sustainable and effective change is a gradual process. It might sound counter-intuitive to speed to evolve something slowly rather than completely renovate it, but it’s often the small incremental changes that add up to a big overall impact.

In the process of making small optimisation tweaks on one part of a product, you’re also learning a lot that will feed into the bigger innovation projects or new features. The team that works most efficiently works on a combination of small changes they can learn from, and more strategic, bigger projects which they can enter into with the confidence of learning from the small things.

4. Making things measurable

Having a purpose is important, but it’s just as important to track progress against targets.

The teams I’ve worked on who regularly see how they’re tracking against their goals are the ones that keep up momentum.

Making goals and current results visible in a place where the team meets regularly is one way to make sure everyone’s engaged. It’s also really helpful for individuals to be able to go into monthly review meetings with a clear idea of how they’re contributing to the company’s targets. The shared accountability of targets means that everyone has the power to make an impact, and everyone can share the success when things are going well.

A sketch showing a person and team in front of a chart

5. Testing and learning

Running A/B tests and split tests is one of the easiest ways to test an isolated change such as copy or visual design. It’s also a great way to test a hypothesis before you commit to bigger changes.

Teams that don’t have the ability to test can run up against opposition to changes they suggest because there’s no way to justify the effort and resources needed to make the change. This leads to frustration within the team and resentment, which always slows down velocity.

When small tests can be run, it enables teams to put a value against a change, which can then be used to estimate the incremental impact of rolling out the change permanently. This may only give a quantitative view of changes, but when teams have the opportunity to test, they feel much more empowered to come up with solutions.

It’s also true that a team who have clear recommendations based on user research need to be given the space to iterate accordingly. If research has shown something to be a suboptimal solution, then any user-centred design team worth their salt will want to make sure they can amend it. Leaving enough time for iteration after research is vital for a team to feel confident in their solution. This can be hard to do when you have engineers itching to build, but I’ve found that the most effective teams get their design team running two or three sprints ahead of the build team for this very reason.

6. Knowing when day two is

Nothing is more demotivating to a team than the expression ‘Let’s look at that in day two’ when they know that day two will never come. Shipping an MVP is one thing, but taking away the ability to iterate is super-frustrating.

Effective teams accept that they might need to postpone some things until after launch, but they have a backlog of prioritised items ready to go just as soon as they can. Of course, all backlogs are subject to change and refinement, particularly if there are teething problems or more urgent bugs that need fixing. But it’s helpful to set a ‘day two’ date, or a target date to get the first round of iterations made by, even if it’s more of a window than a deadline.

Allowing a team to see there’s a future vision for the product and that their ideas haven’t been parked indefinitely is really important if you want the team to feel enthusiastic, motivated and inspired.

7. Shipping regularly

Designing but never shipping is really demoralising for a team. This can happen for many reasons in businesses, but it really damages productivity and morale. Nothing makes a team drag their feet more than the lack of a deadline. It’s also heartbreaking to invest time and effort into something which then sits on a Jira ticket or in a forgotten file for the rest of time.

For this reason, it’s not a good idea to get the design team out too far ahead of development. When designs happen too far in advance they can get put on a development backlog then superceded by other things.

Finding a balance between longer-term strategic work and short term tactical changes is hard, but also one of the reasons why allowing testing is so important. Tests may seem small, but just the fact you’re putting changes live can be enough to keep a team motivated and moving at pace.

Sketch of three people having a retro using post its on a wall

8. Acting on regular retros

As with testing and learning, retros allow you to get feedback and make small calibrations to your team’s ways of working. Effective product team leaders create psychological safety for team members to speak their minds in retros and really say what is or isn’t working. They then actually assign actions to the team (or themselves) to make the necessary changes.

The teams that regularly feedback, listen, and take steps to make things better, are the ones which over time will move from storming and norming, to performing. And top-performing teams are those which create brilliant work together.

This post was originally published on Rachel’s Medium.

Feel better - don't go it alone Mon, 16 Dec 2019 14:10:00 +0000 “A problem shared is a problem halved” - an old adage we’ve probably all heard from at least one elderly relative, and probably at a time when it was the last thing you wanted to hear.

But it turns out there might just be some truth behind Great Aunt Nell’s words of wisdom - according to research by Age UK, nearly a fifth of UK adults have something constantly playing on their mind, with over half the population shouldering several worries a day, and nearly another fifth carrying around more than 10 worries at any one time.

As a nation of worriers, perhaps these figures don’t come as a great revelation, but with the top topics of concern being finance, health, age and the stress of work - basically something for everyone - it seems worth considering just what improvements we can all make in order to help ourselves out a little.

Personally I have always found I shared my problems easily (thanks Mum), and when it comes to work I’ve never been shy of saying what I think (thanks Dad). But over the last few months I’ve had several experiences (penny-drop moments even) that have helped me put into context what has been a somewhat challenging professional year for me.

Penny-drop no.1

Rewind to the end of last summer and I found myself in a bit of a position of professional isolation - even though I had peers and a great team around me, I often felt out on a limb, doubting, facing problems that it seemed no one else could see, or that hadn’t been there previously. At the time I wasn’t really sure what was going on - “is it just me?” - and even though I’m a confident person, my professional confidence seemed to be taking a hit.

Add to that multiple responsibilities - people, clients, a whole host of other things - and my ‘problems’ seemed compounded. It was well-timed coincidence then that at the end of the summer I found myself on a bus with a group of wide-eyed attendees winding through the majestic Norwegian fjords to Clearleft’s Design Leadership retreat in the mountains.

Now in the interest of brevity and out of respect for all those present, I’m skipping over the retreat itself here, apart from to say that it’s no surprise that taking time away from our day-to-day emails, meetings and routines in a setting that begged relaxation and reflection would yield positive mental outcomes. However what I didn’t expect was the revelation that in fact I wasn’t as ‘alone’ as I’d thought - it turns out that everyone on the retreat had similar (in some cases almost identical) professional concerns as me. Through the process of sharing these with each other it also became clear that we all had a lot of the ‘answers’ to these concerns - we’d just needed to hear someone else say it to believe it.


When people share their worries with others, it can have a positive impact on their situation - of the 3 in 10 adults that regularly share their worries, over a third claim to feel brighter and more positive as a result, with others reporting feelings of relief and even the disappearance of their problems. For me this couldn’t have been more true - the net result of sharing with others was a vastly increased sense of personal professional confidence - knowing that others in similar roles with more experience than me shared my worries made a big impact, and helped me step back a little and see the (Norwegian) wood for the trees.

Penny-drop no. 2

Fast-forward from snowy September in Norway to rainy November in London, and I found myself in the audience once again at Clearleft’s stellar Leading Design conference. I won’t spend the time here extolling the conference’s virtues, but what I will say is that in my recently refreshed professional mindset I started picking up on lots of moments in which speakers, attendees and peers were openly sharing - “I thought it was just me”, “recently, there was this thing”, “oh, that happens for you too?”.

Get a room full of like-minded professionals with similar experiences together and this kind of conversation is inevitable - indeed it’s one of the many side-benefits of conferences and meet ups - however, the step change for me was acknowledging the importance and frequency of those conversations and realising that there’s a lot more shared concern out there than I (we) all might have thought.

Time for reflection

I’ve started to try and notice these opportunities more and more, and have been making an effort to share (and be shared with) as much as possible. Now I’m not suggesting that by running off to hills to cleanse ourselves in nature whilst outpouring all our worldly worries we’ll solve all our professional troubles (what happens in Norway stays in Norway, right?!), but I am saying that you could do a lot worse for yourself than taking a little time to reflect, connect with others in a similar position to you, and notice the conversations that you’re having.

You never know, you might just find that ol’ Nell was right after all. And what was it that she said about a ‘fortifying sherry’? It is the season after all…

Our next Leading Design retreat is specifically for women (and those identifying as such) is in the Cotswolds, and applications are open now.

Learnings from a design internship Fri, 13 Dec 2019 12:21:00 +0000 15 weeks have flown by here at Clearleft. You can see the concept we designed at our website

We’ve loved this project and it’s been everything an internship should be: fun, rewarding and challenging in equal measures. We have appreciated the privilege of driving a project with a high degree of autonomy but with the essential support and input from experienced designers and researchers.

In this final blog from us we wanted to share our main takeaways:

A worried well patient sitting on the sofa looking at her phone. A screen showing the self treat interface
A still from our Self treat concept video

We learned to turn challenge into opportunity

During our research phase we ensured a good diversity of research. Uncovering conflicting research, which we initially saw as a challenge, showed us a problem that needed solving, and with the help of a fellow Clearleft designer this led to our dashboard concept to help bridge gaps in understanding between two groups of stakeholders.

It taught us the importance of always being curious to get underneath what people are saying; after all, they’re human, and subject to the same bias’ and behaviors anyone is. UX Design is all about questioning to get to the closest place of truth and designing from there.

We became a bit more comfortable with not being comfortable

The design process is fraught with unknowns. Again, making sense of a large set of problems left us in the period of the unknown for a long time. It’s perhaps a natural human desire to seek certainty, but we learned to relax a little more in the uncertainty and trust the process. To do that we had to use the design approach to guide us, and use the UX methods to help us. At points we questioned how we could add value and be impactful in a short period, conscious of lots of factors around feasibility and innovation. Ultimately though we kept moving forward, and we ended up with a service that we believe in.

Collaboration strengthens design

We’ve been working in a studio full of talented UX designers, researchers, visual designers. Whenever we were unsure of something, at a design milestone or simply felt a chat would be useful we reached out and used the experience of others to give a different perspective. This is something we will continue to seek in our future roles as it was, without fail, incredibly insightful.

We also really appreciated the team dynamic throughout the internship. We all come from different backgrounds and we have different ways of working but we realised how our methods complement one another.

Language is crucial to user experience

Healthcare is a fascinating, important area for technology to impact and we were excited to work in this space. We also appreciated more and more throughout our research that designing in this space has a greater depth and breadth of human emotion to consider. It’s also perhaps the industry that carries the most risk - getting it wrong can be literally fatal. Language is even more important, and safetynetting and considering edge cases were crucial.

Don’t spend too much time in early stage research

Our biggest takeaway was not to spend too much time in research. Keen to feel like we were making sufficiently informed choices, it took us five weeks to narrow into our focal topic before further research to go deeper into this. The weight of the ‘right decision’ weighed fairly heavily, but on reflection we knew intuitively almost in week one what we did in week five. We also learned that it’s easy to stay safe in the secondary research. It’s hard having conversations with users in a large problem space but we now know to talk to people sooner, even in the uncertainty.

Speaking to user’s earlier, and not staying ‘too wide’ for too long would have given us a longer design phase to concept test with more people, develop the prototype and conduct usability testing.

Holly and Lacin sat at the kitchen table with laptops

We’re looking forward to our next projects, taking with us the knowledge that every challenge is an opportunity, discomfort is normal, we should seek input at every opportunity, language is crucial, and most important of all, speaking to users early in any project is central to true user-centred design.

You can read about the project at

Leading Design London 2019 talks Mon, 09 Dec 2019 15:43:00 +0000 We’re excited to share the talks from Leading Design London 2019.

Our Leading Design conference is a unique opportunity for design leaders from across the globe to come together, learn, be inspired and connect with their peers. Held at the beautiful (and brutalist) Barbican Centre, the talks range from Design Ops, self-evaluation, diversity and much more. We hope you enjoy watching them as much as we did.

Once again a huge thank you to all of our amazing speakers, you make this conference what it is.

Andy Budd on stage at Leading Design

Day 1 Talks

Day 2 Talks

A man and two women at Leading design London in the Barbican conservatory
Basil: Secret Santa as a Service Mon, 09 Dec 2019 09:00:00 +0000 I recently launched, a ‘Secret Santa as a service’.

Basil has two modes. The first is a traditional list generator, letting you shuffle the participants and print off a nice, foldable list of names. The second is a little more involved, but considerably more exciting! A ‘head elf’ from your company can sign up and enter all participant names into the system. Basil will email everyone, letting them know who their giftee is.

But that’s only the beginning. We’ve all been there; you start in a new company and you get assigned the one person you’ve never spoken to. This is where Basil steps in. In each email, there’s a unique link that, when clicked, anonymously emails the giftee, asking for a little nudge in the right direction. They can respond, all without knowing who has asked for help! Basil-based encryption!

The home page

The legend of ‘Basil’ started many moons ago at Clearleft, when Kate Bulpitt discovered the mysterious elvish hero. Kate *ahem* Basil organised the whole affair, emailing each person in the team; acting as the encryption go-between. This worked great, but meant that individual knew all the Secret Santarers. It sounded to me like an opportunity for tech!

To be honest, it’s a bit of a silly side project, but there’s always ample opportunity for learning on websites like this. With no client restraints or budgets to consider, a side project is a great opportunity to try out new technologies and push ones design chops.

The stack

Vue.js is my go-to framework. When set up with Nuxt.js, I find it really quick and empowering to build in. Rather than spin up a Node.js server, I opted to use the generate mode, and host the site on Netlify. It gives me CDN hosting and a great devops experience with zero configuration.

The database & backend layer was an interesting choice, and where I focused my learning efforts. I opted for an avant-garde option of Airtable + Netlify Functions. Airtable is a lovechild of a spreadsheet and a database. The columns are typed, and the rows can be linked, so it’s possible to run it as a relational database. It has a very sensible API (and incredible live API docs). I used Airtable for our signature generator, but rather than use the HTTP REST API, this time I went for the npm module. Another learning opportunity.

The module still uses callbacks, so there was a bit of ‘promisification’ required to get it work nicely with async/await.

exports.updateElf = (rowId, payload = {}) => {
  return new Promise((resolve, reject) => {
    base('Elves').update(rowId, payload, function(err) {
      err ? reject(Errors.Generic) : resolve();

Netlify Functions are ‘serverless lambda functions’ that run as individual backends. When called, they spin up and make calls to the Airtable database. All API authentication is handled with environment variables stored on Netlify, so when developed with Netlify Dev, all your security is handled for you.

Emails were handled by Mailgun. The biggest hurdle was getting the first email to send. Their documentation doesn’t currently mention a different API URL for EU domains. As soon as I found this stackoverflow answer, I was away.

Classic form POSTs

Rather than use AJAX and JSON requests as is the usual approach in this decade, I ended up going old school and use form POSTs and redirects for the data exchange. This meant I could start from a base of solid HTML, without worrying about requests from JavaScript. It might not be quite as seamless having full page refreshes, but given most users will only see one form in the whole flow, it doesn’t harm the experience.

Deciding when to add complexity, and when to hold back, is another skill that’s worth honing. So regularly do we reach for the shiny tool, when the slightly dusty one will do just fine. Even in modern tools, like Vue.js, there’s still plenty of power in the humble <form> and 302 redirect.


I'm not a designer, but I do love Christmas

With those credentials out the way, I decided to have a crack at designing this site. Creative Market was my biggest friend on this project. There are so many über talented individuals on that platform. As soon as I stumbled upon these creatures, I fell in love.

The colour scheme and typography had to be suitably festive for such a project. Zeichen, and DM Sans provided a nice mix of conversational ‘basil tone’ and readable prose. A contrasting scheme of pink and dark blue, combined with lashings of noise, and topped with some wonderful snowflakes (created by Cassie), let to a suitably seasonable creation.

The initial design direction was decided in Sketch, but I quickly moved to the browser to roll it out. Working in Vue.js components, I was able to swiftly build out the various form-based pages with great ease.

Error codes

Deciding on an error structure is easily overlooked. As this project used redirects, rather than JSON responses, it was important to establish a format that could be interpreted by the frontend.

I came up with an ‘enum’ of possible error codes and shared it between the front- and backend. If the serverless function ever caught an error, it redirected the user to /error/${ErrorCode}/ where Nuxt rendered the appropriate message to the user. This was also an opportunity to play around with Basil’s tone of voice.

  'TokenExpired': 'My dearest elf, it\'s time to log in again',
  'AlreadyContacted': 'Have patience, child. You\'ve already contacted that elf!',
  'FarTooMany': 'Humble apologies, you\'ve hit your elvish quota!'

Planning for 'appropriate scale'

Basil was never going to take over the internet, but there was a chance a few others may like to use it. Rather than build it just for our internal use at Clearleft, I made sure the schema was set up to allow multiple groups to use the system. This did mean the added complication of putting in an authentication system, but that in itself was an opportunity to build a password-less authentication flow for the first time.

There was no need to prepare for greater scale than that. I think we’ve all been burned in the past worrying about whether the stack will cope with X users, with no basis for whether any users will arrive. More and more, I’m realising that building for myself, keeping in mind not to be exclusionary, nor paint myself into a corner, is the best bet for web things.

Give it a go!

If you’re in the market for a Secret Santa generator, managed or otherwise, please feel free to give Basil a whirl!

Visit Basil

This was originally posted on my own site

Which content expert do you need? Tue, 03 Dec 2019 00:00:00 +0000 As digital disciplines mature, it’s normal for them to fragment as practitioners begin to specialise.

There is often overlap between areas, but it’s hard to find someone who is genuinely excellent at everything. When you look at how quickly the digital landscape is growing and evolving, it creates space (and a need) for people to specialise. This has been happening with content roles for a while.

But how do you know who you need? It’s one thing to know you need a content expert, but an expert in what? If you try to create hybrid roles, it can result in even more job titles being created which confuses the market. And if you recruit one type of content specialist when actually you need another, you may end up finding skill-gaps in your team. The same goes when appointing an agency.

To help ease some of the confusion around content roles, I’ve created a quick quiz. It’s just a guide – of course, it can’t account for every possible scenario. But it should give you a general indication of what kind of content expert you need. Enjoy!

Which content expert do you need?

5 Steps To Better Research Fri, 29 Nov 2019 12:00:00 +0000 Time and again, decisions made during a research project come back to haunt us. Square up to the usual suspects and take 5 steps toward delivering better research.

We deliver better research when we:

  • Have conversations early
  • Let the experts do the recruitment
  • Check the calendar
  • Use a balanced ratio of research and analysis
  • Share the journey

Have conversations early

Shaping a research study properly is crucial for good results. Early conversations draw out learning objectives, assumptions, recruitment criteria and potential methods. Involving researchers in these discussions help to develop a solid project foundation and save time later on. Agency researchers benefit by receiving early indications of a client’s research maturity and helps frame future conversations and identify where the best value lies for the client. In-house researchers benefit by providing the inside knowledge of recent and related studies that can offer existing actionable insight, helping to avoid repeated studies at the cost to the organisation.

For both, there is an opportunity to start refining the research goals from day zero so there are no surprises or sudden u-turns at the project kickoff. Likewise, getting an early understanding of the research audience sets us up for a head-start on recruitment.

Let the experts do the recruitment

Recruitment is difficult and time consuming. Although it offers an opportunity to start learning from our audience from day one, the reality is that practitioners seldom have the time. Recruitment is often overlooked and under-resourced as an activity which ultimately impacts the project as a whole.

This underestimation of effort also exists when clients take on recruitment, remarking “I never thought it would be this difficult!” after exhausting their entire panel in the first week with little to no progress. This is not due to a lack of effort on their part, rather the complexity and success ratio that goes with the territory.

Actionable insights hinge on a careful selection of pre-screened and representative sample of incentivised participants. When we cut corners or “just make do” the resulting drop in quality is embarrassingly obvious. Garbage in, garbage out.

Recruitment is a job, unless there is a dedicated role in-house or have the privilege of extra resources, bring in a trusted professional.

Check the calendar

When the research is conducted can occasionally have an undesired and negative impact on results. Each sector has its own peaks and troughs of activity. For instance, the travel sector trading period peaks over Christmas and new year. During this time the stakes are high and there is little room for experimentation. Higher education institutions almost completely shut down over the summer holidays making it difficult to gain access with stakeholders and students.

It’s also worth considering whether other calendar dates might impact participants behaviour. For example, grocery shopping behaviours will differ over bank holidays and other seasonal dates. Likewise, family behaviours will be different over term time and school holidays.

These key dates are often overlooked or not discussed as part of early conversations, whenever planning research activities, it’s always worth asking “why are we specifically conducting the study during this period?” “what might impact our research during this period?”.

Use a balanced ratio of research and analysis

Rich insight comes from spending quality time with the research observations we collect. When the ratio of research collection to analysis is out of balance we compromise on the quality of the outputs. At the very least, we should follow a 1:1 ratio. For every hour we spend talking to participants, spend the same amount of time with our observations.

When it comes to recall our memories are fallible. As time passes we remember events less accurately and become more susceptible to our own biases. This is problematic when we schedule long, concurrent days of research with little time or opportunity to gather thoughts and discuss observations. Shortening the time between research and analysis and introducing activities for sense-making helps us to maintain the integrity of our insights and avoid bias creep.

Share the journey

There’s no doubt that research is a team sport and the value it creates through collaboration. Involving teams across different departments and areas of the business increases awareness and encourages discussions. Together we break down siloed structures within organisations.

Encouraging a broad range of team members across the business to attend research sessions is a step toward creating internal research evangelists. Session attendees invariably find value in what they observe and bring this enthusiasm back into the business. Not only does this encourage cross functional collaboration and the dissemination of customer insight but, more importantly, amplifies the volume of the customer voice and drives the shift toward a true customer centric culture.

This was originally posted on my own website.

Mental models Thu, 21 Nov 2019 12:00:51 +0000 I’ve found that the older I get, the less I care about looking stupid. This is remarkably freeing. I no longer have any hesitancy about raising my hand in a meeting to ask “What’s that acronym you just mentioned?”

This sometimes has the added benefit of clarifying something for others in the room who might have been to shy to ask.

I remember a few years back being really confused about npm. Fortunately, someone who was working at npm at the time came to Brighton for FFConf, so I asked them to explain it to me.

As I understood it, npm was intended to be used for managing packages of code for Node. Wasn’t it actually called “Node Package Manager” at one point, or did I imagine that?

Anyway, the mental model I had of npm was: npm is to Node as PEAR is to PHP. A central repository of open source code projects that you could easily add to your codebase …for your server-side code.

But then I saw people talking about using npm to manage client-side JavaScript. That really confused me. That’s why I was asking for clarification.

It turns out that my confusion was somewhat warranted. The npm project had indeed started life as a repo for server-side code but had since expanded to encompass client-side code too.

I understand how it happened, but it confirmed a worrying trend I had noticed. Developers were writing front-end code as though it were back-end code.

On the one hand, that makes total sense when you consider that the code is literally in the same programming language: JavaScript.

On the other hand, it makes no sense at all! If your code’s run-time is on the server, then the size of the codebase doesn’t matter that much. Whether it’s hundreds or thousands of lines of code, the execution happens more or less independentally of the network. But that’s not how front-end development works. Every byte matters. The more code you write that needs to be executed on the user’s device, the worse the experience is for that user. You need to limit how much you’re using the network. That means leaning on what the browser gives you by default (that’s your run-time environment) and keeping your code as lean as possible.

Dave echoes my concerns in his end-of-the-year piece called The Kind of Development I Like:

I now think about npm and wonder if it’s somewhat responsible for some of the pain points of modern web development today. Fact is, npm is a server-side technology that we’ve co-opted on the client and I think we’re feeling those repercussions in the browser.

Writing back-end and writing front-end code require very different approaches, in my opinion. But those differences have been erased in “modern” JavaScript.

The Unix Philosophy encourages us to write small micro libraries that do one thing and do it well. The Node.js Ecosystem did this in spades. This works great on the server where importing a small file has a very small cost. On the client, however, this has enormous costs.

In a funny way, this situation reminds me of something I saw happening over twenty years ago. Print designers were starting to do web design. They had a wealth of experience and knowledge around colour theory, typography, hierarchy and contrast. That was all very valuable to bring to the world of the web. But the web also has fundamental differences to print design. In print, you can use as many typefaces as you want, whereas on the web, to this day, you need to be judicious in the range of fonts you use. But in print, you might have to limit your colour palette for cost reasons (depending on the printing process), whereas on the web, colours are basically free. And then there’s the biggest difference of all: working within known dimensions of a fixed page in print compared to working within the unknowable dimensions of flexible viewports on the web.

Fast forward to today and we’ve got a lot of Computer Science graduates moving into front-end development. They’re bringing with them a treasure trove of experience in writing robust scalable code. But web browsers aren’t like web servers. If your back-end code is getting so big that it’s starting to run noticably slowly, you can throw more computing power at it by scaling up your server. That’s not an option on the front-end where you don’t really have one run-time environment—your end users have their own run-time environment with its own constraints around computing power and network connectivity.

That’s a very, very challenging world to get your head around. The safer option is to stick to the mental model you’re familiar with, whether you’re a print designer or a Computer Science graduate. But that does a disservice to end users who are relying on you to deliver a good experience on the World Wide Web.

This was originally posted on my own site.

Becoming medical experts in the world of design Wed, 20 Nov 2019 09:45:00 +0000 In our last blog we shared how we moved from concepts to our chosen design problem. Here we want to bring you up to speed on our design process.

Now that we’re deep in the design phase of this project, storyboarding is becoming incredibly helpful. Not only does it help us build empathy for different groups of patients suffering an illness, but it also identifies the different pain points and opportunities in peoples’ experiences. It’s amazing what simple sketching can do to uncover things you hadn’t thought of. We’ve been sketching everyone from ‘stoic men’ who have a tendency to avoid self-care, all the way to our ‘worried well’ who need that extra reassurance. With the extensive medical terminology, diagnosis and treatment information we’re gathering along the way we’re considering ourselves quite the medical experts in the world of design right now.

storyboarding intern project

Throughout designing we wanted to be mindful of the barriers to self-care. The main ones include:

  • Anxiety and belief that the severity and duration are beyond normal
  • Past experiences of prescription for minor ailments deemed confirmation of the need for medical intervention in any future illness
  • Lack of sufficient knowledge and skills to implement self-care
  • Lack of attention to self-care

To do this we flipped the various barriers into opportunities, framed as ‘How Might We’ statements. In essence we stepped down a level into more granular framing of the problem. You can read more about ‘How Might We’s’ in one of our blogs here.

We began ideation at a high level, imagining different self-care structures, via design studios that we shared with you in our previous blog. With our focus on the exciting opportunity to empower people to “self-prescribe” and access more personalised self-care advice we diverged our imagination again – how could we best design for that? With the backdrop of storyboards showing us where points of intervention were needed we sketched, and sketched some more. As we were sketching, we focused on the users’ needs in each square of the storyboard and came up with solutions to address those needs. Some of these were larger concepts, others appeared to be features, but it gave us a lot to work with.

Our extensive set of How Might We's

We seemed to be aligned in what ideas should be set aside for now. At this point we started to see the connection between the more compelling ‘mini-ideas’ and the formation of a user journey that addresses a range of problems and opportunities for our different personas. Fleshing this out on Post-its meant we could easily shift things around or cut what we later felt was unnecessary. As always, we sourced feedback from Clearlefties, this time to ‘sense-check’ the wider service as well as give a different eye to the detail. A conversation with one of our developers helped clarify technical constraints and options for delivery. As a result we decided that our concept will be in the form of a progressive web app.

Beginning to form a basic user journey

Although we’re designing a digital solution, it has non-digital interfaces and integration that makes it somewhat service-like. We’re now guerilla testing the concept whilst considering the content and copy of the screens. Although good user experience always relies on an almost pedantic consideration of copy, designing in the health space perhaps depends on this even more. It means on top of the brand voice, clarity, instilling trust and other content considerations, we need language that reassures, and keeps people 100% safe. We’re enjoying the challenge!

You can follow us on twitter @clearleftintern for regular updates on the project.

Tiny Lesson: Sketching, the timeless design tool Mon, 18 Nov 2019 00:00:00 +0000 I’ve been working in design for 15 years and I’ve relied and honed one flexible thinking tool my whole career. One that is almost barrier-less and one that’s speed is so incredibly powerful.

That tool is sketching.

Anyone that has worked with me for any amount of time will know that I literally draw as I think and am likely to leave little tracing of my thinking in the form of doodles all over the place. I might say not always ideal in a paperless corporate culture or a tidy polished agency environment!

I don’t just sketch interfaces, I sketch strategy frameworks, concept models, storyboards and random diagrams. I live sketch too in workshops, which is probably more of expert skill, but one that’s extremely valuable alignment tool in a workshop environment. Sketching has simply become my way of thinking.

Over the years, many people have asked me to give them sketching tips and to be honest I’ve always put it to the back of my priority list as I’ve almost seen it as not the most valuable part. The challenging part I’ve always thought is working out what to sketch in the first place. On reflection, I wonder if I’m wrong. I’ve done it so much, it comes so naturally now that I find it very difficult to work without a pen and a piece of paper. Like everything, it takes a degree of confidence to put pen to paper and certainly in full view of others.


Recently I was asked whilst working at a client’s office to provide a sketching workshop and this time I accepted. So these were my top tips:

Use good pens

I consider a trip to a stationary shop a real treat and the array of pens on offer is immense, without meaning to you can easily spend a fortune. My favourite pen though is actually not one of the fancy ones it’s a trusty Paper-Mate Fineliners. I discovered it in an agency 3 jobs ago and it’s made the stationary cupboard of every agency I’ve been at ever since (and now Clearleft). A good pen, not too thin and not too thick, makes a massive difference when sketching.

Use colour strategically

Before you start a sketch consider how you are going to use colour and be consistent with it. Typically my main sketch is in black pen, I use a red pen for linking arrows and then a reserve a colour for the title and notes and then a different colour for questions.

Use highlighters to lift the edges

As well as good drawing pens consider buying a grey shadowing pen to lift the sketch. I typically use Tombow Dual Brush to add a sort of drop shadow to the edge of the sketch and key elements within it. You’ll be amazed what difference it makes.

Sketching out a system
Using sketching to illustrate a platform's system during a kick-off workshop

Start messy and then draw a neat version

In the case that you want to use a sketch to communicate an idea. I’d just drawing a neat version after some messier doodles.

Practice readable writing - write in uppercase

My natural handwriting is very messy and I always wondered at school how on earth examiners would be able to read it. Over the years though I’ve developed a neat uppercase writing style that I use for more sketches.

Scan and tidy up in photoshop

If I am adding my sketches to a deck I always use photoshop to clean them up a bit. Sometimes scanning can add little marks that look messy and also occasionally I add colour to key buttons to lift them.

Doodle of a user group or persona from a workshop
Using sketching to illustrate user groups during as client workshop

We find sketching can be an incredible ‘unblocker’ when it comes to designing a complicated system or service, as well as getting stakeholder buy-in. We’d love to hear how you use sketching on Twitter.

Professional Development Framework: Roles Thu, 14 Nov 2019 10:55:00 +0000 It’s been 7 months since we publicly released our professional development framework. In that time we’ve received lots of helpful feedback from the design community in terms of how it’s been useful, how it could evolve, and where we want to take it next.

From supporting individuals and teams working with our framework directly to inspiring design leaders to create their own professional development frameworks using ours as a starting point, we’ve been humbled by how helpful people have found it so far, and energised by the potential to do so much more with it.


We were also fairly surprised by how extensively the framework has been shared and put into action. What we published was very much in an Alpha state, missing some essential context of how to use it, and some nice data visualisation artefacts that help to make it more practical to use, both of which we were aware would limit its effectiveness.

Nonetheless, we’re happy to be able to elaborate further on the framework by demonstrating how it can be used to define specific roles and their career path(s) in relation to some role archetypes relevant to us: UX Designer, Product Designer and Design Researcher.

We’re also pleased to announce our Professional Development Framework is now available on Progression at, which elaborates further on these role specifications and their respective primary career paths.

Framework principles

As we touched upon on the initial release, there are a few critical principles behind our framework:

Measure what matters
Define an appropriate level of specificity, that neither overwhelms or abstracts what’s important.

Shape behaviour
“What gets measured gets done”, so only measure what you want to influence.

Exemplify values
Soft skills, attitudes and behaviours, such as collaboration and empathy, are equally important, if not moreso, than hard skills.

Be role agnostic
Support an approach to professional development that can scale and flex to multiple roles, initially within digital but potentially beyond.

Open the conversation
The quantification of professional development into numbers is meaningless without the conversation framing it (as Jason Mesut also alluded to in his talk at Leading Design London this year.)

A professional development framework is the starting point for a dialogue between people. It is a means to an end, rather than the end itself.

© Hayden Slaughter

Defining a role

Defining a role should hopefully be as simple and obvious as it sounds:

Step 1. Shortlist the prerequisite skills
The framework currently contains 20 skills. Not all skills are relevant to measure on every role, so a useful starting point is to filter out the things that aren’t essential to the role, or shortlist the ones that are.

Step 2. Benchmark the proficiency
When you’ve decided on the skills to measure, the next step is to decide on the proficiency level required of each skill for the role.

Step 3. Plot the career path(s)
As a general rule, aim for a tiering that allows skills to ‘level up’ logically as the seniority of the career path for that role evolves. This isn’t necessarily always relevant however, given that the Mastery level of each skill can be extremely hard to accomplish, and skill focus areas can naturally change based on seniority (see example below).

Step 4. Ensure roles complement each other
No discipline exists in a silo, and your framework should ensure roles when combined together provide a set of skills that is greater than the sum of the parts.

Example: The UX Designer Role

Here’s a practical example of how we’ve put this into action at Clearleft…

At Clearleft we use a set of 9 skills intrinsic to our values which we feel are important to measure in all roles at the company. These are:


  • Collaboration
  • Presentation
  • Feedback

Problem solving

  • Initiative
  • Methodology
  • Planning


  • Relationships
  • Support
  • Human-centricity

That’s already a fair few skills to measure, so we’re very conscious not to overwhelm this list with an unwieldy number of additional things to measure.

For our junior and midweight UX roles, as an example, we measure around 12 skills in total. This grows to 15+ skills for senior roles. These additional discipline-specific skills in UX are:

  • Architecture
  • Validation
  • Exploration
  • Craft

It’s worth stating what may already be obvious here, in that the framework categorisations of Core skills, Strategy, Design, Leadership, and Operations are not necessarily analogous with roles. A role can comprise of skills from multiple categories.

Also of note is that at Clearleft, around three quarters of what we measure is based on the same foundational behaviours, the remaining 25% on roles-specific hard skills. Maybe that feels like a disproportionate split but Clearleft’s collective values and collaborative, consultative and open design approach is intrinsic to our way of working and continued success as a design studio, moreso than any discipline-specific hard skills, hence this focus.

At Clearleft we have three simple tiers of Junior, Midweight and Senior to most roles. This generally maps nicely to the Novice, Intermediate and Expert proficiency levels in the framework, but as already mentioned, it isn’t always the case that skills follow this obvious progression, or that the tiers for the skill are relevant to the seniority of the role.

As a demonstration, our midweight UX Designer role skills shift considerably when levelling up to UX Strategists.

e.g. UX Career Path - from midweight to senior

Example: The Design Team

A common team shape at Clearleft might be a UX, Designer and Researcher, which would provide the following complementary skills mix for our clients.

e.g. 3 person design & research team

Another probably even more common team might be a UX Strategist and Product Designer, which would still create a strong mix of complementary skills. It’s also worth bearing in mind that all our UX Strategists have already accumulated the skills of our midweight UX Designers, such as intermediate-level Validation skills, so there is more depth than may be initially obvious looking at a single role description alone.

e.g. 2 person strategic design team

You can therefore see how we shape different teams, for different clients, based on the needs of each specific project and the skills we measure within the individuals in our team.

Next up from our professional development framework will be some visualisation tools that help you benchmark the individuals in your team against the roles you have defined, and start to understand where they’d like to go next.

Get in touch if you’d like us to help apply it to your company.

Microfrontends with Vue.js Wed, 13 Nov 2019 11:30:00 +0000 We’ve recently been building a complex search integration for a holiday provider using a microfrontends approach in Vue.js.

I’ve noted in the past, that there’s a common trap many fall into with frontend frameworks:

Not all of your app/site needs to be controlled by JavaScript. When you dive into the framework pool, the natural, and most documented step is to write it all in the framework.

This site uses a traditional server-rendered stack, so we began from a position of great markup, and added layers of functionality. Instead of using Vue CLI to spin up a new Vue website, we opted to import Vue into the existing JS pipeline - a Gulp build system provided by the client. It meant losing some of the HMR benefits that come from a well-tuned Webpack setup, but it was definitely the most appropriate and comfortable option to fit for the client.

That’s one of the fun parts of agency-life, each project is a case of finding the balance between user needs, client appropriateness, and developer appetite.


The site needed to render components for various features on the results page:

  1. Search panel
  2. Search results & pagination
  3. Search filters
  4. Search sorting

And a different set on the details page:

  1. Search panel
  2. Holiday details
  3. Edit holiday details
  4. Holiday pricing

Choosing an approach

Option 1

Write isolated Vue instances that read data from localStorage & the URL, and work independently.

There was some definite initial appetite for this choice. Truly encapsulated components is the utopian dream, but it has a major downside: code duplication. If each component is working in isolation, they all have to do a lot of similar grunt work (reading URLs, catching errors, responding to APIs).

Option 2

Use a single Vue instance wrapper and use portal-vue to push the components into the correct parts of the non-Vue DOM

The client had previous experience with portal-vue, so this seemed like a sensible route. But for our use-case, portal-vue simply acted as an unnecessary abstraction around Vue’s default instance mounting logic. Sharing a Vue instance would also mean prop-drilling and event bubbling galore. Not fun.

Option 3

Write a Vue instance per feature, mount them to various DOM nodes, and link them all together with a Vuex store.

Vue already has a ‘portal’ system out of the box: the .mount() function. This, combined with Vue’s ability to automatically inject the store dependency into all child components, makes this option extremely powerful. Every feature of the website is its own distinct Vue application, but with the option to hook into global data if required.

The code

Here’s how we instantiated the various Vue applications:

import Vue from 'vue';
import SearchPanel from './components/SearchPanel/SearchPanel.vue';
import SearchResults from './components/SearchResults/SearchResults.vue';
import Feefo from './components/Reviews/Feefo.vue';
import store from './store';

store.dispatch('init', storeDefaults);

const vueRoots = [
    id: 'search-panel',
    component: SearchPanel,
    id: 'search-results',
    component: SearchResults,
    id: 'reviews-box',
    component: Feefo

vueRoots.forEach(({ id, store, component }) => {
  if (document.getElementById(id)) {
    new Vue({
      render: h => h(component)

After importing our top-level components, we instantiate the store, passing in any default state (driven by server-rendered JSON). This backbone of data includes items like API endpoints and feature flags.

Next we have a list of all the Vue instances we wish to load. It’s here where we pass in the reference to the store for the components that require it. In the example above, the Feefo component doesn’t need access to the store, so it doesn’t get lumbered with it.

Finally, we loop around the objects and check whether the mounting node is on the current page. Vue will still instantiate a component, even if element isn’t available. While this can be helpful, it’s not the desired effect for this site.

Accessing data

The beauty of this approach over option two, is the way Vue injects the store as a property of this in all child components & mixins.

Reading global data is so clean:

export default {
  computed: {
    hasResults() {
      return !!this.$store.state.results.length;

Writing data is a little more involved. Due to the actions/mutations pattern in Vuex, we can’t write directly to this.$store.state properties.

One approach I tend to lean towards is a generic state updater mutation, which works for most use-cases:

const mutations = {
  updateState(state, payload) {
    const payloads = !Array.isArray(payload) ? [payload] : payload;

    for (const { key, value } of payloads) {
      state[key] = Array.isArray(value) ? [...value] : value;

Writing to global state is then achieved with the following call:

this.$store.commit('updateState', {
  key: 'stateKey',
  value: 'new-value'

// Multiple value update
this.$store.commit('updateState', [
    key: 'stateKey',
    value: 'new-value'
    key: 'aDifferentStateKey',
    value: 'another-value'

Vuex helpers

Store state is generally read in with computed properties, but it can be cumbersome writing this.$store.state.key if you’re pulling in a lot of data. Vuex comes with some handy helper methods out of the box for this very purpose.

import { mapState } from 'vuex';

export default {
  computed: {

    hasResults() {
      return !!this.results.length;

mapGetters, mapActions and mapMutations work in the same way, and go a long way towards cleaning up your code.

Microfrontends benefits

The biggest win from this approach came when we realised that the ‘Edit holiday details’ component really should be working against the same dataset as the ‘Search panel’. Had they been written as isolated components; reading data in from the URL and working independently, it would’ve been a nightmare to unpick. This approach made is very straightforward to conform the two components retrospectively.

This approach doesn’t give you the ability to communicate directly between components, but that’s broadly seen as a feature, not a bug. Firing events out and receiving data in is a scalable component design paradigm. Components, where possible, should be a reflection of state, not stateful.

We’re used to the idea of systematic design, and component-based thinking, but this frontend infrastructure modularity feels like an interesting space. There’s certainly more to be explored when it comes to bundle sizes, dynamic imports, and working with multiple stores/modules, but on the back of this project, it feels like a very viable approach to adding a bit of framework spice to a server-rendered site.

Preact & Unistore does a great job of injecting different dependencies into a component if you’re on the other side of the JS fence! I’ve written about that previously here.

This was originally posted on my own site

FF Conf 2019 Mon, 11 Nov 2019 15:42:31 +0000 A report from Brighton’s unmissable annual front-end gathering.

Friday was FF Conf day here in Brighton. This was the eleventh(!) time that Remy and Julie have put on the event. It was, as ever, excellent.

It’s a conference that ticks all the boxes for me. For starters, it’s a single-track event. The more I attend conferences, the more convinced I am that multi-track events are a terrible waste of time for attendees (and a financially bad model for organisers). I know that sounds like a sweeping broad generalisation, but ask me about it next time we meet and I’ll go into more detail. For now, I just want to talk about this mercifully single-track conference.

FF Conf has built up a rock-solid reputation over the years. I think that’s down to how Remy curates it. He thinks about what he wants to know and learn more about, and then thinks about who to invite to speak on those topics. So every year is like a snapshot of Remy’s brain. By happy coincidence, a snapshot of Remy’s brain right now looks a lot like my own.

You could tell that Remy had grouped the talks together in themes. There was a performance-themed chunk right after lunch. There was a people-themed chunk in the morning. There was a creative-coding chunk at the end of the day. Nice work, DJ.

I think it was quite telling what wasn’t on the line-up. There were no talks about specific libraries or frameworks. For me, that was a blessed relief. The only technology-specific talk was Alice’s excellent talk on Git—a tool that’s useful no matter what you’re coding.

One of the reasons why I enjoyed the framework-free nature of the day is that most talks—and conferences—that revolve around libraries and frameworks are invariably focused on the developer experience. Think about it: next time you’re watching a talk about a framework or library, ask yourself how it impacts user experience.

At FF Conf, the focus was firmly on people. In the case of Laura’s barnstorming presentation, those people are end users (I’m constantly impressed by how calm and measured Laura remains even when talking about blood-boilingly bad behaviour from the tech industry). In the case of Amina’s talk, the people are junior developers. And for Sharon’s presentation, the people are everyone.

One of the most useful talks of the day was from Anna who took us on a guided tour of dev tools to identify performance improvements. I found it inspiring in a very literal sense—if I had my laptop with me, I think I would’ve opened it up there and then and started tinkering with my websites.

Harry also talked about performance, but at Remy’s request, it was more business focused. Specifically, it was focused on Harry’s consultancy business. I think this would’ve been the perfect talk for more of an “industry” event, whereas FF Conf is very much a community event: Harry’s semi-serious jibes about keeping his performance secrets under wraps didn’t quite match the generous tone of the rest of the line-up.

The final two talks from Charlotte and Suz were a perfect double whammy.

When I saw Charlotte speak at Material in Iceland last year, I wrote this aside in my blog post summary:

(Oh, and Remy, when you start to put together the line-up for next year’s FF Conf, be sure to check out Charlotte Dann—her talk at Material was the perfect mix of code and creativity.)

I don’t think I can take credit for Charlotte being on the line-up, but I will take credit for saying she’d be the perfect fit.

And then Suz Hinton closed out the conference with this rallying cry that resonated perfectly with Laura’s talk:

Less mass-produced surveillance bullshit and more Harry Potter magic (please)!

I think that rallying cry could apply equally well to conferences, and I think FF Conf is a good example of that ethos in action.

This was originally posted on my own site.

Developing Concepts Mon, 04 Nov 2019 18:15:34 +0000 A few weeks ago we shared our work in defining the problem space and moving to design. In this week’s blog we’re showing you that our design process hasn’t been a linear process and we’ve been both completing researching and developing concepts in parallel with each other.

Expanding research

We made the considered decision to focus our work on helping better prevent and self treat minor illness to avoid the use of GP time for these. But we soon realised we wanted to build a richer connection to people’s experiences and we could do this in parallel with beginning to consider solutions at a conceptual, high level.

GP reception staff at our pilot surgery had already painted us a picture of their daily challenges via interviews. We were fortunate to expand on this by shadowing their day, over two days, to gauge the demands of patients first hand and how they serve these. We were struck by the opportunities for operational efficiencies to manage more routine or administrative needs and that a drive to digitally enable patients was missing, something we suspect is common given the pressures on receptionists as it stands. It was also interesting to hear the variation in how people are triaged, which showed the personalised approach the reception team are proud to give.

Initial concept sketches and affinity map of interview insights

There is a significant body of research quantifying the problem of GP use for minor conditions but we wanted to go deeper into why people see GPs for minor ailments and when and why people use other sources of support. We ran a survey to answer these questions. It told us that people generally access GPs when they feel symptoms have been going on too long, are concerned it’s more serious, and they want reassurance, even when symptoms were not severe. It showed us people are not consistent with self-care practices and interestingly only 20% of respondents were “ideal” self carers. In depth interviews unveiled that people tend not to receive self-care advice from GPs and pharmacists and online information is a source of anxiety and greater GP use, not something that helped avoid it.

Coming up with concepts

As we deepened our research we began concept ideation to design for self-care. How could we increase self-care and thereby reduce use of GPs? A sketching workshop and informal discussion with the design team at Clearleft generated many post-it note concepts, everything from wider community wellness, self-care kits, NHS footprinting and appointment tiering, to name a few. The idea at this stage was to think big and sketch fast.

Armed with post-its, sharpies and sketching icebreakers we took the design process to Henfield Medical Centre. We wanted to ensure any ideas of experienced staff were given a voice. It also ensured the pool of ideas was as diverse as possible and we felt it was helpful in creating a partnership approach in the project.

Designing with the Henfield Medical Centre team

An intern team design studio gave us the space to individually generate ideas and share these. The research we ran alongside the ideation process identified other important opportunities so we included these problem areas in our sketches. A second sketching round allowed for the collective pool of ideas to be turned on their head, combined, and moulded into new forms. Having completed this we aggregated all the fantastic ideas and whittled these down to the most exciting concepts.

Using a workshop with Clearleft allowing for voting and open discussion, we narrowed our concepts down to three key ones, two on the patient side and one on staff side:

  • Integrated self-care: Currently self-care provision in GP surgeries is inconsistent and outdated and surgery staff don’t signpost people to self-care. This concept is about designing for integrated, engaging and more personalized self-care support into the NHS primary care journey
  • Self-prescribing: Although many people want to self-care, applying this to daily lives isn’t easy. Self-prescription would empower people to prevent and self-treat conditions using their daily routines and practices.
  • Reception Insights dashboard: Front lines teams at Henfield Medical centre don’t have any insight into the trend in demands coming to the surgery. This means operational inefficiencies are not known and more interestingly, the changing medical demands not visible. This concept would empower staff to address inefficiencies and deliver targeted, more real-time community health improvements.
Concept Gallery

Empowering self-care

Using the insights from conversations with the team, Dr Sheppard and our own analysis we’re beginning to design how self-care can be better supported in daily lives. We’re excited to start developing this into something more tangible using our personas and storyboards.

You can follow us on twitter @clearleftintern for regular updates on the project.

Design Effectiveness Report 2019 Mon, 04 Nov 2019 12:00:00 +0000 We surveyed designers from hundreds of organisations to uncover three factors that impact design effectiveness.

Earlier this year we surveyed over 400 designers working in many different sectors and locations around the world. Our aim was to investigate the current state of design and to determine under what conditions design could be most successful.

Get the report

Take a look at the design effectiveness report

We’ll be running the survey again early in 2020. If you would like to participate or be notified when the results are out, please drop us your details:

Increasing design impact

Like any investment or operational cost, design needs to be having an impact on the goals of the organisation. We concentrated our data analysis on what organisational and day-to-day practices are most likely to be in place in companies where design was said to have ‘contributed to an increase in sales, competitiveness, and/or brand loyalty’.

The data indicates there are three key factors to increasing design effectiveness. All three ring true here at Clearleft. We’d love to hear your thoughts on if, and how, these factors are nurtured in your organisation. We will be repeating this survey every year to track changes.

1. Empowered by management

The highest performing design teams are those which are empowered by executive management to identify and pursue unplanned or unrequested ideas.

Over half of design teams have the freedom to iterate solutions rather than be expected to get a perfect solution first time. This is incredibly important in maturing your design function, and why autonomy is a core part of life at Clearleft.

However, less than half of the respondents work by developing hypotheses and experiments to test ideas and solutions, showing a gap in structure to enable this freedom.

2. The right environment

Creating a physical environment that supports collaborative design activities is another essential factor present in 9/10 organisations where design is making an impact. Spaces that break down siloes and enable dissemination of ideas and process are not to be underestimated.

This means nurturing an environment where all disciplines can collaborate closely throughout the design and development processes, and giving all employees a good sense of customers and their needs.

While it’s encouraging that design impact can be improved by making simple environmental changes, it’s worth keeping in mind that while a collaborative workplace is important, the empowerment of design teams by executive management to pursue unplanned ideas is vital to design impact.

3. The importance of doing research

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

Companies with the most effective design functions have integrated research and design teams. They are set up with research and design distributed throughout the organisation. The work of those disciplines is shared with the rest of the employees so that research and design become fundamental to the decision making and strategy of the organisation. It’s easy to see why and how this is beneficial to the business results as a whole, and perhaps why we’re seeing the increasing rise of Research ops.

Attendees of our Design Leadership Breakfast getting an early look at the report

What’s next?

We hope you enjoyed the insights we gleaned from this survey. By downloading the report you should gain some ideas about what your company can do to improve the effectiveness and impact of its design teams. drop us your details to be a part of the 2020 survey.

If you’d like to discuss the report on the phone or in person, or share insights from your own company email us at

Connect your content for better products and services Mon, 21 Oct 2019 09:15:00 +0000 Whether you’re a content strategist, service designer, or work in customer experience, you need to know how content connects across your business.

Understanding the content that finds its way to the customer, or informs how you communicate to customers, is vital to understanding the experience you’re providing across all interactions customers have with your brand.

Here’s an example matrix showing the types of internal and external content. You may not have considered how much internal content you have that informs what a customer sees or hears. The quality of your internal content can impact your customer’s experience just as much as the content they see or hear directly.

Example of content across an organisation

Improve your products

Content experts are often left out of the product development process. When product naming conventions or feature names are defined, they often stick, and unfortunately, this means something that started out as an internal name or company jargon finds its way onto the website or app and then doesn’t resonate with customers. Involving content experts in this process means you’re always thinking about how the product or feature will be perceived in its final implementation and using the language of the end-users.

Provide better customer conversations

Other areas with neglected content are internal tools and call scripts. The systems and call guides that staff use inform the conversations they have with customers. Involving content experts in the development or optimisation of tools and processes can have a hugely positive impact on the service provided. Spotting opportunities to improve scripts or content in the UI of internal tools shouldn’t be left to chance — content designers are just as valuable on your internal-facing content.

Check your feedback loop

One way to make your own content stronger is to make sure the right people see user-generated content. This could be social media comments about service, live chat conversations or customer complaints. If digital content teams never know why people are phoning up because they’re stuck onsite, or customer service teams never get to find out what customers are complaining about on Twitter, then how can they improve? Sharing the qualitative insights that sit behind the more commonly used data such as NPS scores can be much more useful and actionable than the scores themselves.

Insight teams need to be connected to content providers and regularly sharing.

Connecting your content

It’s rare that a central content team would create all the content shown in this example matrix. It’s much more likely that content creators sit in pockets of the business, such as marketing, UX teams, customer experience, brand or customer comms.

One way to better connect these teams is to think about content in terms of customer lifecycle, rather than by channel, and ensure that all the people responsible for each stage are connected, and talking to each other regularly. This way they can ensure their content and messaging is consistent.

There are techniques the teams can use together, for example, journey mapping, which will help identify all the content elements and how they hang together, and identify any opportunities for improvement.

Setting up content steering groups or holding regular content sharing sessions for all creators across the business are also both great ways to ensure alignment. But ideally, alignment should start at the top, with a joined-up strategy.

Make it strategically-driven

All content should be underpinned by a shared set of values, principles, voice, and terminology. For customers to trust a brand, they need to see or hear consistent and well-crafted content — any dip in quality or break inconsistency will erode this trust.

The best way to achieve this it to have an overarching content strategy. Not only is it key to business success, it will also give your teams direction and provide the frameworks they need to make their content creation efficient and effective.

Who should steer the ship?

To achieve connected content across an entire organisation you’ll need someone to map out the architecture, spot opportunities and highlight pain points. You’ll then need to establish guidelines, create and agree workflows, create shared lexicons, and all of the operational elements that allow teams to do their day-to-day work more effectively. This work can be done by senior content strategists, but to fully embed this across the business you’ll need sponsorship and endorsement from the top down.

Even companies with Chief Content Officers aren’t focusing enough on their internal content problems — they tend to focus on the customer-facing content as people in these roles often come from marketing backgrounds. Perhaps this will change as service design thinking gains traction.

In the meantime, content teams will rely on the advocacy of senior digital or customer experience leaders who fully understand the importance of content.

There’s also often a disconnect between traditional content (editorial and marketing) and product teams. For a business to grow its content maturity it will need to recognise that content lives on the inside and the outside of a business. And far from being invisible to customers, it’s often the back-end content that can have a detrimental effect on the experience with a brand.

Follow us on Twitter to join the conversation and share your take on the topic.

This post was originally published on Medium

Are you designing a product or a service? Fri, 18 Oct 2019 10:09:00 +0000 Traditionally, the distinction between a product and a service was relatively clear.

While a product is a tangible thing that can be measured and counted, a service is less concrete and is the outcome of using skills and expertise to satisfy a need. However, the digital space has certainly blurred the lines between products and services, so it’s no longer sufficient to define a product as something you can “drop on your foot” (The Economist, 2010) In fact, it’s actually quite difficult to explain the difference without getting tied up in quite complex linguistic knots!

In the digital space we talk a lot about products; many organisations have Product teams with Product Owners supported by Product Designers working towards their product strategy by progressing through their product backlog. There is a lot of debate about what makes a good product and how to deliver them, but what about the services that underpin them?


So how do you determine if you are working on a product or a service? We created an interactive tool to help you do just that…

Are you designing a product or is it really a service flow chart

This model highlights that although you might be positioning yourself as working on a digital product more often than not it’s a vehicle for service provision. Afterall, people only want a product because it gives them an experience and an outcome.

The model also highlights that in some cases the entire service is embodied in a digital product, think of the likes of Netflix, Uber or Spotify. In these cases, there is a massive opportunity for ‘Product Teams’ to influence the entire service experience, thinking not only of the end-to-end customer journey but also the front-stage and back-stage workings. This would involve exploring not only the customer interactions but also the operating model, the content workflow/approvals, the business model and even down to the governance structures.

So my advice, therefore, is to recognise when your product embodies a service and push your remit to explore the entire design challenge.

Defining the problem Tue, 15 Oct 2019 09:32:00 +0000 We’re 7 weeks into our three-month internship program and lots has happened. Once again we want to share the techniques and path we’ve taken to reach the double diamond midpoint.

In our last blog we talked about our interviews with GPs, nurses and front line staff, and the use of How Might We’s to frame the design opportunities in four key problem areas. These challenges are experienced by Henfield Medical Centre but research shows us they are shared across primary care.

Guerilla research

To move forward with more in depth research we narrowed our focus towards the two interrelated areas: self-care (how can self-care information and uptake be better integrated in the GP patient journey) and the practice of triaging patients (could design improve the efficiency of triage?). Although we had important insight from the practice side we wanted to speak to people in the community. We visited Henfield, using guerilla research techniques to gain fast insight. We were left struck by the different understandings of self care and attitudes towards the role of GPs.

Synthesising the opportunities

Back in the studio we hit a decision wall, and we thought that was the time to elicit some advice from more experienced Clearflefties. Encouraged to diverge our thinking again to check we had considered all the opportunity areas we ran a How Might We’s rethinking session. We individually wrote HMW statements before theming these and dot voting. Here we met our first plot twist, bringing the topic of ‘reassurance’ back to the drawing board (the reliance on GPs for sometimes unnecessary reassurance).

We crafted problem statements in these target areas so we were clear on our users, user needs and impact of the problems. But we needed one problem statement to move forward with! With different views in the team we mapped out the opportunities in these areas, as well as the challenges we faced if designing for these. From this we used the ‘NUF’ technique, comparing our initial broad concepts for these problems in terms of how new, useful and feasible they are.

From the research there were some clear personas of patients that we hadn’t yet mapped out on paper. So using our best friend the post it, we assessed what we considered relevant to understand in the context of this project and brought these groups of people to life against these metrics. These included typical self-care practices, attitudes to GP care and of course needs. It was important to clarify the different needs and goals of users before designing for one.

Playback and next steps

Nearing the end of discovery we wanted to bring the rest of the team in the project in greater depth, so we hosted a ‘brown bag’ lunch. Something us designers need to be able to do in the ‘real world’ is present our work to stakeholders. As such we prepping as one would for a client playback, beginning with storyboarded the project journey so far. This helped us take the high level view of the process before surfacing all the findings, methods, quotes, insights and learnings along the way that enriches the picture.

All of this research has helped us move into the design phase! We’ve run a design studio with fellow colleagues, and ideation sessions with stakeholders. We realised we needed more data to be confident in our designs so alongside starting the idea development phase we are gathering more user insight via a survey. This is also giving us access to people to interview or test concepts on before moving to implementation.

You can follow us on twitter @clearleftintern for regular updates on the project.

The rise of research ops — a view from the inside Thu, 10 Oct 2019 23:00:00 +0000 Earlier this week Clearleft hosted a lively morning of debate around ‘Accelerating Your Digital Design Maturity’ featuring leading industry voices from Tesco, Babylon Health, Sky, Twitter, Google Ventures and UCL.

In front of an audience of 70 design leads, two panels explored the challenges and approaches their organisations have around getting closer to customer needs and delivering better products faster, or to use a couple of industry buzzwords: research ops and design ops. We wanted to share some key insights from the former.

Kate Tarling discussing Research Ops in our first panel

What is research ops?

Research ops are the processes necessary for understanding customer needs and integrating research into an organisation’s decisions. It is the latter part that can be most challenging.

It stands to reason that research ops should ensure that researchers have what they need to do their job. That might include the right software, labs and other tools, training and professional development. It should also include consistent methodologies for different forms of research, along with all the legal and administrative systems and paperwork required.

But that’s a baseline. Where research ops really comes into its own is in establishing research across the organisation. According to Daniel Burka (Director of Product and Design, Resolve to Save Lives), research ops needs to “be both selfish and selfless” meaning it must be objective in its pursuit of insight and understanding, but then open and active in socialising the results.

Design research vs. market research

In many large organisations there is an insights team tasked with market research. This kind of research has been around for many years and has earned a mature place within companies. Conversely design research is relatively new. Some of the techniques may be similar, but the purposes tend to be different, and practitioners in the two camps can have a tendency to look down on one another, with design researchers dismissing market research’s focus groups and the insights team not seeing why they should spend time watching usability testing.

Of course both have their place and the panel stressed the importance of the insight team joining design researchers combine their efforts in understanding the desires of the market and the direct needs and difficulties of customers.

Do we need specialist researchers?

Unanimously, yes, there is definitely a role for specialised researchers. A trained researcher will be able to put together a programme of research and design sessions with users that are as unbiased as possible, non-judgemental and objective. But more than that, Tomasz Maslowski (Head of UX & Design, Tesco) pointed out that an experienced researcher “doesn’t just play the notes but hears the space between the notes.”

So while it’s really helpful that designers, developers, product owners, executives and others are all taken into the field at various points, the skill of the specialist research is to distill what people say into what people mean. The non-trained ear can be prone to confirmation bias and pick out the soundbites and opinions that supports their theory or position, or not take what they are hearing into context or proportion.

Research should collaborate and communicate

You could say that about any discipline, but Dan noted that if you put research among designers then they can hear where designers are unsure about decisions and bring that into their research.

Dan points out that a potential problem with product design is assuming that users care about the product when what they really care about is what a product can do for them. Researchers can help expose this if they are working closely with designers, rather than the design or product team simply giving research a list of questions to get answers to. “They should be the team’s questions, not the researchers’ or the designers’ questions”. Quite often the more useful research questions lead not to answers but more questions.

This is why research is far less effective when done in isolation. It’s time for researchers - and research ops - to “get scrappy” and think about how to get learnings into the wider team, and up to executive levels. Examples include running mandatory “customer closeness” sessions enabling all employees to see first-hand customers using products.

Ultimately the panel concluded that research’s job is to mitigate risk and confirm (or deny) opportunity, and these are aspects that the whole organisation needs to understand and use.

Many thanks to Daniel Burka (Director of Product and Design, Resolve to Save Lives), Tomasz Maslowski (Head of UX & Design, Tesco), James Stevens (Director of Group Product Design, Sky) and Kate Tarling (Digital and Design Leadership, Fly UX) for their generous time.

In part two we’ll cover the second panel and ask what design ops is and whether we should care about it?

If you’d like to discuss how we could help you mature your research function do get in touch.

Critique your shortcut to better designs Fri, 04 Oct 2019 13:22:29 +0000 Want to create better designs? Interested in becoming a better designer? There are few shortcuts to better design but introducing regular structured critique to your design process is one of them.

In my role as a UX consultant, I’m often helping clients improve the impact and efficiency of their design work. In reviewing how design is done I’m surprised that there is frequently an absence of routine critique sessions.

The good news is that critique is an easy habit to adopt and develop. I’m going to give a few tips in this article to show it’s quick to do, rewarding to participate in, and will lead to immediate improvements in the quality of your design work.

Critique of early concept ideas with the team from Virgin Atlantic

Does the word critique make you cringe?

When I ask design teams who don’t do critiques why it’s not a fixture in their working work they tend to pull pained expressions. Digging deeper and asking what comes to mind with the word critique and the associations are exclusively negative.

I commonly hear mentions of Statler and Waldorf the old cranky upper balcony hecklers extraordinaire in the muppets, or Dorothy Parker and her acerbic poison pen, Simon Cowell and his judging panel of cronies and Anton Ego voiced so sardonically by Peter O’Toole in ratatouille Pixar’s Ratatouille.

Critique, when done properly, provides a safe space to get feedback from peers. If it doesn’t improve the designs or help you grow as a designer then you are doing it wrong.

If you remember one thing: Critique ≠ Criticism.

Why make design crits part of your practice?

A good peer-review process acts as essential quality control. Getting feedback early and often enables you as a designer to benefit from the wisdom of your colleagues.

It’s a tried and tested practice used in varying forms in other creative endeavours to help challenge, shape, and enhance work. When making movies, dailies (the previous day’s outputs) are watched by the cast and crew to improve their performances, actors receive notes from directors and producers in rehearsals and during the run of a performance, novelists receive comments on manuscripts as they move from draft to draft.

In all these cases feedback is a baked-in part of the creative process. It starts early and continues through iterations from lo-fidelity to polished product.

A design critique should be time spent well for both the person seeking feedback and those giving it.

As a designer, the activity gives an opportunity to stress-test design ideas by seeing what questions it raises. It also improves design quality by gathering suggestions for enhancements and reduces risks by getting a sense check of the work with time to make any adjustments.

Equally, for participants, giving feedback should be rewarding – as you get to see how your colleagues approach design problems and get to sharpen your critical thinking skills.

At Clearleft, we’ll use the expertise of our colleagues when we are looking to get input on project work, devise new workshop activities and prepare conference talks etc. Anything you are creating will benefit from you having to explain your design decisions and from the feedback from a fresh pair of eyes with a new perspective.

Critiques of work are better when done more often and earlier rather than less and later.

Critique of a mobile prototype with the team from

How do you run a productive design critique?

It feels embarrassingly simple when written down. But that’s the point. Critique is simple to do if you bear in mind a couple of essential things:

1 Set a time and place

Invite the colleagues you feel can give you some considered feedback. A mix of designers, subject matter experts and insightful others. Aim for 3 to 5 people to provide a range of views while having enough time for everyone to be heard. Set aside 30 to 45 minutes as people will appreciate a calendar meeting that isn’t an hour long.

Of course, this step is easier if you have critiques booked in as a regular ongoing ceremony.

2 Facilitate the session

Help the people you’ve invited to give you better feedback. Start by briefly giving some context on the problem you are trying to solve and any key insights or constraints that are useful for them to know. Then tell them what you are looking for feedback on. Keeping it targetted will help them focus and give you more actionable suggestions.

Then show your designs. Sometimes it helps to do this with a commentary walking people through the designs. Other times a timed silent gallery allows people to view the work and consider their responses. You want to foster an atmosphere that encourages considered advice rather than knee jerk reactions.

3 Get some feedback from your peers

This is the point at which the tension seems to rise the first few times you do a critique. It’s helpful to set a few ground rules to make everyone feel more comfortable and make the session more productive. You want to create a space that allows people to be constructive rather than combative.

Remind people why they are there: to use their expertise to help improve the design.

Remind people to use language that questions or offers advice rather than dictates. Move from ‘you should …’ to ‘you might want to consider …’.

Remind people to separate critique of the person from the product. My go-to phrase is ‘Be hard on ideas. Be kind on people’.

To balance feedback I like to get everyone, in turn, to contribute one thing they like in the design that they feel meets the brief and then one thing they would suggest changing.

I’m a fan of helping the attendees frame their feedback by starting their replies with:

I like how … (to pull out a positive thing to keep), and Even better if … (to suggest something to reconsider or change).

Once you’ve captured the feedback and if time allows dive into a discussion on the areas you want to explore in more detail. However, be careful not to dive into creating solutions on the spot. This is not the purpose of the session and is unfair on the person giving you the feedback and you as a designer to have an immediate fix. Questions in the session and solutions later.

What are you waiting for?

One of the key activities that lead to better quality designed products and services is to do regular critiques. When run well they help designers to articulate their work and to canvas valuable insight and input from colleagues.

For teams who don’t yet do critiques, what’s stopping you from putting one in the calendar to improve whatever you are working on now? After all, any habit needs to start with the first time.

How to be a good speaker Thu, 03 Oct 2019 13:43:00 +0000 I’m in the process of curating our UX London and Leading Design events, I watch around 200+ conference talks a year. Here’s a quick checklist of things I find work well and work poorly.

Don't worry about having a unique concept

I see too many smart people put off of public speaking because of this. It’s perfectly reasonable to take an existing concept and layer on your own perspective and experiences. This humanises the topic and makes it interesting. Also, remember that what’s obvious to you isn’t obvious to everybody. There are always new people joining the industry.

Also don’t feel you need to write a new talk each time. Like music or stand up comedy, talks get better with practice. As a side note, I saw the same talk 5 times over the course of 3 years. Each time I took something new away because I was in a different place in my career.

45 minutes is a looooong time to keep somebody's attention

No matter how interesting the subject, a monotone delivery make it hard for your audience to stay engaged. Use your voice (speed, pitch, volume etc) and body (gestures, stage) as a tool to keep things interesting. Try to minimise the “ums” and “ahs”. This comes from practice.

Try to avoid the “speaker square dance” when you shift your weight from one foot to the other. It’s distracting and makes you look nervous.

(These are all things I still do, to my annoyance).

Try to avoid “listicle talks” if possible. You know the type. Here are 7 or 12 things I think are important, and I’m going to go through them one by one. It’s a handy formula, but it make people conscious of time. “Crikey, they’re only at number 4”.

A few things to avoid

Try to avoid giving a big bio at the start of a talk. I know it’s a great way of you “justifying to the audience” why you’re on stage, but folks generally don’t care. Often it’s better to start right in the middle of a story, as it makes the audience tune in.

Typical speaker jokes like “I’m the only thing between you and beer” can be risky. Especially if you haven’t been listening to the other speakers and they’ve already said that about lunch or coffee. I also worry about normalising over consumption of alcohol at conferences.

Asking your audience to perform a task can be risky, especially in front of Brits and Northern Europeans, who would rather curl up into a ball and die that risk the social awkwardness of talking to their neighbours. However… Once people get talking, it’s actually hard to get them to stop. If you do have an activity planned, make sure you leave enough time for it to be a meaningful connection.

It’s super common to make jokes about finishing off your slides last night or not getting to bed late because you were out drinking While it’s good to be vulnerable and human, if played wrong, the message this sends is that you don’t care about the audience.

If you are going to present a concept or opinion style talk, you’ll probably need to give some back story. Try to keep this short as I’ve seen plenty of talks that are so much back story, they run out of time to cover the more interesting topics.

The best talks have a really clear story arc

Things that make sense when you read them in your head, often don’t gel when read aloud. So make sure you practice your talks out loud half a dozen times to make sure it flows. A surprising number of “natural” speakers have a speaking coach.

I think it’s usually better to assume a reasonable amount of audience knowledge. For instance, If in doubt assume folks know what a Design System is rather than spend 20 minutes explaining it to folks. Better to spend that time talking about what you do differently.

Nerves are natural

If you’re a little shy at conferences, speaking is The Best way to break the ice. Nobody talks to you before the talk. Everybody wants to talk to you afterwards, largely because they have a way in. As such, public speaking is bizarrely good for introverts.

Nerves are natural. Everybody gets them. Some of the best speakers I know are an absolute wreck before going on stage, swearing they’ll never speak again. Then they get up on stage, really enjoy the talk and can’t wait to do the next one.

You can’t really banish nerves, all you can do is manage them. You may think the whole audience can tell that you’re nervous. Generally, nobody has a clue. You are your own worse critic. Remember nerves are really just excitement and excitement is a good, performance enhancer.

Be visible, be reliable

Many conference organisers like to have seen people speak in advance, so if possible try to record your talks, even if they’re internal presentations or at local networking events.

Organisers appreciated that you’re busy, but also appreciate it if you can respond back to them in a timely manner. One of the reasons we see “the same old faces” is because those speakers are reliable.

There are more conferences and events than ever before. As such there’s a huge demand for new voices, especially from underrepresented groups. I encourage you to take advantage of this opportunity and put yourselves forward.

I’ve shared this thread and some follow-up resources on Twitter - please add you own.

One last thing (I promise). Speaking is fun and provides a great sense of accomplishment sharing what you’ve learnt to help other people.

However, conference speaking isn’t necessary to advance your career. Some of the best, most successful people I know don’t do talks. Don’t feel pressured into speaking.

How to measure content Mon, 30 Sep 2019 13:45:00 +0000 Good content is often seen as something that’s hard to measure. It’s (a sometimes small) part of much broader system and is so closely intertwined with design. But sometimes as content designers, we’re asked to demonstrate the effect of our content.

If you’re changing content as part of a whole page design, then you won’t be able to test the effect of changing the content in isolation. But when you’re only making changes to content, with the right analytics and behavioural insights you should be able to measure the effect of that change.

Visualising results will help you tell your story. Photo by Carlos Muza on Unsplash

What you measure will be determined by the impact you’re trying to have. And the mistake people often make is not setting a target for their content up-front. Without a target metric or purpose in mind, it’s impossible to review your content to see whether it did what you wanted it to. Firstly because you don’t know what you wanted it to do, and secondly, because you didn’t work out upfront what you could measure, and how.

To set good targets upfront, you need to know the problem you’re trying to solve. Once you know that you can think about how you’ll know when you’ve solved that problem. You’ll also need the capability to measure. Without access to data or analytics it becomes much harder (but not impossible) to measure effectiveness. Ideally you also need to combine quant data with more qualitative insights. Data will tell you what but not why.

Here are a few ideas of how to measure content for different problems:

1. Awareness

In this instance you want people to be made aware of your product or service or draw a user’s attention to particular important information. The key metric here is visibility — you need more people that see or find your content. The isolated content changes you could make to drive traffic include:

  • Navigation labels
  • Page headers
  • Meta-data
  • Clearer preceding call to action labels
  • Hyperlinks or related links
  • Clearer categorisation of help content (if your content is help-related)
  • Exposed or surfaced help
  • Social sharing links

How will you know if it’s worked?

Metric-driven measurement for this could include page-views, click-throughs, site traffic, social shares, fewer calls to your contact centre or live chats on a particular topic. If it’s navigation labels you’ve changed, you could also run tree tests.

For more qualitative data you could run some basic guerilla research — giving participants a task to find a particular piece of information. You could also ask your customer call centres to anecdotally record whether related queries or complaints have increased or decreased after a set period of time. Depending on the volume of traffic your site receives it may take a while to see strong results this way.

2. Engagement

Better engagement isn’t just about time spent on a page — there are many other ways we can measure it. Often when we want to increase engagement it’s because we want to keep people onsite for longer, so they’re more likely to buy or stay loyal to a brand. But sometimes we just need to make sure they’re reading what we want them to read because it’s important, or we want them to interact with something or provide information. Changes to content might include:

  • Product or pricing information
  • Help content
  • T&Cs or legal information
  • Forms
  • Article content
  • Proposition messaging
  • Videos
  • Social media posts

How will you know if it’s worked?

Metrics you might look at could include page dwell-times, video views, likes or shares, page bounce rates (you would be hoping these decrease). You should also look at how many users are clicking through to other parts of your site (vs leaving the site), form completions, or data or comment submissions.

Qualitative insights are always useful, even when you do have data, to understand user behaviour. Consider usability testing, or reviewing heatmaps, which will help you see which bits of content users are spending the most time on. But use heatmaps with caution as they don’t often tell the full story and not all analytics tools let users know they’re being monitored.

3. Comprehension

It’s all very well driving more traffic and engagement, but if users don’t understand what they’re reading, then they won’t understand what they’re buying or signing up to either. Confusion can lead to a loss of custom, complaints, and negative sentiment.

Content changes can be tested on many parts of your site to improve understanding, such as:

  • Product or pricing information
  • Help content
  • Legal wording and T&Cs
  • Special offer wording
  • Questions in forms
  • Service emails

How will you know if it’s worked?

From a data point of view you could monitor calls to your call centre, live-chat starts, on-page feedback submissions and click-throughs to help. You’d expect these to decrease. You might also be able to look at brand sentiment through social media channels or complaints data.

Testing comprehension through usability testing is great. Set participants a task, then once they’ve completed it ask questions to see what they understood from the content your testing. Cloze tests or highlighter tests are also a basic way to test comprehension.

A/B tests are a great way to test content changes (image courtesy of FezBot2000 on Unsplash)

4. Conversion

Copy changes can be one of the most effective ways to increase conversion. Here are some of the things you might want to test or optimise:

  • Call to action labels
  • Marketing proposition messaging
  • Price and product information
  • Help copy in forms
  • T&C wording

Help copy in forms and T&Cs are often neglected, but if a user has anxiety about not knowing what’s expected of them, or what they are signing up to, they can drop out at the final hurdle. Making sure your copy is clear and honest is the best way to build trust and improve conversion.

How will you know if it’s worked?

Click-throughs, page progression, quotes or leads, sales, renewals, and newsletter sign-ups are all quite standard metrics to use depending on the copy you’re changing.

Qualitative insights are much more useful to see exactly which copy is causing a user to drop out of a journey. For example on web form, identifying the field or bit of copy that’s causing users to panic or feel frustrated and leave the page, will give you the insight you need to iterate that copy. This can be done by watching users interact with the site, as well as by looking at tools such as heatmaps.

Conversion is often driven by a combination of factors, but usability, comprehension and task completion are important elements, and working on these metrics can have a positive impact on conversion rates too.

To find out why page 4 was seeing such comparatively high drop-outs you’d need to get more insight

5. Task completion

Getting someone through to their task as quickly as possible can be a key goal for many sites who want to ensure an efficient and effective user experience. The balance you must find is one between speed and comprehension. Some experiences shouldn’t be fast; for example purchasing insurance too quickly could lead users to feel wary about having everything covered. If you’re aiming for speed your content needs to be super-clear and transparent. The other way to measure task completion is whether someone could complete their task or not. Content you might test for task completion could be:

  • Online self-service (for example amending account details)
  • Purchase or renewal journey
  • Navigation labels to help users find information (for example help content or a phone number)

How will you know if it’s worked?

If you’re looking at completion time, as with all metrics, you’ll need a benchmark to start from, which means you’ll need to have gained some ‘average time to task’ metrics through user-testing. This gives you a way to assess whether your content change has improved this time. Some great work has been done by the GDS team on benchmarking.

If you don’t have metrics to start from, then usability testing is your best way to test, but you’ll be looking at whether the participants are able to complete the task at all, which arguably you could learn from site metrics.


You might be able to A/B test different versions of the same copy element (so some of your users see one version and the rest see the other). If you can’t run such tests, you might just have to make a change, monitor the results over a set period of time, then revert or iterate if you don’t get your required outcome.

One of the great things about content is that it’s often a relatively easy and cheap way to make small changes but see big results. If you do see big results, then share them widely. To create content advocates, you need to demonstrate the value — so create reports, dashboards, or a ‘successful content tests’ Workplace channel…whatever it takes to tell your story.

This post was originally published on Medium.

Geneva Copenhagen Amsterdam Tue, 24 Sep 2019 17:16:50 +0000 Back in the late 2000s, I used to go to Copenhagen every for an event called Reboot. It was a fun, eclectic mix of talks and discussions, but alas, the last one was over a decade ago.

It was organised by Thomas Madsen-Mygdal. I hadn’t seen Thomas in years, but then, earlier this year, our paths crossed when I was back at CERN for the 30th anniversary of the web. He got a real kick out of the browser recreation project I was part of.

I few months ago, I got an email from Thomas about the new event he’s running in Copenhagen called Techfestival. He was wondering if there was some way of making the WorldWideWeb project part of the event. We ended up settling on having a stand—a modern computer running a modern web browser running a recreation of the first ever web browser from almost three decades ago.

So I showed up at Techfestival and found that the computer had been set up in a Shoreditchian shipping container. I wasn’t exactly sure what I was supposed to do, so I just hung around nearby until someone wandering by would pause and start tentatively approaching the stand.

If you’re at in Copenhagen, drop in to this shipping container where I’ll be demoing

“Would you like to try the time machine?” I asked. Nobody refused the offer. I explained that they were looking at a recreation of the world’s first web browser, and then showed them how they could enter a URL to see how the oldest web browser would render a modern website.

Lots of people entered or, but some people had their own websites, either personal or for their business. They enjoyed seeing how well (or not) their pages held up. They’d take photos of the screen.

People asked lots of questions, which I really enjoyed answering. After a while, I was able to spot the themes that came up frequently. Some people were confusing the origin story of the internet with the origin story of the web, so I was more than happy to go into detail on either or both.

The experience helped me clarify in my own mind what was exciting and interesting about the birth of the web—how much has changed, and how much and stayed the same.

All of this very useful fodder for a conference talk I’m putting together. This will be a joint talk with Remy at the Fronteers conference in Amsterdam in a couple of weeks. We’re calling the talk How We Built the World Wide Web in Five Days:

The World Wide Web turned 30 years old this year. To mark the occasion, a motley group of web nerds gathered at CERN, the birthplace of the web, to build a time machine. The first ever web browser was, confusingly, called WorldWideWeb. What if we could recreate the experience of using it …but within a modern browser! Join (Je)Remy on a journey through time and space and code as they excavate the foundations of Tim Berners-Lee’s gloriously ambitious and hacky hypertext system that went on to conquer the world.

Neither of us is under any illusions about the nature of a joint talk. It’s not half as much work; it’s more like twice the work. We’ve both seen enough uneven joint presentations to know what we want to avoid.

We’ve been honing the material and doing some run-throughs at the Clearleft HQ at 68 Middle Street this week. The talk has a somewhat unusual structure with two converging timelines. I think it’s going to work really well, but I won’t know until we actually deliver the talk in Amsterdam. I’m excited—and a bit nervous—about it.

Whether it’s in a shipping container in Copenhagen or on a stage in Amsterdam, I’m starting to realise just how much I enjoy talking about web history.

This was originally published on my own site.

The discovery phase of our healthcare brief Mon, 23 Sep 2019 10:32:00 +0000 As we introduced in our first blog post, our brief is focused on Primary care and their ambition to ‘Do more with Less’. Whether enhancing the network of primary caregivers, improving efficiency and/or reducing the load on clinicians and staff.

It’s a huge problem area for us to understand and we want to share what we’ve been up to so far.

We have Clearleft at our disposal, whether via meetings, playbacks, our ‘open surgeries’ or over granola and coffee in the morning, however, we have the autonomy to shape our project to some degree.

Discovery playback session with our Clearleft stakeholders

Our fantastic project manager Alison keeps us moving forward at the pace we need to, amongst many things. We agreed to split the 13-week project into three distinct phases; Discovery, Design and Implementation, using the Double Diamond to guide our work through these phases. With a complex problem space, we planned for a slightly longer discovery phase, and to define our focus over five weeks.

Our double diamond

Kicking off discovery

The brief touched on some of the difficulties experienced by our stakeholder GP surgery, these included rural transport, continuity of care and provision of out-of-hours services amongst many others. This helped us not go into the project cold, but we were keen to meet with doctors face to face and delve into their day-to-day life as GPs, as well as introduce ourselves.

We wanted to gauge what the most limiting challenges are. We were interested in who they partner with, the impact of third party innovations in healthcare, and how they operate as part of the newly formed Primary Care Network of Chanctobury. Not only did we listen and learn, but the meeting generated some empathy for the varied challenges in Primary care.

Narrowing down

An affinity mapping exercise back at the office helped us see the themes in what we learned, and helped us mentally get some clarity amongst a sea of new acronyms. We also began building an experience map of people and Primary care journeys.

There were a number of challenges we started to uncover.

  • Transport of people in rural communities to other regional services, especially older people, is pen and paper based and lacks easy volunteer driver organisation.
  • Unsurprisingly, IT capabilities and integration underpin many inefficiencies.
  • Staffing issues, especially turnover and new staff training of front line staff is a pressure on resource and service.
  • New groupings of surgeries, with the Chanctonbury PCN being no different, are just starting to embed ways of working together.
  • Demands on GP surgeries for problems that can be treated at home or with over-the counter remedies
  • Raising awareness amongst patients to direct people to out of hours services at different local practices
  • Mental health in rural communities and impact of isolation.
An experience map of post its on brown papare
Experience map

We wanted to talk further with a wider set of staff. We were very grateful to have the opportunity to return and meet with front line staff, nurses, doctors and the practice manager to talk more around our targeted areas.

We planned the lines of enquiry while allowing for a fluid conversation, and used the app Otter to auto-transcribe the 2.5 hour session for us to refer back to. Initially planned as separate interviews, on the day staff joined us when they were able to step out, so the session naturally became a more informal group interview and discussion.

At Henfield medical centre posing our research questions and faciliatating discussion around the problem space

Exploring the problem space using 'How might we' statements

Compiling our insights we were able to create a first round of ‘How might we’ statements to help identify problem areas that may be helped through design in the time frame we have.

‘How Might We’ (HMW) statements are useful when wanting to frame the broad areas of challenge that you might want to design for. Very deliberate in its wording, ‘How’ reminds us that we don’t know how this can currently be addressed, helping create a sentiment of curiosity and openness to the challenge. ‘Might’ invites the team to consider lots of different ways to come to a solution, which may or may not be used. ‘We’ reminds us of the collaborative nature of most design projects. It provides gentle guidance for the team without restricting too early. These were our first round:


How might we improve self-care rates in rural areas to reduce demand on GP and front line staff time in triaging?


How might we help the surgery and newly formed PCN work with partners to manage community health?

Triaging system

How might we support or scale the Henfield Triage process?

Awareness and communications

How might we help the surgery and PCN better work with partners to manage patients’


How might we help the surgery better communicate with the local community?

Learn more in our first Vlog:

Next steps

We’ve gained incredible new perspectives from experienced Clearlefties in project playback sessions and ‘open surgery’ sessions. We will be going back to our pilot area Henfield, to talk to local users about their experiences and perspectives of GP health care, utilising some of Clearleft’s Guerilla research techniques.

You can follow us on Twitter here to help and follow our project. We’d love the support of the design and research community.

Tiny lesson: rapid builds, email signatures and Airtable Mon, 23 Sep 2019 08:00:00 +0000 We’re fortunate enough to have some rather snazzy email signatures, kindly created by Benjamin. He’s been lovingly crafting these by hand; diligently updating them each time an event concludes or a new Clearleftie joins.

This seemed like a fun and helpful task to automate, and after a morning of hackery, I had a working version of the signature generator deployed and ready for an internal test.

There are a couple of interesting technical decisions which we’ll delve into, but before that, let’s talk about building at pace more generally.

Quick web things, quick web wins

One of my passions is rapidly testing ideas on the web. Development pace is one of the biggest things the web has going for it over native applications. A HTML file, domain, server space and a couple of hours is all you need to get something online.

It’s worth saying upfront that rapid builds are definitely not for everything. In fact, they should be used sparingly for prototypes or side projects that aren’t business-critical. Like the good, fast, cheap venn diagram, quick builds are inherently flawed, but they do still have merit.

I really love a thorough plan and technical spec, but there’s something wonderful about rapidly spiking a problem and not worrying too much about the details. It’s how Sergey, JS Pedalboard, Javasnack and several marginally popular F1 parody websites came about.

The stack isn't really important

Spikes are a great way to try a new technology and learn by making mistakes. The only pre-requisite I’d suggest is to use a stack that you can deploy easily. There’s nothing worse than getting something working locally, then finding you can’t host it without an AWS degree or pricey hosting infrastructure.

In the past, PHP was my jam. It’s still so much easier to host than Node.js, and you can build quickly without getting too bogged down in implementation details. These days I’m tending to lean on static site generators like Hugo and Sergey (shameless plug), before deploying to Netlify.

For this project, I opted for Preact and a small vanilla Node build script. Preact CLI boilerplated the site very quickly, and after a few minutes of stripping back the extra cruft, I had an ES6, reactive and hot-loaded development environment ready. I then ran a quick ‘hello, world’ deploy to confirm it would all build on Netlify.

With that in place, it was time to actually build the darn thing.

From the very rough plan in my head, it appeared there were two main parts to this project:

  1. The template generator - Preact
  2. The data source - JSON & Airtable

Generating code with code

Email signatures are notoriously awful to code, but fortunately Benjamin had done the hard work already! I grabbed an existing signature and converted it into a little method that squirted the parts of a ‘person’ in, mixed it with some sensible defaults, and returned some HTML (well, JSX).

const person = {
  forename: 'Trys',
  surname: 'Mudford',
  team_name: 'trys-mudford',
  avatar_name: 'trys-mudford-small',
  role: 'Front end developer'

renderSignature = person => (
  <div style="min-height:50px;line-height:17px;color:#505050;min-width:350px;font-family: Arial, sans-serif; font-size: 10pt; line-height: 1.5;">
    <a href={data.defaults.team_url + person.team_name}>
        style="float:left;margin:2px 6px 32px 0;width:90px"
        src={data.defaults.avatar_url + person.avatar_name + '.png'}
        alt={person.forename + ' Profile Pic'}
      <strong>{person.forename + ' ' + person.surname}</strong>
      <br />
      {person.role} |{' '}
      <br />

The next step was to import the list of staff from a JSON file, pick out a selected team member and render the above template. Thanks to JS imports, this was nice and clean to achieve:

import { h, Component } from 'preact';
import data from './data';

class App extends Component {
  render() {
    const person = => x.team_name === 'trys-mudford');

    return (
        {person && (
          <section class="person">{this.renderSignature(person)}</section>

Next I moved the hard-coded user identifier up into state, and added a <select> field to control it.

state = {
  teamName: ''

setTeamName = event => {
  this.setState({ teamName: });

render() {
  return (
      <label for="who" class="screen-reader-only">
        Pick a team member
        <option value="">Who are you?</option>
        { => (
          <option value={person.team_name}>
            {person.forename} {person.surname}

Finally, I added a touch of state restoration with the help of localStorage. When a user returns to the site for a second time, their previous staff choice gets prefilled, saving one click. The goal of this site is to save us time so this feature is; although by no means essential, surprisingly useful.

const STORAGE_NAME = 'signatureTeamName';

state = {
  teamName: localStorage.getItem(STORAGE_NAME) || ''

setTeamName = event => {
  this.setState({ teamName: }, () => {
    localStorage.setItem(STORAGE_NAME, this.state.teamName);

With that, plus a bit of styling, the frontend was complete.

Airtable API

The above was achieved with a static JSON file, which was super rapid to build with. As an MVP, this all works and could genuinely be used in production - there’s no shame in avoiding databases altogether. But part of the fun in rapid building is trying new things out.

Airtable is like Excel on steroids - and a spreadsheet seemed like the most straightforward way to get data into this system without getting tied up in databases and servers. I considered Google Sheets, but their API authentication was too cumbersome, so Airtable won the day. As I said, pick tools that deploy easily!

Once I had an API key, I created a file called fetch.js and ran node fetch.js in the terminal. This runs whatever JS is in the file - like a Bash script for those of us who don’t know Bash. Data fetching in Node is still less than ideal, but I’ve got a handy little method that converts the in built https library into a promise:

const https = require('https');

 * Generic HTTP Get request promisified
 * @param {string} url - the API endpoint
 * @returns {Promise<Object>} - the response
function get(url) {
  return new Promise((resolve, reject) => {
      .get(url, res => {
        let data = '';
        res.on('data', chunk => (data += chunk));
        res.on('end', () => resolve(JSON.parse(data)));
      .on('error', err => reject(err));

The response from Airtable is an object with a records array. Each record is a row in the spreadsheet which in turn has a fields property. Each item in this object is keyed to the name of the column, and represents a cell.

I started out writing some fairly dodgy but working™ code to take the rows, loop them and add them to a new array. That array was then converted into a new JSON file ready to be consumed by the Preact application. Once I’d confirmed that was all working, I refactored a bit and ended up with this:

 * Parse Airtable response, running through a transform callback function
 * @param {string} url - the Airtable endpoint
 * @param {transform} transform - the transform function to run through
 * @returns {Promise<AirtableRecord[]>} - an array of records
function fetchFromAirTable(url, transform) {
  return get(url)
    .then(res => res.records
      .filter(x => Object.keys(x.fields).length)

function fetchStaff() {
  return fetchFromAirTable(
    record => ({
      forename: record.fields['First Name'],
      surname: record.fields.Surname,
      team_name: record.fields['Team Name'],
      avatar_name: record.fields['Avatar Name'],
      role: record.fields.Role

(() => {
  console.log('Fetching data from Airtable...');

  return Promise.all([fetchStaff()])
    .then(([team]) => {
      let data = JSON.stringify({
      console.log('Writing results...');
      fs.writeFileSync('src/data/index.json', data);
      console.log('Build complete');
    .catch(err => {
      throw new Error('Fetching failed', err);

Instead of pushing the transformed data into a new array, I relied on the wonderful Array methods we have available in JS. Using .map() with a callback worked as a really neat way to extract the data transformation out into the calling function, simultaneously keeping the data fetching code nice and generic.

Scaling this to work with ‘events’ as well as ‘staff’ was a case of creating a new method, adding the appropriate API URL, and writing a new transform function.

Build time scraping

One option would’ve been to hit the Airtable API directly on the client-side. This has the advantage of always being up to date, but has a few downsides:

  • Additional point of failure on the live site
  • Dependant on Airtable keeping their API format consistent
  • Rate limiting & pricing considerations
  • ‘Dangers’ of exposing all the spreadsheet data
  • Definite dangers of exposing API keys
  • CORS hell

The approach I took was to fetch the data once at build time, create a new JSON file and read that in to Preact. It’s the same technique I used on the 2018 incarnation of Paul the Octopus.

The biggest benefit of this approach is how well it fails. If: Airtable change their API design/auth, someone updates the spreadsheet format drastically, or the sky falls in, new releases will simply not build and the current release will continue to stay live. I’ll get an email alerting me to the failed build, and I can investigate in my own time.

Hiding secrets

With any quick build, you need to decide what’s worth optimising and what’ll ‘do’ for the MVP. If you get bogged down optimising prematurely, you’ll never ship anything. If you cut too many corners, the product will be unsalvageable. The trick is to avoid painting oneself into a corner.

Environment variables are one of those things that are worth setting up early doors. They’re not exactly exciting, but retrospectively adding them is even less fun. Plus, the very act of adding them to a project forces you to consider how the site will be deployed.

Hard coding secrets into a repository isn’t a hugely clever idea, so it’s good practice to create an .env file, pull in the dotenv module, and rely on environment variables from the start.

Come up with a plan

You don’t have to fly totally blind with projects like this. It’s worth coming up with a small plan, even if it’s only in your head. For this project, the plan looked a bit like:

  • Decide on a stack
  • Bootstrap the site
  • Render a plain HTML signature
  • Make a template to render a signature from an object
  • Extract user details & defaults into a JSON file
  • Fetch something from Airtable
  • Save that thing as JSON
  • Trigger the fetch at build time

If you have a reasonably big idea in mind, it’s worth breaking it down into smaller features first. This ‘backlog prioritisation’ exercise might sound pretty formal for a single day build, but I find it helps me stay focused. I quite like GitHub projects & Trello for this task - I’ll make ‘MVP, nice to have, backlog, in progress, done’ columns and divide the features accordingly. The MoSCoW method is a decent alternative approach.

Guessed requirements

The final thing I wanted to touch on was guessed requirements. It’s an inevitability that the thing you build will have some rough edges and won’t work perfectly first time out. But that’s okay, you’re not building a business-critical system, you’re building a ✨ fun web thing

With this project, I got a bit carried away and added a ‘copy the code’ feature. It ran the renderSignature method through Preact’s render to string library, before copying it to your clipboard with execCommand. There were some interesting success/error states to consider and I had to use refs to select DOM nodes within the application.

The only problem was, the feature wasn’t needed.

Gmail and Apple mail both work from the default browser selection and clipboard, and don’t allow you to paste HTML. So the feature was swiftly removed. It could’ve been avoided with some basic specifications, but it also wasn’t a big deal. The feature took about 30 minutes to add, and was a nice problem to solve.

The fact that it didn’t make it to launch matters little, it was still useful to learn and code, even if I was the only beneficiary.

This was originally posted on my website.

Applying a system mindset at both a service and product level Thu, 19 Sep 2019 09:10:44 +0000 Over my career, I’ve applied my design skills in a number of different realms.

I’ve been called an ‘Ergonomist’ designing a national transport system, I’ve been called a ‘Service Designer’ designing an end-to-end airport passenger experience and more recently at Clearleft I’ve been called a ‘UX Designer’ designing a relationship management product for a large investment bank. However, the one thing that has stood me in good stead throughout my whole career is taking a system’s approach to all problems - no matter whether they are at a service or product level.

I'm not a fan of the phrase 'digital service design'

The benefits of taking a system’s approach at a service design level is well understood. The whole premise behind service design is that an experience should be designed across all customer touchpoints - including understanding how the tangible and intangible components influence one another within the whole system. It’s one of the reasons the new term of ‘digital service design’ has never sat well with me as, unless the service is 100% digital, dividing the service design between the digital and non-digital parts defeats the object.

At a product level, your brief is typically more focused on an individual/subset of product(s) or service ’touchpoints’. However, it’s absolutely critical not to lose sight of where this component sits within the broader service strategy - what is your role, what is your relationship with other touchpoints and how might your design decisions influence other areas of the service.

Ultimately, the experience is defined by all touch-points, not just the ones you are focused on.

The risk of not maintaining a systems mindset

Not maintaining this system mindset at all levels is one of the reasons in my experience that it’s all too easy for the original service strategy to get lost at execution or take a life of its own. One of my favourite quotes of all time is this one by Steve Jobs which highlights that the journey from idea to product is rarely a straight one:

You know, one of the things that really hurt Apple was after I left John Sculley got a very serious disease. It’s the disease of thinking that a really great idea is 90% of the work. And if you just tell all these other people ‘here’s this great idea’ then of course they can go off and make it happen. And the problem with that is that there’s just a tremendous amount of craftsmanship in between a great idea and a great product. And as you evolve that great idea, it changes and grows. It never comes out like it starts because you learn a lot more as you get into the subtleties of it. And you also find there are tremendous tradeoffs that you have to make.

Steve Jobs

Successful innovation relies on both service and product-level design working hand-in-hand. This is importantly a two-way relationship that requires everyone to understand that executed well the whole can actually be greater than the sum of all the parts.

A new way to talk about content strategy Fri, 13 Sep 2019 09:03:00 +0000 I don’t know about you, but I need methodology and theory to be really simple, and also visual. ‘Draw me a diagram’ is often my go-to line. I find it very hard to make the abstract tangible and practical without clear diagrams and examples.

For this reason I sometimes struggle to articulate content strategy to clients and colleagues. It’s essentially the substance, tools, people and process that get you to your outcomes — or how to focus your efforts to achieve your goals. And that’s important, because without focus you’re just building ‘stuff’ without purpose.

But when it comes to breaking that down into tangible things that a business can do, I just couldn’t find a diagram that said what I wanted it to. So I’ve created my own.

Content strategy as a process

It made sense for me to think of a strategy in the form of a process – the steps to get from here to success. So the steps I’ve come up with are:

1. Focus

What are you trying to achieve as a business, and what do your users need? Thinking about your user goals in terms of business value can help to align these.

For example, if customers are seeking more information on a particular topic, by providing that info you can keep customers onsite for longer and increase the chances of them buying. You meet their needs and by doing so, sell more.

While the overall goal you are trying to achieve through content is probably sales or loyalty, think about the more granular metrics that contribute towards this about might be more relevant to user needs.

Once you’ve drawn out the areas to focus on, you can define a content mission statement.

2. Foundations

In order to create effective content you need to lay the foundations. This consists of:

  • your values (which are aligned to your content mission)
  • voice and tone
  • the substance and structure of your content, ie. WHAT will you be creating or refining?

Once you know what you need to create, it’s easier to work out how to get there.

3. People

It goes without saying you’ll need someone to create or refine your content. Perhaps multiple teams and disciplines need to be involved? Setting out the roles and responsibilities is particularly important when you don’t have a defined content team. Who needs to provide product information, and who has overall accountability for the content once it’s live? No accountability isn’t just dangerous from a quality point of view. If no one’s reviewing the existing content once it’s live then you’re accumulating content debt.

4. Process

The next thing to focus on is your production and build process. This could be very simple if you’re a team of one or embedded in a product team. But if you’re in a large, fragmented organisation it’ll be more complex. Creating briefing templates or setting SLAs (service level agreements) might even be necessary if you’re managing a vast number of stakeholder requests. The great thing about defining metrics and KPIs is that you now have a criteria to prioritise content against. If it’s not contributing to business goals or metrics then is it really a priority, or do you need to include other objectives options in your brief such as ‘legal requirement’?

If you have a CMS it’s best practice to document the workflow and list out creators, editors etc. Even if this is just to keep track of who has access. You’ll need to make sure there’s a process for removing users when they leave the business or adding new users when they join too.

Under process I’d also include style guides and QA checklists. Part of any content production is ensuring it’s governed in such a way that whoever produces it achieves a high quality and consistent piece of content. When multiple content creators exist you’ll need guidelines to make sure this happens.

5. Measurement

Much like the agile process of test and learn, we must make sure we’re tracking against our targets. Whether this is through analytics and data, or more qualitative feedback such as usability testing, we need to revisit what’s gone live. In the case of a large website with multiple content producers, it’s advisable to review the content at regular intervals and check it’s still accurate and fit for purpose.

6. Maintenence

Once our content is live our work isn’t done. Iterating content, testing new versions (through AB testing) and optimising for usability isn’t just advised, it’s essential if we want our site to be the best it can be. We all like to think that when we hit publish that it’s the best work we’ve ever done. But the chances are that looking at your site with a critical eye will highlight lots of room for improvement.

Content strategies are only achievable with buy-in from senior stakeholders, which is sometimes tricky. My top tip is to include them in the strategy creation process. Start with stakeholder interviews to understand what they think the company should be trying to achieve through content, and bring them into any workshops you run. In a recent presentation by Gather Content I heard:


so the appetite for better content is there. But better content doesn’t just happen — it starts with a better strategy.

This post was originally published on Medium

Tiny Lesson: 3 useful Figma features Thu, 12 Sep 2019 10:47:00 +0000 I recently started designing and prototyping in Figma and I want to quickly show you three useful features I’ve discovered. Those are smart selection, colour styles, and prototype master connections.

Smart selection

When you select elements which are evenly spaced, Figma recognises that these are related and allows you to adjust the spacing for all of them at once. You can also swap the position of these elements without disturbing the spacing. You can read more about smart selection on Figma here.

Colour Styles

In Figma you can save any colour as a style and apply it to fills, strokes, and text to ensure consistency throughout your designs. Any updates you make to your colour styles will be immediately reflected in your file or project, anywhere you’ve applied that style. The real-time updating means you can tweak colours and test colour combinations really fast with your actual components. This is the way that colour styles should work in a design tool, but it could also be a really cool way to help you with some specific tasks, like adjusting brand colours to meet accessibility requirements, or I could see this working really well to help with designing a themable template.

Prototype connections

If you have a component which appears on multiple pages, like a website header or footer, connections added to the master instance of that component will work in all of its instances. I think at the moment this only works if the master component is on the same page as its instances but it’s still really useful and can save a lot of time. Here’s some more information on creating prototypes in Figma.

Those are just a few of the nice touches Figma has introduced that I’ve found useful. I’m really enjoying using the app – it’s a pretty exciting tool and I’m learning something new about it every day. It’s definitely my first choice design app at the moment. It’s cross-platform and there’s a free tier, so have a look, and let us know what you think.

Getting started Mon, 09 Sep 2019 10:53:23 +0000 I got an email recently from a young person looking to get into web development. They wanted to know what languages they should start with, whether they should a Mac or a Windows PC, and what some places to learn from.

I wrote back, saying this about languages:

For web development, start with HTML, then CSS, then JavaScript (and don’t move on to JavaScript too quickly—really get to grips with HTML and CSS first).

And this is what I said about hardware and software:

It doesn’t matter whether you use a Mac or a Windows PC, as long as you’ve got an internet connection, some web browsers (Chrome, Firefox, for example) and a text editor. There are some very good free text editors available for Mac and PC:

For resources, I had a trawl through links I’ve tagged with “learning” and “html” and sent along some links to free online tutorials:

After sending that email, I figured that this list might be useful to anyone else looking to start out in web development. If you know of anyone in that situation, I hope this list might help.

This was originally posted on my own site.

Hello from the Interns Thu, 05 Sep 2019 08:30:00 +0000 We’re pretty excited to be part of the Clearleft 2019 Internship Programme. We’ll be sharing our design process with you throughout our journey – but before we do, let’s introduce ourselves and the project.

Clearleft has seen past interns produce some great solutions, such as a connected audio player and a product to empower citizens in planning applications. This year we’re exploring the opportunities for user-centred design and technology to enhance primary care in the NHS (GP services).

The NHS is undergoing both a digital transformation and operational one with the recent grouping of surgeries into Primary Care Networks (PCNs). This will enable efficiencies and greater resilience, but it’s early days. Alongside this the NHS continues to feel pressures from growing patient demand and falling GP numbers.

This project brings doctors and designers to the table with a shared purpose of uncovering opportunities and designing for good to support our much loved NHS.

A bit about us

Beyza has a background in industrial design and recently finished her master’s degree in Entrepreneurship, Innovation, and Technologies from Strathclyde Business School. She has expertise in medical device design and UX, and has founded a start-up in oral health technologies. She was also the design manager at Ege University design centre, supporting innovation in the medical sector. She’s excited to join this programme to improve her UX & UI skills in healthcare technologies.

Holly is a UX Designer with an interest in health and nutrition, in particular in the growing research area of the human microbiome and disease. She has trained in biomedicine and volunteered for the mental health charity Mind. After 12 years crafting solutions and engaging users in reducing carbon emissions she successfully completed a 3 month immersive programme in UX Design. She’s excited to have joined Clearleft in her home city where she can build her skills alongside a team of talented designers.

Lacin is a researcher and multidisciplinary designer. Having completed an interior architecture degree she continued her studies by doing a masters degree in Design where she started to become interested in design research. Her research focuses on sensory design, biophilia and immersive environments within the healthcare industry. She is very excited to collaborate with talented people from various backgrounds and learn as much as she can about the design and research process in an agile environment.

Discovery to implementation

This is a three month project. We’re lucky to have a project manager, helping us to keep to our trajectory. Five days in we are deep in the discovery phase of this vast problem area, speaking with local doctors. During the second month we will be exploring different designs for our target problem before the final stage of implementation in which we will be bringing that solution to life.

You can follow us on twitter @clearleftintern and we will be posting regular blog posts here on the Clearleft site. If you have any comments or want to share any experiences or ideas in this area you can email us.

Debunking some design sprints myths Thu, 29 Aug 2019 14:33:00 +0000 We regularly use design sprints to help clients to accelerate design, unblock problems and investigate new ideas. We’re big fans of design sprints when done well. However …

… we also find there are some common misunderstandings about the technique pioneered by Jake Knapp and the team at Google Ventures.

During UX London Jerlyn and I ran a Design Sprint 102 workshop. As part of it, we tested 5 myths we often hear by getting people to run to different sides of a room to show if they thought a statement was true or false.

We discovered there was little consensus in the attendees’ answers.

So which side of the room would you go to? For each of the five myths below do you think the statement is true or false?

Chris running a design sprint workshop in a large glass room at UX London
Chris and Jerlyn running the Design Sprint 102 workshop at UX London 2019

Myth 1: Design sprints only work for digital products

Answer… False

Design sprints are delivery medium agnostic. If you have a business challenge that you want to give focus to by exploring, creating and testing possible solutions then a design sprint can be a valuable approach.

We’ve used design sprints to reimagine a Council’s omnichannel service delivery, to redesign billing information (including the paper version) for a utility company, as well as on many digital products.

In his Sprint book, Jake Knapp talks about using the process for making and testing a new chocolate bar. Ex-Clearleftie, Cennydd Bowles has an [ethical design sprint] ( to shape policy and procedures.

The size and nature of the design problem are more important than if the solution is digital, physical or a mix of both.

Myth 2: Design sprints are a cheap 
way to do quality design work

Answer… False

It’s easy to see the appeal to business decision-makers in the strapline from the Sprint Book. Who doesn’t want to ‘Solve Big Problems and Test New Ideas in Just Five Days’.

In organisations where there is a perception that design takes too long and innovation is costly then a design sprint may appear to be a silver bullet.

However, design sprints can be incredibly wasteful if you don’t focus on the right problem. Afterall they involve a lot of concentrated time from a team of skilled people.

The true value in a design sprint is in exploring new possibilities and learning quickly the ones that offer value to pursue further and the ones to let go.

Myth 3: You can test your prototypes
 with whoever you can find

Answer… True but …

The final day of the design sprint is set aside to test your ideas. This is where you learn what is useful and desirable for the intended audience.

Our top tip is to build as little as you can to learn as much as you can. Aim to be prototype ready not production ready. It’s okay if your artefact for testing is held together with sticky tape and string.

When it comes to who to evaluate your ideas with always test with people who belong in the space you are exploring. Shortcuts in recruiting lead to a shortfall in insight.

When testing for usability you can get away with a less strict recruit. When testing for desirability and validating user needs then make sure you research with people who’ll use your product or service.

Myth 4: Design sprints are a great way to show your organisation the value and benefit of design

Answer… True but …

As fans of design sprints, we certainly advocate using them as a low-risk and relatively low-cost method for exploring potentially high-value ideas.

We have many examples of design sprint successes both in developing new products and services but also in engaging stakeholders in the value design and design thinking offers.

However, it is easy for teams and stakeholders to become addicted to the energy and excitement a design sprint generates. There is often a danger that this leads to becoming blinkered to other design techniques.

Design sprints are best as a kick-starter but lack the rigour to deliver fully considered products or services.

Myth 5: A design sprint is a 
 five-day long process

Answer: False

The length of a design sprint is not fixed. We have taken the principles of a structured rapid design process and applied it to projects ranging from four days to three weeks. The semi-official design sprint 2.0 outlines, as a headline at least, a four-day process. Although it shrinks the week by a day by moving some activities into pre and post phases of the design sprint.

There seems to be an arms race going on to see how quickly you can run a design sprint. If you search on Medium you’ll find articles on running a one-day design sprint, topped by the five-hour design sprint that gets superseded by the three-hour version before another article trims this to a two-hour process. At some point, you don’t have space and time to explore possibilities but merely to badly execute your first obvious ideas.

Be careful of speed design. Design sprints are best to address tricky challenges with a degree of divergent thinking. If the business challenge you face is worth investigating then it needs enough time to figure out and to play around with some design alternatives that move away from just obvious and safe solutions.

Interested in design sprints?

Find out more about Design Sprints at Clearleft with a collection of our thoughts and resources to help you get more from this valuable and often misunderstood design technique.

Linear Interpolation Functions Wed, 21 Aug 2019 11:00:00 +0000 Linear Interpolation isn’t just for animation, it’s amazing for data manipulation and a worthwhile tool to have in your coding arsenal.

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

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

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

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

The four functions

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

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


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

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

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

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

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


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

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

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

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

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

Inverse Lerp

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

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

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

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

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

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


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

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

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

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

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

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

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

Typescript version

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

This was originally posted on my website.

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

What is a diary study?

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

Why conduct a diary study?

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

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

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

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

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

Evaluating tools

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

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

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

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

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

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


Designing the study

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

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

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


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

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

Preparing the participants

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

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

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

Checking in with participants before the diary study starts

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

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


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

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


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


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

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


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

Here are our top 4 takeaways:

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

Good luck with your diary study and happy researching!

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

This was originally posted on my own website.

Tiny Lesson: The 20-second gut test Mon, 19 Aug 2019 10:22:00 +0000 Ah, the sweet smell of exploring a new project’s design direction. Often one of the most exciting parts of a project, it’s where stakeholders tend to show a lot of interest.

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

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

We’ve written about this workshop before, and now you can consume it in video form.

Keep reading if you need a more detailed breakdown.

What you’ll need

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

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

The Pre-Prep

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

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

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

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

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

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

The Workshop

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

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

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

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

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

The Outcomes

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

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


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

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

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

Once again a huge thank you to our amazing speakers:

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

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

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

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

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

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

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

Designing products

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

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

Designing for people

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

Erika Hall at UX London

Designing the future

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

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

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

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

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

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

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

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

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

Government should only do what only government can do.

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

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

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

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

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

JavaScript should only do what only JavaScript can do.

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

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

Choose the least powerful language suitable for a given purpose.

Or, as Derek put it:

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

ARIA should only do what only ARIA can do.

JavaScript should only do what only JavaScript can do.

CSS should only do what only CSS can do.

HTML should only do what only HTML can do.

This was originally posted on my own site.

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

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

A bit of background

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

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

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

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

Challenges and change

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

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

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

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

Making meaning

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Through the keyhole

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

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

Design debt

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

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

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

7 ways to make design and agile play well together

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

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

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

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

1. Use Sprint zero

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

2. Do a best first pass

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

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

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

3. Have a North star

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

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

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

4. Get your Devs involved early

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

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

5. Work in swim lanes

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

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

6. Always zoom out

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

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

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

7. Keep 10% time

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

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

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

A post agile world

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

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

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


This article was originally published at

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

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

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

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

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

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

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

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

This was originally posted on my own site.

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

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

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

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

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

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

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

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

So what comes first, the copy or the UI?

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

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

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

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

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

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

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

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

How UX writers add value to teams

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

Realistic testing

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

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

Elevating designs

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

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

John Saito

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

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

Getting the tone right

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

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

Improving conversion

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

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

Five quick ways for designers to think more about content

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

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

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

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

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

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

Work across multiple touchpoints

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

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

So consider…

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

Meet everyone’s needs

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

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

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

So consider…

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

Build a lasting relationship

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

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

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

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

So consider…

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

Aid speedy recovery.

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

So consider…

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

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

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

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

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

Systematised design

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


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

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

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

Systematised design in the wild


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

Fundamentals - the guiding principles for design, content and technology

Stuff in the middle

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

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

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

Pattern library (a.k.a component library)

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

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

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

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

Templates and pages

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

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

Templates & pages - components assembled into 
structures and larger groups


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

Amy Hupe, Content Strategist at GDS says that…


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

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

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

Design system

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

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

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

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

The onion

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

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

The onion - layers of systematised design

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

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

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

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

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

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

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

Lastly, it’s not about the label

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

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


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

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

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

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

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

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

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

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

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

Silent sketching

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

Sketch example

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


Time for feedback

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

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

Dot voting

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


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

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

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

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

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

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

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

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

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

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

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

You’ve all made me very happy.

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

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

— (@dhuntrods) June 29, 2019

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

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

— Alla Kholmatova (@craftui) June 29, 2019

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

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

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

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

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

— Dave (@daveymackintosh) June 28, 2019

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

— trash bandicoot (@freezydorito) June 28, 2019

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

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

— Andy Bell (@andybelldesign) June 28, 2019

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

— Kimberly Blessing (@obiwankimberly) June 28, 2019

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

— Dan Donald (@hereinthehive) June 28, 2019

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

— Alex (@alexandtheweb) June 28, 2019<

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

— David Roessli (@roessli) June 28, 2019

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

— Garrett Coakley (@garrettc) June 28, 2019

This was originally posted on my own site.

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

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

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

A missed opportunity

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

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

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

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

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

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

Design systems which have successfully incorporated content:

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

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

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

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

So, where to begin?

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

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

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

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

Integration is key

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

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

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

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

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

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

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

Bar chart

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

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

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

Bar chart

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

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

Bar chart

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

bar chart

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

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

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

Read the full Design Effectiveness report.