Clearleft | Blog https://clearleft.com/posts/ The latest news from Clearleft en-gb Sat, 28 Nov 2020 19:06:33 +0000 Sat, 28 Nov 2020 19:06:33 +0000 Static sites, slack and scrollytelling. https://clearleft.com/posts/static-sites-slack-and-scrollytelling Wed, 18 Nov 2020 13:23:00 +0000 https://clearleft.com/posts/static-sites-slack-and-scrollytelling Since I started at Clearleft, I’ve had my eye on our timeline…

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

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

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

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

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

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

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

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

a screenshot of an airtable database

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

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

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

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

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

The fun bit

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

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

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

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

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

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

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

]]>
Dashboards: a design discussion https://clearleft.com/posts/dashboards-a-design-discussion Thu, 12 Nov 2020 13:03:00 +0000 https://clearleft.com/posts/dashboards-a-design-discussion We have regular design debates here at Clearleft. A few months back, we had a provocation prompted by a tweet.

Our friend Jared Spool tweeted:

Dashboards are often what customers ask for.

They are rarely what customers need.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

]]>
Service Designers don’t design services, we all do https://clearleft.com/posts/service-designers-dont-design-services-we-all-do Wed, 11 Nov 2020 12:04:00 +0000 https://clearleft.com/posts/service-designers-dont-design-services-we-all-do Sometimes I wonder if the design industry—and particularly the digital space—has over-complicated things.

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

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

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

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

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

Service dimensions

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

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

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

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

iPad showing the cityclean app

Pushing the service dimensions

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

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

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

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

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

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

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

Good luck everyone in pushing those dimensions.

]]>
Accessible interactions https://clearleft.com/posts/accessible-interactions Thu, 29 Oct 2020 09:49:00 +0000 https://clearleft.com/posts/accessible-interactions Accessibility on the web is easy. Accessibility on the web is also hard.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So I can answer my first two questions:

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

…by answering a different question:

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

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

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

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

When the target isn’t being shown:

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

When the target is shown:

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

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

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

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

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

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

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

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

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

This was originally posted on my own site.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Say hello to our new owners

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

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

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

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

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

Now’s the time

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

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

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

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

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

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

]]>
Engineering Neon https://clearleft.com/posts/engineering-neon Wed, 07 Oct 2020 13:10:00 +0000 https://clearleft.com/posts/engineering-neon EngineeringUK is a non-profit on a mission to inspire the young people of today to become the engineers of tomorrow.

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

Bringing STEM to life through real-world engineering

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

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

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

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

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

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

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

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

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

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

Identify relevant characteristics of your participants

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

Double-check your ability to contact people

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

Define incentives and delivery

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

Identify key gatekeepers and their involvement

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

Prepare a communication and contact plan

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

Screen your participants

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

Prepare for rejection

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

Define metrics of success and corrective actions

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

Don’t take shortcuts

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

]]>
Performance and people https://clearleft.com/posts/performance-and-people Mon, 28 Sep 2020 16:01:15 +0000 https://clearleft.com/posts/performance-and-people I was helping a client with a bit of a performance audit this week.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This was originally posted on my own site.

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

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

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

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

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

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

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

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

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

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

]]>
Tiny lesson: Netlify redirects and downloads https://clearleft.com/posts/tiny-lesson-netlify-redirects-and-downloads Mon, 14 Sep 2020 10:39:00 +0000 https://clearleft.com/posts/tiny-lesson-netlify-redirects-and-downloads Making the Clearleft podcast is a lot of fun. Making the website for the Clearleft podcast was also fun.

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

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

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

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

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

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

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

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

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

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

<a href="/files/ugly-file-name.xyz" download="nice-file-name.xyz">download</a>

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

<a href="/files/nice-file-name.xyz" download>download</a>

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

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

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

