Clearleft | Blog https://clearleft.com/posts/ The latest news from Clearleft en-gb Mon, 25 May 2020 12:46:53 +0000 Mon, 25 May 2020 12:46:53 +0000 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.

    ]]>
    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.

    ]]>
    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

    ]]>
    Researching the research https://clearleft.com/posts/researching-the-research Fri, 06 Mar 2020 14:00:00 +0000 https://clearleft.com/posts/researching-the-research I’m helping to run a research repositories workshop in March. Find out more about the project and how you can help.

    For those who don’t know about the ResearchOps community, they are “a global group of people who’ve come together to discuss the operations and operationalization of user research and design research”.

    Similar to the DesignOps community, their aim is to further the practice through the process and technological advancements.

    The community is built on three core beliefs:

    • ResearchOps is an emergent consequence of knowledge work at scale
    • Scaling the operation of research requires specific skills and attention to corporate memory
    • Our collective experience holds the keys to building capability within the profession

    The community regularly holds global workshops to discuss and collaborate on specific projects.

    The rise of Research Ops is something we’ve been exploring through our panel events.

    re+ops research ops community logo

    Everything in its right place

    The most recent project to emerge from the community is the research repository project. It is exploring how research is processed, stored and retrieved. The current definition of a repository differs widely across the industry. Solutions range from live products to home-spun ‘hacks’. For these reasons, the project is starting broad to understand the nuances of the process.

    The overall aim:

    • Evaluate the pros/cons of having a research repo with regard to a variety of research methods
    • Gather a folksonomy for each method and develop a structured taxonomy for human research
    • Review strengths/weaknesses of governance in terms of practice and policy
    • Create a list useful requirements for repo builders to prioritise their roadmap.

    Over the next few months, there will be workshops held worldwide to feed into the project. The core of the workshop will be an experience mapping activity. Currently, 55 organisers in 20 countries have signed up, making it one the biggest projects to date!

    I’ll be helping to run a Brighton workshop later this month. If you are involved in the practice of research we’d love for you to see you there!

    ]]>
    Telling the story of performance https://clearleft.com/posts/telling-the-story-of-performance Tue, 03 Mar 2020 13:14:00 +0000 https://clearleft.com/posts/telling-the-story-of-performance Competitor analysis and performance are a match made in heaven.

    At Clearleft, we’ve worked with quite a few clients on site redesigns. It’s always a fascinating process, particularly in the discovery phase. There’s that excitement of figuring out what’s currently working, what’s not working, and what’s missing completely.

    The bulk of this early research phase is spent diving into the current offering. But it’s also the perfect time to do some competitor analysis—especially if we want some answers to the “what’s missing?” question.

    It’s not all about missing features though. Execution is equally important. Our clients want to know how their users’ experience shapes up compared to the competition. And when it comes to user experience, performance is a huge factor. As Andy says, performance is a UX problem.

    There’s no shortage of great tools out there for measuring (and monitoring) performance metrics, but they’re mostly aimed at developers. Quite rightly. Developers are the ones who can solve most performance issues. But that does make the tools somewhat impenetrable if you don’t speak the language of “time to first byte” and “first contentful paint”.

    When we’re trying to show our clients the performance of their site—or their competitors—we need to tell a story.

    Web Page Test is a terrific tool for measuring performance. It can also be used as a story-telling tool.

    You can go to webpagetest.org/easy if you don’t need to tweak settings much beyond the typical site visit (slow 3G on mobile). Pop in your client’s URL and, when the test is done, you get a valuable but impenetrable waterfall chart. It’s not exactly the kind of thing I’d want to present to a client.

    Fortunately there’s an attention-grabbing output from each test: video. Download the video of your client’s site loading. Then repeat the test with the URL of a competitor. Download that video too. Repeat for as many competitor URLs as you think appropriate.

    Now take those videos and play them side by side. Presentation software like Keynote is perfect for showing multiple videos like this.

    This is so much more effective than showing a table of numbers! Clients get to really feel the performance difference between their site and their competitors.

    Running all those tests can take time though. But there are some other tools out there that can give a quick dose of performance information.

    SpeedCurve recently unveiled Page Speed Benchmarks. You can compare the performance of sites within a particualar sector like travel, retail, or finance. By default, you’ll get a filmstrip view of all the sites loading side by side. Click through on each one and you can get the video too. It might take a little while to gather all those videos, but it’s quicker than using Web Page Test directly. And it might be that the filmstrip view is impactful enough for telling your performance story.

    If, during your discovery phase, you find that performance is being badly affected by third-party scripts, you’ll need some way to communicate that. Request Map Generator is fantastic for telling that story in a striking visual way. Pop the URL in there and then take a screenshot of the resulting visualisation.

    The beginning of a redesign project is also the time to take stock of current performance metrics so that you can compare the numbers after your redesign launches. Crux.run is really great for tracking performance over time. You won’t get any videos but you will get some very appealing charts and graphs.

    Web Page Test, Page Speed Benchmarks, and Request Map Generator are great for telling the story of what’s happening with performance right nowCrux.run balances that with the story of performance over time.

    Measuring performance is important. Communicating the story of performance is equally important.

    This was originally published on my own site.

    ]]>
    Tiny Lesson: How to run a BERT test https://clearleft.com/posts/tiny-lesson-how-to-run-a-bert-test Sun, 01 Mar 2020 13:55:00 +0000 https://clearleft.com/posts/tiny-lesson-how-to-run-a-bert-test A BERT test allows you to measure how people emotionally perceive your brand through digital products such as a website or mobile app.

    In this lesson, we share how you can run one as part of your next concept test.

    Watch the video, or read the transcript below.

    How to run a BERT test

    BERT stands for bipolar, emotional, response, test.

    You’ll need some Artefact cards or Post-It notes, some Sharpies, and a laptop to analyse the results.

    Start off by generating a longlist of adjectives that describe how your brand should be recognised.

    Next agree on which adjectives are most important to your brand. Tone of voice and branding documents are a great starting point. Agree on 5-6 adjectives to include in your test.

    Now create an opposing or related adjective to create a pair. For example, confident and reserved, premium and budget.

    To create the test, make a 1×7 grid. Add 1 adjective at either end of the grid, leaving the middle 5 blank. Repeat this for each pair.

    During the next round of usability testing include a BERT test at the end of the session. The participant works down the form selecting a point between the 2 adjectives that they feel best describes the ‘personality’ or ‘feel’ of the product. When testing with multiple concepts, include a BERT test for each one.

    Once all the tests have been completed, enter the results into a spreadsheet. The analysis will show the strength of agreement across your participants.

    Now regroup and discuss the results. Which concept performed best? How did internal and external opinions differ? Focus on the worse performing adjectives in future design iterations.

    Resources

    Download the spreadsheet here.

    ]]>
    The changing nature of product teams https://clearleft.com/posts/the-changing-nature-of-product-teams Fri, 28 Feb 2020 13:47:00 +0000 https://clearleft.com/posts/the-changing-nature-of-product-teams Clearleft hosted our third lively morning of debate on the theme of ‘From idea through to delivery’. The first panel discussed how product teams balance business-as-usual with innovation.

    Our first panel featured three digital-first businesses. They’re all 5-10 years old and at different stages of building out their product function.

    You can watch the full panel video here.

    Tension between bottom-up and top-down ideas

    The panel discussed how to level the playing field when it comes to innovation. They all found that the structure of design and research teams plays a key role. An active CEO is also a factor.

    • At ClearScore they know the product is working, but to achieve the active CEO’s vision requires dedicated teams. So rather than random offshoot initiatives, they use standalone teams. They give those teams a bit of space and let them innovate.

    • Receipt Bank are operating in a post-founder world. They needed a whole new cadence of generating strategic visions. It has taken organisational change to shift to an evidence-based approach when they are creating and validating user problems. But some are easier problems than others:

    Very different conversations happen between user problem spaces and optimising checkout flows. The former is still not defined.

    Divya

    There has to be a set discovery process in place, but that seems much easier to define when optimising the existing process rather than the unknown.

    • At OVO they have been growing their research capability to drive innovation and reflect their focus on human-centered design:

    Understanding customer needs is integral and often provides the balance between proving hunches and finding existing problems or opportunities to solve from users.

    Annmarie

    Changing from hunches to hypotheses allows CEO vision and user insights to be validated in the same way.

    Clearleft breakfast panellists

    The spectrum of a product design team

    When prompted on the balance between innovation and business as usual, Annmarie finds two types of designers. There are some who love a challenge and thrive in the unknown. They’re good at identifying problems and coming up with the solutions. Others are not so comfortable with uncertainty. Both are okay:

    This idea of a unicorn I don't think exists. It's okay to be a designer that just loves crafting a great experience that is usable.

    Annmarie

    At Receipt Bank, Divya has focused on the balance of people in the team that you hire: comfort with uncertainty vs. discomfort with uncertainty.

    Perhaps there is not enough recognition of the maintainers?

    There is a tendency to reinvent the wheel. We’ve come to a point in digital design where there isn't that much scope to do new things, which is great in some ways, but not in others especially with new hires who come into their career with the desire to create something new.

    Divya

    When looking at the combination of creators, architects and maintainers, Frank acknowledges that it’s “much harder to create something from what is existing, rather than something from nothing”. For example, it’s easier to create a brand new design system than create a design system from an existing product.

    Scaling product teams

    OVO has gone from five to 30 designers in a very short space of time. They went from being the disruptor to being one of the Big Six. That’s a phenomenal change within a culture that is very agile and digitally focussed. It has taken a lot of work to maintain the culture of being lean: doing discovery and exploration alongside systemised design.

    Designers keen to maintain this culture set up a community of practice. Designers connect across different products, meet regularly and share what they’ve learnt. This maintains a feeling of “we’re all in it together” rather than part of a machine.

    Receipt Bank, on the other hand, has an HR function alone that is 20 people strong. It’s hard to maintain your culture as you scale from a lean 10-20 person start-up to a 100 person product org. Divya learned it is important to “be honest and upfront about it or you will create a false, forced culture”.

    You also need to be realistic about where you are on your product team journey.

    Frank mentioned that one of his first mistakes at ClearScore was thinking he had to hire separate researchers, prototypers, UI and UX designers:

    In a small start-up company, we actually needed more generalists.

    Frank

    This taught him that it’s more important to find people that are right for the current stage of growth rather than sticking to your vision of how the product team ‘should’ be structured. Now that they are a bit larger, they have been able to branch out to more dedicated skillsets.

    Annmarie noticed a spectrum of hiring needs:

    There are those great at discovery and insight, and others that are amazing at brand and applying it to product. It's okay to specialise in one or the other. I have yet to meet someone that covers both.

    Annmarie

    Closing the design and business gap

    • While the design team at OVO is there to discover new things, they also have to deliver on revenue. This can come from both ends of improving the customer experience. You can find solutions to customer problems that can drive new revenue streams that haven’t yet been discovered. Or you can increase the existing revenue stream.

    • Receipt Bank are actively moving away from revenue as a goal. They are moving towards task completion as a goal. They want goals that are more motivating than money-making. This involves some smart measurement of activity.

    • The product team at ClearScore have Objectives and Key Results for design teams. These OKRs quantify the magic and delight of design. But they also ensure that the designers are building something that is contributing to the business goals.

    Clearleft panel audience

    We will be running another breakfast panel in May in London - please register your interest here if you’d like to attend.

    ]]>
    Getting your priorities right https://clearleft.com/posts/getting-your-priorities-right Thu, 27 Feb 2020 13:59:00 +0000 https://clearleft.com/posts/getting-your-priorities-right A handful of things in life are inevitable. On this list you’ll find taxes, death and—if you work in a project team—having more ideas than you have time to deliver.

    Whether creating products or services, working for an agency or for an in-house team, the list of potential features and ongoing fixes is always outpaced by the available time to explore, build and release them.

    In ‘Good Strategy. Bad Strategy’ Richard Rumelt says sagely: “strategy is at least as much about what an organisation does not do as it is about what it does”.

    With this in mind, here’s a roundup of some simple techniques for prioritisation. These can help project teams take control and manage their backlog. After all, your time is too valuable to make decisions on what to work on next by deferring to the hippo (highest paid person’s opinion) in the room or by the toss of a coin.

    Plotting value versus effort

    Value versus effort matrix

    Let’s start with a deceptively simple but incredibly robust method: the 2x2 matrix. In this example user value is plotted against production effort. However, any two competing dimensions can be used.

    It’s an ideal technique to use when you have lots of data points. Seeing the spatial relationship between them will help you identify where the quick wins and long-term value can be found.

    We often use this technique with clients to collectively decide which recommendations we will prioritise from an expert review or findings from user research and which suggestions fall into the quadrants of busy work or time sinks.

    The matrix can be created in a lo-fi way. All you need is brown paper, masking tape, and each item written on an individual post-it® notes to make the information easy to plot and re-plot. Equally, you can use a collaborative digital tool such as Miro. This is ideal if the team doing the prioritisation is geographically distributed.

    In either case, prepare the information to plot in advance so you can use the time in the workshop to map what goes where. People often fall into the trap of trying to make everything high value. To counter this force a decision on relative priorities by insisting that the sticky notes cannot overlap one another.

    Voting for precedence

    Precedence voting chart

    Use this technique when you need to decide what to prioritise from a competing shortlist of possible options.

    In essence, you systematically compare each idea against every other one until you end up with a ranked and scored list of priorities.

    I was introduced to this prioritisation technique by John Sunart who credits Norman McNally for introducing him to it.

    Although the activity takes time, it is worth it if you need to evaluate the relative merit of ideas from a set of options. Give yourself at least 40 minutes for half a dozen deciders to work through a set of six options. Increase the time by five minutes for every additional option, and don’t go over 10 competing options without energy gels at hand.

    The process is relatively straightforward:

    1. Get to around six competing choices. You could dot vote to shortlist.
    2. Draw up a grid. Write in the ideas being evaluated on both the x and y axis. Blank out ideas competing against themselves.
    3. Call out two competing features and ask your participants for a show of hands if they think the first feature is more important, relevant or doable than the second.
    4. Count the hands and add the score to the chart (in two places) for the first and second feature under consideration.
    5. Move across the rows from left to right until all the boxes have numbers in.
    6. Add up the numbers in each row and rank the ideas from the scores.

    This activity works best when the focus is on voting rather than discussing each option. To help keep the activity on track, circulate a brief description of the ideas for consideration to participants in advance of running the workshop.

    Checking there’s innovation in your mix

    The How? Now, Wow! matrix

    Another matrix, this one is ideal to sense-check the makeup of your product roadmap. It will quickly show if you are over-indexed on business as usual and if the team has time set aside for exploring potential futures.

    The How? Now, Wow! matrix is included in Gamestorming, a perennial favourite on the Clearleft bookshelf for finding practical workshop activities.

    Ideally, you are looking for a blended programme of work with items in each of the three named quadrants. It’s a useful method to periodically revisit to evaluate if your team is spending its time appropriately looking across the different horizons of the now, the next and the future.

    Placing your bets and backing the favourites

    The original twitter doodle from Hias Wrba (@ScreaminHias)

    I serendipitously came across this a few years ago via a retweet from a friend. The doodle from Hias Wrba (@ScreaminHias) perfectly encapsulates that not all decisions are (or should be) treated equally.

    Some product decisions are low cost and low risk. Getting on with building them offers more value than having another meeting to debate them. Other options with a higher level of uncertainty and/or risk can best be answered by doing research to provide more insights to give confidence in your future decision making.

    I’m a big fan of having the value and cost scales plotted in humanly understandable terms (going from a beer, a holiday, a month’s salary, a car, a house). Because of these scales, I find this a great tool to use when you want a team to start thinking about their work in terms of competing decisions with financial implications. This matrix also works a treat in workshops to move people from circular conversations to quickly deciding the next best steps for the ideas being evaluated.

    Counting on a repeatable formula

    A table showing a mean score for a number of ideas
    The (Value ÷ Effort) x Confidence calculator

    We’ve used this formula and variations of it on numerous projects. Most recently we introduced it to a client’s customer experience team. They managed multiple websites and wanted a framework that could be used to evaluate requests from numerous stakeholders. They found having a score, from a robust formula, replaced emotive reasoning with a more rational approach to their prioritisation process.

    The technique came to my attention via an article written by Jared Spool who in turn credits the method to Bruce McCarthy.

    The toughest part of using this method is to define your terms so everyone is clear on what you mean by value, effort and confidence.

    For example, value could purely be user value, or business value, or a blend of the two. You might be more focussed on increasing brand reputation rather than revenue or improving the usability of your product over retention rates.

    Likewise, you might articulate and estimate effort in terms of person-hours, the combined capital and operational expenditure, or the blood, sweat and tears the team will shed.

    Confidence is a subjective measure. It can come from having robust user research or having already done a technical proof of concept, or for less risky and innovative suggestions, from best practices or trivial technical requirements.

    The important thing is that everyone has a shared understanding of the terms being used.

    Once you’ve agreed your terms it’s then time to review the scoring system. We tend to keep things simple. Value and effort have a shared three-point scale (1=low, 2=medium, 3=high). For confidence, we use a numeric value between 0 (for no confidence) and 1 (absolutely sure) with incremental steps of 0.25 giving an increased level of certainty.

    Now you’re ready to add the numbers and formula into a spreadsheet with an additional column at the front for features for consideration.

    We find the use of a visible, shared spreadsheet particularly useful when dealing with multiple stakeholders. It enables prioritisation to easily be done over many sessions and for the list to be seen as a living document.

    Making prioritisation a priority

    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.

    There isn’t a single right way to prioritise your work. Different methods help in different situations. Try out some of these methods to see which best helps you. The important thing is that your teams know what they are going to tackle next and why.

    ]]>
    Utopia https://clearleft.com/posts/utopia Tue, 18 Feb 2020 18:10:53 +0000 https://clearleft.com/posts/utopia Utopia is not a product, a plugin, or a framework. It’s a memorable/pretentious word we use to refer to a way of thinking about fluid responsive design.

    Trys and James recently unveiled their Utopia project. They’ve been tinkering away at it behind the scenes for quite a while now.

    You can check out the website and read the blog to get the details of how it accomplishes its goal:

    Elegantly scale type and space without breakpoints.

    I may well be biased, but I really like this project. I’ve been asking myself why I find it so appealing. Here are a few of the attributes of Utopia that strike a chord with me…

    It’s collaborative

    Collaboration is at the heart of Clearleft’s work. I know everyone says that, but we’ve definitely seen a direct correlation: projects with high levels of collaboration are invariably more successful than projects where people are siloed.

    The genesis for Utopia came about after Trys and James worked together on a few different projects. It’s all too easy to let design and development splinter off into their own caves, but on these projects, Trys and James were working (literally) side by side. This meant that they could easily articulate frustrations to one another, and more important, they could easily share their excitement.

    The end result of their collaboration is some very clever code. There’s an irony here. This code could be used to discourage collaboration! After all, why would designers and developers sit down together if they can just pass these numbers back and forth?

    But I don’t think that Utopia will appeal to designers and developers who work in that way. Born in the spirit of collaboration, I suspect that it will mostly benefit people who value collaboration.

    It’s intrinsic

    If you’re a control freak, you may not like Utopia. The idea is that you specify the boundaries of what you’re trying to accomplish—minimum/maximum font sizes, minumum/maximum screen sizes, and some modular scales. Then you let the code—and the browser—do all the work.

    On the one hand, this feels like surrending control. But on the other hand, because the underlying system is so robust, it’s a way of guaranteeing quality, even in situations you haven’t accounted for.

    If someone asks you, “What size will the body copy be when the viewport is 850 pixels wide?”, your answer would have to be “I don’t know …but I do know that it will be appropriate.”

    This feels like a very declarative way of designing. It reminds me of the ethos behind Andy and Heydon’s site, Every Layout. They call it algorithmic layout design:

    Employing algorithmic layout design means doing away with @media breakpoints, “magic numbers”, and other hacks, to create context-independent layout components. Your future design systems will be more consistent, terser in code, and more malleable in the hands of your users and their devices.

    See how breakpoints are mentioned as being a very top-down approach to layout? Remember the tagline for Utopia, which aims for fluid responsive design?

    Elegantly scale type and space without breakpoints.

    Unsurprisingly, Andy really likes Utopia:

    As the co-author of Every Layout, my head nearly fell off from all of the nodding when reading this because this is the exact sort of approach that we preach: setting some rules and letting the browser do the rest.

    Heydon describes this mindset as automating intent. I really like that. I think that’s what Utopia does too.

    As Heydon said at Patterns Day:

    Be your browser’s mentor, not its micromanager.

    The idea is that you give it rules, you give it axioms or principles to work on, and you let it do the calculation. You work with the in-built algorithms of the browser and of CSS itself.

    This is all possible thanks to improvements to CSS like calc, flexbox and grid. Jen calls this approach intrinsic web design. Last year, I liveblogged her excellent talk at An Event Apart called Designing Intrinsic Layouts.

    Utopia feels like it has the same mindset as algorithmic layout design and intrinsic web design. Trys and James are building on the great work already out there, which brings me to the final property of Utopia that appeals to me…

    It’s iterative

    There isn’t actually much that’s new in Utopia. It’s a combination of existing techniques. I like that. As I said recently:

    I’m a great believer in the HTML design principle, Evolution Not Revolution:

    It is better to evolve an existing design rather than throwing it away.

    First of all, Utopia uses the idea of modular scales in typography. Tim Brown has been championing this idea for years.

    Then there’s the idea of typography being fluid and responsive—just like Jason Pamental has been speaking and writing about.

    On the code side, Utopia wouldn’t be possible without the work of Mike Reithmuller and his breakthroughs on responsive and fluid typography, which led to Tim’s work on CSS locks.

    Utopia takes these building blocks and combines them. So if you’re wondering if it would be a good tool for one of your projects, you can take an equally iterative approach by asking some questions…

    Are you using fluid type?

    Do your font-sizes increase in proportion to the width of the viewport? I don’t mean in sudden jumps with @media breakpoints—I mean some kind of relationship between font size and the vw (viewport width) unit. If so, you’re probably using some kind of mechanism to cap the minimum and maximum font sizes—CSS locks.

    I’m using that technique on Resilient Web Design. But I’m not changing the relative difference between different sized elements—body copy, headings, etc.—as the screen size changes.

    Are you using modular scales?

    Does your type system have some kind of ratio that describes the increase in type sizes? You probably have more than one ratio (unlike Resilient Web Design). The ratio for small screens should probably be smaller than the ratio for big screens. But rather than jump from one ratio to another at an arbitrary breakpoint, Utopia allows the ratio to be fluid.

    So it’s not just that font sizes are increasing as the screen gets larger; the comparative difference is also subtly changing. That means there’s never a sudden jump in font size at any time.

    Are you using custom properties?

    A technical detail this, but the magic of Utopia relies on two powerful CSS features: calc() and custom properties. These two workhorses are used by Utopia to generate some CSS that you can stick at the start of your stylesheet. If you ever need to make changes, all the parameters are defined at the top of the code block. Tweak those numbers and watch everything cascade.

    You’ll see that there’s one—and only one—media query in there. This is quite clever. Usually with CSS locks, you’d need to have a media query for every different font size in order to cap its growth at the maximum screen size. With Utopia, the maximum screen size—100vw—is abstracted into a variable (a custom property). The media query then changes its value to be the upper end of your CSS lock. So it doesn’t matter how many different font sizes you’re setting: because they all use that custom property, one single media query takes care of capping the growth of every font size declaration.

    If you’re already using CSS locks, modular scales, and custom properties, Utopia is almost certainly going to be a good fit for you.

    If you’re not yet using those techniques, but you’d like to, I highly recommend using Utopia on your next project.

    This was originally published on my own site.

    ]]>
    Fluid custom properties https://clearleft.com/posts/fluid-custom-properties Fri, 14 Feb 2020 13:55:00 +0000 https://clearleft.com/posts/fluid-custom-properties A core theme of the seminal introduction to responsive web design was an acceptance of the ‘ebb and flow’ found on our inherently fluid web.

    But despite a broadly accepted view that device-based breakpoints are flawed, and a myriad of solutions proposed to solve the problem, it’s fair to say we still mostly think in terms of pre-defined breakpoints.

    Writing truly isolated components and tailored breakpoints; where we reevaluate our original CSS decisions as the viewport gets to a size that breaks the component, is great in theory, but challenging in practice. Ubiquitous language in a team, and a natural desire to consolidate magic numbers tends to lead to either a set of easy to remember numbers: 30em, 40em, 50em, or more generic ‘small, medium, large’ mixing breakpoints. Both approaches create jarring ‘breakpoint jumps’ rather than a natural easing as a screen changes.

    When there is shared styling between components, our instinct is to group the components in some respect. This tends to fall into one of three camps:

    • Writing large selectors, or relying on Sass @extends, despite its flaws and horizontal coupling.
    • Peppering our HTML with utility classes like .mt18 and .pb24.
    • Duplicating the common styles and accepting the performance hit.

    These all work at a single width, but begin to fall apart as more screen sizes get involved. Here are some of the most common next steps to patch the issue:

    • Adding @media breakpoints to the utility classes and renaming them to something more generic.
    • Create multiple utility classes with breakpoint-specific suffixes, adding all of them to an element.
    • Continuing the duplication with identical @media breakpoints in each component.

    None of these are ideal – not only are we duplicating code or coupling horizontally, we’re still thinking about device-specific breakpoints. It’s a problem, and it affects all aspects of our work – spacing, rhythm, layout and typography.

    We need to think fluidly.

    A proposal

    Fluid custom properties combine CSS Locks, CSS Custom Properties, and the concept of hills (yes, hills). They allow us to write fluid CSS without writing any breakpoints.

    A fluid custom property is a font-size representation of a gradient or slope, set between two screen sizes, and stored as a global CSS custom property.

    With a predefined set of fluid custom properties at the heart of a project, we can hook onto them to create natural, breakpoint-less spacing and typography that gradually interpolates across screen sizes.

    Relying on these global rules brings consistency across a project, and helps to ensure every component looks ‘just right’ on all screens. There are no nasty ‘breakpoint jumps’, just buttery smooth interpolation.

    They significantly reduce code duplication and keep code succinct and readable. Rather than coupling horizontally, shared styles are linked vertically to these global, project-specific constants.

    All the complicated maths is abstracted away, leaving you to work with natural numbers, browser text zoom preferences are respected, and they work naturally with ems.

    They’re also entirely opt-in; the brilliance of custom properties is that they do nothing to your webpage until you reference them. This makes it a great way to retrospectively add fluid sizing to an existing site.

    Let’s dig into the three concepts in a little more detail:

    CSS Locks and interpolation

    Linear interpolation is a mathematical technique used to calculate the value at a position between two points. In the CSS and animation world, Interpolating or ‘tweening’ is the process of smoothly changing a value between the two points over two screen sizes. We can achieve this effect with CSS locks, a technique coined by Tim Brown.

    Below is a CSS lock that interpolates between a font-size of 1em and 2em between the two screen sizes of 20em (320px) and 50em. The locking is handled by the media query directly below it, without it the growth would continue at the same rate forever.

    
    p {
      font-size: calc(1em + (2 - 1) * ((100vw - 20em)/(50 - 20)));
    }
    
    @media screen and (min-width: 50em) {
      p {
        font-size: 2em;
      }
    }
    

    Writing a lock by hand is pretty verbose, so Sass mixins are regularly turned to. This has the huge advantage of making your life as a developer easier, but the distinct disadvantage, like all pre-processor features, of distancing yourself from the final CSS output. Once you’ve been bitten by the fluid bug and seen its virtues, it’s very easy to end up with several hundred CSS locks, and thus several hundred media queries. That’s a lot of code.

    CSS custom properties

    There are plenty of wonderful guides to CSS custom properties, so I shan’t go into too much detail. Here’s a CSS custom property definition and usage example.

    
    :root {
      --brand: #FF4757;
    }
    
    a {
      color: var(--brand);
    }
    

    Not only are they a great way to extract common values out to a central location, they can be overridden using the cascade, and used in calc() functions. Using custom properties for typography and vertical rhythm has been well documented, but they can be used for so much more. We can combine CSS custom properties with locks to great effect…

    Refactoring the lock

    Let’s rewrite the CSS lock we used earlier, harnessing the descriptive power of custom properties. We start by extracting the configurable parts of the lock into a :root definition. The vast majority of CSS locks run from 20em/320px, so we’ll keep that in the lock for brevity. Then we can substitute the values within the declaration and media query, multiplying the appropriate values by 1em:

    
    :root {
      --max-value: 2;
      --min-value: 1;
      --max-screen: 50;
    }
    
    p {
      font-size: calc(
        (var(--min-value) * 1em) + (var(--max-value) - var(--min-value)) *
          ((100vw - 20em) / (var(--max-screen) - 20))
      );
    }
    
    @media screen and (min-width: 50em) {
      p {
        font-size: calc(var(--max-value) * 1em);
      }
    }
    

    Sadly, we can’t use custom properties in the media query definition, so we have to repeat the 50em. But ignoring that, we’ve extracted all the other ‘bits’ of the calculation into a single source of truth. The CSS lock now looks even more unwieldy than it did before but – crucially – the bits we actually need to access are much easier to read.

    Even more refactoring

    With traditional CSS locks, you need a media query for every lock, but as fluid custom properties rely on cascading custom properties, we can solve this really elegantly in one line.

    CSS locks use the 100vw unit to represent the varying screen size, but this doesn’t have to be the case. We can extract that value into its own custom property: --f-screen.

    When we’ve reached the ‘lock point’, rather than update all the CSS locks we have on the page, we can update the value of --f-screen to be the width of our --max-screen. This one line change holds every lock in its maximum state.

    
    :root {
      --max-value: 2;
      --min-value: 1;
      --max-screen: 75;
    
      --f-screen: 100vw;
      --f-bp: (var(--f-screen) - 20em)/(var(--max-screen) - 20);
    }
    
    p {
      font-size: calc((var(--min-value) * 1em) + (var(--max-value) - var(--min-value)) * var(--f-bp));
    }
    
    @media screen and (min-width: 75em) {
      :root {
        --f-screen: calc(var(--max-screen) * 1em);
      }
    }
    

    This is a rather neat refactor, but it’s still only working at a selector-level - we can still step it up a notch or two. But before we can talk about that, we need to talk about hills.

    Hills, grades & slopes

    When travelling by road, we can refer to the steepness of a hill by a gradient or grade. They’re often given in terms of a ratio: 2:1 or a percentage: 30%. The higher the percentage, the steeper the incline, and the more likely you’ll need to get off your bike and walk up the hill.

    A CSS lock can also be visualised as a hill. The screen sizes define the where the hill starts and ends (or the foot and summit), and the two values (say, 1em and 2em) dictate the gradient. When plotted onto a graph, it looks a little like this:

    A graph demonstrating a CSS lock
    A CSS lock, visualised

    In this example, we’re interpolating between two specific values: 1em and 2em, a relationship of 2:1. This is great, but a bit limiting. What if we wanted to interpolate between 2em and 4em. Fluid custom properties encapsulate that relationship into a fluid multiplier that lets you re-use that angle in various ways across a project.

    The implementation

    Below is the CSS for four fluid custom properties than run between 320px and 1200px.

    
    :root {
      --f-summit: 1200;
    
      --f-screen: 100vw;
      --f-foot: 1 / 16;
      --f-hill: (var(--f-screen) - 20rem) / (var(--f-summit) / 16 - 20) + var(--f-foot) * 1rem;
    
      --f-1-25: ((1.25 / 16 - var(--f-foot)) * var(--f-hill));
      --f-1-5: ((1.5 / 16 - var(--f-foot)) * var(--f-hill));
      --f-2: ((2 / 16 - var(--f-foot)) * var(--f-hill));
      --f-3: ((3 / 16 - var(--f-foot)) * var(--f-hill));
    }
    
    @media screen and (min-width: 1200px) {
      :root {
        --f-screen: calc(var(--f-summit) * 1px);
      }
    }
    

    Let’s break it down section by section.

    
    --f-summit: 1200;
    

    This property denotes the largest screen size in px. This gets converted to rems internally to ensure text zoom preferences are respected.

    
    --f-screen: 100vw;
    --f-foot: 1 / 16;
    --f-hill: (var(--f-screen) - 20rem) / (var(--f-summit) / 16 - 20) + var(--f-foot) * 1rem;
    

    --f-screen holds the width of screen (100vw) until we reach the summit. Extracting this make sets us up to be able to succinctly lock all the properties in one go. All fluid custom properties are ratios based off of 1, and --f-foot represents that.

    --f-hill is the media query part of the lock, running from 320px to our --f-summit. By extracting this out from the back end of the CSS lock, and into its own CSS custom property, we can cap all the custom properties in one go - more on that later.

    It’s worth noting I’ve intentionally baked in the assumption of that start point. Extracting that out to another custom property is perfectly valid if it fits your use-case better.

    
    --f-1-25: ((1.25 / 16 - var(--f-foot)) * var(--f-hill));
    --f-1-5: ((1.5 / 16 - var(--f-foot)) * var(--f-hill));
    --f-2: ((2 / 16 - var(--f-foot)) * var(--f-hill));
    --f-3: ((3 / 16 - var(--f-foot)) * var(--f-hill));
    

    These are the fluid custom properties themselves. --f-1-25 represents a gradient of 1.25:1. The names are down to personal preference, I like the clarity of exposing the gradient angle in the variable, but you may prefer more generic names like --f-shallow or --f-steep. Equally, you may find a name like --f-gutter would be more appropriate.

    Side-note: custom properties aren’t evaluated until they are used, so there’s no need to wrap each one in a calc().

    
    @media screen and (min-width: 1200px) {
      :root {
        --f-screen: calc(var(--f-summit) * 1px);
      }
    }
    

    Finally, we have the aforementioned screen width lock to prevent the values from growing to silly levels.

    Using fluid custom properties

    The actual values stored in fluid custom properties are tiny, so they need to be multiplied up to useful numbers. The multiplier you choose represents the pixel size of the value at 320px. You can calculate the final size by multiplying it against the gradient.

    Let’s look at a specific example, setting the font-size on the document body.

    
    body {
      font-size: calc(var(--f-1-25) * 16);
    }
    

    This declaration will interpolate between 16px and 20px (16 * 1.25 = 20), without a breakpoint jump. All screens will get an appropriate font-size somewhere in between those two values.

    Now we’ve written that, we can use ems in the normal way to get relative fluid sizing off the body.

    
    h3 {
      font-size: 1.5em;
    }
    

    This will size h3 tags to be 24px on small screens, gradually changing up to 30px on larger screens.

    Working with steeper gradients

    Here’s an example for a hero banner. These are normally pretty painful to write, involving multiple padding breakpoint jumps as the screen expands. But when we use a fluid custom properties at a steeper gradient, we can achieve it in one line:

    
    .hero {
      padding: calc(var(--f-5) * 40) 0;
    }
    

    This gradient of 5:1 interpolates the vertical padding between 40px and 200px as the screen gets larger.

    The flexibility of different gradients give us a multitude of options to build with. If you’re after tight spacing on mobile and ample on larger screens, choose a steeper gradient multiplied by a smaller number. If you want similar spacing on both, increasing ever so slightly, take a shallower gradient and multiply it by a larger number. You can even use negative gradients to make reductions on larger screens!

    Fluid custom properties can be applied to margins, border-widths, padding, font-size, grid-gaps, transforms and all manner of other properties.

    Common patterns can be consolidated in other CSS custom properties to reduce the number of calc() function calls. There’s also no reason why they can’t be applied to design tokens or utility classes. These common calculations can then be surfaced in a design system to ensure maximum usage and understanding on a project.

    This post was originally published on Utopia.fyi.

    ]]>
    Leading Design 2020 https://clearleft.com/posts/leading-design-2020 Fri, 07 Feb 2020 10:53:00 +0000 https://clearleft.com/posts/leading-design-2020 We’ve got exciting things afoot in the coming year. Through our Leading Design events, we equip design leaders, whether they’re newly in post or have that hallowed seat at the table, with everything they need to take both their careers and their leadership to the next level.

    Our events team had our own retreat to take time to reflect, learn and spend time on understanding the needs of design leaders, that’s why we are excited to announce our Leading Design events over 2020.

    Leading Design logo

    Leading Design Conferences

    Our conferences bring together experts who lead design teams, oversee design direction and know what it takes to successfully create design culture in organisations. You’ll hear their practical tips, take part in hands-on workshops, and get a chance to meet peers from all over the world.

    After four years of successful sell out events in London and most recently in New York, we decided to head to the West Coast - San Francisco. We’ve assembled a wonderful group of design leaders who will cover a wide range of topics to help you make the most of your Design Leadership journey. Even though we have sold out you can add your name to the waitlist and of course keep an eye out for the talk videos post conference.

    European folk, do not fear we will be having Leading Design London the 4-6th November, 2020. We’re launching tickets on the 9th March so if you are interested in getting early bird tickets let us know here and we will be sure to drop you an email when the tickets go live.

    Two people with glases of wine at the Leading design Meetup in New York

    Leading Design Community meet-ups

    Leading Design isn’t all talks and workshops - we’ve created plenty of opportunities for you to meet like-minded design leaders, swap stories, and build relationships we hope will last the rest of your careers. Our community meet-ups are a place to meet other design leaders in a safe, relaxed, supportive space – to share, learn, and have fun. This year we are hosting a number of Leading Design Community Meetups across the globe - London, San Francisco, New York and more!

    Find out more about our meet-ups and all the dates here.

    P.S If you are going to be at SXSW - Andy Budd, LD Conference curator and founder of the LD Slack Community will be arranging a causal drinks meetup on Thursday 19th March. If you’re around and want to meet other design leaders register your interest here.

    Juvet Landscape Hotel

    Leading Design Retreats

    As a design leader, you’re responsible for a team, the direction they take, how they carry out their work, how they innovate, and how they make progress in their individual careers. That’s a lot of responsibility to hold and sometimes when looking after others we neglect ourselves. Our retreats are a perfect opportunity to re-focus on your own self-development and prioritise your own journey.

    Find out more about our Retreat in Norway in September 2020.

    Stay connected

    Follow our Leading Design Medium account where we have recently interviewed Margaret Lee (Director, UX Community & Culture at Google) reflecting on her own personal journey as a leader and how she came to reconcile her own true self against conventional expectations.

    For all the latest Leading Design updates and announcements you can either:

    Well, that’s all for now folks, we can’t wait to see you all in 2020!

    ]]>
    Design systems roundup https://clearleft.com/posts/design-systems-roundup Wed, 05 Feb 2020 13:16:00 +0000 https://clearleft.com/posts/design-systems-roundup A provocative post about design systems prompted some excellent responses.

    When I started writing a post about architects, gardeners, and design systems, it was going to be a quick follow-up to my post about web standards, dictionaries, and design systems. I had spotted an interesting metaphor in one of Frank’s posts, and I thought it was worth jotting it down.

    But after making that connection, I kept writing. I wanted to point out the fetishism we have for creation over curation; building over maintenance.

    Then the post took a bit of a dark turn. I wrote about how the most commonly cited reasons for creating a design system—efficiency and consistency—are the same processes that have led to automation and dehumanisation in the past.

    That’s where I left things. Others have picked up the baton.

    Dave wrote a post called The Web is Industrialized and I helped industrialize it. What I said resonated with him:

    This kills me, but it’s true. We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it. We operate more like Taylor and his stopwatch and Gantt and his charts, maximizing effort and impact rather than focusing on the human aspects of product development.

    But he also points out the many benefits of systemetising:

    At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.

    Emphasis mine. I think that’s a key phrase: “a willing team.”

    Ethan tackles this in his post The design systems we swim in:

    A design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing.

    But a design system need not be a constraining straitjacket—a means of enforcing consistency by keeping creators from colouring outside the lines. Used well, a design system can be a tool to give creators more freedom:

    Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?

    This is key. A design system is the product of an organisation’s culture. That’s something that Brad digs into his post, Design Systems, Agile, and Industrialization:

    I definitely share Jeremy’s concern, but also think it’s important to stress that this isn’t an intrinsic issue with design systems, but rather the organizational culture that exists or gets built up around the design system. There’s a big difference between having smart, reusable patterns at your disposal and creating a dictatorial culture designed to enforce conformity and swat down anyone coloring outside the lines.

    Brad makes a very apt comparison with Agile:

    Not Agile the idea, but the actual Agile reality so many have to suffer through.

    Agile can be a liberating empowering process, when done well. But all too often it’s a quagmire of requirements, burn rates, and story points. We need to make sure that design systems don’t suffer the same fate.

    Jeremy’s thoughts on industrialization definitely struck a nerve. Sure, design systems have the ability to dehumanize and that’s something to actively watch out for. But I’d also say to pay close attention to the processes and organizational culture we take part in and contribute to.

    Matthew Ström weighed in with a beautifully-written piece called Breaking looms. He provides historical context to the question of automation by relaying the story of the Luddite uprising. Automation may indeed be inevitable, according to his post, but he also provides advice on how to approach design systems today:

    We can create ethical systems based in detailed user research. We can insist on environmental impact statements, diversity and inclusion initiatives, and human rights reports. We can write design principles, document dark patterns, and educate our colleagues about accessibility.

    Finally, the ouroboros was complete when Frank wrote down his thoughts in a post called Who cares?. For him, the issue of maintenance and care is crucial:

    Care applies to the built environment, and especially to digital technology, as social media becomes the weather and the tools we create determine the expectations of work to be done and the economic value of the people who use those tools. A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.

    Well-trodden territory indeed. Back in 2015, Travis Gertz wrote about Design Machines:

    Designing better systems and treating our content with respect are two wonderful ideals to strive for, but they can’t happen without institutional change. If we want to design with more expression and variation, we need to change how we work together, build design teams, and forge our tools.

    Also on the topic of automation, in 2018 Cameron wrote about Design systems and technological disruption:

    Design systems are certainly a new way of thinking about product development, and introduce a different set of tools to the design process, but design systems are not going to lessen the need for designers. They will instead increase the number of products that can be created, and hence increase the demand for designers.

    And in 2019, Kaelig wrote:

    In order to be fulfilled at work, Marx wrote that workers need “to see themselves in the objects they have created”.

    When “improving productivity”, design systems tooling must be mindful of not turning their users’ craft into commodities, alienating them, like cogs in a machine.

    All of this is reminding me of Kranzberg’s first law:

    Technology is neither good nor bad; nor is it neutral.

    I worry that sometimes the messaging around design systems paints them as an inherently positive thing. But design systems won’t fix your problems:

    Just stay away from folks who try to convince you that having a design system alone will solve something.

    It won’t.

    It’s just the beginning.

    At the same time, a design system need not be the gateway drug to some kind of post-singularity future where our jobs have been automated away.

    As always, it depends.

    Remember what Frank said:

    A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement.

    The reasons for creating a design system matter. Those reasons will probably reflect the values of the company creating the system. At the level of reasons and values, we’ve gone beyond the bounds of the hyperobject of design systems. We’re dealing in the area of design ops—the whys of systemising design.

    This is why I’m so wary of selling the benefits of design systems in terms of consistency and efficiency. Those are obviously tempting money-saving benefits, but followed to their conclusion, they lead down the dark path of enforced compliance and eventually, automation.

    But if the reason you create a design system is to empower people to be more creative, then say that loud and proud! I know that creativity, autonomy and empowerment is a tougher package to sell than consistency and efficiency, but I think it’s a battle worth fighting.

    Design systems are neither good nor bad (nor are they neutral).

    Addendum: I’d just like to say how invigorating it’s been to read the responses from Dave, Ethan, Brad, Matthew, and Frank …all of them writing on their own websites. Rumours of the demise of blogging may have been greatly exaggerated.

    This was originally published on my own site.

    ]]>
    Tiny Lesson: How to run a premortem workshop https://clearleft.com/posts/tiny-lesson-how-to-run-a-premortem-workshop Mon, 03 Feb 2020 15:54:00 +0000 https://clearleft.com/posts/tiny-lesson-how-to-run-a-premortem-workshop A premortem is a great way to help mitigate bad outcomes on a project. It helps project teams identify risks and put actions in place to avoid them from the start.

    In this Tiny Lesson we share how to run one for you and your team.

    Watch the video here, or read the transcript below.

    How to run a premortem workshop

    Allow half an hour. You’ll need a few pens, some post-its of different colours, some wall space, and of course, some willing participants.

    First, ask the team to think about what’s happened in 12 months time, (you can adjust the duration to match your project or product roadmap). then imagine if everything that could’ve gone wrong has gone wrong. Give them about five minutes, and ask them to map all of the things they can think of onto the wall, explaining as they go along. Assign a note-taker to capture any salient points.

    Once they’ve done that, start mapping them into themes. If you can, group the items and give each theme a heading, such as people or processes or systems or ways of working. This will really help later on.

    Next work through each of the post-its, ask the team to think of ways to mitigate these bad outcomes and stick all the ideas they have over the top. Again, explaining each as they go along.

    Now you can take this output and create your action plan. If you can, it helps to assign timings or an owner to each action, and then share the plan with the group.

    This way, everyone’s aware of anything bad that could go wrong, and what you can do to stop it, and you’ll have a much better chance of success on your project.

    We used this technique recently at the start of our project with Virgin Holidays.

    ]]>
    Architects, gardeners, and design systems https://clearleft.com/posts/architects-gardeners-and-design-systems Wed, 29 Jan 2020 16:10:00 +0000 https://clearleft.com/posts/architects-gardeners-and-design-systems Design systems promise efficiency and consistency. But what’s the end game?

    I compared design systems to dictionaries. My point was that design systems—like language—can be approached in a prescriptivist or descriptivist manner. And I favour descriptivism.

    A prescriptive approach might give you a beautiful design system, but if it doesn’t reflect the actual product, it’s fiction. A descriptive approach might give a design system with imperfections and annoying flaws, but at least it will be accurate.

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

    Meanwhile, over on Frank’s website, he’s been documenting the process of its (re)design. He made an interesting comparison in his post Redesign: Gardening vs. Architecture. He talks about two styles of writing:

    In interviews, Martin has compared himself to a gardener—forgoing detailed outlines and overly planned plot points to favor ideas and opportunities that spring up in the writing process. You see what grows as you write, then tend to it, nurture it. Each tendrilly digression may turn into the next big branch of your story. This feels right: good things grow, and an important quality of growth is that the significant moments are often unanticipated.

    On the other side of writing is who I’ll call “the architect”—one who writes detailed outlines for plots and believes in the necessity of overt structure. It puts stock in planning and foresight. Architectural writing favors divisions and subdivisions, then subdivisions of the subdivisions. It depends on people’s ability to move forward by breaking big things down into smaller things with increasing detail.

    It’s not just me, right? It all sounds very design systemsy, doesn’t it?

    This is a false dichotomy, of course, but everyone favors one mode of working over the other. It’s a matter of personality, from what I can tell.

    Replace “personality” with “company culture” and I think you’ve got an interesting analysis of the two different approaches to design systems. Descriptivist gardening and prescriptivist architecture.

    Frank also says something that I think resonates with the evergreen debate about whether design systems stifle creativity:

    It can be hard to stay interested if it feels like you’re painting by numbers, even if they are your own numbers.

    I think Frank’s comparison—gardeners and architects—also speaks to something bigger than design systems…

    I gave a talk last year called Building. You can watch it, listen to it, or read the transcript if you like. The talk is about language (sort of). There’s nothing about prescriptivism or descriptivism in there, but there’s lots about metaphors. I dive into the metaphors we use to describe our work and ourselves: builders, engineers, and architects.

    It’s rare to find job titles like software gardener, or information librarian (even though they would be just as valid as other terms we’ve made up like software engineer or information architect). Outside of the context of open source projects, we don’t talk much about maintenance. We’re much more likely to talk about making.

    Back in 2015, Debbie Chachra wrote a piece in the Atlantic Monthly called Why I Am Not a Maker:

    When tech culture only celebrates creation, it risks ignoring those who teach, criticize, and take care of others.

    Anyone who’s spent any time working on design systems can tell you there’s no shortage of enthusiasm for architecture and making—“let’s build a library of components!”

    There’s less enthusiasm for gardening, care, communication and maintenance. But that’s where the really important work happens.

    In her article, Debbie cites Ethan’s touchstone:

    In her book The Real World of Technology, the metallurgist Ursula Franklin contrasts prescriptive technologies, where many individuals produce components of the whole (think about Adam Smith’s pin factory), with holistic technologies, where the creator controls and understands the process from start to finish.

    (Emphasis mine.)

    In that light, design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.

    Humans aren’t always great at efficiency and consistency, but machines are. Automation increases efficiency and consistency, sacrificing messy humanity along the way:

    Machine with the strength of a hundred men
    Can’t feed and clothe my children.

    Historically, we’ve seen automation in terms of physical labour—dock workers, factory workers, truck drivers. As far as I know, none of those workers participated in the creation of their mechanical successors. But when it comes to our work on the web, we’re positively eager to create the systems to make us redundant.

    The usual response to this is the one given to other examples of automation: you’ll be free to spend your time in a more meaningful way. With a design system in place, you’ll be freed from the drudgery of manual labour. Instead, you can spend your time doing more important work …like maintaining the design system.

    You’ve heard the joke about the factory of the future, right? The factory of the future will have just two living things in it: one worker and one dog. The worker is there to feed the dog. The dog is there to bite the worker if he touches anything.

    Good joke.

    Everybody laugh.

    Roll on snare drum.

    Curtains.

    This was originally published on my own site.

    ]]>
    Web standards, dictionaries, and design systems https://clearleft.com/posts/web-standards-dictionaries-and-design-systems Thu, 23 Jan 2020 19:50:00 +0000 https://clearleft.com/posts/web-standards-dictionaries-and-design-systems I’ve noticed a trend. It all starts with web standards.

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

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

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

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

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

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

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

    Dictionaries are descriptive, not prescriptive.

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

    Jordan Moore talks about intentional and emergent design systems:

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

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

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

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

    Simplified flow of an intentional design system (building blocks first) by Jordan Moore
    Simplified flow of an intentional design system (building blocks first) by Jordan Moore

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

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

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

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

    This was originally published on my own site.

    ]]>
    Exploring DesignOps https://clearleft.com/posts/exploring-designops Thu, 23 Jan 2020 10:32:00 +0000 https://clearleft.com/posts/exploring-designops Late last year we hosted our second Design Leadership Breakfast, with two panels debating in front of 70 design leads.

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

    Four panellists and Jeremy comparing in front of a blue screen

    What is DesignOps?

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

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

    Dave Malouf

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

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

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

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

    9861

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

    How embedded is DesignOps?

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

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

    Are we really there yet?

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

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

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

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

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

    The benefit of DesignOps

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

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

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

    ]]>
    11 things I know to be true https://clearleft.com/posts/11-things-i-know-to-be-true Thu, 02 Jan 2020 16:49:00 +0000 https://clearleft.com/posts/11-things-i-know-to-be-true Here are some things I’ve come to believe over the years…

    1. You are not your user

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

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

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

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

    This is one of the benefits of the agile process.

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

    3. Sometimes you need to slow down to speed up

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

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

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

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

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

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

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

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

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

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

    7. Everybody is largely trying to do the right thing

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

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

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

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

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

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

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

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

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

    10. Product management is the hardest job in tech

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

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

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

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

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

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

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

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

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

    1. Creating strategy together

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

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

    2. Collaborating

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

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

    Rachel's sketch of a team climbing a mountain

    3. Having a stepped process

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

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

    4. Making things measurable

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

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

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

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

    5. Testing and learning

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

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

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

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

    6. Knowing when day two is

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

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

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

    7. Shipping regularly

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

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

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

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

    8. Acting on regular retros

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

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

    This post was originally published on Rachel’s Medium.

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

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

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

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

    Penny-drop no.1

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

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

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

    9689

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

    Penny-drop no. 2

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

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

    Time for reflection

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

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

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

    ]]>
    Learnings from a design internship https://clearleft.com/posts/learnings-from-a-design-internship Fri, 13 Dec 2019 12:21:00 +0000 https://clearleft.com/posts/learnings-from-a-design-internship 15 weeks have flown by here at Clearleft. You can see the concept we designed at our website www.selftreat.co.uk.

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

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

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

    We learned to turn challenge into opportunity

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

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

    We became a bit more comfortable with not being comfortable

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

    Collaboration strengthens design

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

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

    Language is crucial to user experience

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

    Don’t spend too much time in early stage research

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

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

    Holly and Lacin sat at the kitchen table with laptops

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

    You can read about the project at www.selftreat.co.uk.

    ]]>
    Leading Design London 2019 talks https://clearleft.com/posts/leading-design-london-talks Mon, 09 Dec 2019 15:43:00 +0000 https://clearleft.com/posts/leading-design-london-talks We’re excited to share the talks from Leading Design London 2019.

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

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

    Andy Budd on stage at Leading Design

    Day 1 Talks

    Day 2 Talks

    A man and two women at Leading design London in the Barbican conservatory
    ]]>
    Basil: Secret Santa as a Service https://clearleft.com/posts/basil-secret-santa-as-a-service Mon, 09 Dec 2019 09:00:00 +0000 https://clearleft.com/posts/basil-secret-santa-as-a-service I recently launched basil.christmas, a ‘Secret Santa as a service’.

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

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

    The basil.christmas home page

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

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

    The stack

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

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

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

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

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

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

    Classic form POSTs

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

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

    Design

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

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

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

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

    Error codes

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

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

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

    Planning for 'appropriate scale'

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

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

    Give it a go!

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

    Visit Basil


    This was originally posted on my own site

    ]]>
    Which content expert do you need? https://clearleft.com/posts/which-content-expert-do-you-need Tue, 03 Dec 2019 00:00:00 +0000 https://clearleft.com/posts/which-content-expert-do-you-need As digital disciplines mature, it’s normal for them to fragment as practitioners begin to specialise.

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

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

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

    Which content expert do you need?

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

    We deliver better research when we:

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

    Have conversations early

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

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

    Let the experts do the recruitment

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

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

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

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

    Check the calendar

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

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

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

    Use a balanced ratio of research and analysis

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

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

    Share the journey

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

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

    This was originally posted on my own website.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    This was originally posted on my own site.

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

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

    storyboarding intern project
    Storyboarding

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

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

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

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

    Our extensive set of How Might We's

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

    Beginning to form a basic user journey

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

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

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

    That tool is sketching.

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

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

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

    Sketching

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

    Use good pens

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

    Use colour strategically

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

    Use highlighters to lift the edges

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

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

    Start messy and then draw a neat version

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

    Practice readable writing - write in uppercase

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

    Scan and tidy up in photoshop

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

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

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

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

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

    9365

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

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

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

    Framework principles

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

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

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

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

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

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

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

    © Hayden Slaughter

    Defining a role

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

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

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

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

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

    Example: The UX Designer Role

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

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

    Communication

    • Collaboration
    • Presentation
    • Feedback

    Problem solving

    • Initiative
    • Methodology
    • Planning

    Empathy

    • Relationships
    • Support
    • Human-centricity

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

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

    • Architecture
    • Validation
    • Exploration
    • Craft

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

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

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

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

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

    Example: The Design Team

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

    e.g. 3 person design & research team

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

    e.g. 2 person strategic design team

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

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

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

    ]]>
    Microfrontends with Vue.js https://clearleft.com/posts/microfrontends-with-vue-js Wed, 13 Nov 2019 11:30:00 +0000 https://clearleft.com/posts/microfrontends-with-vue-js We’ve recently been building a complex search integration for a holiday provider using a microfrontends approach in Vue.js.

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

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

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

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

    Requirements

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

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

    And a different set on the details page:

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

    Choosing an approach

    Option 1

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

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

    Option 2

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

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

    Option 3

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

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

    The code

    Here’s how we instantiated the various Vue applications:

    import Vue from 'vue';
    import SearchPanel from './components/SearchPanel/SearchPanel.vue';
    import SearchResults from './components/SearchResults/SearchResults.vue';
    import Feefo from './components/Reviews/Feefo.vue';
    import store from './store';
    
    store.dispatch('init', storeDefaults);
    
    const vueRoots = [
      {
        id: 'search-panel',
        component: SearchPanel,
        store
      },
      {
        id: 'search-results',
        component: SearchResults,
        store
      },
      {
        id: 'reviews-box',
        component: Feefo
      }
    ];
    
    vueRoots.forEach(({ id, store, component }) => {
      if (document.getElementById(id)) {
        new Vue({
          store,
          render: h => h(component)
        }).$mount(`#${id}`);
      }
    });

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

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

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

    Accessing data

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

    Reading global data is so clean:

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

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

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

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

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

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

    Vuex helpers

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

    import { mapState } from 'vuex';
    
    export default {
      computed: {
        ...mapState(['results']),
    
        hasResults() {
          return !!this.results.length;
        }
      }
    };

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

    Microfrontends benefits

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

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

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

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

    This was originally posted on my own site

    ]]>
    FF Conf 2019 https://clearleft.com/posts/ff-conf-2019 Mon, 11 Nov 2019 15:42:31 +0000 https://clearleft.com/posts/ff-conf-2019 A report from Brighton’s unmissable annual front-end gathering.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    This was originally posted on my own site.

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

    Expanding research

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

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

    Initial concept sketches and affinity map of interview insights

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

    Coming up with concepts

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

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

    Designing with the Henfield Medical Centre team

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

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

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

    Empowering self-care

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

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

    ]]>
    Design Effectiveness Report 2019 https://clearleft.com/posts/design-effectiveness-report-2019 Mon, 04 Nov 2019 12:00:00 +0000 https://clearleft.com/posts/design-effectiveness-report-2019 We surveyed designers from hundreds of organisations to uncover three factors that impact design effectiveness.

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

    Get the report

    Take a look at the design effectiveness report

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

    Increasing design impact

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

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

    1. Empowered by management

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

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

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

    2. The right environment

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

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

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

    3. The importance of doing research

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

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

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

    What’s next?

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

    If you’d like to discuss the report on the phone or in person, or share insights from your own company email us at info+report2019@clearleft.com

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

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

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

    Example of content across an organisation

    Improve your products

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

    Provide better customer conversations

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

    Check your feedback loop

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

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

    Connecting your content

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

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

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

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

    Make it strategically-driven

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

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

    Who should steer the ship?

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

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

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

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

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

    This post was originally published on Medium

    ]]>
    Are you designing a product or a service? https://clearleft.com/posts/are-you-designing-a-product-or-a-service Fri, 18 Oct 2019 10:09:00 +0000 https://clearleft.com/posts/are-you-designing-a-product-or-a-service Traditionally, the distinction between a product and a service was relatively clear.

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

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

    8917

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

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

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

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

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

    ]]>