/download/*  https://clearleft-audio.s3.amazonaws.com/podcast/:splat  200

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

Oh, and the 200at the end is the status code: okay.

Now I can use this /download/ path in my link:

<a href="/download/season01episode06.mp3" download>Download mp3</a>

Because this URL on the same origin, the download attribute works just fine.

This was originally posted on my own site.

]]>
SofaConf 2020 talks are now live https://clearleft.com/posts/sofaconf-2020-talks-are-now-live Wed, 09 Sep 2020 13:16:00 +0000 https://clearleft.com/posts/sofaconf-2020-talks-are-now-live This June we brought together 18 speakers from the world over with 1000 attendees, for five days of incredible content, entertainment and a good number of impromptu pet photos for SofaConf.

SofaConf was our first foray into online events and we were delighted by the positive feedback we had from attendees and speakers. Amidst all the challenges 2020 has presented to our communities it felt great to be able to bring folks together and share amazing content from industry leaders directly from their living rooms to ours…

We’re now able to publically share all the talk videos and live Q&As from SofaConf. Whether you are interested in product design, content design, research, service or interaction design we’re sure you’ll find these brilliant talks and discussions inspiring and full of valuable learnings you can action.

We’d like to extend a huge thank you to all our speakers and our wonderful compères, Rachel McConnell and Andy Budd for such a great show. We’d also like to thank our wonderful sponsors, Google, InVision and Intercom for their support in making this event happen.

Day 1: Product Strategy

We kicked off on Monday with Product Strategy - our four stellar speakers gave tips and techniques to get the most from your product teams, prioritise and plan effectively, and achieve consistently great outcomes.

Melissa Perri, The Secret Weapon To Finding Focus

Josh Seiden, Outcomes Over Output

Haroon Aslam, Advanced Facilitation: Using a Designer’s Toolbox to address Organizational Strategy

John Cutler, Healing The Designer/Product Manager Divide

Day 2: Research

Day Two was all about Research, an area with particular relevance in this era as we increasingly move our work online. Remote research techniques aren’t new, but now we’re reliant on them, how do we make them even better? Our speakers were on hand to share their learnings and case studies.

Leisa Reichelt, Things We Learned About Ourselves And Our Research Practice From Our Internal COVID-19 Surveys.

Kelly Goto, Fieldwork From Home

Rachel Price, You’re on the Air, I’m Listening: Facilitating Remote Research

Quote from Leisa Reichelt reading "Half of the company has no idea what the research does and how it contributes value"

Day 3: Service Design

Our third day brought together experts in Service Design who explored creating simpler experiences across fast-moving organisations and embedding behaviour change and scale service-design thinking. They shared stories from their experience as well as actionable tools and insights.

Lou Downe, Good Services: Building User-Centred Organisations At Scale

Marc Stickdorn, 20 Tips - How To Embed And Scale Service Design In Organisations

Akil Benjamin, AK Experiments

Dr Sarah Drummond, Full Stack Service Design

Day 4: Content Strategy

Day four was curated by ex-Clearleftie Rachel McConnell and was all about Content Strategy. Whether you’re a designer, team lead, product owner or content expert, if you are interested in taking your content to the next level, these talks and discussions are for you! The Content Strategy day brought together world-class content designers and strategists to show how they create impact, integrate content into the design process, and scale the role of content. It’s worth saying we were so sad not to be able to hold Content Design in 2020 (it would have been on the date we held SofaConf) and although we couldn’t bring together the brilliant line up we had in store, it was great to be able to bring these three incredible content experts together with Rachel at SofaConf.

Amy Hupe, Designing Content For Emotionally Distressed Users

Jonathon Colman, How We Destroyed Content Design

Kristina Halvorson, In conversation with Kristina Halvorson

Day 5: Interaction Design

Our fifth and final day focussed on Interaction Design. Whether you’re creating new experiences, or optimising existing ones, you’ll find great tools and insights from these talks and discussions as our speakers share their advice for problem-solving, testing, and effective design.

Ross Chapman, Remote Sprints

Simeon Wishlade, How To Lose Less In AB Testing

Richard Banfield, Organisational Underwear: How To Successfully Collaborate With Cross-Functional Teams

Lex Roman, Practicing Growth Design

Quote from Richard Banfield saying "Trust is like a bank account, you have to make small deposits"

And then some...

We shared some of our favourite talks curated from past conferences which we thought would be interesting and relevant. These included Director of User Experience Design at Google Magaret Lee’s talk from 2018 ‘Insights from a Reluctant Leader’. And Farai Madzima, UX Lead at Shopify talk from 2019 ‘Cultural Bias in Design(ers)’.

Some of our speakers across the event joined us to answer a few questions about themselves, their role and their talk topic before the event which you can read on Medium.

SofaConf wasn’t all talks, we also had social sessions, entertainment and some yoga classes from the lovely Jeff Phenix especially designed to help counteract the effects of sitting at a desk all day long. We’ve shared his two short classes, one which is designed to be done seated and the other more of a vinyasa flow class.

Finally, we have had all these films closed captioned as part of our ongoing commitment to improve the accessibility of our events.

We hope you enjoy the content from SofaConf, we are currently plotting and planning our next online event so do join our mailing list if you’d like more information.

]]>
Tiny lesson: Project Canvas https://clearleft.com/posts/tiny-lesson-project-canvas Thu, 03 Sep 2020 11:19:00 +0000 https://clearleft.com/posts/tiny-lesson-project-canvas Miro has changed the way we work. It seemed logical to convert our much-loved Project Canvas template from 2015 into an open-source board and share a short Tiny Lesson on how we use it.

What's a project canvas?

Being able to concisely articulate the purpose, audience, vision and goals of a project is crucial. Yet it’s harder than it sounds. Other well-known canvasses can feel too large and grandiose, or far too granular. This project canvas — like Goldilocks’ porridge — is just right. It provides key information that is summative, visible and, crucially, relational. Through open dialogue and collaboration, the canvas helps to create a shared understanding around the brief and goals of the project, aligns the entire team, exposes unknowns and assumptions and provides a strategic purpose to the project at hand.

Project Canvas Miro board
Our Project Canvas Miro board

When should I use it?

A project canvas is a great kick-off exercise, as a collaborative and remote workshop. The canvas highlights and makes visible the relationships, dependencies and intentions that are often intangible or muddy at the start of many projects.

However, the canvas shouldn’t be used once and thrown away. Using a Miro board makes it revisitable at any time. Ideally, the canvas should be updated as and when needed, with new project intel, stakeholders or if the scope changes.

Sounds good. So how do I start?

There is no linear method for using the project canvas. It is laid out in three separate altitudes that provide varying levels of strategic detail, and four pillars that address the purpose, audience, vision and goals for your project. You might want to start with the ‘known knowns’ such as the audience, stakeholders and team. Or you might want to start large and uncover the proposition and vision. It’s entirely up to you.

Here are some tips to get the most out of your project canvas:

  • Involve the widest team possible - get your team and stakeholders involved.
  • Look to uncover and unpack assumptions.
  • Use as a way to create alignment and reduce opacity, build a shared understanding.
  • Treat it as a summative, high-level view of your project at hand.
  • Show the meaning and intentions behind the project, it helps provide the bedrock for a successful outcome.

To learn more read our original blog post on canvassing a project.

Start using the Miro board here

]]>
When the going gets tough, the tough get training https://clearleft.com/posts/when-the-going-gets-tough-the-tough-get-training Mon, 17 Aug 2020 10:32:00 +0000 https://clearleft.com/posts/when-the-going-gets-tough-the-tough-get-training Just because your training budget has stopped doesn’t mean your training should. Instead of making cuts to staff training, I want to suggest some alternative and cost-effective ways to achieve similar results.

In times of economic uncertainty, one of the first things to get cut and last to get reinstated is the training budget. Upskilling staff is often perceived as an unjustifiable expense. A luxury, an extra, a perk only to be rolled out during the good times.

Yet team members who feel invested in with up-to-the-moment skills are likely to be the catalyst for the growth of your business.

Make learning a habit

Whether you are a military unit, a dance troupe, a sports team, or a rock band, training is the way to become match fit or performance-ready. For any team, the results you achieve have a direct correlation to the practice you put it.

At Clearleft we have a long-standing culture of learning. It’s one of the things that personally appealed to me before working here and has carried on since.

One of our values is ‘Learn and share. Share and learn’. This gets lived out in numerous ways:

  • We put on prestigious conferences from the recent remote SofaConf to UX London, Leading Design and dConstruct.
  • Our practitioners coach students on digital design courses, this year running sessions pre-lockdown at Ravensbourne University London and remotely at the University of Greenwich.
  • You’ll find us involved with and regularly talking at meetup groups such as Codebar, Ladies that UX and nUXers Brighton.

So what can you do when training budgets are frozen and your team are working remotely?

Here are three ideas for some cost-efficient but still effective ways to engage and upskill your digital team.

School room Photo by Nathan Dumlao on Unsplash
Photo by Nathan Dumlao on Unsplash

1. Start with a list

There’s no shortage of useful training materials online, much of which is free. More often, the challenge is narrowing down what to learn and then finding quality resources to use.

To give yourself focus, ask your team for a long list of their learning objectives. Get them to review their development plans and to plunder any bookmarks and lists of topics they have identified. Go broad and go big.

Once you have a longlist ask the team to prioritise a selection. It’s useful to get the team to think about the skills to polish up on now that will be useful to improve the quality of their upcoming work. Don’t think too far into the future.

We recently ran three remote training sessions for a global software company. The first two sessions covered product design and research techniques which had been identified as areas for training. However, we purposefully left the agenda for the third session unspecified so the participants could decide what they wanted additional coaching in. Giving the team a say was a powerful way to empower them in the development of their skills.

Armed with your list of potential training topics, start to curate the resources to use. Now, this doesn’t have to be as daunting as it might sound.

Three ways to quickly find quality content are:

  • Ask for recommendations from the team, your network and from the hive mind on social media.
  • Think about who you know who you could offer to do a reciprocal skills swop with.
  • Pay a person or company to curate a list of bespoke material for you based on your requirements.

Creating a calendar of training sessions will help your staff develop the habit of training and for you to ensure there is a variety of both topics and delivery styles.

2. Training together but apart

Going to a conference, sitting in an auditorium and listening to a speaker was as much about being part of a shared experience with the audience around you.

To (almost) replicate this remotely, set a time and place for your team to collectively watch or listen to a presentation and then discuss it afterwards. This is most effective when everyone is consuming the media at the same time and even better if the follow-on discussion or activities have some structure. Zoom, Meet, Teams are all ideal for streaming talks and collectively conversing afterwards.

As a starting point, if you want some inspiration dive into the Clearleft video archive.

On Clearleft’s Vimeo channel, you’ll find 178 videos from the conferences we organise. You’ll find amazing talks covering a vast swathe of topics from Leading Design, UX London, Patterns Day and Ampersand.

Alternatively, the audio archive from 10 years of dConstruct is an audio treasure trove of 3390 minutes of insightful thinking from the brightest minds in the digital design industry.

3. Give some training

Another idea is instead of receiving training why not give some training? Every project team I’ve worked in – both agency colleagues and client’s teams – have such untapped potential to teach something useful to their teammates.

At Clearleft we have a range of formats for sharing tips and advice.

At the end of the week wind-down, people are encouraged to show and tell project work, demo tools and share techniques that they’ve been using. It’s informal, short and requires little preparation.

Up a level from this, we regularly hold brown bags. These have continued even whilst working remotely. The format is simple. Over lunch, someone will talk through something of interest. The eclectic nature of the talks keeps the format interesting.

Some examples of sessions include project teams giving highlights of their projects, Cassie recently walked through the rebuild of her SVG animation rich website, we had clients from the Natural History Museum talk about what goes on behind the exhibition halls and a designer from OpenTable showing us their process for A/B testing.

Getting a little more formal we also do longer form training sessions within the team. These provide the opportunity for someone to provide a more considered or in-depth presentation on a topic. Recent subjects have included facilitation skills for running remote workshops, and a run through by Katie of a talk she gave on service design at Future London Academy.

The value of training

Ongoing training is vital in maintaining and developing a highly-skilled team. The rate of change in how digital products and services are delivered benefits teams who adopt a culture of continuous learning.

Training doesn’t need to be expensive to provide value to both staff and the business.

In the current climate of forced remote work, and the potentially isolating effect this can have, training offers an opportunity to bring your team together to collectively and collaboratively develop skills together.

]]>
Season one of the Clearleft podcast https://clearleft.com/posts/season-one-of-the-clearleft-podcast Thu, 13 Aug 2020 14:38:00 +0000 https://clearleft.com/posts/season-one-of-the-clearleft-podcast The Clearleft Podcast has finished its inaugural season.

I have to say, I’m pretty darned pleased with the results. It was equal parts fun and hard work.

Episode One

Design Systems. This was a deliberately brief episode that just skims the surface of all that design systems have to offer. It is almost certainly a theme that I’ll revisit in a later episode, or even a whole season.

The main goal of this episode was to get some answers to the questions:

  1. What is a design system exactly? and
  2. What’s a design system good for?

I’m not sure if I got answers or just more questions, but that’s no bad thing.

Episode Two

Service Design. This is the classic topic for this season—an investigation into a phrase that you’ve almost certainly heard of, but might not understand completely. Or maybe that’s just me. In any case, I think that coming at this topic from a viewpoint of relative ignorance is quite a benefit: I have no fear of looking stupid for asking basic questions.

Episode Three

Wildlife Photographer Of The Year. A case study. This one was a lot of fun to put together.

It also really drove home to just how talented and hard-working my colleagues at Clearleft are. I just kept thinking, “Damn! This is some great work!

Episode Four

Design Ops. Again, a classic example of me asking the dumb questions. What is this “design ops” thing I’ve heard of? Where’d it come from?

My favourite bit of feedback was “Thanks to the podcast, I now know what DesignOps is. I now also hate DesignOps”

I couldn’t resist upping the ante into a bit of a meta-discussion about whether we benefit or not from the introduction of new phrases like this into our work.

Episode Five

Design Maturity. This could’ve been quite a dry topic but I think that Aarron made it really engaging. Maybe the samples from Bladerunner and Thunderbirds helped too.

This episode finished with a call to action …with the wrong URL. Doh! It should’ve been surveymonkey.co.uk/r/designmaturity

Episode Six

Design Sprints. I like how the structure of this one turned out. I felt like we tackled quite a few angles in less than 25 minutes.

That’s a good one to wrap up this season, I reckon.

If you’re interested in the behind-the-scenes work that went into each episode, I’ve been blogging about each one:

  1. Design Systems
  2. Service Design
  3. Wildlife Photographer Of The Year
  4. Design Ops
  5. Design Maturity
  6. Design Sprints

I’m already excited about doing a second season …though I’m going to enjoy a little break from podcasting for a little bit.

As I say at the end of most episodes, if you’ve got any feedback to offer on the podcast, send me an email at jeremy@clearleft.com

And if you’ve enjoyed the Clearleft podcast—or a particular episode—please share it far and wide.

This was originally published on my own site.

]]>
Using your status as a speaker to promote others https://clearleft.com/posts/using-your-status-as-a-speaker-to-promote-others Thu, 13 Aug 2020 11:59:00 +0000 https://clearleft.com/posts/using-your-status-as-a-speaker-to-promote-others Being invited to speak at a conference is a privilege, and we can use that privilege in a number of ways.

For newer speakers, the most obvious benefit of speaking is to advance your career. Speaking at an event confers a certain amount of legitimacy and status. The fact that you’re on stage and other people are listening to you implies that you’re somebody who deserves to be listened to. That your ideas hold value that the other people in the audience will benefit from them. This is a great thing to have in your back pocket at interviews, and is sure to impress the person doing the interviewing.

Speaking at a conference also helps raise the status of the company you work for, which is why so many companies are keen to encourage their staff to speak. If you say smart things, the audience will naturally ascribe those thoughts to both you and the company you work for. They’ll think “company X hires really smart people” or “I like the way folks from company X think”. This leads to tonnes of ancillary benefits for the company like finding new customers, attracting new talent, and generally raising the brand even further.

If you come from a recognisable brand, this works the other way around as well. While folks may not have heard of you, they may have heard of the company you represent. This will create a bit of a halo effect around you as a speaker, and confer some of the company’s brand value on to you. “I like the work company X does, this person is from company X, so I’ll probably like them and their work too”. In truth, this is often the way new speakers break into the speaking circuit—by utilising the value of their employers brand.

New speakers (as well as more experienced ones) also get to benefit from the connections they make—especially with other speakers. They may also get exposed to new job offers from employers in the audience who were impressed with their spiel. As such, there’s a lot of very good reasons why individuals can benefit from this sort of exposure.

Of course it’s not all about the person speaking.

The very best speakers will usually have something important they want to say. Something they feel really strongly about, and wish to share with their peers in order to make their lives better. Maybe they’ve just come up with a clever technique that makes folks’ lives easier and want to share it with as many people as possible? Maybe they’ve seen people making the same mistakes over and over again that’s easily avoidable if they just do this one small trick? Or maybe they’ve been the brunt of some sort of challenge or injustice and are looking to highlight these problems and drive a deeper systemic change. Whatever their motivators, making a platform is a powerful thing, and something not to be squandered.

As a result of the Black Lives Matter movement, a lot of experienced speakers are looking for ways to do more with their privilege; to use the power, connections and opportunities they’ve been given to raise others up. One simple way to do this is to pepper your talks with references and quotes by peers from under represented groups. I’ve seen this done a number of times and it can be super effective.

However the more obvious solution is to step aside and recommend speakers from underrepresented groups who could take your place. This is a wonderful, altruistic thing to do. To offer up your place to somebody else who you know would value it more than you. This approach works, but maybe not as often as it should. Unless the people we recommend get picked, we haven’t made any significant change; we’ve just made ourselves feel good. Fortunately there are a few small, simple things we can do to improve our hitrate here.

The first thing to do is to understand why the conference organiser has reached out to you in the first place. Was it because of a specialism you hold, a talk you’ve done in the past, or a project you worked on; or was it simply down to the company you work for and the position you hold?

Many conference organisers—especially smaller ones— may simply be looking for a speaker from a well-known brand to help them sell tickets. In this case, it’s really easy to suggest an alternate speaker. You simply say something along the lines of “Unfortunately I’m not available but my colleague X would love to speak”. If you’re lucky, that’s all you need to do.

However, these pesky conference organisers probably want to make sure that the person you’re recommending is actually a good speaker and not just a report who mentioned wanting to do more public speaking in their last evaluation. As such it’s usually a good idea to send a link to a recent talk from that person, rather than just a list of names. If it comes with a personal recommendation, even better. Something like “I’m afraid I’m not available but I saw X do an amazing talk at Y recently. I think they’d be perfect for your event, so would you like an intro?”

Sometimes conference organisers aren’t just looking for any old speaker—amazing I know. Sometimes they’re looking for somebody with a specific angle to talk about a specific topic. In these instances, it’s helpful to understand what role the organisers were wanting you to fill, and recommend a speaker you know can do similar. “I’m afraid that I can’t make this event, but I saw X give a really good talk on the same subject as me at Y recently, and I was really impressed. In fact, I was thinking of using some of their ideas in my next talk. Want me to make an intro?”

From a conference organisers perspective, this is probably the perfect recommendation. You’ve had personal recommendations from somebody you trust. They’ve seen the person speak, can vouch for them, and have shared a link to see for yourself. They’ve even said that they’ve been so inspired by that person that they’re going to use some of their ideas in future talks themselves. This person is somebody I definitely want to speak to.

This is great, but what if the people you want to recommend aren’t as established as you?

Maybe they haven’t even spoken before. You have an inkling that they’ll be good, but you don’t really know.

If you have somebody on your team who wants to speak at a conference, before giving up your seat and thrusting them into the limelight—or under the bus—it may be worth investing a little more time in their development. Consider spending some time in your one-to-ones to pull out the topics they’d like to speak about. I can’t tell you the number of times I’ve had folks tell me they’d like to speak at one of our events, but then have no clue what they’d speak about (TOP TIP: “Oh, whatever you want me to speak about” isn’t a good answer). Once they’ve got some ideas starting to develop, help them write a talk description, help them put together an outline, help them write a first draft and give them feedback. Find opportunities inside the company for them to speak first, and try and record their sessions if you can. Many a great talk started life as an internal brown-bag session, got honed at community meet-ups, and only then found its place on a conference stage.

You see, developing one of your team as a new speaker is more than just throwing out their names in an email. It’s about investing in that person and helping to transfer some of the skills that have made you such a good speaker over to them.

Another great way to develop new speakers is to suggest that you do a joint talk. The conference still gets to have you on the bill for all the reasons they reached out in the first place, but now they get a second amazing speaker as a result. You get to confer some of your legiticancy on them, and they’re going to learn a tonne about being a great speaker from you in the process. This effectively takes ALL—or at least most—of the risk away form the conference organiser, while using your platform to raise somebody else up. As such it’s a win-win for everybody involved.

This works especially well if the conference is looking for you to talk about a specific project. Sure you may have overseen the project—and claimed much of the Kudos from that Medium article you wrote about it a few months ago—but you know that your team put the hard work in. So suggesting a joint talk where you frame the project, and then have your colleague jump into the details, can work really nicely. In fact I know several well established speakers who started their speaking careers in this way. Very soon they’d eclipsed the person that got them on stage in the first place, and had developed their own stand-alone speaking career.

It’s often harder if the people you’re recommending don’t work for you. However it’s worth thinking about why exactly you’re recommending them. Maybe you haven’t seen them speak, but you read a really smart article they wrote a few months ago. Or maybe you’re aware of the work they did on a specific project. Any background you can give about why you’re suggesting them as a potential alternative is better than a list of unqualified names. If you’re unable to confer a sense of equivalence to the conference organiser—that you’re confident that the person you’re recommending would do an equally good job as you—the chance of that person being selected is fairly slim. So the more evidence you can supply to underpin your recommendations the better.

]]>
2020 Women in Software Power List https://clearleft.com/posts/2020-women-in-software-power-list Wed, 05 Aug 2020 09:01:37 +0000 https://clearleft.com/posts/2020-women-in-software-power-list The Women in Software Power List celebrates and showcases the female rising stars in the UK’s coding community.

Created by Makers Academy and in partnership with ComputerWeekly, Google for Startups and Level39. This year’s theme was Changing the narrative. Independent judges helped whittle hundreds of initial applications down to 30 women who are considered rising stars in the software sector across various industries and who have made a significant contribution to software development in the past 10 years.

Cassie working at her desk in the Clearleft office in a colourful shirt

We hope that initiatives such as the Women in Software Power List will encourage more women to play a part in developing tomorrow’s breakthroughs and therefore helping to shape all of our lives for the better. There’s so much talent in the UK, and through our Power List, we are extremely thrilled to identify some of the best, high-calibre and game-changing women who are advancing our community for the common good.

Evgeny Shadchnev

By publishing the list, Makers aims to make some of the role models in the software industry more visible and accessible. You can read the full list here.

Cassie codes colourful homepage with a desk illustration

Cassie has recently also launched a highly acclaimed personal website which won a CSS Design Award and is now a frequent speaker on the International circuit. We certainly see her as a rising role model for others.

]]>
Delivering training remotely – the same yet different https://clearleft.com/posts/delivering-training-remotely-the-same-yet-different Tue, 04 Aug 2020 15:14:00 +0000 https://clearleft.com/posts/delivering-training-remotely-the-same-yet-different I find training people in UX, research and digital design skills both a rewarding and fascinating part of my role at Clearleft.

Over the years I’ve done a fair amount of remote training sessions. However, my preference has always been for delivering in-person classroom-based training. Well, times have changed. For me, this has been an opportunity to reconsider the best ways to run training at distance.

I recently had the privilege of running some training sessions with the design team at Duck Duck Go. We covered product design and research techniques. Beyond having a great search engine that puts privacy first, they are also a really interesting team that has always been distributed. The training sessions were attended by 10 people, in 4 continents, across 8 timezones.

As with the best training sessions, as a facilitator, I learned some new things from the attendees. In particular, I got their tips on maintaining engagement and energy when working apart.

With training in mind, here are three differences to consider when going remote.

Less attention and more disruptions

In a training room, you have a high level of control of the environment. You can arrange the seating, lighting and equipment to best suit the activities you have planned. As you move from one activity to the next you can switch the room around to meet your needs.

Going remote requires letting go a little. Rather than trying to control every aspect of the environment, learn to embrace more chaos. Being more on the edge and improvising when needed adds positive energy to the sessions.

Even with everyone in front of a screen plan for breaks in attention. Audio will drop out, the live stream will freeze, someone will have a knock on their door and their cat will be making an unscheduled appearance. Build in some time for all of these occurrences and more.

Instead of beating yourself up for the few inevitable technical glitches reframe around the positives. After your session, make a list of what went well before thinking about the ‘even better ifs’.

Ice breaker remote training activity where we asked people to pin their mugs to the Miro board
Finding remote ways to get to know your attendees

Getting comfortable with deafening silences

As a facilitator, there is a loneliness to remote training. In a physical setting, when the attendees were heads-down in an activity, I’d prowl the room and pick up on how people were getting on with the task at hand.

No more. Now I set up an activity and then … nothing. With people muted or working away in breakout rooms there is an unnerving silence.

The same happens when you’re giving information or instructions. In a physical space, you can feel if what you are saying is making sense, if people have questions, and how engaged they are.

When you are training in a virtual space it’s hard if not impossible to accurately read the room. You have to put more faith in your material. Trust yourself that you are making sense and your gags are getting a response.

If the people you’re training are heads-down in an activity, don’t fill the void by chattering away. It’ll break their concentration. Equally, resist the temptation to fill the time by looking through Slack or social media. Stay present, just quiet.

Countering the energy drain

Concentrating on a computer screen for an extended period of time is hard. Being static, sitting down, headphones on and staring into a panel of glowing glass is exhausting.

Facilitating and attending remote training drains a person’s battery more quickly than being in the same space together. For the training for Duck Duck Go, we deliberately broke the sessions into smaller chunks and spread them over 3 days with none of them longer than 3 hours.

Remember to be kind to your participants. Make sessions shorter. Switch between different styles of activities. Vary group sizes (the breakout room feature on Zoom is excellent for this). And include more frequent breaks.

One of the best pieces of advice I got when I started planning coaching sessions was to start with the breaks and then add in the activities around these. Even if you are the most compelling tutor, people who are tired, thirsty and desperate for the toilet just can’t concentrate on what you have to say.

Having the team at Duck Duck Go span so many timezones presented an unexpected concentration-sapping challenge. Running the training during the early evening (at least for the timezone I was in) left me spending the last hour of each session catching tantalising smells from the food my partner was preparing. You don’t have to deal with that situation when coaching in a training room!

It’s the same but different

The good news is most of the skills you have as a facilitator and most of the material you use for face-to-face sessions easily translate for remote training. It’s more of an evolution of the activities, resources and ideas rather than a revolution.

The more I do online training the more I think there’ll be a time in the near future when I’m writing a companion article to this one. But next time it will be on new things I’m learning when readjusting to coaching in a classroom in front of attendees.

If you run remote training sessions I’d be interested in hearing what you think the key differences are and what changes you have made to deliver successful learning outcomes.

]]>
The nature of change https://clearleft.com/posts/the-nature-of-change Mon, 27 Jul 2020 09:38:00 +0000 https://clearleft.com/posts/the-nature-of-change We are likely standing on the brink of an era of either dramatic collapse or radical regeneration. From our collective perspective in the thick of change, it’s impossible to tell which path we are on and how we can ensure the right path succeeds.

However, for the esoteric systems thinkers, agents of change and restless digital transformers amongst us, an idea called the Two Loops theory could be a useful model that serves as a timely reminder of some easily overlooked aspects of how change occurs.

The Two Loops model describes the process of change in complex living systems observed in nature. The theory goes that by learning from the cyclical characteristics of the natural world we can more consciously and intelligently manage change of any kind, whether it be individual behaviour change, organisational transformation, or something much bigger.

Given the turbulent times we find ourselves in, perhaps there is no better time to connect with deeper, more universal truths, and find a constructive way to transition away from our current situation and onto greener pastures.

Paradigm shifts

The theory goes that an ecosystem can be thought of as a complex and constantly evolving ‘hyper-organism’ of change. Everything within an ecosystem moves along an irreversible timeline: Each and every part or element of the system begins in a state of ascendancy or growth, before its descent into decay. Decline is inevitable, as predictable as death superceding life, by following the laws of thermodynamics and entropy.

When enough complementary elements of the system grow and coalesce at the same time, a critical mass of change emerges, creating the possibility that one day the system will recognisably transform from its current state to this newer offspring - a ‘paradigm shift’ in the system itself. Although the new paradigm isn’t immediately or universally adopted, it is because of the ongoing process of growth and decay that the system already consciously or even unconsciously reacts and adapts to this next possible incarnation. It’s dominant characteristics continuing to evolve over time despite any collective intent or resistance to such a change.

This difficult to articulate concept is simplified in the model as one loop that ascends and descends like a hill (the ‘incumbent’ state), followed by a second loop which descends and ascends like a valley (the ‘insurgent’ state), hence ‘two loops’. The two loops aren’t directly connected to each other to represent the fact that this transition between states, the paradigm shift, needs to be bridged and nurtured to succeed.

Two Loops theory of change: Migrating from todays status quo to tommorows
Two Loops theory of change: Migrating from todays status quo to tommorows

This innate knowledge of how the natural world works is so intuitive it almost feels foolish to articulate it. We all learn as children that flowers bloom, bees pollinate and nutrients feed the soil to fertilise new life. So obvious. So what?

Well, on reflection, it seems odd we rarely apply the same logic to the systems of organisations we work for, or the civilisations we live in. What is interesting and useful about Two Loops is the conscious recognition of a few key principles:

  1. The ongoing transition between growth and decay of a given system is cyclical, without exception. Enough sensory awareness of an imminent paradigm shift helps forecast the demise of the system’s current state, and acts as a conscious precursor to prepare for the rise of its successor.

  2. Enabling a paradigm shift in a system to be a harmonious transition requires stewardship; both the nurturing of the new, alongside an equally considerate retirement of the old. Change is more naturally inclined to be slow and painful rather than an immediate change from one state to the next, so dealing with the pain is important.

  3. Most astutely is the recognition that Two Loops helps us reflect on our disillusioned state of existence. Fraught with tension due to the ongoing denial of unavoidable truths that come with living in a shared, all-encompassing natural system, pitting unsustainable pollution, consumerism and population growth alongside finite fossil fuels, mineral resources and species diversity in decline.

Growth and Decay

Regarding the first principle, the dominant mode of thinking within society today, especially within the business world, can often be biased towards the mathematical or mechanistic. A reductionist logic encourages us to believe that if parts of a system are broken, we simply fix the broken parts and the system will return to ‘normal’. The same system, but better. Optimised.

If we believe that the ebb and flow of the natural world carries a broader, more universal logic, this fixation on fixing would be a fallacy.

10887

In a natural world governed by entropy, nothing is static or can be maintained. ‘Normal’ is at best a temporary state. Two Loops can help better prepare for the ongoing inevitability of a new system paradigm, rather than unduly investing in an ailing status quo.

Nurture and Retire

We are also too often trapped by binary thought when it comes to conceptualising change. Seeing things as existing in a single static state, either new or old, rather than on a transition of ongoing change between the two. We dwell too long or too cautiously in the old when the new is too intimidating or unknowing to easily adopt. Or inversely, we sometimes obsess on the novelty or opportunity of the new because of the boredom or decrepitude of the old.

Nowhere is this binary thinking more the case than in economics and politics. Looking at the last 40 years, Two Loops theory is a helpful lens to interpret how critical moments of change were hijacked to accelerate the demise of “undesirable” paradigms (to those who instigated them), such as Latin American socialism or Chinese or Soviet communism, whilst simultaneously injecting new ones, such as corporate neoliberalism, in the form of aggressive economic reform. The handprints of this proactive substitution of the State for the Market, under various guides, are evident on almost every major global economic shift in the last 40 years. In no case did any of these transitions avoid very real casualties for the sake of an orderly migration from old to new. Needless to say, this is quite a heavy and extensive subject so I recommend a read of The Shock Doctrine if you’re interested in finding out more.

In this regard, Two Loops helps us appreciate the successful transition from old to new is more of a gradual flux than the simple flicking of an on/off switch.

10891

The next paradigm

At this point of incredible turbulence in our society, politics and environment, it’s difficult to reject the notion that we’re living at a time of significant change, and we’re almost certainly already at the point of, or imminently approaching, a paradigm shift. As highlighted by Two Loops theory: yesterday’s great solution is today’s problem.

Perhaps then this is why there is nothing ‘usual’ about the current state of ‘business as usual’. In an era of significant change to the norm, this means constantly challenging what is accepted as normal and questioning the prevailing wisdom of normality. The stakes are high given the dominant characteristics of the next paradigm are still up for grabs and could fall so dramatically between utopia and dystopia.

As designers now is the time to be more conscious than ever of our role in helping contribute positively to the problems behind the problems behind the problems we’re solving. Essentially, to direct our energy and momentum towards helping solve problems of ever increasing magnitude. As the systems we contribute to designing become unfathomably complex, Two Loops may help us better reconnect knowingly with hard-earned yet oft-forgotten wisdom. Helping avoid us finding ourselves unwittingly back in an era in which coexistence with the raw reality of nature and the ‘natural world’ is no longer a luxury but an unavoidable necessity.

The ouroboros. “The all is one”. An ancient Egyptian symbol for eternal cyclic renewal
The ouroboros. “The all is one”. An ancient Egyptian symbol for eternal cyclic renewal

It's my belief that history is a wheel. Inconstancy is my very essence, says the wheel. Rise up on my spokes if you like, but don't complain when you are cast back down into the depths. Good times pass away, but then so do the bad. Mutability is our tragedy, but it is also our hope. The worst of times, like the best, are always passing away.

Boethius’ Rota Fortunae (524) via Frank Cottrell Boyce (2002)

Author note: These thoughts were originally captured early in the coronavirus pandemic, and preceded the recent Black Lives Matter protests. I’ve revisited them since to question and reflect on what are essentially amorphous and relatively abstract thoughts about consciously coping with change, during what looks now even more like a significant paradigm shift in our times. During a period of huge complexity, optimism and pessimism, fear and anger, and hope and tragedy are never too far apart. I happily welcome a conversation about the specific nuances of the perspectives raised here and how they relate to specific events and individuals, such as those that have happened to George Floyd in Minnesota and the protests around the world since.

]]>
Conducting project retros as customer journey maps https://clearleft.com/posts/conducting-project-retros-as-customer-journey-maps Wed, 15 Jul 2020 11:22:00 +0000 https://clearleft.com/posts/conducting-project-retros-as-customer-journey-maps A retrospective helps the immediate team understand where things went well and what can be improved. Once the project is finished or changes, team members disseminate and can take their learnings into their next tranche of work.

Yet in some cases and contexts, retros uncover aspects of a project that need to be shared with a wider audience. Stakeholders, project sponsors and HiPPOs might have been distant from the work being done ‘at the coal face’. By sharing the retro’s outcomes with the wider business, you can help ensure future projects avoid — or adopt — particular aspects of your project.

10779

Customer journey maps

If you’re not already familiar with customer journey mapping, it’s a great activity for helping to visualise a user’s experience over time as they use a particular feature of your product or service.

Journey maps not only help to build a design team’s empathy with users, but they also help identify gaps, pain points and opportunities for improvement. It was this aspect that we saw a fit for our particular retrospective.

Customer journey map
A customer journey map at Clearleft

Building empathy with an internal design team

In this case we cast the design team as the users in a journey map, and the session mapped our experience as we progressed through a multi-month project. We put the wider business — the senior stakeholders, HiPPOs and sponsors — into the research hot seat, able to view and understand what a typical project looks like, what and where things went well, and where things could be improved.

As with any retro, hindsight provides clarity. Standard retros end on ‘what can be improved’ or ‘next steps’, and this was no different. We collectively offered ideas and opportunities that — should we do the project again — would save time, money and revenue to the organisation.

Here’s how

Here’s how we conducted a retro as a customer journey map:

1. Jog the memory

First, we tasked the project lead to map out all major events along a wall, horizontally. The team helped fill in any gaps. This became our project timeline. In our case the project spanned multiple months, so we created a new row above the events, marking calendar months.

2. Map the activities

We then had the team share any and all activities conducted during each event, collectively. We time-boxed this activity, and provided ample time to recall many activities over the course of months. As always, we required one topic per post-it.

3. List the pain points (what can be improved)

Next we tasked the team with sharing the pain points they encountered throughout the project, aligning as close as possible to the activities above. As above, we allowed ample time for this activity as (like in most retros) this is often the most cathartic. The team (individually) answered the questions:

  • What went badly?
  • What can be improved?

4. Recall the happy moments (what went well)

Addressing the negative events first in a retro borrows from the peak-end rule, whereby an experience is judged based on how they (the participants) felt at its peak and at its end.

We had the team individually list out all the aspects of the project that went well. As with many retros, the happy moments often equal the amount of negative moments, which is often a relief for project managers and product owners. In this activity we tasked the team to consider:

  • What went well?
  • What were the wins?

5. Find the opportunities

With any customer journey mapping session, the opportunities row is often a gold mine for new product features, ideas and concepts. Our retro was no different.

As a group we listed any and all opportunities for change, mapped to either happy or painful moments alike. These opportunities might have been small (consistent stationary supplies), medium (better wall space ) and large (consistent access to stakeholders) . Whatever size the opportunity, we captured it.

It’s this row that turns the retro into something to be shared with our senior stakeholders and HiPPOs audience. It creates tangible value by providing a compiled list of needs and requirements for future projects.

Bonus round: As a future task, we intend on mapping the team’s emotional journey across the project. Doing so will allow us to visualise how impactful the peaks and troughs were and how they might correlate to productivity, tasks, pain points and happy moments.

Creating a shared understanding

The outcome of this retrospective was to create organisational empathy with the design team, and to deliver new opportunities to the business that might allow future projects to run more efficiently.

Every project is unique, but many — especially those in large organisations — tend to follow similar trajectories and challenges. Through the consistent use of project wash-up retros as journey maps, we hope that other design teams can merge these two proven methods and deliver value to the wider business. Better efficiencies, a shared understanding of what challenges crop up through projects, and how best to tackle them are among the benefits of this type of exercise.

This post was originally published on UX Collective’s Medium by Jon.

]]>
Putting design principles into action https://clearleft.com/posts/putting-design-principles-into-action Wed, 15 Jul 2020 08:43:42 +0000 https://clearleft.com/posts/putting-design-principles-into-action I was really looking forward to speaking at An Event Apart this year. I was going to be on the line-up for Seattle, Boston, and Minneapolis; three cities I really like.

At the start of the year, I decided to get a head-start on my new talk so I wouldn’t be too stressed out when the first event approached. I spent most of January and February going through the chaotic process of assembling a semi-coherent presentation out of a katamari of vague thoughts.

I was making good progress. Then The Situation happened. One by one, the in-person editions of An Event Apart were cancelled (quite rightly). But my talk preparation hasn’t been in vain. I’ll be presenting my talk at an online edition of An Event Apart on Monday, August 17th.

You should attend. Not for my talk, but for Ire’s talk on Future-Proof CSS which sounds like it was made for me:

In this talk, we’ll cover how to write CSS that stands the test of time. From progressive enhancement techniques to accessibility considerations, we’ll learn how to write CSS for 100 years in the future (and, of course, today).

My talk will be about design principles …kinda. As usual, it will be quite a rambling affair. At this point I almost take pride in evoking a reaction of “where’s he going with this?” during the first ten minutes of a talk.

When I do actually get around to the point of the talk—design principles—I ask whether it’s possible to have such a thing as universal principles. After all, the whole point of design principles is that they’re specific to an endeavour, whether that’s a company, an organisation, or a product.

I think that some principles are, if not universal, then at least very widely applicable. I’ve written before about two of my favourites: the robustness principle and the principle of least power:

There’s no shortage of principles, laws, and rules out there, and I find many of them very useful, but if I had to pick just two that are particularly applicable to my work, they would be the robustness principle and the rule of least of power.

What’s interesting about both of those principles is that they are imperative. They tell you how to act:

Be conservative in what you send, be liberal in what you accept.

Choose the least powerful language suitable for a given purpose.

Other princples are imperative, but they tell you what not to do. Take the razors of Occam and Hanlon, for example:

Entities are not to be multiplied without necessity.

Never attribute to malice that which is adequately explained by stupidity.

But these imperative principles are exceptions. The vast majority of “universal” principles take the form of laws that are observations. They describe the state of the world without providing any actions to take.

There’s Hofstadter’s Law, for example:

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Or Clarke’s third law:

Any sufficiently advanced technology is indistinguishable from magic.

By themselves, these observational laws are interesting but they leave it up to you to decide on a course of action. On the other hand, imperative principles tell you what to do but don’t tell you why.

It strikes me that it could be fun (and useful) to pair up observational and imperative principles:

Because of observation A, apply action B.

For example:

Because of Murphy’s Law, apply the principle of least power.

Or in its full form:

Because anything that can go wrong will go wrong, choose the least powerful language suitable for a given purpose.

I feel like the Jevons paradox is another observational principle that should inform our work on the web:

The Jevons paradox occurs when technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises because of increasing demand.

For example, even though devices, browsers, and networks are much, much better now than they were, say, ten years ago, that doesn’t mean that websites have become better or faster. Instead, it’s precisely because there’s more power available that people think nothing of throwing megabytes of JavaScript at users. See Scott’s theory that 5G Will Definitely Make the Web Slower, Maybe:

JavaScript size has ballooned as networks have improved.

This problem would be addressed if web developers were more conservative in what they sent. The robustness principle in action.

Because of the Jevons paradox, apply the robustness principle.

Admittedly, the expanded version of that is far too verbose:

Because technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises because of increasing demand, be conservative in what you send, be liberal in what you accept.

I’m sure there are more and better pairings to be made: an observational principle to tell you why you should take action, and an imperative principle to tell you what action you should take.

This was originally published on my own site.

]]>
Tiny Lesson: A postcard from the field https://clearleft.com/posts/tiny-lesson-a-postcard-from-the-field Wed, 08 Jul 2020 11:59:00 +0000 https://clearleft.com/posts/tiny-lesson-a-postcard-from-the-field Sharing your progress with others is so important when trying to build momentum around a design project.

The close rapport you build up with the core project team is absolutely fundamental to this, but it’s critical to never underestimate the importance of keeping the wider stakeholder group informed and on board. On a recent project with a large corporate, I was reminded of the power of sending a weekly postcard. This can simply be circulated to stakeholders as a more approachable and shareable version of a status update.

The first postcard can be sent before the project actually starts to say hello, outline the scope and your key activities. After that, a typically weekly postcard provides a short snapshot of:

  • Where you are in the overall programme plan
  • The key activities that took part that week, along with the key insights and outcomes
  • The activities to look forward to next week
  • Key team members and contact details
Project postcards

I’d suggest keeping it deliberately short and sweet and where possible adding some photos and images to bring the project to life. I’d also suggest using a light-weight programme like Keynote or Powerpoint so as not to over-engineer it.

This technique is not new, in fact, I remember using it on a project over a decade ago, but with the recent move to more distributed teams it has made this weekly habit more useful than ever.

No longer are we able to have a war room in a clients office or put artefacts up on their walls as a permanent reminder that the project is happening. So a little visual snapshot arriving in their inbox at the end of each week can prove to be a helpful prompt.
During our roles mapping session at the beginning of the project, we allocate an individual involved in the project to be responsible for its creation each week, with input from the rest of the team of course. Once the format is created it can be completed in a very short space of time each week, literally a matter of minutes.

In my experience, this technique proves particularly useful when working for a large organisation with sprawling stakeholder groups. On occasion, it has triggered some pivotal stakeholders to get engaged with the project early on, which is always incredibly useful and can manage the risk of them getting involved too late on.

So why not give it a try on your next project?

]]>
Announcing the Clearleft podcast https://clearleft.com/posts/announcing-the-clearleft-podcast Mon, 06 Jul 2020 14:06:00 +0000 https://clearleft.com/posts/announcing-the-clearleft-podcast I’ve been working on something new for the past few months and now I’d like to share it with you…

The Clearleft Podcast
podcast.clearleft.com

The Clearleft Podcast.

Now I know what you’re thinking: aren’t there enough podcasts in the world already? Well, frankly, no. Unless you also concede that there are enough books and records and films in the world already too (to be fair, this is a reasonable thought to have when you’re navigating Amazon, Spotify, and Netflix).

In any case, this podcast is going to be a bit different.

In our field, the usual podcast format is in the form of a conversation: a host or hosts interviewing a guest or guests. Those are great. I’ve certainly enjoyed being the guest on many a great podcast. But I wanted to do something a bit more like an audio documentary.

If you’ve seen a lot of documentaries you’ll know that there are two key factors to getting a great story:

  1. the source material and
  2. the editing.

That’s what makes the Clearleft podcast different.

For the source material, I’ve interviewed my colleagues at Clearleft as well as our peers in other companies. I’ve also gathered great material from conference talks—we’ve got a wealth of wonderful insights from multiple editions of events like UX London, Leading Design, Ampersand, Responsive Day Out, Patterns Day, and dConstruct.

A lot of work has gone into the editing. It probably works out at about an hour of work per minute of podcast. I know that seems excessive, but I really wanted to get a snappy feel for each episode, juxtaposing multiple viewpoints.

The focus of the episode will be around a particular topic rather than a person and will feature lots of different voices woven together. The really challenging part is threading a good narrative. It’s kind of like preparing a conference talk in that respect—I’ve always found the narrative thread to be the hardest but most rewarding part of putting a talk together.

It’s simultaneously exciting and nerve-wracking to put this out into the world. But I think you’re going to enjoy it.

Visit the website for the podcast and choose your preferred method of subscribing. There’s the RSS feed, but the Clearleft podcast is also available on Apple Podcasts, Google Podcasts, Spotify, Stitcher, Deezer, TuneIn, Castro, and Overcast.

The first episode will go live later this week. In the meantime, there’s a short trailer to give you a taste of what’s to come.

The episodes will be grouped together into seasons. I reckon a season will around six episodes long. So you can expect the first season to be released over the next six weeks.

Hope you like it!

podcast.clearleft.com

This was originally published on my own site.

]]>
Designing with fluid type scales https://clearleft.com/posts/designing-with-fluid-type-scales Wed, 01 Jul 2020 12:31:00 +0000 https://clearleft.com/posts/designing-with-fluid-type-scales Breakpoint-based type sizing has always felt a bit arbitrary to me. It seems like equal parts guesswork and compromise, where the better we want it to work, the more stuff we need to design. It strikes me as inelegant and inefficient.

Over the past few years I’ve been lucky enough to work with some very smart designers and developers who have helped me hone my thoughts and ideas into a more tangible approach to fluid responsive design – particularly with regard to typography.

Although every project has different requirements, type size variation on a phone is usually relatively conservative, given that there’s limited horizontal space available. On a large laptop or desktop display it’s often desirable to use much more dramatic type scales to make the most of the extra space. The question is how to accommodate both screen sizes while respecting everything in between.

The big idea that triggered this train of thought now seems very simple:

  1. Define a type scale for a small screen
  2. Define a type scale for a large screen
  3. Tell the browser to interpolate between the two scales, based on the current viewport width.

This results in a set of type sizes which is always “in tune” with itself and feels at home on any device, without needing to manually specify sizes for x number of arbitrary breakpoints. For example we can just say H2s are always “size 4” and trust the calculation to generate a suitable size heading for everybody.

A chart showing scaling fluid fonts
Visualising what this means

In the example above, I defined a typographic scale of 1.2x at 320px (mobile-ish) and 1.333x at 1500px (desktop-ish). At any viewport width in between, the set of type sizes is proportional, although I haven’t needed to manually specify any additional values. I dropped a line at 1024px to show the automatically-calculated font size values at that viewport size. For this example I generated the values using a Google Sheet but this can be elegantly replicated in CSS as described in this excellent blog post by Clearleft developer Trys.

Here’s how these values can translate into design:

A simple example showing typography automatically “breathing” into the available space in a tablet-ish viewport size.
A simple example showing typography automatically “breathing” into the available space in a tablet-ish viewport size.

Trys has created a live version of the above example so you can see it in action: Watch the type breathe as you resize your viewport.

Exactly how you define your two type scales will depend on your product’s fonts, visual style, content, layout, audience, etc. This approach is not a substitute for good design, rather it encourages focusing design effort into the creation of a robust system. This should help to speed up future activity and decision making, as well as bake in consistency by establishing a “palette” of related type sizes.

The user benefit to this approach is that typography will always look “right”, regardless of the device being used. This is not always the case with the standard approach, where your brand new tablet might land you on the wrong side of the nearest breakpoint.

This was originally published on the Utopia website.

]]>
Transitioning to design management is hard, risky and requires a lot of luck https://clearleft.com/posts/transitioning-to-design-management-is-hard-risky-and-requires-a-lot-of-luck Thu, 25 Jun 2020 13:26:00 +0000 https://clearleft.com/posts/transitioning-to-design-management-is-hard-risky-and-requires-a-lot-of-luck There are three common paths into Design Management. Either you start at the bottom and work your way up, you take on a stretch project that elevates you above your peers, or you hit a glass ceiling and are forced to jump ship.

I know a lot of people who have followed the first path. They joined an early-stage start-up as its first designer, and four years later are running a team of 40 people as Vice President.

It’s easy to see how this happens. As Designer number one, you’re responsible for hiring designers number two, three and four. For the first 18 months or so you’ve moved from being a regular designer to a lead designer. You understand the design system, and know why certain decisions were made, and everybody comes to you for advice.

When it’s time to hire your fifth, sixth and seventh designer, you’re the one who ends up writing the job spec, doing the interviews, and onboarding the new hires to the team. Once folks start, they report to you, and when they want a pay increase, it’s you they come to first. You probably don’t have the title of manager yet, but you’re effectively doing the job of one.

A lot of career advancement comes that way. You accidentally find yourself doing a particular job, and the title, salary and job description follows 6 months later. Eventually, you’re doing so much people management that you move out of production, hire a couple of leads who eventually become managers themselves, and now you’re a Head, Director or VP of Design.

This is a wonderful career trajectory and looks amazing on a CV. However, it’s a super hard career trajectory to plan, as a lot of it revolves around joining the right company at the right time. This doesn’t diminish the hard work and effort you put in. It’s just a hard route for others to follow with any certainty.

10720

The next approach is more common inside larger, more stable teams. As a designer, you’ll see some sort of opportunity, improvement or trend that you’d like to explore. These tend to be internal focussed opportunities like the creation of a Design System, or the formation of a DesignOps team.

Using your natural sales and leadership abilities, you’ll secure some time and budget. If you’re lucky, the project will be a success, and you’ll end up being put in charge of this new initiative. The powers that be will see this drive and other leadership roles will soon follow.

This is a great way to prove yourself as a leader, but it comes at some risk. Convincing your company to do something new is always a challenge, and if you fail you’ll lose the trust of your superiors and your status in the organisation. As such, this can be especially hard to do for people from more diverse backgrounds, who may not feel as confident in their ability to leave and walk into another job with ease.

Unfortunately, these opportunities are few and far between, so there’s an element of being in the right place at the right time. There’s also a big element of office politics going on here.

As leaders, it’s our job to find these stretch assignments for our teams, but there’s a good deal of evidence that these sorts of assignments aren’t evenly distributed. That promotion worthy stretch assignments get given to white men more than women—who are often given maintenance assignments—or people of colour. As such it’s important for design leaders to make sure that these opportunities are distributed evenly and judged fairly.

10722

The third most common route into management is through promotion. You’re a great Designer or Design Lead, who continuously goes above and beyond the call of duty. Your design work is stellar and your peers consistently approach you for advice. You know how to navigate projects through your organizations successfully, and your stakeholders appreciate your diligence and hard work. The only problem is, there are no leadership roles available.

While most people assume that they’ll eventually be promoted into a leadership role, this happens a lot less frequently than you’d think. Unless the company you’re working at is growing quickly, you’re effectively waiting for your boss to leave; and while individual contributors seem to move roles fairly frequently, managers stay much longer. As such, the only option is to jump ship.

If you’re lucky, you’ll land your first leadership role at a company with a long history of Design Leadership, a group of peers to learn from, and a governance structure in place. However, that often isn’t the case for new managers. Instead, they’ll often find themselves being hired by companies with little background in design, as a Player Coach.

On the surface, the Player Coach role sounds ideal. You get to learn new management skills, while continuing to do the design work you know and love. The problem is that management very quickly becomes a full time job, especially when you discover that you don’t have basic things like standard job descriptions, team charters, or progression frameworks in place. You spend so much time working on these fundamentals that your design work and people management skills begin to slip. Very quickly you find yourself stuck in the new manager death spiral, and start wondering whether you did the right thing. Maybe life would be easier if you went back to being an IC.

I’ve seen this cycle repeat itself more times that I care to say. Fortunately, this feeling will pass. You’re not a bad manager. You just found yourself in an impossible situation, so it’s time to move on. The best thing you can do is use this experience to land a design management role at a much larger company with an experienced design leader, a supportive group of peers, and all the necessary governance and infrastructure in place.

As you can see, none of these routes into Design Management are especially easy, and a lot of them require being in the right place at the right time. However It’s important to be aware of these common tropes, so you can take advantage of them when they present themselves, or know when to step away when they don’t.

This was originally published on Andy’s website

]]>
10 ways design leaders are maintaining happy teams https://clearleft.com/posts/10-ways-design-leaders-are-maintaining-happy-teams Fri, 12 Jun 2020 12:31:00 +0000 https://clearleft.com/posts/10-ways-design-leaders-are-maintaining-happy-teams The new normal we find ourselves in has changed the way we run design teams, prioritise and measure success. Last month we hosted our fourth Design Leadership Panel where we discussed the challenges that come with managing teams that have been forced to go remote.

From the panel discussion, we’ve assembled 10 themes, tools and thoughts which emerged that we can all apply to how we lead and manage teams now, and moving forward in the future.

Many thanks go to our panel featuring Dan Cordor, Head of UX & Design at Gumtree, Stuart Gomersall, Head of Digital Technology at Lloyd’s, Christine Pizzo, Studio Design Lead at Digital Products, an Accenture Studio, Dan Potenza, Head of UX at MoneySuperMarket Group and Katie Taylor, Head of Experience Design at Wellcome Trust.

Maintaining happy teams intro slide

1. Steal processes from different groups

Learn, borrow and steal from other disciplines. At Accenture, Christine has borrowed the concept of mob development and applied it to the design team. She has found it stops the ‘designing behind a desk’ mentality, is more casual and interactive, with constant casual conversations bringing natural learning from more senior peers. We love a design jam on Figma here at Clearleft, and this is an approach Dan at Gumtree uses with his team also, bringing that sense of collective creativity.

2. Assess leadership speaking down

Over-communicate yes, but make sure you mix the voices up. At Gumtree there was already a company culture of transparency, by ensuring they over-communicate at a team level, it naturally gives visibility from above without the need for more updates/briefings. At Accenture, Christine has made sure the weekly company scrums are not just leadership talking down. Getting different people to run stand-ups is a great way to get the rest of the team talking for you or with you.

3. Use real-time tooling judiciously

Breaking down barriers, and getting the closest experience to being in the room is essential. At MoneySupermarketGroup Dan has run entire product inceptions with 50-60 people across the company co-contributing to a Miro whiteboard successfully defining a proposition. But there is a danger for them to get out of hand without physical constraints - imagine translating your vast Miro boards into a real space. Remember to be concise.

4. Find the right boundaries

It’s a tricky juggle to get it right. Dan Potenza, Dan Corder and Katie had some key thoughts to check before you act -

  • Find the right balance for people and don’t push them too much. Have the awareness as a people leader that there are external stresses.
  • Ultimately look after your own work/life balance. Your family, your health needs to come first and work should, quite rightly, come second.
  • Ask what do I need to be where for, and when/where am I at my best? Ask those questions before defaulting.

5. Maintain professional development

While it may not be the first thing you think of, many of our attendees were concerned with maintaining career momentum during this time. Christine believes it is a really important time to look at it, and to create those personal growth tools and processes. At MoneySupermarketGroup they have a soft skills review yearly. This is not about scoring everyone, but helping their team open conversations - are you interested in this? Do you get your energy from here? Again this is not pushed, but available through 1-2-1s as an ongoing agenda item if people feel differently during this time.

6. Remove the formal

Avoiding the calendar based fear. There are many ways our leaders recommend making leading a team more relaxed. Katie at Wellcome Trust asks her team ‘how do you want to chat today? You choose.’ She’s found it helps to build trust and create a real relationship where your team feels comfortable to say that they’re not up to something. Accenture launched a ‘COVID connection plan’; effectively a phone tree of check-ins. Asking who has the best connection with these people? They then check-in and make a note of who needs help or is fine. This helps her by knowing everyone is being talked to at a glance, and no one is being left behind, without the need for anything more formal.

7. Translate

It’s an incredibly important time to check how your messages are landing as a design leader. For Christine, it’s not about adding additional worry for everyone but being realistic about where the business is and what we can all do about it. Make sure everyone knows how they can help and why we’re asking for things that are critical. And ask in a way that doesn’t make them fearful. Dan has found himself listening far more and picking up on signs at MoneySupermaket Group, allowing a silence in order to let people get to something they may want to bring up.

8. Iterate constantly

With parameters changing on a day to day basis, we are all having to iterate constantly. One way is to increase your commitment to research to give that sense of certainty and confidence. At Gumtree, Dan’s team had the ethical discussion on whether it was the right time to ask how the pandemic has changed how their customers transact with them. Stuart at Lloyd’s has found a similar thing, finding himself and his team asking questions they otherwise wouldn’t. Which he hopes is a positive cultural shift that sticks around for a long-time to come.

As well as increasing our research we can also iterate on team structures and skills. Christine has found when finding people underutilised or on the bench, it’s a perfect time to think about repositioning them a little or allowing them to upskill into areas that will help the business in the long term.

9. An accelerant to tackle the tricky stuff

In many ways, these times have accelerated conversations, approaches and processes that are hard but need to be addressed. Christine has found it stretches us in a way that’s challenging, but we as leaders still have to grow. Often the hardest discussions are the ones where you grow the most. Many leads may have never had to do that, so it’s good we are all tackling these conversations now, of what might happen.

10. Old-style management Vs new-style leadership

Recent times have brought a whole suite of skills that design leaders may have had, but never exercised in this way. Stuart at Lloyd’s flags that there needs to be value to interactions as they are more cognitively exhausting. Leading by example, he’s found himself feeling it’s important to challenge even the CEO/CIO to try and reduce down meeting times to encourage the rest of the team to do the same. Katie has also found that after an initial rush to have more meetings at Wellcome Trust she is now advocating for a more asynchronous leadership style.

Our next panel discussion will be in September. You can register your interest here.

]]>
A universal theory for DesignOps https://clearleft.com/posts/a-theory-for-design-ops Mon, 08 Jun 2020 09:50:00 +0000 https://clearleft.com/posts/a-theory-for-design-ops As we say up front on our website, Clearleft help organisations, designers and leaders “realise [their] digital potential”. Through events, research, design and strategy we enable innovation, build capability and foster an appetite for change.

Sounds so easy, right? Well, of course not. We’re aware that this is much easier said than done. No-one has perfected design down to a tee and many organisations face challenges in how they design. For us at Clearleft, and maybe for you too, this can sometimes be frustrating. Aren’t we supposed to have this design thing sorted by now?

Design as competitive advantage

Design as a capability for innovation and competitive advantage has been on the radar with business leaders for many years now. Way back in 2004 two designers, Tim Brown and David Kelley of IDEO, made the cover of Business Week. That’s over 15 years ago now, from a pre-iPhone era. Essentially the digital equivalent of the Old Testament.

Between 2005 and 2015 we’ve also had organisations such as the Design Management Institute (DMI) creating the Design Value Index (DVI), an experiment conducted to measure how much value design creates for businesses. The DMI invested $10,000 dollars in design-centric companies – those who had made significant investment and structural support for design – such as Apple, IBM, Nike, and Disney. The $10,000 fund was then compared against one of the major US stock market indices to track performance of these design-centric companies against the broader market. While the market grew by almost 80%, the DVI-listed companies grew by nearly 300% in the same period.

The Design Value Index (DVI) by Design Management Institute (DMI) (2005 - 2015)
The Design Value Index (DVI) by Design Management Institute (DMI) (2005 - 2015)

This result surely demonstrates that design is valuable. So why aren’t we living in a design utopia? Why do most companies feel as though they have an immature understanding of design? That very few stakeholders are fully invested and committed to it?

Based on our experiences at Clearleft, we see a few common recurring themes in the struggle designers are facing within organisations. Names have been changed to protect the innocent.

Scenario 1: The Hooli problem

The first organisation, Hooli, has a really sophisticated technology setup. They know everything there is to know about Agile, DevOps and continuous delivery, having optimised their development cycles within an inch of their life. They’re as fast as they can possibly be, with hourly updates as needed, and numerous updates daily. But look a bit closer and something isn’t quite right.

Firstly, the design team is hugely outnumbered in comparison to their engineering colleagues, and even though they sit together as part of a cross-functional team they have no clout and no say. Design is in service to Technology and Engineering, and isn’t represented in any significant way higher up the food chain of the organisation, in the boardroom and where the big decisions happen.

Also, because everything is done so fast, paradoxically nobody has time to worry about whether or not they’re shipping things the customers want or need. There’s a rudimentary amount of usability testing but fixing anything that crops up isn’t factored into the release schedule. The user experience suffers as stuff gets pushed live without any proper consideration to the quality.

10633

Their motto is “Design just slows us down”. This is Design by Engineering.

Scenario 2: The Wayne Enterprises problem

Wayne Enterprises are an established market leader looking to push the boundaries within their sector, and keen to disrupt their industry by bringing new and exciting products to market. They have a lot of investment, they pay huge salaries, and money isn’t a problem. But as they are a publicly-traded company, they are obsessed about the impact any decision has on their shareholders, and as a result their culture is obsessed with the short-term impact on the bottom line.

10637

Because of this, their team of highly (over)paid contract designers struggle to get any buy-in on anything. The team is paralysed by the demand to provide evidence for every single subjective or qualitative improvement in the user experience. Because brand loyalty and customer satisfaction are difficult to both quantify and affect in a short timeframe, none of the more ambitious customer-centric projects ever get off the ground. Nobody is interested in committing the budget unless they can quantify the returns. Despite all the ambition to innovate and disrupt their market, the rhetoric is hugely misleading — they are trapped by numbers and risk averse.

Unfortunately, this means the design team only ever optimise around what they know. Poring over analytics and hypothesising how to improve conversion by marginal percentages. They’re at the mercy of the local maxima – optimising existing design solutions until they’re drained of any more gains, while missing the bigger opportunities to reimagine something with greater potential.

Their motto is “I can’t see the ROI of design”. This is Design by Business Case.

Scenario 3: The Cyberdyne Systems problem

You may have heard of Cyberdyne. They’re a highly secretive but much publicised startup working on some ‘exciting’, progressive and innovative AI solutions to automation. An ideological organisation earnestly believing it is making the world a better place. (Big fans of the lockdown.)

Design here is both tactical and practical. Designers are used to add the final touches to marketing websites, presentation decks and so on. Designers don’t have any say in the design of their AI systems. Their logo probably wasn’t even done by a designer because it looks terrible. The sad truth is that there is no organisational malice behind these actions.

10641

Their motto is: “Less thinking. More colouring in.” This is Design by Naivety.

Design’s Iron Triangle

The three companies described above obviously aren’t real, but exaggerated archetypes we can surely all identify with. Their problems, however, are very real, and seem to be universal to design:

  • Is design efficient enough? How much time and resources does it take to design?
  • Is design profitable enough? How much money do we need to spend on it to see a valuable return on investment?
  • Is design effective enough? Is the quality and scope of what we’re doing enough to satisfy customers or users? To meet their needs, goals and ambitions? We can change the colour of a button sure, but are we even making a product they’d use? Are we designing the right thing?
Good design needs to be efficient, profitable and effective
Good design needs to be efficient, profitable and effective

And of course these are universal considerations of design, because they’re also the same universal success factors to balance in any organisation: time, money and quality.

The Iron Triangle of time, money and quality
The Iron Triangle of time, money and quality

Changing one factor has an impact on the other factors. For instance, if you have a much bigger ambition of scope or quality to what you’re trying to achieve, that comes with a bigger price tag or a greater effort. Equally, spending less time will save money but impact the scale of what is being delivered. You may have heard of this as “pick two”: You can have it fast, cheap, or good, but not all three. You may have heard of this model as the Iron Triangle or the Project Management Triangle.

10654

No-one has achieved the perfect design team, or process, or outcome, because the constraints demand that you can only ever optimise for two of the three factors.

  • Do you want it fast and cheap by sacrificing the extent of its qualities, whether that be scope, scale or finish?
  • Do you want it fast and to a high standard by paying more?
  • Or do you want to achieve the most ambitious quality and scope whatever the cost, at the price of it taking longer to deliver?

It’s no coincidence that a similar triangle of interdependent constraints exists elsewhere.

Critical Success Factors

It was Bill Moggridge and IDEO in the early 00’s that first coined the Design Thinking mantra of the three factors considered vital ingredients to the success of any product or service.

  • Feasibility: Can we make this happen?
  • Viability: Can the company profit economically from this?
  • Desirability: Do users or customers or people want or need this?
Design thinking triangle

You could also call these technology needs, business needs and user needs. Most companies typically assign responsibility for each of these factors to specific areas of the business: Engineering, Product or Strategy, Design or Marketing, respectively.

Within the conceptual model of this Iron Triangle lies a potential model to help explore the challenges and tradeoffs good design needs to thrive.

Engineering teams are responsible for technology needs, ensuring solutions are feasible. Because the team’s primary constraint is the effort (i.e. time) required for the solution, they have the biggest influence on how efficiently the organisation solves design problems. Who hasn’t heard the development mantra “anything is possible given enough time”?

Product or Strategy teams are responsible for business needs, ensuring solutions are viable. Because the team’s primary constraint is the cost, or cost-benefit ratio, of the solution, they should have the biggest influence in how profitably the organisation solves design problems. In other words, how it maximises value from what it does.

Finally, Design or Marketing teams are responsible for user needs, ensuring solutions are desirable to potential or existing customers. Because the team’s primary constraint is the quality, or qualities, of the solution, they should have the biggest influence in how effectively the organisation solves design problems, in terms of meeting customer expectations and ensuring the best product-market fit.

Designops triangle unpacked

When these constraints are not in harmony, which they rarely are, you see a symptom of one or more of them negatively affecting the design outcomes. Organisations typically assign accountabilities at a departmental level, and when they do so they are giving focus to one of these constraints at the expense of the other two.

10666

Organisations which face Hooli problems are struggling to get Design to work with Engineering and Technology teams in an efficient manner. Design is perceived as taking too long.

Organisations with Wayne Enterprises problems are struggling to get Design to work with the wider business to demonstrate how it can create new value and competitive advantage. Design isn’t obviously and transparently benefiting the bottom line.

And organisations with Cyberdyne problems have yet to appreciate or maximise customer-centric design at all. Design is just an aesthetic veneer before you put a product to market. The understanding of design itself is immature.

Organisational structures and hierarchies have a dramatic effect on culture and, by extension, the challenges relating to design. Culture is the greatest influencer on an organisation’s ability to be mature at design. Therefore in order to know how to tackle design challenges where you work, and to improve the outcomes of design, you first need to start with reflecting on the collective behaviour of your organisation – the culture. A good method of doing so would be to imagine where it fits on this triangle of balancing factors between efficiency, profitability and effectiveness and start nudging the culture in a more harmonious direction that will improve your design maturity.

But how? Let me have a think…

]]>
7 learnings from a virtual onboarding https://clearleft.com/posts/7-learnings-from-a-virtual-onboarding Tue, 02 Jun 2020 08:45:04 +0000 https://clearleft.com/posts/7-learnings-from-a-virtual-onboarding During these strange times, we are re-learning to work as teams at a distance, and this comes with challenges. But onboarding a new designer is an entirely different beast.

Being introduced to the new environment while not being in that environment can be a roller coaster of mixed feelings. It can also be revealing about a company.

As I started my role as a UX designer in full-on lockdown mode, I had the unusual experience of becoming part of Clearleft in this peculiar and unforeseen way.

Everyone has an onboarding plan, a welcome pack for the newcomer, or a number of automated rituals that are more or less effective in shortening the distance between a well-acquainted, tightly-knit team and the stranger standing in front of them.

Being no design leader, and having experienced onboardings only twice before, I wondered how many other people—designers, project managers, HR leads—are going through the same remote ordeal, on different sides of the barricade. As the remote office newbie I wanted to share some considerations that anyone preparing for virtual onboarding may learn from.

1. Be ready, possibly in style

A company is almost exactly like a person. It has its character, a voice and body language, its personality, its beliefs and values. One way or another, the company-person needs to be introduced to the newbie.

The way Clearleft does it is simple yet pretty elegant: a dedicated microsite, nicely matching the branding and website of Clearleft. Step by step, I was walked through the core and soul of Clearleft, all the way to any kind of practical information. I couldn’t really use the details about how good the coffee machine is in the office, but it’s all stuff that adds up to the understanding of where I’ll be working and what I’m getting into. Plus, it’s a reassuring fact to see the level of detail your company would go to just to welcome you onboard.

2. An organised company is an organised newbie

A place for everything, and everything in its place. The welcome website (welcsite?) pointed me towards a number of drives, folders, sheets, and documents that listed vital, important, and useful logistic things.

Clearleft prepared a specific onboarding Drive too, aligned with the microsite. This option is by far simpler than a swanky onboarding site, but it presents its own challenges: file duplication, taxonomy confusion, un-shared folders…we know the list. Asking rookie questions about where one would be able to find this file is a guaranteed chills-inducer for most companies. Lesson learned: better keep organizing tools clear and clean.

Alongside file managers, contacts and tools lists should be ready. This is a life-saver, especially when you start your first project after 3 days of being onboarded. And it’s much easier if there are etiquette and protocols next to each tool. There’s nothing that makes a newbie more anxious than being afraid of kicking his boss out of a working tool.

Tip: If you have a resource/training folder, share it immediately with the new colleague: they’ll sure be happy to access expensive books and documents while being locked up at home.

3. 1-2-1s

This is one of the tricky ones, because:

  1. nothing replaces a good ol’ chat in a coffee shop or around a pint, and
  2. that’s more video calls for the whole team.

Still, they need to happen, possibly as individual chats. The only thing worse than a video call is a video call with 29 people playing the hangouts bingo of “I didn’t quite catch that” or “Can you hear me”. What had been prepared for me was a calendar dotted with 25-minute intro calls with colleagues, with no specific order or pattern to it. That was great because it surfaced individuals rather than teams (in a place like Clearleft there is nothing like siloed teams) and because it allowed everyone to put their own twist into their job and workplace description.

Tip: Everyone I spoke to recommended I dig up a blog post or case study from Clearleft archive to get me into the mindset of the company.

4. Talking about...everything

Half of my 1-2-1s ended up being the most random and chaotic conversations I had in a formal onboarding. The calls with two of the founders ended up being longer than expected, very lightweight while talking about the company for only a third of the time. That was fine - even better. Hierarchies can be scary, even in horizontal companies. You both like typography? Speak about it for the whole time, it’s worth it.

5. Over-ask (over-communicate)

Another thing that everyone at Clearleft did was to constantly reassure me about support and, given the lockdown-remote combination, the fact that it was fine for me to raise my hand and ask, request and grab people on Slack. It might sound obvious, but during onboarding (and especially for a remote one) being constantly reminded that “It’s OK to ask” helped a lot.

6. Beware comms overload

But where to ask? Behold the labyrinth of Slack channels, groups, @here, and direct communication. I personally follow the funny-named slatiquette.com like gospel since I’ve found it. But it might not be enough for all the nuances of a company’s internal chat. Do I post it in #general or #random? If basic Slack hygiene routine is in order (and bonus: they’re explained in onboarding documents), these trivial problems won’t apply, and it will save everyone unwanted notifications and clogged channels.

7. Get thrown in the mix

Every time I’ve been onboarded I jumped straight into a project. “It must be hardcore to start working immediately”, everyone said. Well…it wasn’t. I think it’s one of the best ways to start blending with the inner functionings of a company. The first client meetings and workshops might feel daunting (and they are!), but that’s when smart onboarding and access to resources comes into play. I felt ready for the challenge, and I knew where to find what I needed to kickstart my job.

Tip: This is where precise and reasoned planning can be used to assign roles and (as mentioned before) reassure the newcomer that it’s fine to spend some time riding the bench.

It was thanks to planning that my remote onboarding experience didn’t turn out to be a nightmare. As everyone was continually checking on me, I realised that, in fact, everything was good.

Yes, there were apocalyptic encounters at the office to get my laptop and equipment (6 meters distancing and masks), but I was also greeted by a case of company brewed beer as the office was shutting. And probably the best thing about a remote onboarding: never, ever, getting a name wrong thanks to the little, underrated, but incredibly effective name at the top of every video call.

]]>
What companies get wrong about launching new products https://clearleft.com/posts/what-companies-get-wrong-about-launching-new-products Tue, 19 May 2020 10:54:17 +0000 https://clearleft.com/posts/what-companies-get-wrong-about-launching-new-products Kicking off a new product? How do you go about finding the right team for the job?

There’s a logic in the tech industry—popularised by books like The Lean Startup—which explains that the goal of any start-up is to achieve product-market fit; the perfect nirvana of a product that people want, that solves a real problem, and customers who are willing to pay.

It takes a lot of time, effort, talent and money to reach true product-market fit, and the majority of companies fall by the wayside. That’s often because they run out of time, run out of money, or lack the talent needed to get them there in the first place.

There’s another piece of tech industry logic, which is variously described as “ship early, ship often”, “move fast and break things” or “build, measure, learn”. It’s a combination of learning by doing, and the realisation that speed and momentum are key.

I generally hold these concepts to be true, with a few minor caveats. I’m always surprised that there’s a third and final piece of tech company wisdom that seems to undermine these two philosophies. Something that actively slows production and the search for product-market fit. What’s this concept you ask? It’s the fixation on doing everything in-house and building the perfect team.

I get where this is coming from. VCs invest in talent as much as ideas, so they want to know that you have the team to deliver the goods. The problem is, building the perfect team is a lot harder than you think.

Tree vector created by www.freepik.com/pch-vector
Tree vector created by www.freepik.com/pch-vector

Assembling a team

The first problem is simply finding good people. It can easily take six months to assemble your founding team and get them up to speed; to get them forming, storming, norming and performing. It’s also hard to know what good looks like, especially if you’re a first time founder or from outside the industry.

There’s a mistaken belief that talent is widely distributed and largely equivalent. That one designer, product manager and engineer is much like another. In my experience, nothing could be further from the truth. I’ve seen founders go through multiple design, engineering or product leads before they find the right person. This all costs time and money. Often that’s time and money the founders don’t have.

It’s also worth noting that teams aren’t a static thing. In fact the team you need to invent a new product is going to be quite different from the one you need to scale, monitise and maintain the product. And because there are a lot more companies in the scale, monitise and maintain phases, they’re much easier to find.

So if you’re kicking off a new product, how do you go about finding the right team for the job? I think there are three opportunities available to you that are faster and better than trying to recruit a permanent team.

Contractors

The first option is to go freelance. To find individuals who have a proven track record inventing and scaling new businesses. These people tend to be pioneers. They enjoy the challenge of solving new problems so probably aren’t looking for a permanent position. They know their worth and will be reasonably expensive on paper, especially if they’re looking for equity.

It will take time to find these people. But if you find a good freelancer, they’ll undoubtedly know other people they’ve worked with and trust. This can help reduce the time it takes them to get up to speed, avoiding the forming and storming phase, and jumping straight to norming and performing.

Agencies

If you don’t have the time and contacts to build out and manage your own team of contractors, the next most obvious solution is to hire a pre-built team with a proven track record, in the form of an agency.

While agencies may feel more expensive than permanent staff when you consider day rates, you need to add on the time you’re saving by not having to recruit, onboard and bring these teams up to speed. There’s also a tendency for agencies to work faster, so they’re regularly able to deliver in 6 months what would take an in-house team a year or more.

Partners

The final option is to look towards a new breed of “sweat equity” investors. Rather than offering you cash, these investors will agree to design and build your product for a share of equity. Like all investors, these companies are taking a huge risk so would typically expect a higher reward. Usually something in the region of 20-30% equity.

This is a really interesting new model, so it could be worth a try. However because it’s so new, it hasn’t really been stress-tested yet. So there’s a chance that the teams may not be as good as they claim to be, but unlike a relationship with an agency, it’s much harder to offload an investor you don’t like. If you are going to go down this route, it’s worth doing your due diligence, and see if they have the track record to back up their equity stake.

Choose carefully

Whatever approach you choose, it’s always important to balance time, money and risk. Building an in-house team takes longer, and therefore presents a higher risk. Get it right and it can save you a lot of money, but get it wrong and you’ll hit the end of your runway fast.

Using contact or agency talent helps reduce the time, risk and managerial overhead, but it comes at a cost. The equity funding model is a new and exciting approach, but yet to be properly proven.

]]>
Balancing business and user needs https://clearleft.com/posts/balancing-business-and-user-needs Mon, 18 May 2020 10:24:00 +0000 https://clearleft.com/posts/balancing-business-and-user-needs Clearleft hosted the third in our Design Leadership panels in February, the second panel discussed the complex nature of balancing business needs with those of the user, and the challenges faced.

We were joined by Conor Ward, Director of Design at BT, EE and Plusnet, Daniel Souza, Design Operations Director at Babylon Health, Ana Jakimovska, Chief Product Officer at Culture Trip and Andy Budd, Chairman at Clearleft

You can sign up to join our next (now virtual) design leadership panel here.

Clearleft design leadership panel sitting infront of a blue screen

Scaling design

The panel explored the nuances of scaling design, and how Design Ops is integral to bridging the gap between business and user needs. On one end of the spectrum, we had Culture Trip, who Ana referred to as a ‘start-up, scale-up in hypergrowth’. Similarly, Babylon Health is growing rapidly, investing heavily in Design Ops as they become more complex, dealing with more and more markets as they scale. For both companies, however, it’s not about growth but more about how design at scale can improve the business’ relationship with the product.

When you move from start-up to scale-up you start to make better proposition decisions. You have a more mature relationship with the product teams, and you find more balance between cost reduction and a good experience.

Daniel Souza

On the other end of the spectrum, BT are an older, more traditional company. They are very much operating at scale with a digital team of 1,000 and a 200-strong design team. However it’s a challenge to foster a scale-up and start-up mentality within an older organisation. Since joining BT as Director of Design, Conor’s goal is to bring together the various design teams into a single digital team, reporting to the CEO. By removing some of the bloat found in traditional organisations, he has been encouraging more of an entrepreneurial mindset.

Org structure matters

When it comes to organisational structure, people are always looking for the ideal model. Balance becomes increasingly important. Simply adding one more person to the team, or one more product to the stack can see it quickly destabilise. Org structure can be a bit like building on shifting sand… although a reorg may fix a bunch of problems now, it can also create a myriad more later. Similarly, one designer embedded in a team can feel completely overwhelmed. The attempt to solve this by centralising the design team can see the whole team end up becoming a siloed resource. It’s not easy.

Organisational hierarchy is inherently problematic, it seems.

At BT, Conor is embracing the fuzziness by trying to make operational models and structures without looking at the exact skills and types of people available. Asking first ‘how do we want teams to work together’ followed by ‘how are we going to give them line management and support’ and working from there is a good start.

At Culture Trip, they tend towards simplicity, using mental models and narratives and embracing what Ana refers to as ‘the messy middle’.

The messy middle can work great if there are enough boundaries and goals, and it supports the right relationships between people. If you put too much process in you can starve innovation and self-initiation. Org philosophies need to change, and the messy middle is OK but design leaders have to support that

Ana Jakimovska

Avoiding pitfalls

In order to change the mindset in larger, more traditional companies, it seems to start with good communication from design leaders. Conor has taken three steps to elevate design to a business level:

  1. Define who design reports into ‘at the table’. Set design as a peer to Product, as well as Engineering and Data

  2. Change the language. Rather than the leadership team they are called the ‘Digital Enablement Team’

  3. Re-define Design itself. Think ‘how do you define design’? How can you make it as wide as possible, encompassing product design, content design, user research and Design Ops?

The breadth of these steps means they can’t have a typical design process at BT. Instead they have to adopt a user-centred process with wide guard rails. The importance of language cannot be underestimated either, as we’ve spoken about before with Martyn Reding.

Babylon tries to avoid using terms like innovation and BAU altogether, arguing that when everyone has a shared mission on patient outcomes, they can flex to deliver them in different and new ways.

Ana also recommends clear guides around innovation to avoid a business obsession with the ‘new’:

I don’t believe in feature bloat. Building new things the whole time is overrated. Focus on what is the core value you bring to the user — making that really good first — rather than this obsession with innovation and new things.

Ana Jakimovska

Designers moving into product

There is a lot of tension now between Designers and Product that hasn’t existed before. Is this because product managers have the business acumen and language, able to have the conversations that design can’t?

More designers are moving into Product (particularly in the US) in order to influence at an organisational level. Arguably now more than ever, Design has to prove it can deliver business-level outcomes, with user outcomes as an added benefit.

Babylon, for example, has seen huge benefits in Design Directors becoming Product Directors. They are seeing unexpected levels of collaboration between Product and Design, which in turn elevates the product by removing tension and friction between teams.

Empowering teams with metrics

A bit like Maslow’s hierarchy of needs we often see different levels of metrics. The first level is no metrics; everyone works from random decisions. The next, but arguably more dangerous level, is individual team metrics which can often cause conflicts. The third level is a company-wide alignment — not necessarily the same metric, but connected ones. Andy Budd argues that nirvana is ‘having metrics so embedded in your values and culture that you don’t need to rely on them so much anymore’.

For Conor it’s about short-termism vs long-termism. Some companies have a culture or leadership that’s looking at quarterly stakeholder value whereas some choose to treat the customer properly, play the infinite game over short term gain. It’s up to both Design and Business leaders to set the right environment for both metrics and culture.

Ana as a Chief Product Director sees her role in three ways to:

  • Deliver the best product for the users via other people
  • Enable the environment for people to thrive and be their ‘best selves’
  • Communicate strategy and choice of metrics in a way that creates empowered teams

The panel’s advice? Find the metrics that get the best results for the business. Provide clear boundaries within which teams can work, and offer the right support, resources and buy-in to make it happen. Where possible embed ‘user value’ within a metric to hit that nirvana of empowered teams.

Have you found this useful? Watch the video of the full panel here and make sure to join our next panel on the 27th May.

]]>
Hard to break https://clearleft.com/posts/hard-to-break Mon, 18 May 2020 09:16:00 +0000 https://clearleft.com/posts/hard-to-break I keep thinking about some feedback that Cassie received recently.

She had delivered the front-end code for a project at Clearleft, and—this being Cassie we’re talking about—the code was rock solid. The client’s Quality Assurance team came back with the verdict that it was “hard to break.”

Hard to break. I love that. That might be the best summation I’ve heard for describing resilience on the web.

If there’s a corollary to resilient web design, it would be brittle web design. In a piece completely unrelated to web development, Jamais Cascio describes brittle systems:

When something is brittle, it’s susceptible to sudden and catastrophic failure.

That sounds like an inarguably bad thing. So why would anyone end up building something in a brittle way? Jamais Cascio continues:

Things that are brittle look strong, may even be strong, until they hit a breaking point, then everything falls apart.

Ah, there’s the rub! It’s not that brittle sites don’t work. They work just fine …until they don’t.

Brittle systems are solid until they’re not. Brittleness is illusory strength. Things that are brittle are non-resilient, sometimes even anti-resilient — they can make resilience more difficult.

Kilian Valkhof makes the same point when it comes to front-end development. For many, accessibility is an unknown unknown:

When you start out it’s you, notepad and a browser against the world. You open up that notepad, and you type

<div onclick="alert('hello world');">Click me!</div>

You fire up your browser, you click your div and …it works! It just works! Awesome. You open up the devtools. No errors. Well done! Clearly you did a good job. On to the next thing.

At the surface level, there’s no discernable difference between a resilient solution and a brittle one:

For all sorts of reasons, both legitimate and, as always, weird browser legacy reasons, a clickable div will mostly work. Well enough to fool someone starting out anyway.

If everything works, how would they know it kinda doesn’t?

Killian goes on to suggest ways to try to make this kind of hidden brittleness more visible.

Furthermore we could envision a browser that is much stricter when developing.

This something I touched on when I was talking about web performance with Gerry on his podcast:

There’s a disconnect in the process we go through when we’re making something, and then how that thing is experienced when it’s actually on the web, which is dependent on network speeds and processing speeds and stuff.

I spend a lot of time wondering why so many websites are badly built. Sure, there’s a lot can be explained by misaligned priorities. And it could just be an expression of Sturgeon’s Law—90% of websites are crap because 90% of everything is crap. But I’ve also come to realise that even though resilience is the antithesis to brittleness, they both share something in common: they’re invisible.

We have a natural bias towards what’s visible. Being committed to making sure something is beautiful to behold is, in some ways, the easy path to travel. But being committed to making sure something is also hard to break? That takes real dedication.

This was originally published on my own site.

]]>
SofaConf 2020 - a technical write-up https://clearleft.com/posts/sofaconf-2020-a-technical-write-up Wed, 06 May 2020 23:00:00 +0000 https://clearleft.com/posts/sofaconf-2020-a-technical-write-up We’ve just launched 2020.sofaconf.com and you should definitely come along! The tickets are incredibly reasonable for a one day conference, let alone a FIVE DAY conference, with an amazing roster of speakers!

We build a good number of event sites at Clearleft, including: dConstruct (we all remember this absolute peach), UXLondon, Leading Design, and Ampersand. Each has its own personality, intricacies and challenges.

Choosing a backend stack

With just eight weeks to go till the conference, we discussed how we would build this site. Our usual go-to is CraftCMS. We have a pretty well-oiled setup for deploying PHP sites (yeah, PHP still works in 2020, crazy-right). It works well, and we’re pretty snappy at building with it.

There is a downside though. With the content and frontend tied together, we end up blocking the fantastic content writers until we’ve done our job, which often leads to a frantic few days for them before launch.

We therefore wanted to separate the two elements. Headless CMS’s are very much a solved problem, and after a recent round of thorough research on CMS options, we had a good idea of what was out there. But for all the brilliant features and options offered by Contentful & Prismic, there was one more attribute to consider.

Familiarity.

CraftCMS can output HTML, but it can also output JSON. We can stick to the CMS our team is familiar with, but consume the content in a totally different, modern codebase!

However, there is a trade-off here. We’ve doubled the number of systems we need for every conference. When the next event comes around, we’re going to have to host a PHP site AND a separate frontend.

The solution? Write a generic multisite event system atop CraftCMS, allowing future event CMS’s to be created in the click of a button, without any code! Decision made at 10am.

Sidenote, time was incredibly tight on this project, but we were ambitious and driven to get this right. A herculean amount of effort was put in by the whole team to pull this off, and it was an honour working with them.

Sophia and I spent a few hours mapping out the entities and endpoints required for the system. With her wealth of events knowledge and my ruthless determinism to make things as generic as possible, we landed on a list of models & fields to create.

Post-its with entities and endpoints

Every event has tickets, a schedule (usually over several days), talks/workshops, people (speakers / MC’s / curators), ‘hygiene pages’, and general conference settings. So starting with that as the basis, I created a new multisite Craft instance and began building the CMS.

Craft does have a GraphQL API, but there’s nothing wrong with a classic bit of JSON. The element API works really nicely and we could build custom endpoints very quickly. By the afternoon of day one, we had speakers and schedules into the CMS, and exposed on two endpoints.

The project config file was a lifesaver for this project. It gave us ‘migrations through commits’ and proved incredibly useful for deploying changes without interruption over the past week.

We deployed the CMS and handed the keys over to the events team to begin adding content - in record time.

Choosing a frontend stack

As big fans of the principle of least power, it was essential we had a solid base of HTML for the site. So the choices were:

  • Server render (like PHP) - given we’d stepped away from Craft for the frontend, this seemed like a backwards step. It also exposed the API as a point of failure, something I wanted to avoid
  • SSR (like Next/Nuxt) - we’d need a Node environment, and again, point of failure
  • Pre-rendered/JAMstack (like Gatsby/Eleventy/Hugo) - this seemed to tick all the boxes

Of the pre-rendered options there was really only one contender. Gatsby arrives with a gigatonne of unnecessary JS for a site like this. Hugo sadly can’t create pages from data files. So we opted for the coolest kid in the class right now, Eleventy

/* _data/speakers.js */

const fetch = require('../_utilities/content');

module.exports = async function () {
  try {
    return fetch('speakers').then(({ data }) => data);
  } catch (e) {
    return [];
  }
};

And a wrapper around node-fetch

/* _utilities/content.js */

const fetch = require('node-fetch');
const https = require('https');

const httpsAgent = new https.Agent({
  rejectUnauthorized: false,
});

const API = process.env.API || 'https://events.local';
const CONF = process.env.CONF || 'sofaconf2020';

module.exports = function (path, query = '') {
  return fetch(`${API}/${CONF}/${path}.json${query}`, {
    agent: httpsAgent,
  }).then((x) => x.json());
};

Next, I created a file called speakers-pages.njk as per the create pages from data documentation.

---
layout: layouts/base.njk
pagination:
  data: speakers
  size: 1
  alias: speaker
permalink: 'speakers/{{ speaker.slug }}/'
---

<div class="flow">
  <h1>{{ speaker.title }}</h1>
  <p>{{ speaker.role }}</p>
  <a href="{{ speaker.companyWebsite }}">{{ speaker.company }}</a>
  {{ speaker.bio | safe }}
</div>

I visited /speakers/andy-budd, and hey presto, we had a basic speakers page! From that we fleshed out the structure of the site for the data-generated pages (hygiene pages, schedule and speakers), and single pages (tickets, home, venue). After a day of hard work, we had a skeleton site ready and a CMS, all while the design was still in the infancy.

The next day, I made a start on the utopia implementation and design tokens, then cracked on with a first pass at the speakers grid.

Speakers grid with Amy Hupe, Andy Budd, John Cutler, and Jonathon Colman

Eleventy exposes the fetched API data as a global variable, so looping the speakers into a grid was as succinct as:

<div class="speakers-grid">
  {% for speaker in speakers %}
    {% include '_includes/components/speaker-preview.njk' %}
  {% endfor %}
</div>

Blobby masks are all the rage right now, but I’d not created one before. However, my learned colleague and friend, Cassie had just built a client site that was oh-so-blobby! Using a @supports query, we can serve a circular image to browsers that don’t support masks, and enhance up for the ones that do!

.speaker-preview img {
  border-radius: 100%;
}

@supports (clip-path: url(#speakerMask)) {
  .speaker-preview img {
    clip-path: url(#speakerMask);
    -webkit-clip-path: url(#speakerMask);
    border-radius: 20px;
  }
}

Soon after this point, I was seconded back to a client project, and I handed the frontend over to Cassie. Thanks to the decoupled site & CMS, she focussed on absolutely nailing the frontend with mocked data. I then spent the first hour of each day adding and tweaking endpoints as required. It was a great way to play to our strengths and use our time wisely to get this site ready as soon as possible.

Deployments & collaboration

Rather than rely on an API & database for every page load, a JAMstack site gathers up the content at build time. So we needed a way to trigger a build of the site. Netlify; our host for this project, allows you to trigger a build via a POST to a webhook - a unique URL to your project. Ideally we’d add a button to do this within Craft, but given the very tight timeframes and MVP mindset, we went for a Slack integration.

The build hook builder on Slack.com

You can set up Slack integrations with zero code through their website. When Slack sees the words launch-sofaconf in our internal channel, it fires a POST to Netlify, which rebuilds and deploys the site. 25 seconds later, the site is live! A button is probably more useful, but there’s something really fun seeing your colleagues tweaking the site and making deployments!

Jason & Sophia triggering the build

As well as getting the CMS live quickly, we deployed the frontend almost immediately, allowing us to collaborate:

  • We adapted the frontend during the build as the live content arrived
  • There was no ‘big reveal’ or surprises, as everyone involved could see the latest version of the site
  • We could deploy CMS changes without disrupting the team or imposing content freezes.

Added bonus

Finally, Eleventy and Netlify made it incredibly straightforward to max out Lighthouse.

100 across the board in Lighthouse

This was originally posted on my website.

]]>
Tiny lesson: the question protocol https://clearleft.com/posts/tiny-lesson-the-question-protocol Wed, 06 May 2020 10:38:00 +0000 https://clearleft.com/posts/tiny-lesson-the-question-protocol The question protocol is a simple but effective technique we always use at Clearleft when we’re designing online forms. It’s a way of doing detective work to fully understand the real purpose of a form in order to maximise the effectiveness of it design.

The biggest effect you can on a form’s effectiveness is to ask the right questions, and only the right questions. Every piece of information you ask for is another hurdle for your user to get over before they complete the process.

When designing a form, you can ensure you are gathering only pertinent information by always invoking the question protocol. The question protocol forces you — and your organisation — to ask yourselves why you are requesting a piece of information from a customer. Getting to the bottom of why you’re asking a question means determining precisely how you will be using the answer, if at all.

Each piece of information you ask for has two costs:

  • Firstly it is an impairment to accurate completion of the process;
  • Secondly there is a time and money cost of collecting, storing and processing any additional information, and handling situations where the information is false or inconsistent.

With this in mind, the question protocol asks the following of any information that you are asking:

  1. Why do you need this information?
  2. Who will use the information, and what decision will be made or action taken based on the information collected?
  3. How will you validate the information that is submitted?
  4. What happens if the submitted information is false or made up?
  5. What’s the impact of the information not being submitted?
  6. What happens if the information goes out of date?
  7. Can a customer update their submitted information? Should they be able to?
  8. Are you allowed (legally and ethically) to collect this information?
  9. How is it shared? With whom? What are the privacy implications?
  10. How securely does it need to be stored?

Asking those questions should lead you to answering the ultimate one: “Is the question really necessary?” In the long run following the question protocol can save money and improve conversions and process completion.

You can watch our other #TinyLesson videos here

]]>
Introducing SofaConf, the new low-cost stay at home conference https://clearleft.com/posts/introducing-sofaconf-the-new-low-cost-stay-at-home-conference-from-clearleft Tue, 05 May 2020 23:00:00 +0000 https://clearleft.com/posts/introducing-sofaconf-the-new-low-cost-stay-at-home-conference-from-clearleft While Clearleft are first and foremost a design consultancy, we’re huge fans of conferences and events. We love attending them, we love speaking at them, and most of all we love producing them.

We love bringing people together from around the world to meet, socialise, share ideas, build friendships, and learn from the experience of others. Most of all I think we love the sense of connectedness and community.

This desire to learn from others and share what we know is one of our core values. It’s also part of our mission to advance the practice and impact of design. Events are in our DNA.

The past few months have been especially hard for us. We’ve had to cancel travel plans, withdraw from speaking opportunities, and postpone several of our own events. It’s funny how much one relies on community connectedness, until it’s no longer there. So we’ve been jonesing for a good online event and couldn’t wait to get cracking with producing one of our very own.

That’s where the idea for SofaConf came from. We didn’t just want to create an online version of one of our traditional conferences. Instead we wanted to create a new event from the ground up, with the online experience in mind.

A big part of the in-person event experience is the location. Both the venue itself, and the city it’s in. We love using non traditional spaces, from dance schools (UX London) to brutalist design classics (Leading Design). Sadly this isn’t something you can recreate online, nor should you want to. But the online environment is equally important.

We’ve spent the last 2 months trialing every online event platform we could, and I have to say that as product people we’ve found it hard to find a platform that suits our needs. Some tools are better than others, but it feels like a market ripe for improvement. Fortunately we’ve partnered up with a relatively new platform who are up for doing things differently. So while they’re not quite there yet, they’re one of the few heading in the right direction. As an agency with UX at our heart, we look for the partners who will work with us on making the most of the customer journey. There might be hiccups along the way, but we work tirelessly to try and get it right for all involved.

Another important aspect of a great conference are the speakers and the content they bring. One of the things I’m most proud of with our events is their curation. If you come to a Clearleft event you know that you’ll be seeing amazing speakers with polished presentations, and an interesting perspective to share. I think it’s this mark of quality that keeps folks coming back to our events year after year.

Sofaconf daily themes
Each day of the conference focuses on a different theme

So I’m thankful to all the wonderful speakers who have put their faith in Clearleft to pull off our first ever online event.

The last component to a good conference is obviously you, the attendees. After all, without you it would just be a bunch of speakers standing on an empty stage—or in this case talking to an empty online conference room. We’re doing everything possible to make this more than a series of Zoom calls joined together with a loose theme.

Sofaconf speaker headshots
Some of the SofaConf speakers

We also realise it’s a tough time for many in our industry at the moment. Many designers, researchers, content writers and product people have had their hours cut, been put on furlough, or found their roles made redundant. At the same time there are a host of graduates about to enter the job market for the first time. Under these circumstances we wanted to make our event as affordable as possible, as well as ensuring we had a some scholarship places available.

The pricing also reflects the fact this this is our first online event, and our reliance on new tech platforms and transfer speeds. We’re working on getting it right, we want it to be the absolute best and we’re really looking forward to getting cracking. As with all new ventures, there may be a tweak or two needed here and there, so please bear with us if there is!

Fortunately, while our operational costs and commitment to paying speakers and suppliers remains the same, our unit costs in the form of venues, catering and AV have come right down, which allows us to play with our pricing. We launched ticket sales with a mega early bird price of £39 +VAT and currently our last chance tickets cap out at a remarkably low £65 +VAT.

To make this work we need to sell a tonne of tickets. Probably 20 times more than we’d normally sell for an in-person event. So we’re going to need the community’s support.

If you’ve been to one of our events in the past, however long ago, and would like to join us, please buy a ticket. If not for you, you can always give it to somebody in need. Maybe a student, a junior designer, or somebody who you know would really appreciate it. We are also able to offer some tickets as part of our scholarship programme. If you’d like to apply for one of these tickets please fill in this short form by Friday 29th May and we’ll be in touch by Friday 5th June with more information.

We’d also be grateful if you could spread the word on social media…

As well as putting on a wonderful event to lift spirits and bring the product design community together, we also wanted to have a positive impact on the current situation. So if you can afford it (and only if you can afford it) we’re suggesting that folks add an extra £7 donation to help support key workers during this difficult time. The uptake has been really impressive with nearly 70% of attendees adding a donation. We’re also looking for an event sponsor to match these donations, so if you’d like to get involved, please drop us a line.

We can’t wait to see you all there…until then…

]]>
Navigating remote at Clearleft https://clearleft.com/posts/navigating-remote-clearleft Mon, 04 May 2020 21:04:00 +0000 https://clearleft.com/posts/navigating-remote-clearleft It’s not easy, working in lockdown, juggling caring needs, client projects and everything in between. So we wanted to share what we’ve been doing to help.

With remote working in the current circumstances, we all need to be more flexible and accommodating. We wrote a few things so everyone at Clearleft knows It’s OK for them to be working a bit differently. We’ve also been discussing what we’ve learnt overcoming the challenges of working remotely with our clients. Since lockdown, we’ve run remote design sprints, workshops, project kickoffs and design walkthroughs. We’ve certainly found a few things help and we wanted to share them with you.

Work to the lowest denominator

As tempting as it is to dive into a complex remote set-up, basing the technology on the person with the worst set-up is essential in order to level the playing field. We’ve been checking not just everyone’s tech set-up, but also, importantly, tech preferences.

Even if all the tech seems OK, we lean towards having backups for both video calls and collaborative tools so we can quickly switch from Zoom to Google Hangouts or Miro to Mural, without losing precious time.

Build in asynchronicity

Asynchronicity allows for work to happen at a different pace, and fit into different remote working commitments and needs. As highlighted in level four of Matt Mullenweg’s Five Levels of Autonomy “You evaluate people’s work on what they produce, not how or when they produce it. Trust emerges as the glue that holds the entire operation together.”

During design sprints, we may choose to share the activities that we as a group need to organise, and re-convene in an hour or two to share the outcomes. This can also ease some of the fatigue, and provide respite from being always on video.

Similarly, planning concurrent, complementary activities to complete on a project remotely can create a nice energy. It builds a creative connection between the team and disciplines where we’ve lost that design studio feel.

Consider your options

We’ve been trying to ask ourselves - could a phone call do instead? For one-to-one conversations that don’t require a screen, we’ve fallen back in love with the trusty telephone. They are also a great chance to do a standing or walking meeting and give our eyes a break.

Where a video call would be beneficial but the team may not be available at the same time, we’ve been using embedded videos. Loom (embedded video) is great for those asynchronous conversations. We’ve been using it to talk through wireframes and share work across time zones, and have found it invaluable in helping with flexible working. It’s definitely something we’ll continue to use long after this burst of remote working ends.

Start the workshop before the workshop starts

For workshops and sprints, we’ve been providing a link to Miro (or collaborative tool of choice) with small warm-up exercises to the client team in advance. This helps avoid new information overload and helps people get used to the tool, even if they haven’t used it before. It helps save tech admin time, and makes participants feel more at ease.

In the same vein, we always build-in a small activity at the start of a workshop or sprint to practice the basics, test the tech and bond the team. We’ve had clients designing their top trump card, doodling their everyday superhero or uploading a pic of their favourite mug. Visit Gamestorming or Session Lab for more ideas.

Gamestorming diagram
Gamestorming explains activities have three phases. Vary the style of activity (and avoid death by post-it note)

Create your own watercooler moments

We’ve found that opening up the video call 5-10 mins early is a great way to supplement the watercooler moments you would normally have in-person. Having an off-topic, human conversation before ‘talking shop’ helps to get to know clients better, and build better relationships.

If you’re using Miro, consider creating a breakout area/kitchen board complete with coffee and plants to capture those offline chats and thoughts that happen over the coffee breaks.

Increase preparation time 4:1

Take the time and effort to design the virtual workshop room with exercises and virtual post-its. We now create separate boards or constrained frames in Miro so people can’t look ahead, akin to reading the next chapters in a text book before you’re there. This helps retain focus which helps both the facilitator and the team. You could also consider having a front-of-house and back-of-house Miro board that you can copy and paste from and into, as you go. We know it’s all too tempting to scroll ahead and look around the artboard at the next activity.

Splitting a one week sprint over two can feel like you’ve made less progress, but when you’re remote it’s about quality, not speed. So make time to build-in extra clarity around working time and expected outcomes, each step. Aim to end a day with no outstanding tasks to complete alone.

Over-facilitate

From meetings to workshops, an extra level of facilitation can make all the difference. We’ve been making sure our meeting etiquette is on top form, from having a clear agenda to being wary of Zoom fatigue and checking if certain times of day are more convenient due to personal needs.

For workshops and sprints, make sure to include rules (and permissions) of the workshop in a slide at the start - for example, phone off, do not disturb on, raise a hand to speak, thumbs up to agree, feel free to sit back and listen rather than sitting forward and looking at the screen.

Every workshop lives or dies by two factors:

  • What information and ideas the audience provides
  • How the audience feels (energy and attention)

Your job as the facilitator is to maintain education, energy and attention.

We’d love to hear what you’ve learnt over the recent months and how you’re supporting each other and clients @clearleft

]]>
The Good, The Bad and The Ugly of A/B Testing https://clearleft.com/posts/the-good-the-bad-and-the-ugly-of-a-b-testing Sun, 03 May 2020 23:30:00 +0000 https://clearleft.com/posts/the-good-the-bad-and-the-ugly-of-a-b-testing Like many designers, I have a complicated relationship with A/B testing.

On the one hand I think it’s a very powerful tool that can help designers cut through opinion battles, test hypotheses, and get the most effective solutions into the hands of customers quickly. However, we also run the risk of removing human judgement from the equation, prioritising company KPIs over customer needs, and iterating towards local maxima.

A chart showing of the dangers involved in iterating towards a local maxima.
An Explanation of the dangers involved in iterating towards a local maximum. Also known as "putting lipstick on a pig."

The Benefits of A/B Testing

The benefits of A/B testing are fairly obvious. You have a couple of simple design or product improvements you’re looking to make, but aren’t 100% sure which will yield the best results. One of your team feels very strongly about one direction, one of your stakeholders feels strongly in the other direction, and the rest of you can’t be sure either way.

In these sorts of stalemates, politics invariably comes to play. Who has the most sway in the organisation, who is the best at arguing their case, and who can’t you afford to piss off? If the person in question is particularly good at arguing their case, could they argue the counterpoint just as convincingly? In which case, is there really a clear and obvious solution?

In these situations two things can happen. Either one person gets their way, leaving the others feeling frustrated that their opinions haven’t been heard, or worse, no decision gets made and this conversation is set to repeat itself ad nauseam. I’m sure we’ve all been there.

A good example of this sort of decision is the humble ratings widget. Imagine you’re in a product team trying to decide whether a star or a number system would be better. If you go for the star system, should you use four, five or six stars, and should you allow only portions of a star to show? If you choose a number system, should it be a 5, 10 or 100 point rating, and will you accept decimals?

You could do some desk research to see if there’s a research paper on the subject, but how do you know this will work with your particular audience? Or you could simply copy what your competitors are doing. After all, they’re bigger than you so surely must have done the research?

This is the situation that Sim Wishlade from OpenTable found himself in recently, and he writes eloquently about the research they undertook and the finding they made in a Medium article entitled, When 3/5 doesn’t equal 6/10. As you can imagine, the obvious solution isn’t always the best solution.

When 3/5 doesn’t equal 6/10 Exploring the perception of user ratings
When 3/5 doesn’t equal 6/10. Sim Wishlade explores the perception of user ratings

When Opinion Fails

As Designers we see ourselves as experienced decision makers with a keen sense of what works and what doesn’t. Repeated A/B testing goes to show that we’re not quite as accurate as we’d like to think. We like to explain that customers are terrible judges of future behaviour, without realizing that we fall prey to the same biases. It turns out we’re actually pretty poor judges of future user behaviour.

In his talk from The Next Web back in 2013, Dan Siroker explains some of the tests he carried out for the Obama Campaign. He poses a simple question to the audience. Which of these videos, which of these header images and which of these calls to action proved to be the best. As you can imagine, the audience got the answer spectacularly wrong, as did their own designers.

Why Don’t Designers Test More?

If even the best designers make these sorts of mistakes, why aren’t we testing more? I think there are a couple of answers to this.

The first answer is a process and tooling problem. While it’s relatively easy for an individual designer to initiate a quick usability test independently, A/B testing requires tooling and coordination. You need to pick an A/B testing platform, you need your dev partners to implement it, and you need to have both the time and capacity to do something with the results. As you can see, there are a lot of places where something like this can fall down.

For a start, picking and implementing A/B testing solutions takes time and money. So who is going to be responsible for evaluating and procuring this system, who is going to manage and implement the system, and who is going to pay for it? Most product teams find it hard enough shipping their existing backlog, without adding more work for themselves.

If you do manage to put a testing framework into place, implementing tests will require coordination between your design, engineering and analytics teams. I’m sure QA will also have something to say here. Considering the relationship between design and engineering can be challenging at the best of times, is it any wonder that designers prefer to stick with a more qualitative testing approach they can manage largely on their own?

The other problem is one around power and self-image. Designers have always been at the bottom of the pecking order when it comes to product teams, as they neither have the muscle of the engineering teams (in the form of headcount), or the influence of the product managers. So designers are very conscious of anything that may devolve further power away from them.

Admitting that they don’t know the answers to even basic questions like “should we use star or number ratings?” can undermine what little power and status they already have. Handing some of that power over to a more analytically focussed team can be even more challenging, especially if recent history is anything to go by.

41 Shades of Blue

No, we’re not talking about some new E.L. James series here. Instead we’re talking about an incident that happened at Google many years ago, and has subsequently gone down in designer folklore. In the early days of Google, design didn’t yet have a “seat at the table” and designers found it difficult to thrive in an environment dominated by testing. Every small decision needed to be tested and validated, including the precise hex value of a button. In a now famous article, designer Doug Bowman explained how their testing culture had driven him out.

10357

This article resonated with many designers who felt that they had to prove every small decision from first principles, and their agency as a designer was being diminished as a result. While Google later justified their decision, I can understand this point of view. It often feels like questionable decisions get pushed to production by other departments with little or no due diligence, but when a designer wants to make even a small change, they have to provide incontrovertible evidence that it’s the right thing to do.

Building a Culture of Experimentation

The key thing therefore is balance. Creating a culture where A/B testing isn’t used as a battering ram to win arguments, and ensuring the right things get tested.

One company understands testing better than most, and that’s the folks at Booking.com. In his excellent Google Conversations talk, then Director of Design Stuart Frisby, explains how he went about creating a culture of experimentation amongst his team.

The Potential Pitfalls of A/B Testing

While designers should be doing a lot more A/B testing than they currently are, there are some pitfalls to be aware of. Not least the idea that every solution that performs better is therefore the right solution.

It’s easy to see where this attitude comes from. Teams are taught that it’s their job to improve customer experience, and that the way to do this is to optimise for specific KPIs and OKRs; usually relating to acquisition, retention and customer satisfaction. So teams set out to move the dial, safe in the knowledge that if they hit their targets, everything will be okay.

You can see a glimpse of this mindset in this excellent story from Anna Blaylock at Netflix. On joining the Netflix team, Anna wondered why the product didn’t let prospective customers see all the content on offer before signing up. From a designer’s perspective, this seems like a sensible thing to do, and so Anna set about devising a test.

As you can probably imagine, the test came back negative. It turns out that more people sign up to Netflix if they don’t get to see everything that’s on offer in advance. Anna likens this to the difference between reading a restaurant menu and eating the food. The experience of using Netflix is so much more than just the list of films and TV shows on offer; anything else is a distraction. If I worked at Netflix, I’d probably have a similar take. I’d know the product was amazing, in part because I built it, and so all I needed to do was remove as many barriers as possible, to let others fall in love with it as well.

However I believe there could be another reason why registrations went down. What if some users wanted to make an informed decision about the content and decided that there wasn’t enough value for them? Maybe they were looking to see if their favourite show was on that particular platform, or they were trying to judge whether Netflix had more of the content they liked than Amazon? So maybe showing users the catalog before singing up was the “right” thing to do, even at the expense of sales.

I think this is one of the challenges with A/B testing. It’s easy to assume that optimising around a specific metric is inherently good, and do everything in your power to hit those numbers.

Now this particular incident is fairly innocuous, which is why I picked it. However I do believe that when unchecked, A/B testing can lead to serious problems.

The World We Live in Today

It’s safe to say that things are a little crazy at the moment. Global pandemics aside, all sorts of fringe beliefs seem to be gaining traction of late, from flat Earth theorists, to people burning down 5G masts, and much much worse.

While a lot of people blame “The Algorithms” what they’re really talking about is an extreme form of multivariate testing. Seeing what content is most effective at driving engagement, and providing more of it. Modern platforms may be running dozens, hundreds, even thousands of tests a day. Many of these tests are automated, the decisions aren’t fully understood, and aren’t necessarily passed through some sort of ethical lens. As long as the metrics are going up and to the right, everybody is happy.

[I sometimes joke that while engagement metrics are going up and to the right, so is the tone of the conversation]

I worry that in their quest for efficiency, many of the big players have over-instrumented their design processes; removing human due-diligence, and hiding behind their OKRs in their unwavering belief that more means better.

I mean, I think we can all agree on the transformational experience of travel (carbon footprint aside). But what about the additional stress you’re causing with your cleverly worded prompt explaining it’s the “last room left at this price” and that “5 other people are looking at this room right now”? It’s not exactly a dark pattern (assuming the information is true) and I’m sure the wording tested well, but is it the “right” thing to do?

Similarly I think we can all agree how useful the recommendations are on video streaming platforms. However is it really beneficial to the user when they intended to watch one video, but end up watching three? The biggest competitor to these streaming platforms may be sleep, but is that something to optimise towards?

Now I appreciate that A/B testing—and its cousin, programmatic recommendations—aren’t solely to blame here. But the scale at which this is happening inside companies has become difficult to counter. Especially when hiding behind the argument that all we’re really doing is optimising for the same set of KPIs we’ve always been doing; we’re just getting better at it.

So while I think designers should be doing more testing than they currently are, I also think it’s important to know when not to automate decision making. I’d encourage you to start playing with the technology, and maybe even consider moving somewhere with a mature testing culture when it’s next time to switch jobs.

But it may also be worth asking the interviewers the following question:

“When was the last time you decided not to ship a change that A/B testing demonstrated performed better, and why?”

That way you can at least tell whether the dog is wagging the tail, or the tail wagging the dog.

]]>
Principles and priorities https://clearleft.com/posts/principles-and-priorities Mon, 27 Apr 2020 14:36:52 +0000 https://clearleft.com/posts/principles-and-priorities Using design principles to embody your priorities.

I think about design principles a lot. I’m such a nerd for design principles, I even have a collection. I’m not saying all of the design principles in the collection are good—far from it! I collect them without judgement.

As for what makes a good design principle, I’ve written about that before. One aspect that everyone seems to agree on is that a design principle shouldn’t be an obvious truism. Take this as an example:

Make it usable.

Who’s going to disagree with that? It’s so agreeable that it’s practically worthless as a design principle. But now take this statement:

Usability is more important than profitability.

Ooh, now we’re talking! That’s controversial. That’s bound to surface some disagreement, which is a good thing. It’s now passing the reversability test—it’s not hard to imagine an endeavour driven by the opposite:

Profitability is more important than usability.

In either formulation, what makes these statements better than the bland toothless agreeable statements—“Usability is good!”, “Profitability is good!”—is that they introduce the element of prioritisation.

I like design principles that can be formulated as:

X, even over Y.

It’s not saying that Y is unimportant, just that X is more important:

Usability, even over profitability.

Or:

Profitability, even over usability.

Design principles formulated this way help to crystalise priorities. Chris has written about the importance of establishing—and revisiting—priorities on any project:

Prioritisation isn’t and shouldn’t be a one-off exercise. The changing needs of your customers, the business environment and new opportunities from technology mean prioritisation is best done as a regular activity.

I’ve said it many times, but one on my favourite design principles comes from the HTML design principles. The priority of consitituencies (it’s got “priorities” right there in the name!):

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

Or put another way:

  • Users, even over authors.
  • Authors, even over implementors.
  • Implementors, even over specifiers.
  • Specifiers, even over theoretical purity.

When it comes to evaluating technology for the web, I think there are a number of factors at play.

First and foremost, there’s the end user. If a technology choice harms the end user, avoid it. I’m thinking here of the kind of performance tax that a user has to pay when developers choose to use megabytes of JavaScript.

Mind you, some technologies have no direct effect on the end user. When it comes to build tools, version control, toolchains …all the stuff that sits on your computer and never directly interacts with users. In that situation, the wants and needs of developers can absolutely take priority.

But as a general principle, I think this works:

User experience, even over developer experience.

Sadly, I think the current state of “modern” web development reverses that principle. Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience.

I feel like personal websites are an exception here. What you do on your own website is completely up to you. But once you’re taking a paycheck to make websites that will be used by other people, it’s incumbent on you to realise that it’s not about you.

I’ve been talking about developers here, but this is something that applies just as much to designers. But I feel like designers go through that priority shift fairly early in their career. At the outset, they’re eager to make their mark and prove themselves. As they grow and realise that it’s not about them, they understand that the most appropriate solution for the user is what matters, even if that’s a “boring” tried-and-tested pattern that isn’t going to wow any fellow designers.

I’d like to think that developers would follow a similar progression, and I’m sure that some do. But I’ve seen many senior developers who have grown more enamoured with technologies instead of honing in on the most appropriate technology for end users. Maybe that’s because in many organisations, developers are positioned further away from the end users (whereas designers are ideally being confronted with their creations being used by actual people). If a lead developer is focused on the productivity, efficiency, and happiness of the dev team, it’s no wonder that their priorities end up overtaking the user experience.

I realise I’m talking in very binary terms here: developer experience versus user experience. I know it’s not always that simple. Other priorities also come into play, like business needs. Sometimes business needs are in direct conflict with user needs. If an online business makes its money through invasive tracking and surveillance, then there’s no point in having a design principle that claims to prioritise user needs above all else. That would be a hollow claim, and the design principle would become worthless.

Because that’s the point with design principles. They’re there to be used. They’re not a nice fluffy exercise in feeling good about your work. The priority of constituencies begins, “in case of conflict” and that’s exactly when a design principle matters—when it’s tested.

Suppose someone with a lot of clout in your organisation makes a decision, but that decision conflicts with your organisations’s design principles. Instead of having an opinion-based argument about who’s right or wrong, the previously agreed-upon design principles allow you to take ego out of the equation.

Prioritisation isn’t easy, and it gets harder the more factors come into play: user needs, business needs, technical constraints. But it’s worth investing the time to get agreement on the priority of your constituencies. And then formulate that agreement into design principles.

This was originally posted on my own site.

]]>
In-House and Agency sitting in a tree https://clearleft.com/posts/in-house-and-agency-sitting-in-a-tree Mon, 27 Apr 2020 10:50:00 +0000 https://clearleft.com/posts/in-house-and-agency-sitting-in-a-tree It’s ironic that since starting Clearleft, we’ve been advising our clients not to become too reliant on agencies like our own.

We remind them that they need to develop both internal capabilities and organizational memory, so that when their agency partners leave—as they always do—they’re not left with a critical skill or knowledge gap.

We start every project with an awareness that we’ll leave as soon as is practical, and it’s our job to make sure the client and their team are in the right place when we do. We’re not here to get you addicted to our services, as many other agencies are wont to do, and pump you for every last bit of budget. Far from it. Instead our goal is to help our clients improve the speed and quality of their output as quickly as possible, and then get out of the way.

We do this by acting as “player coaches”. By embedding in teams, raising standards and setting pace. Now I’m probably the least likely person at Clearleft to use a sports analogy, so apologies if it’s not your bag. But I liken our impact on a team to when David Beckham went to play with LA Galaxy. His very presence caused all the other players to up their game as a result.

Measuring skills

We often start our engagements with a skills audit, to understand the existing skills and experience of the team, and where we can add the most value. This can feel intimidating at first. Especially for design leaders who are tasked with building the perfect team. What will we uncover, and will it potentially make them or their team look bad?

More often than not we discover teams with a high level of competence across the board, but lacking depth in a few key areas. This is often for good reasons.

One of the main reasons is simple pragmatism. If you’re running a team whose job is to iteratively improve an existing project, they probably don’t need (or get to flex) their new product innovation and prototyping skills. That doesn’t mean that they can’t add value. Just that they’ll be more efficient, more effective and learn more on the way if they’re paired with a team that does this every day. This is especially true on week-long design sprints, or six-week innovation sprints, where time is tight, and efficiency and replicability are key.

Running a design sprint with a screen and laptop
We've quickly pivotted taking our design sprints remote

Sharing experience

We’ve also been garnering a lot of interest in our design system experiences of late. It’s not that your typical in-house teams lack the ability to deliver a first-rate design system. In fact, I bet they’ve been reading up about design systems for the past 18 months, and can’t wait to get stuck in. But if it’s the first or second time they’re doing this, there are a tonne of common pitfalls they can avoid, as long as they know what they’re looking for. Those pitfalls can slow adoption to a crawl, and force you to go back to the drawing board.

So while it may feel like an unnecessary expense to bring in outside help when you have a team waiting to go, there can be an extraordinary difference between delivering value in 6 months versus 16.

Opening up opportunities

Product teams are all about “build, measure, learn” these days, so it’s ironic that the biggest gripe we hear from internal teams is their lack of learning. The first 18 months of a new job is all about learning the company business model, culture and jargon. It’s exciting and keeps folks engaged. Once you’ve been there for a while, the next 12 months can start to look very similar to the last. A lot of the teams we partner with feel like they’re stuck in a bit of a slump, and are secretly on the lookout for their next move.

In fact we worked with a team recently who were in exactly this space. In the first week, our lead designer was politely told not to get their hopes up because “nothing ever changes around here” and “most of us are looking for our next gig”. Jump forwards 6 months and the team were still there, and loving their work. It turned out that while the company they worked for did present a challenge, the number of opportunities we’d been able to unlock had shown that it was a challenge they could take on and affect in a meaningful way. On the day our designers left, they were taken out for lunch, bought leaving presents, and treated like another member of the team. A wonderful testament to the impact we can have, if ever there was one.

Just enough agency

I think there’s a myth still circulating inside large companies that you either have an agency or an in-house team, but not both. In truth, agencies can be a great enhancement to an existing team. Just as long as you pick the right agency (hint: Clearleft are pretty good at this).

In some ways a good agency is like seasoning. While you can get away without it, the right amount of seasoning brings out the individual strengths of each ingredient, and makes everything perform better. But too much seasoning can ruin a whole dish, so you need a light touch.

]]>
Five steps to an effective content strategy https://clearleft.com/posts/five-steps-to-an-effective-content-strategy Tue, 21 Apr 2020 18:24:00 +0000 https://clearleft.com/posts/five-steps-to-an-effective-content-strategy Content strategy, as I’ve written before, isn’t a magical document you can hand over to a team and expect results. It takes time to create one, and you’ll need to take several people along that journey with you. Here’s how to get started.

Strategy is a combination of things which together will help you achieve an outcome. When it comes to content strategy, these things could include (but may not be limited to):

  • Process
  • Tools and systems
  • Resource and skills
  • Measurement
  • Content foundations (such as guidelines and voice and tone)
  • The drivers (business goals and user goals)
  • It’s a combination of the ‘what’, and the ‘how’ that makes a strategy successful. But how do we work out the ingredients that will go into our recipe? I like to think of this in 5 steps, 4 of which you may be familiar with if you work in product design teams.

    pink staircase
    Photo by Max Ostrozhinskiy on Unsplash

    Step 1: Identify your co-designers

    You can’t create a strategy in isolation. Well, you can, but it will be very difficult to get buy-in from those who will need to sponsor and implement it. Believe me, I’ve tried.

    Think about the co-designers of your strategy as the key stakeholders you need onboard: these could be content team members, senior team leads, directors, product owners, or even the CEO. These people will be involved in your workshops and will help shape the output, so make sure you have a broad enough selection. You should also identify the stakeholders you’d like to interview about their current perception of content (more about that in a moment). These should again be a broad mix: think about your customer experience team, marketing, product owners, design leads, etc. You’ll be discovering the view of content in your organisation, as well as who you might need to spend more time influencing.

    Step 2: Discover

    Discovery is about getting to the root of the problem to find out where your opportunities are. So in the case of content strategy, it’s about understanding which of those ingredients listed above you’ll need to focus on. To do this, you need to understand the current content landscape: what’s happening that shouldn’t be, what isn’t happening that should be, are the right people, tools and processes in place, and how can content be made much more effective to meet user needs and achieve business goals? This will involve:

  • Stakeholder interviews (what they think content is, what they think about the content customers see, but also their perception of internal processes, current strategy, skill gaps etc)
  • Process and tools workshops (mapping out current processes and workflows, roles and responsibilities and understanding current tools and their limitations)
  • Data and analytics reviews (what is performing well, what isn’t, where are customers coming from, what are they doing on site?)
  • Collating brand and marketing strategies (to understand their goals)
  • Collating business goals and strategy (what targets does the business need to hit?)
  • Understanding users through testing (how do they behave on site, what are their pain points, what do they need that they’re not getting?)
  • Mapping out the current content journey (to understand what users see from the brand, and in what order)
  • Step 3: Define

    Now it’s time to take everything you’ve learnt, and look at it with your core strategy ‘designers’. I recommend a workshop (or series of workshops) where you look at the alignment between business goals and user goals, then where your current content needs to be improved to help both achieve their goals.

    I then recommend creating a ‘north star’ for your content, and some guiding principles. You’ll then have some criteria to judge existing and future content against.

    Identifying where your content needs improving will result in a number of actions. The next stage is to determine what needs to be in place to make this happen. Do tools, templates, systems, or ways of working need to change?

    Step 4: Develop

    You’ll now have all you need to develop your strategy and roadmap. Taking the workshop output, use your own judgement and knowledge to outline your recommendations. Develop your north star and principles into some kind of tangible artefact — posters work well.

    Turn the actions into a roadmap (what can be done now, and what needs more time? Are there dependencies), assigning owners to each if you can.

    Think about how this work will be shared in the next phase, and pick a format appropriate to those people you’ll need to influence. Most of them should have been on this journey with you, but there will always be a few outliers. How do they best receive information, are they visual or do they like a lot of detail?

    Step 5: Deliver

    Now is the time to start sharing your strategy and roadmap with your wider business. How you do this will depend on the stakeholders (and the number of them). One-to-one sessions might be more useful than group show and tells for those who may need a bit more background on your process.

    Be sure to provide context, and share the journey you’ve been on, so the rationale for your recommendations are clear. It’s also a good reminder for those that were on the journey with you that this is as much their work as yours!

    ]]>
    Overlay gap https://clearleft.com/posts/overlay-gap Mon, 20 Apr 2020 15:52:00 +0000 https://clearleft.com/posts/overlay-gap A problem shared is a problem halved. And the web has a big problem with awful overlays.

    I think a lot about Danielle’s talk at Patterns Day last year.

    Around about the six minute mark she starts talking about gaps and overlaps.

    Gaps are where hidden complexity live. If we don’t have a category to cover it, in effect it becomes invisible. But that doesn’t mean it’s not there. Unidentified gaps cause inconsistency and confusion.

    Overlaps occur when two separate categories encompass some of the same areas of responsibility. They cause conflict, duplication of effort, and unnecessary friction.

    This is the bit I keep thinking about. It’s such an insightful lens to view things through. On just about any project, tensions are almost due to either gaps (“I thought someone else was doing that”) or overlaps (“Oh, you’re doing that? I thought we were doing that”).

    When I was talking to Gerry on his new podcast recently, we were trying to figure out why web performance is in such a woeful state. I mused that there may be a gap. Perhaps designers think it’s a technical problem and developers think it’s a design problem. I guess you could try to bridge this gap by having someone whose job is to focus entirely on performance. But I suspect the better—but harder—solution is to create a shared culture of performance, of the kind Lara wrote about in her book:

    Performance is truly everyone’s responsibility. Anyone who affects the user experience of a site has a relationship to how it performs. While it’s possible for you to single-handedly build and maintain an incredibly fast experience, you’d be constantly fighting an uphill battle when other contributors touch the site and make changes, or as the Web continues to evolve.

    I suspect there’s a similar ownership gap at play when it comes to the ubiquitous obtrusive overlays that are plastered on so many websites these days.

    Kirill Grouchnikov recently published a gallery of screenshots showcasing the beauty of modern mobile websites:

    There are two things common between the websites in these screenshots that I took yesterday.

    1. They are beautifully designed, with great typography, clear branding, all optimized for readability.
    2. I had to install Firefox, Adblock Plus and uBlock Origin, as well as manually select and remove additional elements such as subscription overlays.

    The web can be beautiful. Except it’s not right now.

    How is this dissonance possible? How can designers and developers who clearly care about the user experience be responsible for unleashing such user-hostile interfaces?

    PM/Legal/Marketing made me do it

    I get that. But surely the solution can’t be to shrug our shoulders, pass the buck, and say “not my job.” Somebody designed each one of those obtrusive overlays. Somebody coded up each one and pushed them into production.

    It’s clear that this is a problem of communication and understanding, rather than a technical problem. As always. We like to talk about how hard and complex our technical work is, but frankly, it’s a lot easier to get a computer to do what you want than to convince a human. Not least because you also need to understand what that other human wants. As Danielle says:

    Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

    Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

    So let’s say it is someone in the marketing department who is pushing to have an obtrusive newsletter sign-up form get shoved in the user’s face. Talk to them. Figure out what their goals are—what outcome are they hoping to get to. If they don’t seem to understand the user-experience implications, talk to them about that. But it needs to be a two-way conversation. You need to understand what they need before you start telling them what you want.

    I realise that makes it sound patronisingly simple, and I know that in actuality it’s a sisyphean task. It may be that genuine understanding between people is the wickedest of design problems. But even if this problem seems insurmoutable, at least you’d be tackling the right problem.

    Because the web can’t survive like this.

    This was originally published on my own site.

    ]]>
    Guerrilla Testing - Tips for better results https://clearleft.com/posts/guerrilla-testing-tips-for-better-results Sun, 12 Apr 2020 23:00:00 +0000 https://clearleft.com/posts/guerrilla-testing-tips-for-better-results In our last post we described the merits of guerrilla testing compared with other research methods. In this follow up post we share some tips for getting better results.

    Now that we’ve selected guerrilla testing as an appropriate method for our research, how do we make sure we get the best results?

    When dealing with the tradeoffs of time and rigour, it’s important to be as prepared as possible on the day. Here are some of our rules of thumb for before, during, and after test day.

    Before

    A refined and rehearsed discussion guide adds structure to your tests. We have found value in front-loading our most important questions and leaving the ‘nice-to-know’ toward the end. Doing a dry-run with colleagues will help to trim down the script, weed out ambiguous questions and flush out prototype gremlins.

    The day before, it’s worth checking the weather and dressing to suit. Nothing’s going to shut down our test day quicker than hypothermia or heat stroke. Striking a balance between smart and casual clothes helps with first impressions. If we’re targeting a particular audience or visiting a location with a specific dress code, go with the flow and try to blend in. Our overall aim is to instil a sense of trust and credibility.

    A day of research fieldwork can be long and tiring. It’s important to be a supportive wing-person and keep spirits high so you can go that extra mile if you need to. Our research kit bag is like another team member. It has our back when the going gets tough. Alongside our essentials, we make sure to have a few extras to brighten the mood and revitalise the team. Here are a few things we wouldn’t leave the office without:

    • Spare battery, charge block and cables. Don’t let the tech let us down.
    • Painkillers, chewing gum and lip balm. Because we’re worth it!
    • Go-to snacks of choice. Everyone has their favourite so make sure you know your team’s weakness, savoury or sweet.
    • Screen wipes and antibacterial gel. Our participants won’t want to handle a grubby looking device and neither will we.
    Contents of guerrilla testing kit bag.

    During

    Choosing where we conduct our research is an intentional decision based on prior thinking. Online maps help us to explore areas of interest and potential places our audiences will be congregating. Maps also help us choose a place to set up base for the day. Coffee shops are a firm favourite for guerrilla testing. If you do intend to use a coffee shop, it‘s worth calling ahead to get permission to run sessions on the premises. The prospect of a continuous flow of customers can be appealing to businesses. They might even have a dedicated room you can use for extra privacy.

    The ideal location is somewhere with a lot of footfall and not much flow. We’ve had success in public parks, gardens, and museum forecourts. These places are quiet and intimate. We’ve had less success in train and bus stations. Although a high volume of people congregate there, they tend not to give you their full attention and they might have to leave suddenly.

    Approaching people out in the field can be awkward for both the researcher and the participant. Be respectful of their context and show genuine interest in talking to them. The reality is that they may be on a lunch break, on the way to an important engagement or just want some headspace. Choosing who to approach will require all of our researcher ‘spidey sense’. There are a number of visual cues that help us decide if someone is likely to give us their time. Here a few examples:

    • Body language - If people are closed-in on themselves or avoiding eye contact, chances are they don’t want to be disturbed.
    • Activity - Avoid people who are eating, performing a complex task, or engaged in a conversation. You may want to approach people after they have completed a task if it relates to your research but use your common sense.
    • Groups - Approaching a group of people can increase your success rate but conditions apply; match the ratio of the group size to researcher (1:1), split up for efficiency, and above all stay safe.

    When someone does give you their attention, smile, be confident and concise. We find one person approaching is less intimidating than two. Have your partner sitting somewhere within eyeshot with all the test equipment ready. Introduce yourself and give just enough context to inform them without overwhelming them. If they accept, use the time it takes to walk to your partner to ask a few questions and add a bit more context.

    The reality is that you will be turned down a lot. This is normal. To flip the perspective on rejection we like to turn it into a game. The rules are simple:

    1. Both researchers alternate in approaching people.
    2. If a researcher is rejected they get a point.
    3. Once you have reached your quota of research sessions, the researcher with the most points wins!

    It goes without saying that winning the game is secondary to the success of the research. Still, the game helps to soften the blow of rejection especially for less experienced members of the team.

    After

    At the end of the day, discuss what did and didn’t work well. Make a note of which locations proved most successful. Include participant criteria, day of the week and time of day. Recording this information helps us to decide where and when to visit next time. For example, Monday lunchtimes are particularly precious to London city workers after a morning of back-to-back meetings. Then, at 4pm on a Friday, you’ll inadvertently be blocking their beeline to the pub.

    Great over good

    The advantage of guerrilla testing is that it can be conducted over a short period of time and on a shoe-string budget. Preparation is key for making these brief interactions with our audiences as impactful as they can be. Follow these steps for better research outcomes.

    ]]>
    Why usability testing is not enough https://clearleft.com/posts/why-usability-testing-is-not-enough Tue, 31 Mar 2020 14:03:00 +0000 https://clearleft.com/posts/why-usability-testing-is-not-enough As we launch our 2020 survey we unpack why research (and empathy) deserve a deeper focus.

    Last year our survey found that almost all of the design teams that don’t contribute to their organisation’s goals are only doing small pockets of research or none at all.

    There’s a small number of design teams who are conducting research at least regularly but are unable to translate those efforts into business results. A closer look at our data showed that most of the research these teams are doing is usability testing to validate their designs.

    Usability testing can be a great step for less mature design teams to start engaging with their users due to its practical and visual nature. It can enrich their design process as it allows them to have a better understanding of the interaction between people and an interface. Then, designers can use that knowledge in order to evaluate, validate and/or improve their work. Recordings from testing sessions are also useful to show stakeholders and the wider organisation the value of engaging with end-users in the design process.

    Although extremely valuable, evaluating a design is not enough if design teams want to make a greater impact on their organisation.

    When we evaluate a design we mostly focus on how people fit into a product or service, not as much on the ways in which that product or service fits into the broader context of people. That means we get a narrow understanding of the relevance of our design in people’s context or might not even understand if it’s relevant at all.

    10012

    In order to better contribute to their organisation’s goals, design teams need to have a deeper understanding of their audiences and contexts. They need rich and relevant information about people, their behaviours, views, needs, goals, and the roles that products and services play for them.

    As we learnt from our survey, the most effective design teams have integrated design and research capacities. Therefore, research should be a regular activity that informs design on different levels. Not just an evaluative activity.

    At the same time, designers need to have a clear understanding of their organisation and its context. In this way, they’re better prepared to participate in strategic definitions that are impactful and valuable for both, business and people.

    We have just launched our 2020 survey that builds on these findings - it should take around 10 minutes and we’d really appreciate adding your voice and sharing with your wider team.

    ]]>
    Yet another remote working tips post https://clearleft.com/posts/yet-another-remote-working-tips-post Mon, 30 Mar 2020 13:17:00 +0000 https://clearleft.com/posts/yet-another-remote-working-tips-post As you might imagine, the last few weeks have been all change for the Clearleft folks. BOY have we learned a lot about each other and our new way of working.

    All in all It’s been a fun process. We’ve been taking ‘Through the Keyhole’ tours of each other’s homes. Introduced to pets, children, and our ever-evolving workstations.

    Fortunately, we’re no strangers to remote working. While we love meeting face-to-face with our clients and their users, it’s not always convenient or necessary. Daily standups, remote design walkthroughs and research sessions are all part of an average client project. Going fully-remote has only added another string to our bow.

    So in the spirit of our values – Learn, share, learn, share – we wanted to share our process and tips for working remotely.

    Getting all the important introductions done

    Culture and wellbeing

    Clearleft HQ is a social, open-plan office. It feels like a home away from home with plenty of interesting watercooler moments. It’s easy to see who’s in and what they’re working on. These were all things we wanted to maintain after going remote.

    #CICO Slack channel - Thanks to Sophia we have a dedicated channel for checking in and out of work. Much like the morning ‘hello’, a chat over lunch, and a parting ‘sayonara’ at the end of the day. It feels like the heartbeat of the team and has become one of our most popular channels.

    Watercooler hangouts - We thrive on sharing and learning from one another. Tuning in and out of office conversations is something we were keen to continue once distributed. To encourage these moments, we’ve created dedicated Google Hangout links so anyone can drop in and out during the day. We have specific Hangouts for project teams but also for people who just want to hang out in the ‘kitchen’.

    Support network - We’re an already tightly-knit team both on and off projects. It was important to keep the banter going, now more than ever. There’s been a noticeable increase of gifs, emojis and Photoshopped-images being added to Slack. A blooper reel of the recent BERT test Tiny Lesson emerged. Sophia has been running virtual sourdough baking lessons. We’ve also kept our Friday afternoon social shindig. These things have kept spirits high and brought us together in new ways.

    Ways of remote working

    There’s been a deluge of remote working resources, blog posts, and tools shared over the past week. We’ve been adding the best ones to the Clearleft knowledge bank. Here are some of the more useful and surprising ones we’ve come across.

    Luis’s in-depth resource for remote work introduction and guide is well worth your time. Ashley’s tips on virtual workshops resonated with us, as did this remote workshop guide by the good people at #designandclimate. We also really enjoyed Dr John Curran’s article about reducing anxiety of virtual meetings. Rob Whiting has a growing resource of remote research. Cate and Nicole have a great webinar on remote management.

    The remote collaboration tools we’re using most at Clearleft are:

    • Miro - We’ve been using the virtual whiteboard app since back when it was called RealtimeBoard. It’s been particularly useful for maintaining a consistent working space and when working between our own and client’s offices. It’s also been a gamechanger for clients that don’t have the privilege of wallspace. Now remote is the new-norm it’s our go-to space for collaboration.

    • Figma - We’ve been using Figma far more recently for walking clients through the design process. Where previously we have wrapped up progress in a polished presentation deck, we’re now seeing value showing the process in all its iterative glory. View-only logins allow clients to have ongoing oversight.

    • Whereby - There are so many telepresence solutions to choose from nowadays. Sometimes the solution with the lowest barrier to entry is the most useful. Remote user testing and in-depth interviews are a good example of such scenarios.

    • Dovetail - We’ve used Dovetail a few times now and our fondness for it grows each time. What we love about Dovetail is its present feature. This is particularly useful for presenting back to internal teams and clients.

    • Google Hangouts & Zoom - We use the suite of Google products at Clearleft so Hangouts are our go-to internal telepresence tool. For everything else, we use a separate tool. Usually governed by our client’s current practice, we adapt to their ways of working as soon as we can. Personally, I prefer Zoom for research activities. Offering breakout rooms, a wide range of integration options, local and cloud recording features.

    remote workshop using a Miro board of post its
    The Miro board used during our Zoom workshop on remote workshops

    Tips for better outcomes

    Here are some of our tried and tested tips for better remote working outcomes.

    Katie says: “Be one step ahead of the tech. Consider using other methods of presenting with less risk. We’ve recorded presentations using Quicktime and layered over audio. It’s easy to stitch multiple videos and audio files together from different presenters. Then upload it to a video hosting service and share the link.”

    Trys says: “Keeping people actively focused during a remote workshop is crucial for better outcomes. That’s why I built a web version of the Design Sprint countdown timer.”

    Chris says: “Preparation is key for better research sessions. Send tech setup instructions as early as possible to avoid wasting time during the session. Have a plan B ready if everything goes to pot e.g. a list of questions ready to post into a chat window. If time is working against you, be ready to ditch a task or two rather than rush your participant. Have your camera on if you can to help build rapport with your participant.”

    Benjamin says: “Harness the biophilia effect for a more positive working environment. Research studies show that ‘environments rich with nature views and imagery reduce stress and enhance focus and concentration’. If you can, position your workstation to face a window, introduce a plant or some flowers to your desk. Even images of nature can help, so consider replacing your desktop or screensaver with images of nature.”

    How we can help

    We’re continuing to help our clients during this challenging time. Helping them adapt to a new way of working, and understand and address emerging audience needs.

    If you are looking for help, please get in touch below.

    ]]>
    Prioritising Requirements https://clearleft.com/posts/prioritising-requirements Mon, 30 Mar 2020 08:00:00 +0000 https://clearleft.com/posts/prioritising-requirements In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.

    Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.

    Summary

    Through several group and individual prioritisation exercises, requirement gathering, tool profiling and weighted rankings, we can remove bias from our decision making and better evaluate the tools we use.

    Use our requirements spreadsheet template as a starting point for your costly and crucial technical decisions.

    How we prioritise

    We’re big fans of prioritisation exercises at Clearleft, and regularly help to steer clients in their technical and product decisions. As an agency, our role is not to dictate solutions or steamroll our agenda, but to listen, interrogate and question before using our experience to empower teams to make their best decisions.

    We recently helped a not-for-profit decide which content management system to use. Rather than dive straight into the build, we took a step back, using a technical discovery phase as an opportunity to ask questions, learn and come to a well-informed decision together.

    Although this was used to decide a CMS, the same approach works well for picking front-end frameworks, CSS methodologies, and design/research tools.

    Types of requirements

    We start by breaking down the decision into four chunks:

    1. Non-functional requirements: “How the system should work”
    2. Functional requirements: “What the system should do”
    3. Costs
    4. Risks

    Although tempting to dive straight into the juicy functional requirements, it’s really helpful to begin by framing the problem-space with non-functional requirements.

    Non-functional requirements

    Often referred to as the ‘-ility’s’ (by virtue of the fact many end in those letters), non-functional requirements are just as important as functional requirements. Here are a few examples:

    • Usability
    • Maintainability
    • Reliability
    • Scalability

    They can be pretty ‘wooly’ and subjective, making them quite difficult to quantify. But they are very useful to help frame how successfully a functional requirement has been achieved. For example, every CMS may have the ability to ‘write content’, but some CMS’s may have a text editor that is far more ‘usable’ than others.

    It’s also worth noting that non-functional requirements come with trade-offs. By prioritising one, you usually take a negative hit on another. For example, by prioritising a non-functional requirement of ‘Security’, you may decide to impose strict password requirements, or require two-factor authentication. While that helps achieve the secure goal, it also makes the system more complex from a code point-of-view (less maintainable), but also more complex for the user (less usable).

    Exercise: Ranking exercise

    Take the following list of non-functional requirements, and write them on post-its, if you can think of any others, write them down too:

    Performance

    Response times, TTFB, traffic peaks and troughs, will dictate caching plans and approach

    Scalability

    Does this system need to scale over time?

    Capacity

    How many people can use the system? User accounts.

    Availability

    Where can this system be accessed from?

    Reliability

    Trust in the system & time between failures

    Recoverability

    In the event of a failure, how quickly can the system be restored?

    Maintainability

    Can this system be supported, and is it cost-effective?

    Security

    What is the risk of the system being hacked? User account and passwords

    Regulatory

    Does the system need to be approved, inspected, tested or regulated?

    Manageability

    How easy is it for the maintainers to monitor the system, and spot critical issues?

    Environmental

    How important is environmental impact of the system?

    Data integrity

    Audit trails, revision and checking

    Usability

    The system is prioritised based on usage patterns. User testing and an analytics plan is helpful

    Interoperability

    Should the system slot in with third-party services?

    Affordability

    How price-sensitive is this project? If costs increase, will it be problematic?

    Run through each one, and ensure everyone understands the difference between them all, particularly in how they differ for your project. Scalability and capacity may sound similar, but they will have very different meanings for each project.

    If you’re in a small group situation, rank the requirements. Don’t worry too much if some come out as equally important at this stage.

    In a larger group, you may find dot-voting to be a more efficient way of ranking the most important requirements.

    Pull out the top four or five, discuss them, and write them up in a bit more detail, outlining how they will affect your system.

    Functional requirements

    Functional requirements describe “what the system will do” - or perhaps more accurately, “what the system should do”. These are objective and quantifiable statements that either a system can, or cannot do.

    Here’s a few examples:

    • The system should allow you to upload images
    • The tool should lint our JavaScript
    • The product should have user-editable content types
    • The project should be under £100/month to run

    Exercise: MoSCoW

    Carry out a MoSCoW prioritisation exercise to evaluate and group functional requirements for this system.

    • Must have
    • Should have
    • Could have
    • Won’t have

    By placing each requirement into one of these groups, we gained a sense of importance for each feature. With all the time in the world, everything could be a ‘must’, but that’s not at all practical - be honest about what is achievable for this project.

    Use your prioritised non-functional requirements as a way to justify each decision. If you’ve ranked ‘security’ as a low priority in the first exercise, and then find that in this exercise, ‘two-factor authentication’ is being put forward as a ‘Must have’, it might be worth reevaluating your non-functional requirements.

    Again, post-its are the way to go here, put the four headings on the wall, and group the requirements below them.

    Group the four headings with post-it notes

    Tip: It’s a good idea to pre-prepare a bunch of post-its with common or more obvious functional requirements beforehand, then add to that list as you go.

    Feel free to delve into the rabbit warrens when they arrive. If your pre-prepared requirement says: “users should be able to log in”, interrogate that a little further; start asking questions about roles and permissions, about how many users you may have, and how many concurrent users need to access the system. You may uncover some interesting assumptions from within in the group.

    Costs

    Open source software is fabulous, but not always right for every project. For some systems, relying on a tried and tested paid solution may well be more appropriate. Depending on the non-functional requirements you previously gathered, uptime SLA’s, and guaranteed support might be more important than price.

    Some software has upfront costs, some has monthly or annual subscriptions. Sub-sections of the system may also have their own costs; plugins, add-ons and transaction fees come to mind.

    If you are relying on open source software, strongly consider donating back, it helps keeps the authors in business, and in-turn, working on the project that powers your system.

    Risks

    There are always risks to consider when making a tech stack decision. We joke about there being a “new JS framework every week”, but the age of the product may well be a deciding factor. Too new and you could encounter teething problems, too old and you run the risk of the project being discontinued, or support being challenging to find.

    The ecosystem and community of the solution should also be considered. If there is a healthy community of supporters, maintainers, and authors, the risk of project discontinuation is reduced. It will also be easier to find external support when required.

    Finally, you need to consider your own experience. In our most recent case of picking a CMS, it might’ve been that a system written in Java was the most appropriate, but if no-one on the team has experience in that language, or your hosting infrastructure doesn’t allow for it, that’s a huge risk to undertake.

    Exercise: list your solutions

    Start gathering a list of the possible solutions. Go as wide as you can and include a few wild cards, even if they feel totally inappropriate, they may well surprise you. It’s worth asking your network, colleagues and on Twitter. The more options you have to profile, the better.

    Main exercise: Ranking spreadsheet

    It’s time to start ranking our solutions against our requirements. We like to use a Google Sheet for this sort of thing, but feel free to use Airtable or a simple piece of paper!

    To help you along, we’ve created a Google Sheets template that you can use to get you started.

    Download the template

    Along the top, we list our solutions, and down the side our requirements, costs and risks:

    Create the four requirement sections of the spreadsheet

    In the world of software development, anything is technically possible given the right time, budget and team. A simple boolean yes/no isn’t a fair assessment when profiling systems against functional requirements. We need a more nuanced profile, and go for a 5-point scale:

    • -2: Incredibly complex or time consuming to fulfil
    • -1: Complex to fulfil, requiring a lot of custom code
    • 0: Possible, but would require custom coding
    • 1: Achievable, perhaps adapting an existing system feature
    • 2: Very achievable, and available out of the box

    The same -2 to 2 scale can be used for non-functional requirements too.

    Work through each system, one at a time, ranking it against the requirement. Bring up the project documentation as you go - it’s a great way to get a flavour of how well written their supporting information is, should you choose that solution.

    Try to be as objective as possible when scoring. By breaking out each project feature into requirements, we’re trying to reduce our overall and individual bias.

    For costs, work out the year one and two costs. It’s good to be as aware of the ongoing costs as it is the upfront ones. Factor in plugins, add-ons, donations, maintenance and hosting. You may find it helpful to also break it down to monthly figures, if that will aid stakeholder buy-in. Once you’ve completed the cost breakdown for all the solutions, rank them accordingly working from 0 down. In a group of ten solutions, the cheapest should score: 0, and the most expensive: -9.

    Risks are subjective, and in some ways they should be. Consider age of solution, ecosystem and experience, and rank them from 0 and down.

    Totalling up

    Once you’ve completed all the ranking, it’s time to tally up the results.

    Begin adding values to the spreadsheet

    Non-functional requirement multipliers

    Using the earlier results from the ranking exercise, reverse the order to work out the multiplier. The most important requirements will have the largest number, going down the least important with a multiplier of 1. If you ranked some requirements equally, keep their multipliers the same. You’ll end up with a list a bit like this:

    • Usability × 6
    • Accessibility × 6
    • Security × 5
    • Reliability × 5
    • Maintainability × 5
    • Recoverability × 4
    • Environmental × 4
    • Affordability × 4
    • Performance × 4
    • Availability × 3
    • Interoperability × 3
    • Regulatory × 2
    • Capacity × 2
    • Manageability × 1
    • Scalability × 1
    • Data Integrity × 1
    • Locality × 1

    To amplify the most important requirements, we multiply each score by its position in the scale. A solution that scores negatively on one of the higher priority non-functional requirements, like usability, will therefore take a larger hit than one that isn’t hugely scalable.

    Functional requirement multipliers

    We can use a similar multiplier for functional requirements:

    • Must have × 3
    • Should have × 2
    • Could have × 1
    Total up each section, multiplying the results by their rank

    Cost and risk multipliers

    Multiply the final scores for each solution by 2.

    The results

    Adding up the totals from the four requirements section should give you a score for each possible solution. Sort the solutions in a descending order, where the highest score is the most appropriate option.

    If some of the results seem wildly off, double-check your multipliers, it may be for your project that costs should be multiplied by 4, rather than 2. There’s no one-size-fits-all approach here.

    We then wrote a few paragraphs for the following sections:

    1. The main contenders (top 3-4)
    2. The middle of the pack
    3. The inappropriate options (bottom 3-4)

    Explaining why the solutions were more or less appropriate is incredibly important for when you present these findings back to less technical stakeholders. Don’t skip this step, we found the act of synthesising and writing up the results to be a hugely useful part of the process.

    Next steps

    Discuss!

    The results should by no means be viewed as conclusive, but should help frame a discussion about the various options, and might just pull a few surprise options into consideration - it certainly did for us.

    Download the prioritisation template.

    This was originally posted on my website.

    ]]>
    How to spring-clean your content https://clearleft.com/posts/how-to-spring-clean-your-content Wed, 25 Mar 2020 14:57:00 +0000 https://clearleft.com/posts/how-to-spring-clean-your-content While spring is traditionally time for a clear-out, we often shy away from the boring ‘tidy up’ tasks. In the current climate when we might have some down-time as projects get paused, it seems like a good opportunity to pick up some of those jobs we’ve been putting off.

    Cleaning up your content essentially means starting with a content audit to establish what you have and what kind of state it’s in. If your site has grown organically over time without much of a strategy behind it, the chances are you have a lot of fragmented and inconsistent content, as well as content that’s out of date or not used at all by your customers.

    Regaining focus and creating strategy for content takes time and effort, it’s not an overnight job. But understanding how your existing content needs to be improved is a great starting point.

    In its basic form, a content audit allows you to assess your content against set criteria and work out what the action you need to take with the content. Some suggested criteria are listed below, but you may decide to pick just a handful of these depending on time, access to data, availability of brand guidelines etc.

    Page views

    How many people are actually viewing this page? Does this account for a high volume of traffic?

    Bounce rate

    How many people are leaving this page and not going anywhere else on the site. This might be a good thing (for example if the page is providing a phone number or a link to another site this might be the expected outcome) but if you’re hoping they go onto another part of your site but they’re not, then you’ve uncovered an issue with your content.

    Findability on site

    Can the page be easily found from your main navigation or is there a clear route to this content?

    Findability on Google

    How high does this page rank in search? Going through this exercise is a great way to also audit the metadata and snippet text (but more about that later).

    Tone of voice

    Is the content of the page reflecting your brand voice?

    Accuracy

    Is the content still relevant and up to date? Are there any typos or technical inaccuracies?

    Alignment to principles

    Does the content reflect your brand principles or design principles? For example if one of your principles is ‘Human’, you’d expect your content to sound human, be active (rather than passive) and feature real-life examples or people.

    Value

    What is the main thing you want users to do on this page? Does the main CTA reflect that? And are people doing what you want them to do from this page?

    Usability

    Is your content clear and simple? Is it structured in a way that’s easy to understand, or are users struggling. It might be obviously unclear, or you may have to dig deeper into user behaviour to find this out, for example by doing some more in depth usability testing.

    How do I start my audit?

    I’ve found that boring old spreadsheets work best. Sorry! I know some people use tools such as Airtable, but you’ll have to import the raw data first.

    Begin by extracting a list of your site pages with a tool such as Screaming Frog and export the data into a spreadsheet. Remove the columns you don’t need and clean it up a bit. It’s also worth adding in a column to show what displays in search.

    Begin by extracting a list of your site pages with a tool such as Screaming Frog and export the data into a spreadsheet. Remove the columns you don’t need and clean it up a bit. It’s also worth adding in a column to show what displays in search. Now create a column to add the stage of their journey a user is at for each page and the user’s goal for this stage. For example you might have ‘browse options’ as the stage, and then the user goal as ‘pick an option’.

    Then create columns for the criteria you’re assessing against, so you’ll end up with something that starts to look like this:

    Field labels on spreadsheet
    Field labels

    For the criteria you’re judging against, set some parameters and some conditional formatting. For example, for ‘Tone of voice’ you may want to say ‘Yes’, ‘No’ or ‘Somewhat’, with the cell becoming red for ‘No’, green for ‘Yes’, and amber for ‘Somewhat.’. Using this kind of RAG (Red, Amber, Green) rating system for your criteria will then help you see at a glance which pages are not up to par and will need to be optimised.

    Spreadsheet fields showing red, amber, green
    Your rating system coming to life

    The review process

    Your page assessments will take time, and if a stakeholder is responsible for the content it might take some time to ask questions, or identify the purpose of the page. It’s a lot easier when a content team have created (and are responsible) for all of the content as they have most of the answers.

    I recommend picking off a few pages at a time, and you might want to prioritise your high-traffic pages first. It’s also worth adding a column for comments (what is the page doing well or not doing well?), you can also note any particular typos or issues you spot here. Also add a column to note the page owner, and the action that needs to happen next. Typical actions for the page might be:

  • Remove (page is no longer relevant or not being used)
  • Optimise (it needs updating or improving)
  • Merge (with another page that might have a similar purpose or similar content)
  • You might also want to add ‘Investigate further’ as an option for pages you don’t know enough about.

    How do I prioritise actions?

    If there are a number of pages that can be removed then clean those up right away. For the rest of the content, if it’s important for users and will positively impact your business when optimised, then prioritise it. If it’s not really adding value to users, then the existence of the content should be questioned with the content owner (you now should be able to demonstrate this through your rigorous assessment so make use of your audit in conversations). If you’re the content owner, then have a stern chat with yourself about how this content came to exist!

    Add a column to your sheet for High, Medium or Low priority to your spreadsheet so you know what you need to tackle now, next and later on.

    The other benefit of carrying out an audit is that it can help identify content gaps. You’ll find assessing the content against the user’s goal gives you a different perspective. Are you really giving them what they need at this stage of their journey? If not, add that to your comments column and record an action to improve it.

    Venn diagram showing user needs and business needs
    Where user needs and business needs overlap

    Your audit is going to be a long slog if you have a big website so think about attacking it in chunks, and set a target of maybe 30 pages a week. This makes it something that’s manageable to do in between other work or split across content team members. The more unruly your site, the longer this will take.

    The good news is that you now have a model for any new content. The criteria in your audit sets out a benchmark for future content requests — what’s the purpose, what will success look like, does it follow brand principles and style, etc? But content briefs…well that’s a whole new blog post!

    Once your audit is complete, you’ll have a clear, prioritised list for cleaning up your content, making your site content simpler, more relevant, and much more impactful.

    More about content audits

    Some very wise strategists have written great articles to help you learn more. Try these for starters:

    How to plan a content audit that works for you — Lauren Pope

    How to embrace (and gently encourage) the content audit–Kristina Halvorson

    ]]>
    Design Maturity Assessment https://clearleft.com/posts/design-maturity-assessment Thu, 19 Mar 2020 11:02:00 +0000 https://clearleft.com/posts/design-maturity-assessment In our 2020 survey we are looking for your support to further understand how design works in organisations around the globe. How mature is design as a discipline in your organisation?

    Last year when we launched the Design Effectiveness Survey our goal was to start exploring the conditions under which design could best make an impact on an organisations’ goals.

    By surveying designers across the world, our report found three things which greatly increased design’s impact:

    1. Design teams being empowered by executive management to identify and pursue unrequested ideas,
    2. A physical working environment which supports collaborative design activities,
    3. Undertaking regular design research.

    The power of collaboration, empowerment and research helped form the basis for a new tool we were developing to assess the digital design maturity of a well-known manufacturing brand.

    We wanted to be able to quantifiably measure the state of digital design practice within an organisation across five indicators:

    • Collaboration — the ability to build shared understanding & alignment,
    • Empathy — the organisation’s curiosity in customers and human-centred design,
    • Impact — design’s contribution to business success,
    • Trust — the organisation’s empowerment, influence and belief in design,
    • Purpose — how design is deployed to help solve significant challenges.
    The Design Maturity Assessment showing the five factors and a circle for the score out of 100
    Design Maturity Assessment scorecard

    We immediately saw the benefit of encompassing all five factors of design maturity into our 2020 survey. This survey will help us get a flavour of how present and important these factors are in organisations across the world and allow us to create a global benchmark.

    We would appreciate your support in completing and sharing this survey with your team, friends and partners. We are interested in your opinion whether you are in the design team directly, or involved in design from a distance.

    The report will be shared with everyone who completes the survey.

    ]]>
    Going remote https://clearleft.com/posts/going-remote Tue, 17 Mar 2020 12:53:00 +0000 https://clearleft.com/posts/going-remote As of 17 March 2020, Clearleft have taken the decision to close our office and send our employees home, where we’ll be working remotely until the end of April 2020.

    We are committed to the health and well-being of our colleagues, and in these challenging times we feel this decision will benefit staff and the wider community alike.

    Rest assured this is strictly a precautionary measure. Fortunately, we at Clearleft are well set-up and accustomed to working remotely, both as a team and with our valued clients in the UK and beyond. Whilst the current situation will certainly change our approach, it won’t change the outcomes we achieve with our clients.

    We must all do our part to help contain the spread of COVID-19, and we will continue to evaluate our options as the global situation develops. We hope you and your loved ones are safe during this unprecedented time.

    ]]>
    Guerrilla Testing - What it is and when to use it https://clearleft.com/posts/guerrilla-testing-what-it-is-and-when-to-use-it Mon, 16 Mar 2020 13:39:00 +0000 https://clearleft.com/posts/guerrilla-testing-what-it-is-and-when-to-use-it In this article, I’m going to give an overview of the flavours of guerrilla testing we use most often at Clearleft to encourage you to carry out research whatever timescale and budget.

    For some, guerrilla testing is a dirty word. A victim of its own success, its overuse has given it a bad rap. Thanks to the ever-growing research community ReOps, research is gaining more room at the table. Isn’t it about time we celebrated the strengths of guerrilla testing?

    What is guerrilla testing?

    Guerrilla testing is a low-cost method that helps you quickly answer straightforward research questions. It forces you out of the office and gets you face-to-face with the general public for a short but valuable amount of time.

    Guerrilla testing differs from more structured and in-depth research methods in a number of ways.

    In-depth listening sessions and usability testing go deep to uncover rich and nuanced insights. They need a dedicated period of time for recruitment. We qualify potential applicants against strict audience criteria. This ensures those involved in the research reflect the motivations and needs of the wider audience.

    In comparison, guerrilla testing is shallower in its depth of insight. It shortcuts the recruitment process by using members of the public. Even with this tradeoff, we still want people to be as representative of the audience as possible, so a little more thought and effort is needed to find them.

    Longitudinal and ethnographic methods such as diary studies can span weeks or months. We use these methods to understand the bigger picture of people’s lives and the extent to which products and services support them. However, when our research questions are smaller in scope and we need answers quickly, we can use guerrilla testing to receive answers within hours or days rather than weeks or months.

    More in-depth and longer research studies also come at a financial cost. Alongside time, the cost is one of the most common barriers to conducting research with customers. But it needn’t be. Guerrilla testing is inexpensive to set up and run. When used properly it’s far better than no research at all.

    Research methods for different costs and learning speeds.

    Guerrilla testing offers a handful of benefits, especially for those organisations that have yet to adopt research as part of their design process. Guerrilla testing…

    • Enables teams to break out of the cycle of debating assumptions and into the context of their customers,
    • Introduces the value of customer insight for research-immature organisations,
    • Alleviates the anxieties of time and cost for research sceptics,
    • Helps to move designs more quickly through the decision process,
    • Offers a low friction way of quickly answering questions and avoiding decision making paralysis and stalemates.

    When to use guerrilla testing and why

    At Clearleft, we use three distinct flavours of guerrilla testing; intercept interviews, prototype testing, and light-touch ethnography.

    Intercept interviews

    With intercept testing we approach people in the context of their task and ask them to answer a few questions. To increase our chances of a successful intercept, contexts and tasks should be low-risk. Participants browsing a selection of supermarket jams takes far less mental effort than operating complex equipment. Armed with a handful of snappy questions, we can include a quick design exercise like the 20-second gut test. Intercepts should last 10-15 minutes. As with all research, we believe it is good practice to offer a token of appreciation. A £5 gift voucher is more than enough.

    We used intercept interviews to understand how people respond to product propositions for a well known tech startup. Over the course of the project we spoke to 16 people.

    Prototype testing

    Prototype testing is a pared-back usability test. It’s used to identify a small number of usability issues. The maturity of the prototype shouldn’t prevent you from testing: paper sketches, clickable wireframes, existing websites and native apps are all acceptable. This task-based test lasts around 10-15 minutes. Again, offer a gesture of thanks for people’s time.

    We used prototype testing to quickly and cheaply test early design concepts for Virgin Holidays. We spoke to 10 people in total but started seeing patterns after 5 tests.

    Light-touch ethnography

    Light-touch ethnography combines insight from environment-focused research methods. Methods include competitive testing and unobtrusive measures (learning through physical traces and indirect participant observation). They help us to understand what people are using and the environments in which they use them. We get out of the office, we step into our audience’s shoes, and we gain an immersive empathic first-hand experience.

    We used light-touch ethnography to quickly understand the range of touchpoints customers would engage with for a well known retail giant.

    In-store competitor research.

    Real-world examples

    Here are a few real-world examples of when we’ve decided to use guerrilla testing or not:

    Appropriate

    • Understanding what parts of a UI support and hinder a search journey.
    • Understanding if people can successfully complete a bookmarking journey.

    Inappropriate

    • Understanding the end-to-end process of long-haul holiday planning.
    • Understanding how people plan and shop for groceries over time.

    Guerrilla testing will help you quickly answer a handful of questions at a low cost but it’s not enough to form a business strategy.

    Go forth and learn

    To learn at the required speed and depth we need a range of methods at our disposal. When time and budget are working against you, reach for a method like guerrilla testing that allows you to make the progress you need.

    This post was originally published on my own website

    ]]>
    Using content strategy to present your research findings https://clearleft.com/posts/using-content-strategy-to-present-your-research-findings Thu, 12 Mar 2020 11:30:00 +0000 https://clearleft.com/posts/using-content-strategy-to-present-your-research-findings One of the good things about being a content strategist is that you get to offer practical help to other disciplines (as well as learning heaps from them in return).

    We couldn’t do our jobs without research, and so when researchers ask for content help I am always happy to oblige!

    Structuring research findings can be really tricky — you need to be able to tell a story but also make sure you address your original brief. It’s a presentation, but one which could have serious implications on your product if you don’t position it in the right way. After some presentation training I’d had a while back, it got me thinking about how you could apply similar principles to compiling research outputs. There are some mandatories for playing back your research, but also different ways to position your findings. Here’s my advice on what to include:

    doodles of research findings on paper
    When you have all the stuff but just don’t know how to tell the story

    Introduction

    To make sure your introduction really sets up your findings, here’s what to include:

    • What’s the background to the project, why did you carry out the research, what was your objective?
    • Did you have a hypothesis or some assumptions to prove/disprove?
    • Who were the participants?
    • What were the methods used?
    • Where was the research carried out? Was it carried out in different markets?

    Findings

    The bulk of your playback should be what you discovered. This can be hard to know how to position, so here are three different ideas for presenting back your findings:

    1. Present each key finding followed by the supporting observations.

    This is one of the most common techniques but while it can be tempting, don’t list every single quote or insight, just two or three that strongly support the finding. Also it’s worth only having a handful of the most relevant findings in the bulk of the presentation, and keeping the rest in an appendix.

    2. Present the hypothesis followed by some findings that either confirm or conflict with it.

    As a researcher, your role is to present back the findings but not to come up with solutions. One way to keep your presentation objective is to simply list each hypothesis, with the findings that either confirm or conflict with it. Again, stick to just the strongest quotes and observations to evidence, quality will always beat quantity.

    3. Present the ‘vision’ for the product followed by the reality.

    Perhaps a more unique and thought-provoking way to present back research is to remind stakeholders of their product vision, but then show an alternative user perspective. Your observations/insights will either strengthen the vision or show an alternative view, and this can be quite powerful for stakeholders to see, and influence their direction.

    List the key (strongest) supporting observations/quotes as before, and keep the weaker ones in the appendix if anyone needs more detail later on.

    In any of the above methods, audio or video clips are always stronger than quotes written out on a page, but do be aware of how you’ll be playing back. It might be a good idea to include the written quote as well as a video or audio clip to avoid technical constraints.

    Summary

    Summarise three or four key messages from the findings — not all of them. And stick to the most compelling content or problematic issues.

    Appendix

    You can include more detailed quotes, observations or insights (or links to videos) for those that want more detail in this section.

    Don’t forget about the story you want to tell. While you need a conclusion, your role is to present the insights, and not to jump to recommended solutions, unless you’re recommending further research of course! Slides should be simple to read, with clear headings and well-laid out content.

    The strength of your research depends on a clear, compelling playback, so invest extra time to practise your presentation with another team member before the main event (maybe your friendly content designer!). And don’t forget to proof-read!

    This post was originally published on Medium

    ]]>