Clearleft | Blog https://clearleft.com/posts/ The latest news from Clearleft en-gb Sat, 21 Jul 2018 09:21:34 +0000 Sat, 21 Jul 2018 09:21:34 +0000 Web Animation 0 to 60 https://clearleft.com/posts/web-animation-0-to-60 Thu, 19 Jul 2018 09:19:31 +0000 https://clearleft.com/posts/web-animation-0-to-60 Recently, I had the good fortune to attend the workshop “Web Animation 0 to 60”, by Sarah Drasner and Val Head. I came away with a newfound respect for animation on the web.

The workshop was entertaining, packed with information, and well-run. Even a technical glitch beyond their control was resolved quickly and with grace. Laying the groundwork for attendees from a wide variety of backgrounds, Val and Sarah built a solid foundation of theory. We received many helpful resources and assets tailored to the session. Attendees — no matter their level of experience — were up and running quickly for the practical sections of the workshop.

I’ve gained a deeper understanding of when and why to use animation. I’m excited to try out the tools they shared with us. Some of them turned out, to my delight, to be old friends. The cognitive impacts of animation were of particular interest to me.

Animation is a tool that exemplifies the old adage, “with great power comes great responsibility.” Sarah and Val acknowledged that it can sometimes lead to a bad user experience. But they presented a strong argument that this doesn’t mean we should hate animation — we should instead hate bad animation.

“Bad animation” occurs when its design and implementation get left to the end of a project, or shoehorned in without proper planning. When carefully considered from the outset animation can provide great benefits.

Sarah demonstrating an animation to an attentive audience
Sarah demonstrating an animation to an attentive audience

So, when and why might animation actually be useful?

Spatial awareness is what we humans use to understand the environment and our place within it. This holds both for the physical world around us, and for the websites we visit. Nothing in the real world pops in or out of existence. Instead, things move more-or-less smoothly from one place to another, and from one state to another. We can make life easier for our users by taking advantage of the human tendency to perceive everything in spatial terms. Using animation to create a sense of consistent dimensional space is an excellent way to reduce cognitive load.

In general, there are two types of animation: immersive, and invisible.

Use immersive animations to tell a story, evoke an emotion, or encourage play. They can provide background context or branding material. In most cases, use them sparingly. At best they lose their impact and at worst can be annoying on repeated exposure.


See the Pen Responsive Huggy Laser Panda Factory by Sarah Drasner (@sdras) on CodePen.

Invisible animations exist without drawing any attention to themselves. They are best for user interface interactions. A well-designed user journey should prevent context switching as much as possible. This lets users maintain flow state and focus on the goal they are trying to achieve. One way to do this is to provide users with an intuitive sense of where things “live”. Animating interactive elements to and from consistent locations off-screen creates the illusion of space and maintains context.

Another way we can help our users is by reducing cognitive leaks. Cognitive leaks occur when the models we use to represent something don’t match well with reality. This is illustrated well by the dials on a cooker - how often do we have to check which burner corresponds to which dial? If we could arrange the dials in the same pattern as the burners, we would spend little time determining which dial controls each burner.

Animation can help prevent these cognitive leaks. We can transition interactive elements between states, rather than interrupting with a modal. This maintains any established mental models.

Leaving animation aside, these principles are useful tools to help us check how much work we’re asking the user to do. I’m excited to work with our designers to integrate some of these principles in upcoming projects!

“Web Animation 0 to 60”, by Sarah Drasner and Val Head

]]>
Performance is a UX problem https://clearleft.com/posts/performance-is-a-ux-problem Wed, 11 Jul 2018 13:13:00 +0000 https://clearleft.com/posts/performance-is-a-ux-problem Front-end code quality and performance have a massive effect on the user experience. I’m starting to get really fed up seeing machine-generated front-end code being spat out of libraries by back-end developers that would never have passed muster 6 years ago.

I’m not saying libraries are bad, or that back-end teams shouldn’t use them. But front-end development is a valuable skill and it’s vital to good UX that product teams recognise that and recruit accordingly.

If we continue to treat the web as a hobby and assume everybody can do everything with enough time and effort, we massively devalue the expertise we’ve built up over the past 15 years of web standards.

There was a good 5 year period where I thought web standards had become irrelevant. Seeing some of the crap that’s released these days makes me think it’s more important than it has been in a long time.

Smart products teams genuinely value the front end as the the interface with users, and invest accordingly. In fact, one of the most rewarding parts of our job at the moment is working with forward-thinking product teams to ensure their front-end code is as good as it could be, in a time of spiralling bandwidth and library proliferation.

Don’t get me wrong: I think it’s great to see back-end developers take an interest in the front end. But please don’t let them learn bad habits from other back-end developers. There’s a wealth of front-end knowledge and talent out there, so use it!

And if you’re struggling with front end code quality, size and performance, I can’t think of no better person to help you than Jeremy and his team.

]]>
Components and concerns https://clearleft.com/posts/components-and-concerns Tue, 10 Jul 2018 18:42:00 +0000 https://clearleft.com/posts/components-and-concerns We tend to like false dichotomies in the world of web design and web development. I’ve noticed one recently that keeps coming up in the realm of design systems and components.

It’s about separation of concerns. The web has a long history of separating structure, presentation, and behaviour through HTML, CSS, and JavaScript. It has served us very well. If you build in that order, ensuring that something works (to some extent) before adding the next layer, the result will be robust and resilient.

But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:

Rather than separating concerns by languages (such as HTML, CSS, and JavaScript), we’re are working towards a model of separating concerns at the component level.

This echoes a point made previously in a slidedeck by Cristiano Rastelli.

Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?

There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.

In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:

Your starting point should always be well-structured markup.

This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.

That’s basically an application of starting with the rule of least power.

In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:

We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”

There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.

My point is this:

  • Separating structure, presentation, and behaviour is a good idea.
  • Separating an interface into components is a good idea.

Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.

This was originally posted on my own site.

]]>
(Still) in with the old https://clearleft.com/posts/still-in-with-the-old Thu, 21 Jun 2018 14:39:01 +0000 https://clearleft.com/posts/still-in-with-the-old I am currently still using an Apple iPhone 5.

There, I said it - but for some reason this feels like something of a confession, a nagging thought that I should be ashamed of the ‘old’ technology in my pocket.

How many models there have been since the iPhone 5? How much better must the technology be now? Surely I’m missing out on the improved experiences everyone else is having? Surely it’s time to upgrade?

But up until a couple of months ago, I’d never really given much serious thought to the ‘upgrade’ question - my faithful 2012 device was going strong, running smoothly and did everything I wanted it to do. We got along just fine, more than fine - things were great, great to the point of fading into the background - my phone did it’s thing, it was there when I needed it, nothing more, nothing less. But then one fateful day I tried to add a new app, and was dutifully informed that it was only supported on a more recent version of iOS. 


Only at that point did I realise that the advent of iOS11 (way back in 2017 as it turns out) had pretty much passed me by. Whilst I’ve always paid close attention to software upgrades and updates, diligently obeying those (albeit annoyingly pesky) notifications to ensure that I was looking after my hardware as best I could, it turns out that I was up to date within the hardware limitations of my device. Those kind folks at Apple had thoughtfully refrained from telling me that my phone was slowly on its way out (hat-tip to Apple for keeping me placidly in the dark on that one).


At first I was annoyed, but then pleasantly surprised when I realised just how much life-span I had had from my iPhone without ever a real glitch. An item that I bought outright in 2012 - on the expectation that I would maybe get 1 or 2 years service at best from it - has lasted me nearly 6 years and counting.  Brilliant.

Happy maths

But surely I’m not pleased when faced with the inevitable phasing out of my trusty digital steed? Well, in short, I actually am pleased - I’m pleased that I am still using a piece of technology well past what I would have considered an optimistic lifespan. I’m pleased that my experience in maintaining this technology has been pretty much seamless, and that I continue to own a device that has done everything (almost) I have expected and more. I’m pleased that I bought the iPhone outright  - put into ‘real’ money (enter some very rudimentary maths), my faithful iPhone 5 has cost me approximately 9 pence(!) per day to date - a pretty pleasing figure in my book. And last, but not least, environmentally speaking I can’t be more pleased - more devices and hardware should be made like my the iPhone 5 - I don’t want to ‘recycle’ something if I can keep it running effectively for longer - update the software, change the battery, even replace a button (all things my iPhone has undergone) - anything we can do to reduce our technological environmental footprint is a good thing. 

Looking good

But surely I want something that looks, well, newer? Well, maybe not - in fact I’d argue that of all the iPhone models past and present, the iPhone 5 is in fact one of the most aesthetically balanced - it’s an elegant device, with a slim form that fits and operates perfectly in a single hand, a screen size and resolution that are generous but carefully restrained, and is crucially of a size that fits easily into your pocket (it really does). It’s a carefully crafted, functional piece of technology that isn’t trying to pretend it is something other than a carefully crafted, functional piece of technology going to a well dressed party. Form meets function, with a little shiny - beautiful. 


Now that’s not to say that subsequent models and those from other manufacturers aren’t equally aesthetically pleasing in their own right, but the iPhone 5 has stood the test of time - the current iPhone SE model is for all intents and purposes the same form design, it’s barely changed - something must be right. But in comparing the latest design offerings I can’t help think that the continual product evolutions and ‘improvements’ that are driven by - and driving - consumer demand are somewhat losing the direction and blurring the lines between fashion and technology in an attempt to become the ‘most desirable’ device. This feels like a dangerous game, especially when developing technology that demands such a high impact on our precious natural resources, and one that I’m pretty sure we won’t thank ourselves for down the line.

Time to compare

But a little bit of research shows that in fact consumer demand may be in some respects slowing, and that I am not alone in resisting the ‘need’ to ditch my current smartphone in favour of something newer. Increasingly, consumers are waiting much longer than in previous years to upgrade their handsets, citing complaints such as battery and software issues as the main reasons why they have finally moved on, rather than new designs, features and functions. This is a problem for manufacturers basing some of their product iterations on relatively small upgrades and possibly missing the ‘wow’ factor that might encourage consumers to part with their cash. Recent underwhelming sales of the new iPhone X seem to suggest that the relatively minor technological improvements on previous models and less-than-radical form design weren’t enough to offset the considerably large price tag for many. Now whilst this is only a single example, it does involve one of the most, if not the most innovative manufacturers and is part of growing trend. 

It seems that our increasing tech-understanding is a huge factor here - no longer can we be just sold on the shiny ads and lifestyle promises that come pre-boxed with the latest models - we’re all becoming a little more savvy, are capable (and keen) to engage in readily available comparisons and reviews, supplying us with compelling information with which to make our choices. And perhaps we’re also getting a better understanding of exactly what we use our devices for - another fairly rudimentary bit of research reveals that the majority of us only use a very limited set of potential functions and apps we have installed on our smartphones - come to terms with fact that you don’t actually ‘need’ that enhanced processor and face recognition to send emails, text messages and check the weather (3 of the top 10 common smartphone uses), and you’ve got another compelling reason to hang on to your current model.

For the good of all

So where does this leave the technology designers and manufacturers? In designing beautiful, advanced, functional products that stand the test of time (at least in the short term) perhaps manufacturers are outdoing themselves and providing consumers with the very reasons they need to not upgrade? Maybe our ‘old’ tech will actually be our ‘now’ tech for a lot longer than we thought? 
On the other hand, by offering consistently good products and services to consumers, there is a brand loyalty element to consider as well - my excellent experience with my iPhone will certainly have me turning to Apple products again when it is (finally) time to upgrade, and the same will be true of large numbers of other consumers. It’s not necessary for a manufacturer to sell upgrades every product cycle to their loyal customer base as long as their customer base is just that - loyal. Deliver quality products and services and you’ll increase the likelihood of your customers returning. Make those products robust, desirable and beautiful as well as functional, and the sales should just keep on coming. 


So I’m certainly not suggesting that manufacturers do anything other than continue to design and develop cutting edge technology, but to do this responsibly. As designers it’s definitely our responsibility to ensure we do all we can to future proof our technology solutions - make them extensible, scalable and repairable, and continue to support them well beyond their perceived ‘consumer lifespan’. If we can design and build better, more thoughtful products now that really do stand the test of time, when it really is time to start looking out for the latest model, hopefully we’ll have done all we can to help the environment and our wallets.


So what does all this leave my iPhone 5? Well, I won’t say that a future upgrade isn’t inevitable, but in the meantime whilst things are still going strong, perhaps I should be a little more proud of my faithful and beautiful little digital companion - long may we stay together.

This was originally posted on my own site

]]>
Takeaways from Jan Chipchase’s Field Research Masterclass https://clearleft.com/posts/takeaways-from-jan-chipchase-field-research-masterclass Fri, 08 Jun 2018 12:00:00 +0000 https://clearleft.com/posts/takeaways-from-jan-chipchase-field-research-masterclass When you have the opportunity to add new methods to your UX research toolkit, grasp that opportunity with both hands!

When I joined Clearleft last year the bar for research was set high; very high. Working alongside Steph Troeth and the UX team I was given the opportunity and freedom—encouraged, even—to try new research methodologies, approaches and tools as well as honing my existing toolkit.

Since then I have grown curious about the benefits of mixed methods and broader skill sets that give a deeper understanding of people’s motivations and needs. The world of behavioral economics has led me to cognitive biases and psychology effects that have proved to be another highly useful set of heuristics for decision making.

But in an agency environment, budget and time constraints can sometimes limit the reach of our research. Traditional lab-based usability studies and street-level intercepted guerrilla tests have been our UX research bread and butter for quite some time. Although remote interviews and contextual inquiries might enable us to speak to people in the comfort of their home or work spaces, we seldom get the opportunity to go deep and gain first-hand experience in true ethnographic detail.

To satisfy this hunger for a richer world view of ethnographic research, I attended Jan Chipchase’s Field Research Masterclass, a single day workshop that forms part of the Clearleft Presents series. Here are some of my key takeaways.

Workshop takeaways as a design researcher

Leadership

A clear thread of leadership emerged early on in the workshop. Jan’s hands-on approach to building a team was an open, democratic process built on a bedrock of mutual respect.

One example of ensuring equal status within the team is the upside down principle. Traveling together as a team means relocating many times within a research study. At each new accommodation the rooms must be divvied up. Jan’s approach is to flip the traditional top-down hierarchy on its head by giving the most junior team member first choice of the selection of rooms. This continues with each subsequent relocation, each time moving up the experience ladder.

If you’ve been involved in conducting a research study you’ll know it’s an emotionally intense and cognitively draining process. Part of Jan’s approach to counter this is to reserve a proportion of time and budget for decompression. Its purpose is for the team to relax and recuperate as people. The choice of location and accommodation is team-led, not dictated, and is—crucially—a team activity. Here, Jan cleverly uses the peak end rule to leave his team ending on a high.

Process

As curious practitioners we invariably experiment with our processes at each new opportunity. This might be with a new methodology, tool or team shape. In order to learn from these experiments we need time to reflect on what did and didn’t work. Most important, we need time put these learnings into action. At the beginning of the workshop Jan broke down the research timeline and proclaimed the activity of “the application of insight” as wisdom. This valuable phase of iteration extends to our own processes too.

While we, as researchers, should be striving to hone our processes, we shouldn’t be a slave to them. Interview script run-throughs help to flag issues with timings and the general flow of discussion but it can’t prepare you for that moment with your first participant where the conversation takes you to an unexpected insight. This is where Jan differentiates process (good) and art (great). Knowing when to go off-script—and having the confidence to do so—can be the difference between good and great insight.

Analysis

Toward the end of the workshop, three brave volunteers partook in an exercise in memory, through which Jan demonstrated how our recall diminishes at an alarming rate. This becomes troublesome for research studies structured with large gaps in between analysis.

If time erodes evidence, then we should be reducing the latency for sensemaking as much as possible.

While the workshop was aimed at international ethnographic researchers, I left with a deeper appreciation of team leadership, a fresh outlook on process, and a great responsibly of the evidence I collect.


Clearleft Presents is a programme of workshops, led by some of the biggest names in the tech industry. It’s a hand selected combination of designers, speakers, authors and evangelists, from across the sector; inspired by the most popular and impactful sessions at UX London, Leading Design and working with people we admire. Jake Knapp is up next in our series and he’ll be guiding folk in how to nail Design Sprints. He’s a New York Times bestselling author on the subject, so you’ll be in safe hands! Take a look to book your tickets.

]]>
Clearleft.com is a progressive web app https://clearleft.com/posts/clearleft-com-is-a-progressive-web-app Tue, 05 Jun 2018 17:57:05 +0000 https://clearleft.com/posts/clearleft-com-is-a-progressive-web-app What’s that old saying? The cobbler’s children have no shoes that work offline. Or something.

It’s been over a year since the Clearleft site relaunched and I listed some of the next steps I had planned:

Service worker. It’s a no-brainer. Now that the Clearleft site is (finally!) running on HTTPS, having a simple service worker to cache static assets like CSS, JavaScript and some images seems like the obvious next step.

You know how it is. Those no-brainer tasks are exactly the kind of thing that end up on a to-do list without ever quite getting to-done. Meanwhile I’ve been writing and speaking about how any website can be a progressive web app. I think Alanis Morissette used to sing about this sort of situation.

Enough is enough! Clearleft.com is now a progressive web app. It has a manifest file and a service worker script.

The service worker logic is fairly straightforward, and taken almost verbatim from Going Offline. As you navigate around the site, the service worker applies different logic depending on the kind of file you’re requesting:

  • Pages are served fresh from the network, falling back to the cache when there’s a problem.
  • Everything else is served from the cache where possible, resorting to the network only if there’s no match in the cache—quite the performance boost!

In both cases, if a page or a file is retrieved from the network, it’s gets put into a cache. I’ve got one cache for pages, and another for everything else. And even if a file is retrieved from that cache, I still fire off a fetch request to grab a fresh copy for the cache. So while there’s a chance that a stale file might be served up, it will only ever be slightly stale, and the next time it’s requested, it’ll be fresh.

In the worst-case scenario, when a page can’t be retrieved from the network or the cache, you end up seeing a custom offline page. There you can see a list of any pages that are cached (meaning you can revisit them even without an internet connection).

A custom offline page showing a list of URLs.

It’s not ideal—page titles would be friendlier than URLs—but it’s a start. I’m sure I’ll revisit it soon. Honest.

Oh, and after a year of procrastinating about doing this, guess how long it took? About half a day. Admittedly, this isn’t my first progressive web app, and the more you build ‘em, the easier it gets. Still, it’s a classic example of a small investment of time leading to a big improvement in performance and user experience.

If you think your company’s website could benefit from being a progressive web app (and believe me, it definitely could), you have a couple of options:

  1. Arm yourself with a copy of Going Offline and give it a go yourself. Or
  2. Get in touch with Clearleft. We can help you. (See, I can say that with a straight face now that we’re practicing what we preach.)

Either way, don’t dilly dally …like I did.

This was originally published on my own site.

]]>
The challenges of scaling innovation https://clearleft.com/posts/the-challenges-of-scaling-innovation Mon, 21 May 2018 07:08:00 +0000 https://clearleft.com/posts/the-challenges-of-scaling-innovation In the drive to scale design, organisations often focus on their capability to execute, but forget about their ability to innovate too. In fast-paced markets, your ability to identify and exploit opportunities quickly is crucial to maintaining competitive advantage.

So, you’re scaling design within your organisation. Your designers are distributed and sit within well-oiled, multidisciplinary product teams. They’re all busy, working through your backlog and consistently releasing improvements to your product. But yet, you realise you’re losing market position. A competitor has leap-frogged you by exploiting an opportunity you hadn’t even considered. Your previously held competitive advantage has disappeared. And now you’re playing catch up.

This is a story familiar to lots of organisations seeking to scale design. By focussing on making what they currently do more efficient and effective, there’s a danger they’ll neglect their ability and capacity to exploit longer-term opportunities too.

In a recent piece of research by McKinsey, 70% of executives surveyed said “innovation will be at least one of the top three drivers of growth for their companies in the next 3-5 years”. If that’s the aspiration then what makes it so challenging?

In the drive to make design scalable and repeatable, how do you also make room for genuine innovation? In this (the first of a two-part) article, I’ll outline some of the common challenges we’ve seen organisations struggle with when trying to innovate whilst scaling design.

Business-as-usual comes first

This is probably the most common challenge. Stuff just gets in the way. Whether that’s the day-today product design and development cycle, routines (meetings, planning etc.), or managing the process (hiring, 1:1s, building processes and evaluating tools). It all takes time and, in our experience, it often takes priority (especially in small teams with limited resource).

Short-term focus

Lots of product teams are all too often focussed on shorter-term impact. They’re typically tasked with moving the needle on specific metrics, so are only looking 3-6 months out. They’re optimising their designs, but only within the constraints of what currently exists (referred to as Local Maximum). From this perspective they often view more radical change as risky or potentially wasteful.

Innovation islands

We often see sporadic bursts of ‘innovation’ happening from small groups acting in their own interest. Whilst not necessarily bad, they’re often trying to solve a problem only that particular group has; or, even worse, deliver on one individual’s ‘big idea’. More crucially, they aren’t being led by broader strategy or being driven by actual customer needs. There’s often a lack involvement, feedback and validation from other parts of the business. Without this, these stand-alone initiatives tend to have limited success, lead to disjointed experiences and have a negative impact on other groups.

Lack of customer insight

Lots of organisations still don’t spend enough time really understanding their customers. They’re typically using evaluative methods to measure customer behaviour or validate the work they’re doing. But they crucially lack the ongoing formative research into customer attitudes, behaviours and needs. It’s these insights that provide the opportunities for innovation and exploration.

Organisational culture

This is the biggest hurdle of all, as it’s often the most difficult to change and moves the slowest. Your organisation’s culture can affect how you innovate in a multitude of ways. Lots of organisations (particularly large well-established ones) are inherently risk averse and therefore wary of experimentation and perceived failure. Some have organisational structures or processes that mean they think in terms of one-off projects and outputs rather than ongoing programmes and outcomes. Others don’t especially value brand or product differentiation, or perhaps they don’t have a clearly articulated and understood vision. Any of these can make innovating difficult. All of these are time consuming and difficult to overcome and require both persistence and advocacy at senior levels.

So, if these are some of the challenges, then what do you do? In a follow-up to this post I’ll outline some of the successful strategies we at Clearleft have seen and used to help companies continue to innovate.

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

]]>
Adapting to design culture – pt.2 https://clearleft.com/posts/adapting-to-design-culture-pt-2 Mon, 21 May 2018 06:51:43 +0000 https://clearleft.com/posts/adapting-to-design-culture-pt-2 In part one of this article, I covered how design culture affects your product strategy, production and development processes. In this part, I’ll cover how design culture affects your working environment and hiring process.

To recap… Doing more and better design means change, and not just for those within the design team. A more mature design capability will be disruptive by default, even if you don’t intend it to, or actively work to prevent it. Being aware and suitably prepared for the changes to your existing processes, operations, environment and culture will make you better able to respond and adapt to the inevitable turbulence ahead.

This article is part of a series. Read about how design culture affects your product strategy, production and development processes in part one.

Environment

Do you have enough usable wall space?

No seriously, are you sure? Never underestimate the ability of design to cover the walls of your office. Design is collaborative and transparent, meaning at every opportunity to share work, work should be shared. And this doesn’t just mean user interface mockups. It means workshop outputs, personas, experience maps, sketches, site maps, diagrams, boxes, arrows, and more boxes. If designers can stick a sticky note on it, they will. And should.

Discouraging designers from making your environment appear “busy” or “messy” is the worst reaction possible. Refocus that censoring instinct into actively encouraging this overt saturation of ideas, insights and possibilities. It is in the interests of the entire organisation to achieve more awareness of what design is up to, and capable of, so better to encourage any latent desire within curious individuals to ‘lean-in’ to any public sharing that begins to emerge - it will need encouragement and reinforcement.

And just to be certain: Are you absolutely sure you have enough wall space?

Do you have a workspace suitable for collaboration?

Design is collaborative. It’s impossible to repeat that mantra, yet it’s surprising just how many businesses and teams are unable to grasp exactly what’s required of a contemporary digital working practice, even from those currently self-identifying as exactly that. You don’t need to adopt the extreme gimmickry of Google campuses: hammocks, slides, and fußball tables. Seek inspiration from a (good) design agency near you, or pop down to Clearleft if you’re near Brighton. Hopefully you can spot a pattern emerging; of breakout spaces and dedicated, but temporary, project war rooms; of balancing private and public space rather than the uniform bank of desks and near-continuous interruption which homogenised open plan offices have succumbed to.

Hiring

Are your hiring processes rapid enough to not lose talent?

Design talent is in short supply, and demand for good designers is growing daily. Many HR processes, particularly at larger organisations, are slow and cumbersome. Job titles can exist in straight-jackets. Hierarchical salary bands can exclude the natural language of the design world given their potential for mistranslation in the wider business context (see the Director in Creative Director). HR seems a world ripe for radical digital disruption but for now it may be a case of identifying and applying the subtlest hacks to minimise the pain of the recruitment process.

If it’s a long drawn-out affair, there are approaches to help prevent the conversation going cold. Get candidates in as regularly as feels appropriate to demonstrate your mutual interest in each other. Encourage transparency of your ways of working and environment by breaking out of the stale cliche of the interview room and observe the reality of where, and how, the work really happens. Invite them to team meetings or company socials so they get a realistic feel for the culture and how they would fit into the team dynamic. If either party is ‘faking it’ it will soon make itself obvious, to the benefit of everyone involved in the long run.

Is the quality of your design on public display?

Digital designers already have an obvious window on your design capabilities staring them in the face: your public facing website and/or mobile apps.

Contemporary design practice is one of ever-increasing transparency. The UK Government Digital Service (GDS) is a great example of working in the open for all to see. There are also numerous examples of styleguides, pattern libraries and design systems from the likes of Google and IBM being shared in the full glare of public consumption. Even if you have a relatively immature design practice, it is good to start getting into the habit of thinking how you will share the fruits of your labour with the wider public. This is your window to the world and can be the differentiating factor between yourselves and your rivals when it comes to grabbing the attention of potential employees and demonstrating how seriously you take design.

Habits are hard to change

It’s easy to forget that any significant change needs commitment to ensure it sticks. Human behaviour is not as pliable as it may first seem, particularly with regards to the behaviour of the herd within a well established company culture.

You don’t create a culture. Culture happens. It’s the by-product of consistent behavior.

Jason Fried, Co-founder, Basecamp

If we accept that culture is the natural by-product of consistent behaviour, you’ll need to find methods to reinforce what the ‘new normal’ looks like, through training or rigourous reinforcement of processes and methodology at periodic intervals. It will not be quick and it will not be easy, but “this is how it’s always been done around here” should no longer be an adequate excuse to prevent change for the better.

This article is part of a series. Read about how design culture affects your product strategy, production and development processes in part one.

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

]]>
Adapting to design culture – pt.1 https://clearleft.com/posts/adapting-to-design-culture-pt-1 Thu, 17 May 2018 16:15:00 +0000 https://clearleft.com/posts/adapting-to-design-culture-pt-1 Doing more and better design means change, and not just for those within the design team.

A more mature design capability will be disruptive by default, even if you don’t intend it to, or actively work to prevent it. Being aware and suitably prepared for the changes to your existing processes, operations, environment and culture will make you better able to respond and adapt to the inevitable turbulence ahead.

This article is part of a series. In this part, we’ll cover how design culture affects your product strategy, production and development processes. Read about how design culture affects your working environment and hiring process in part two.

Design is not just a bolt-on

You can’t simply slot design into an existing process, before development and after strategy, and expect everything to work out. For design to be an effective capability it needs to flow through the whole process from beginning to end and may even demand you reappraise what you currently consider to be the ‘start’ and ‘end’ of your process.

If the design you’re currently doing is very tactical in nature (such as solving how things look and behave), rather than strategic (using design to both identify and solve user needs and problems based on evidence), then the pain of transformation will be particularly acute. You’re likely to need to rebuild the whole design process from the ground up, alongside any adaptations to your other existing functions and processes that touch it. Accelerating design is never a designers-only affair, and allies will need to be brought along to collaborate with, nurture, educate and also learn from.

Design starts earlier than you think

Given the obvious point that strategy shapes how and what you design, it’s important to ensure the customers of your products and services are well considered during the shaping of any opportunity.

Ideally, if your organisation is fully committed to human-centered design, customers would be at the heart of the solution. Too often the people who make up the consumer, or end-user, of your products and services are forgotten or misrepresented in key strategic business decisions. This can be due to a combination of factors. Very often a lack of understanding and empathy for the customer is due to lightweight or non-existent research, which in turn breeds aversion, fear or even in some cases borderline hostility to their needs or goals.

Ensuring business success means producing something that your customers desire, and for business and consumer alike to be able to profit or gain value from this exchange. In legendary management consultant Peter Drucker’s own words “the purpose of a business is to create and keep a customer”.

So it’s best to start with a shared understanding of the problem from the perspectives of both business viability and customer desirability. This means identifying a latent customer need and working back from there.

You have to start with the customer experience and work backwards to the technology.

Steve Jobs, CEO, Apple (1997)

Starting anew

So, let’s start at the beginning. What are the key things to consider when planning new projects and initiatives with a desire and capability for greater design impact?

Have you set success criteria for the customer?
How are you going to measure that you are achieving the aims of the customer as well as business targets? New products and services can initially produce positive indicators before burnout or saturation hits as the frustrations or unmet needs of a broader market audience become more telling beyond those who adopted it early.

Does your business case procedure allow for adaptation and iteration?
Very often, work can be tied into a funding model that signs off huge tranches of money up front, leading to a mentality of “delivery at any (or perhaps more accurately exact) cost”. This can be the case even if what is being delivered proves to demonstrate little to no value throughout the course of the design process. Speaking to customers to understand their needs, and gathering feedback on potential solutions can result in a change of direction or a pivot towards an entirely different strategy, or even an alternate problem to be solved.

Is this ability to flex and adapt built into your processes or is your organisation unyielding to change?

The ever increasing risk is that inevitable digital disruption will make you obsolete as a force in your market unless you are capable of staying nimble and efficient in how you execute your business strategy and adapt your business model to the era of constant change. Design, and the skills designers are proficient in, can help you achieve this.

What design [thinking] allows you to do is have a new level of consciousness… and to say ‘I’m actually going to learn how to do this in a way that de-risks our go-to-market’. That’s just, for me, smart business. It happens to be called design, but even the most backwards looking CEO can get behind that as an idea.

Andréa Mallard, CMO, Omada Health

Working beyond your next iteration

Obviously the hard work doesn’t end when the first release is out the door. Design is never done. Evolving a product or service with a more mature design capability might typically prompt the following considerations:

Does the customer influence what to work on next?
When customer research or prototyping feedback generates new ideas for future releases, how is this reflected back and prioritised in the product roadmap? Are opportunities being prioritised around known pain points and challenges faced by customers when using your product or service?

Using a story map as a visual articulation of how mature your product is now, and where the opportunities for enhancement are can be a powerful and transparent way of communicating both the current status and your future intentions.

Does design overlap development rather than precede it?
Many organisations Clearleft work with tend to have a more mature development function compared to design. This often means some practices around Agile development have been formed and in some cases hardened to the extent of having lost the initial flexibility and efficiency they were intended to provide as a competitive advantage. Consider these key questions about your processes:

  • Do you need UI mockups to be 100% signed off and agreed before you start development?
  • Do your developers or designers sit together in exclusive ‘clans’, communicating infrequently or non-verbally with other disciplines?
  • Are your teams truly cross-disciplinary, with designers and other non-development roles fully integrated into regular routines and rituals?
  • Are developers excluded from the initiation of the project or initial design activities, given it won’t reach development for months?

If the answer to any of these questions is yes, it’s likely your process is not sensitive to the changing nature of fluid delivery and the need to learn and communicate continuously throughout the delivery cycle. Yes, this will inevitably create some frustration and friction in the process, but the benefits of cross-disciplinary knowledge sharing and empathy building will be disproportionately magnified in the final product.

This article is part of a series. Read about how design culture affects your working environment and hiring process in part two.

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

]]>
Design systems https://clearleft.com/posts/design-systems Wed, 16 May 2018 07:14:49 +0000 https://clearleft.com/posts/design-systems Talking about scaling design can get very confusing very quickly. There are a bunch of terms that get thrown around: design systems, pattern libraries, style guides, and components.

The generally-accepted definition of a design system is that it’s the outer circle—it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design system. A system is a framework. It’s a rulebook. It’s what tells you how those patterns work together.

This is something that Cennydd mentioned recently:

Here’s my thing with the modularisation trend in design: where’s the gestalt?

In my mind, the design system is the gestalt. But Cennydd is absolutely right to express concern—I think a lot of people are collecting patterns and calling the resulting collection a design system. No. That’s a pattern library. You still need to have a framework for how to use those patterns.

I understand the urge to fixate on patterns. They’re small enough to be manageable, and they’re tangible—here’s a carousel; here’s a date-picker. But a design system is big and intangible.

Games are great examples of design systems. They’re frameworks. A game is a collection of rules and constraints. You can document those rules and constraints, but you can’t point to something and say, “That is football” or “That is chess” or “That is poker.”

Even though they consist entirely of rules and constraints, football, chess, and poker still produce an almost infinite possibility space. That’s quite overwhelming. So it’s easier for us to grasp instances of football, chess, and poker. We can point to a particular occurrence and say, “That is a game of football”, or “That is a chess match.”

But if you tried to figure out the rules of football, chess, or poker just from watching one particular instance of the game, you’d have your work cut for you. It’s not impossible, but it is challenging.

Likewise, it’s not very useful to create a library of patterns without providing any framework for using those patterns.

I would go so far as to say that the actual code for the patterns is the least important part of a design system (or, certainly, it’s the part that should be most malleable and open to change). It’s more important that the patterns have been identified, named, described, and crucially, accompanied by some kind of guidance on usage.

I could easily imagine using a tool like Fractal to create a library of text snippets with no actual code. Those pieces of text—which provide information on where and when to use a pattern—could be more valuable than providing a snippet of code without any context.

One of the very first large-scale pattern libraries I can remember seeing on the web was Yahoo’s Design Pattern Library. Each pattern outlined

  1. the problem being solved;
  2. when to use this pattern;
  3. when not to use this pattern.

Only then, almost incidentally, did they link off to the code for that pattern. But it was entirely possible to use the system of patterns without ever using that code. The code was just one instance of the pattern. The important part was the framework that helped you understand when and where it was appropriate to use that pattern.

I think we lose sight of the real value of a design system when we focus too much on the components. The components are the trees. The design system is the forest. As Paul asked:

What methodologies might we uncover if we were to focus more on the relationships between components, rather than the components themselves?

This was originally posted on my own site.

]]>
The Rise of Digital Service Design https://clearleft.com/posts/the-rise-of-digital-service-design Tue, 15 May 2018 08:23:20 +0000 https://clearleft.com/posts/the-rise-of-digital-service-design The field of User Experience Design, as conceived by Don Norman, was so similar to Service Design, as to be almost indistinguishable.

Both were focussed on the end-to-end user journey, rather than specific platforms or touch points. Both required an understanding of user-centred design, and both used multi-disciplinary teams to solve complex problems. If there were major differences back then, it was in three ways:

  • Geographic (Service Design had its roots in Europe while User Experience Design hailed from California),
  • Market (service designers mostly focussed on designing social services, while UX was focussed on consumer experiences),
  • Distinct communities of practice (largely influenced by the first two factors).

Over the years, UX design, or at least UX designers, began to specialise in the digital channel—possibly because it was new and exciting, possibly because that’s where the most demand was. They designed websites. They designed smartphone apps. They designed digital kiosks, and all kinds of digital products and services. They were still interested in the gaps between channels, and understanding the entire user journey, but as everything was starting to become digital, the bulk of their effort went there.

More and more people started joining the industry, buoyed by high demand and even higher salaries. The focus started to narrow. Quality began to slip. Rather than designing the experience across multiple channels, newly minted UX designers spent their time producing wireframes, building prototypes and occasionally designing screens. The original meaning of the term became lost, to the point that anybody who designed digital products considered themselves a UX designer.

Hiring designers with that broader domain experience became difficult, so organisations like Government Digital Services started advertising for something they called a Digital Service Designer. I hadn’t come across the term before GDS, although I’m sure it probably existed. But if you looked at the skills they were looking for, and the problems they were trying to solve, these were clearly the UX designers of old.

I’ve been in this industry long enough to tire of constant reinvention. As one of the first UX designers in the UK, I’ve always been slightly protective of the term. However I’m finally coming to the realisation that the battle has been lost and “UX Designer” no longer represents the breadth and depth of what we do. Not because we’ve changed, but because the term itself has come to mean something different.

While I’m reluctant to engage in the trend of job title inflation, I’m begrudgingly coming to accept that Digital Service Designer is probably a better and more accurate description of what myself and many of my colleagues do.

For related reading, take a look at some of our other posts on the topic:

]]>
Building allegiances to enable smarter design https://clearleft.com/posts/building-allegiances-to-enable-smarter-design Mon, 14 May 2018 09:50:47 +0000 https://clearleft.com/posts/building-allegiances-to-enable-smarter-design If you’re looking to scale design to have a bigger impact at your organisation, you can’t do it alone.

But if you haven’t got obvious allies or buy-in from up on high to help you spread the gospel of design, there are some proactive steps you can take to build momentum behind your cause.

Kill the silos

Design doesn’t work in isolation. Successful design demands collaboration. To help ensure your design team, and their impact across the wider business, not only grows but thrives, you need to bring colleagues, peers and leaders from elsewhere in the organisation on a journey with you. Seek ways to actively collaborate on design solutions across departments and business units wherever possible, even if you need to force an unnatural fit sometimes, or incentivise others to join in. Blunt means or brute force, like a lunchtime workshop with free food or end of day presentations over drinks, can be effective ways to draw the attention you need.

Identify your evangelists

Who has most to lose from a continuation of the status quo? Who seems frustrated by the current ways of working? Who is frustrated by barriers to progress within the organisation? Those who would benefit most (and soonest) from a more advanced design practice are ideal early adopters and advocates to your cause. If you’ve demonstrated some design success on previous initiatives or projects, then who better to join you than these colleagues you’ve already engaged with? They’ll be advocates for doing more of the same, more often and even better.

Understand your audience

It’s all too easy to make assumptions about the maturity of understanding around user-centered design across your organisation, or in some instances even within your design team. Assessing the understanding and appetite for user-centered design should be a top priority before embarking on any transformation to a more mature design practice.

A Design Maturity assessment can be a useful indicator of the existing status of design within the organisation. Knowing where you are starting from will have a significant influence on recognising what you need to do next to achieve your ambition and reach your ideal destination.

Has the majority of the organisation rallied around the belief that user-centered design helps you deliver better products and services? If so, your task is hopefully more straightforward. If not, you’ll need to educate others on the benefits of putting users and customers at the heart of how you design, or ideally even demonstrate its value more tangibly. UX training, company mini conferences, or running a pilot project can be useful ways of helping others see these benefits.

Tell an engaging story

It’s an intrinsic part of our civilisation and culture as humans to transfer knowledge and pass on invaluable insights through storytelling. How do you articulate what you’re trying to achieve in a compelling way that others want to hear? How is it going to transform the organisation, and the people within, into something better? A story can be infinitely more powerful than a slide deck of dry business jargon and targets. But you need to understand your colleagues’ departmental aims, objectives and individual ambitions so you can incorporate them into the narrative of how design will help them achieve their goals.

Get outside help to advocate for you

Sometimes an external voice from outside the organisation can help highlight sensitive subjects or existing bad practices that, despite being already tacitly recognised as potential issues, are culturally taboo to fix, or even discuss.

“This is how we do things here” or “that’s the way it’s always been” are often used as shortcuts or verbal crutches to shut down debate and avoid the complexity, pain or risk of longer-term positive change. When an independent third-party reiterates the things you’ve already been saying yourself repeatedly to your peers and superiors, it can have greater impact and gravitas simply due to the perspective it comes from.

Don’t underestimate the power of using consultants to achieve a breakthrough simply by voicing things from an outsider’s point of view. Devoid of the political and cultural baggage of your industry and organisation, it can break deadlocks on progress.

Know your limits

It’s worth confronting some hard truths: The impact of design is only ever as effective as your organisation allows. Put simply, if design is tasked with solving insignificant problems, the impact of design will be insignificant. Understanding and being realistic about the scale of the change being attempted will help you accurately calibrate what success looks like within the boundaries of what is possible. For instance, without significant design or customer experience representation at the very top level of the organisation, you shouldn’t expect to affect radical change.

Models such as the Competing Values Framework help you understand which approaches are effective within the prevalent culture of the organisation. How do you ensure you satisfy the need to execute your plans in a controlled manner within a Hierarchy? Or demonstrate innovation and the ability to improvise in an Adhocracy? Identify which leadership skills are going to be useful to help you succeed so that you are able to make good on the execution of your plan to progress and change for the better.

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

]]>
Growing design starts with people https://clearleft.com/posts/growing-design-starts-with-people Mon, 14 May 2018 09:23:00 +0000 https://clearleft.com/posts/growing-design-starts-with-people Working at a design agency as a UX consultant, I get to work with many clients and lots of design teams. I get to see projects from the perspective of the business who initiate them and the viewpoint of the creative teams tasked with delivering them.

In both of these camps there is a emerging consensus: scaling digital design (used deliberately here in its broadest sense) is likely to provide your organisation with its ongoing competitive advantage, unlock its next innovation and kick-start its next growth spurt.

However, ‘scaling design’, this amorphous term, is in danger of meaning everything to everyone… therefore nothing to anybody.

Scaling design promises the heady elixir of bestowing greater recognition on the importance and impact of design, placing the design team as the engine-room for stoking business growth, and elevating designers as the saviours who can drag your business into modernity.

Yet talking to both project stakeholders and designers, I sense there is often a mismatch between how the two groups view design and how to nurture and grow it as a core business function. Is scaling design about becoming bigger, better, faster, cheaper? How can you increase capacity alongside capability? Is it possible to deliver quantity with quality?

When scaling design, the people involved in the process are at the heart of successful change and adoption. Get the teams across the organisation aligned with a shared vision and you are well on your way to success.

Here are some of the common myths and misconceptions I hear from both design teams and non-design business managers. I’d like to suggest some ways for each group to start speaking the same language. After all, things appear different depending on which end of the telescope you look through.

Myths and misconceptions of scaling design

Designer: I don’t work here to be a design robot.

To designers, systems and processes can often sound as if they herald a move towards creating a factory-line churning out components at the expense of individual creativity. Designers need time to do their best work. The aim of systematising design is to help free up this time. But if you then end up just doing more of the business-as-usual type of work, you’ve missed the greatest opportunity you can get from scaling design. Design systems and production processes aim to take the pain away from the routine stuff in order to free up the time for investigating future possibilities.

Manager: Why does everything take so long? All I need is a simple web page!

There is often a shared pain felt between the person requesting the work and the person trying to deliver it. Maybe we start with the wrong question when we ask ‘why does it take so long?’ Instead ask ‘how can we reduce the effort required next time we need to do this?’ Make it a challenge for the design team to solve.

As design scales, and patterns and processes tessellate, it’s time to see where you can save time. Of course, there’s an irony here that to save some time you need to spend some time.

The more successful examples of operationalising design have a few key factors in common. These include shared ownership of the system (don’t impose it on the design team), time set aside for ongoing maintenance, and an expectation of iteration as patterns change and new practices emerge. Think of design ops as a community garden that needs many people to shape and tend to it through the seasons.

Designer: Rules and restrictions are okay for others in less creative roles but they don’t work for designers.

Why do designers bristle at the mention of having rules imposed on their practice? I’ve always found this odd as the world of design is full of guidance covering everything from grids, typography choices, colour theory to gestalt principles, animation and beyond. Brand guidelines are one of the first things designers ask for when starting to work with a new organisation.

I think one of the secrets for adoption is to move from ‘rules’, which feels draconian and inflexible, to framing a design system as a set of patterns which are emergent and open to change. The litmus test is that the design team feel the ‘rules’ provide useful constraints that encourage creativity rather than crush it.

Manager: Can’t we just scale design by hiring another dozen designers?

It’s not as easy as just turning on the design tap and letting the creative outputs flow. Currently, there’s a shortage of digital design talent which means, as an employer, you need to have something exciting to entice potential colleagues. The chance to do meaningful impactful work, opportunities to learn, and space to try new ideas are often key considerations for designers – above mere remuneration.

Because finding designers is hard, make sure you have an active plan for retaining staff. Alongside – or as an alternative – to increasing the headcount make sure you develop your existing talent. Think about how you can increase design capacity by improving the capability of your current team. This may include opportunities for training, sharing ideas and coaching.

Designer: When you say scaling design, why do I think you really mean producing more in less time?

There’s often a misconception from many non-designers that great design can be done quicker. All that time sketching on paper and standing around whiteboards looks more like fun than ‘proper work’. Designers exacerbate this misunderstanding with speed-infused talk about the need to do rapid prototyping or to unlock ideas with a one-week design sprint.

The truth is that great design work doesn’t just happen. Forming, testing, iterating and polishing great ideas takes time to get right, with inevitable moments of going wrong along the way. Scaling design shouldn’t be about producing more of the same. It’s not a race to clear the backlog. True business value comes from focussing on design quality, with quantity as the happy byproduct rather than the intention.

Scaling design should allow you the time to polish the components you need to repeat. Putting them in a pattern library now saves you time with every reuse. However, get the initial quality wrong and every time you deploy the pattern, it will remove value from your digital products. Polish then scale; don’t scale and then try to polish.

Manager: Why should design be excluded from proving its worth to the business?

Just because it’s sometimes hard to quantify the impact of user experience and design doesn’t mean you can bury your head in the sand to avoid the topic. Projects and programmes of work are initiated from business cases, and these need to provide the decision-makers with projected costs and benefits.

Managers and designers need to work together to find ways to evaluate the impact of design in terms that make sense for the business. Stop obsessing about the performance of the UI and start measuring what adds value to the business. A/B testing has its place, but don’t fall into the trap of counting what’s easiest to measure.

To get more savvy about measuring design, never start a piece of work without knowing how you’ll measure it, when you’ll measure it, and how far you need to move the needle.

Designer: Why do you never ask me what design can offer the organisation?

Many designers hold a frustration that they sit at the end of the pipeline and are handed solutions to make pretty. Designers by their nature are inventive problem solvers. If you’re not including them at the framing, investigation and shaping stages of a project then you’re missing a trick.

One way to rapidly and cost-effectively scale design across an organisation is to introduce design-thinking techniques to non-designers. The good news is that you may already have the perfect people in place to introduce design thinking as part of your business practice.

Manager: Why don’t you ever talk about design in ways I can understand?

As designers, if we want to become critical to business then we need to talk in terms non-designers can understand. Geek out less over grids, typography and interaction patterns. Instead talk more about how you’ve rigorously identified and elegantly addressed customer needs. You need a story to tell and the best stories are the ones the audience want to share.

A common goal needs a shared vision

If, as a business leader, you want to scale design, you’ll need to address the fears of your design team. If, as a designer, you want to grow design, you’ll have to demonstrate the value and impact it brings.

Even with the shared goal of growing design, the starting point is to get a shared understanding and empathy for one another’s concerns and motivations. People create the culture. People create the process. So to successfully scale design, start with your people.


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

]]>
Choosing tools for scaling design https://clearleft.com/posts/choosing-tools-for-scaling-design Fri, 11 May 2018 09:23:27 +0000 https://clearleft.com/posts/choosing-tools-for-scaling-design Tools and processes are intertwined. A company or a department or an individual has a way of doing things—that’s the process. They also have software to carry out the process—those are the tools.

Ideally, they should be loosely coupled. You should be able to change your tools without necessarily changing your process. So swapping out, say, one framework or library for another shouldn’t involve fundamentally changing the way you work. Likewise, trying a new way of working shouldn’t require you to use unfamiliar tools.

When it comes to scaling design within organisations, the challenges are almost always around switching processes (well, really it’s about trying to change culture, but that starts with changing processes—any sufficiently advanced process is indistinguishable from culture). All too often, though, I see people getting hung up on the tools.

We need to get more efficient in how we deliver designs …so let’s switch over to this particular design tool.

We should have a design system …so let’s get everyone using this particular JavaScript framework.

I understand this desire to shortcut the work of figuring out processes and jump straight to production solutions. For one thing, it allows you to create an easy list of requirements when it comes to recruiting talent: “Join our company—you must demonstrate experience and proficiency in this tool or that library.”

But when tools and processes become tightly coupled like this, there’s a real danger of stagnation. If a process can be defined as “the way we do things around here”, that’s not something you want to tie to any particular tool or technology. Otherwise, before you know it, you’re in the frustrating situation of using outdated tools, but you can’t swap them out for newer or better-suited technologies without disrupting everyone’s work.

This is technical debt (although it applies just as much to design). You’re paying a penalty in the present because of a decision that somebody made in the past. The problem isn’t so much with the decision itself, but with the longevity of its effects.

I think it’s important to remember what a tool is: it’s a piece of technology that enables you to work faster or better. You should enjoy using your tools, but you shouldn’t be utterly dependent on any particular one. Otherwise, the tail starts wagging the dog—you are now in service to the tool, instead of the other way around.

Treat your tools like cattle, not pets. Don’t get too attached to any one technology to the detriment of missing out on others.

Mind you, if you constantly tried every single new tool or technology out there, you’d never settle on anything—I’m pretty sure that three new JavaScript frameworks have been released since you started reading this paragraph.

The tools you choose at any particular time should be suited to what you’re trying to accomplish at that time. In other words, you’ve got to figure out what you’re trying to accomplish first (the vision), then figure out how you’re going to accomplish it (the process), and only then figure out which tools are the best fit. If you jump straight to choosing tools, you could end up trying to tighten a screw with a hammer.

Alas, I’ve seen plenty of consultants who conflate strategy with tooling. They’re brought in to solve process problems and, surprise, surprise, the solution always seems to involve purchasing the software that their company sells. I’ve been guilty of this myself: I see an organisation struggling to systemise their design patterns, and I think “Oh, they should use Fractal!” …but that’s jumping the gun. They might be better served with something simpler, or something more complex (I mean, Fractal is very, very flexible but it’s still just one option—there are plenty of other pattern library tools out there).

Once you separate out the tools from the process, there’s an added benefit. Making the right technology choice is no longer a life-or-death decision. You can suck it and see. Try out the technology and see if it works. If it’s working, great! Carry on using it. If it’s not working, that’s okay too. Try something different.

I realise I’m oversimplifying things, but I honestly believe that the real challenge is not choosing the right tools, but figuring out the right process for your team.

This was originally published on my own site.

]]>
Process and culture https://clearleft.com/posts/process-and-culture-1 Thu, 10 May 2018 08:13:21 +0000 https://clearleft.com/posts/process-and-culture-1 Cameron has a bone to pick. Why, oh, why, he wonders, are we so quick to create processes when what we really need is a good strong culture?

Strong culture = less process

To stop people breaking stuff: make a process for it. Want to make people act responsibly: make a process for it. Tired of telling people about something? Make a process for it.

For any single scenario you can name it’ll be easier to create a process for it than build a culture that handles it automatically. But each process is a tiny cut away from the freedom that you want your team to enjoy.

I take his point, but I also think that some processes are not only inevitable, but downright positive. There should be a process for handling payroll. There should be a process for handling promotions. Leaving that to culture might sound nice and nimble, but it could also lead to unintentional bias and unfairness.

But let’s leave those kind of operational processes aside and focus on process and culture when it comes to design and engineering. Cameron’s point is well taken here. Surely you want people to just know the way things are done? Surely you want people to just get on with doing the work without putting hurdles in their way?

On the face of it, yes. If you’re trying to scale design at your organisation, then every extra bit of process is going to slow down your progress.

But what if speed isn’t the most important metric of success when it comes to scaling design? You’ve got to make sure you’re scaling the right things.

Mark writes:

This is a post in defence of process. Yes, I know what you’re thinking: ‘urgh, process is a thing put in place to make up for mediocre teams’; or ‘prioritise discussion over documentation’; or ‘I get enough red tape in other parts of my life’.

The example he gives is undeniably a process that will slow things down …deliberately.

Whenever someone asks me to do something that I think seems ill-conceived in some way, I ask them to write it down. That’s it. Because writing is high effort. Making sentences is the easy bit, it’s the thinking I want them to do. By considering their request it slows them down. Maybe 30% of the time or something, they come back and say ‘oh, that thing I asked you to do, I’ve had a think and it’s fine, we don’t need to do it’.

I’ve seen this same tactic employed in standards bodies. Somebody bursts into a group and says “I’ve got a great idea—we should make this a thing!” The response, no matter what the idea is, is to say “Document use-cases.” It’s a stumbling block, and also a bit of a test—if they do come back with use-cases, the idea can be taken seriously; the initial enthusiasm needs to be backed up with hard graft.

(On a personal level, I sometimes use a little trick when it comes to email. If someone sends me a short email that would require a long response from me, I’ll quickly fire back a clarifying question: “Quick question: did you mean X or Y?” Now the ball is back in their court. If they respond swiftly with an answer to my question, then they’ve demonstrated their commitment and I honour their initial request.)

Anyway, it sounds like Cameron is saying that process is bad, and Mark is saying process can be good. Cody Cowan from Postlight thinks they’re both right:

To put it bluntly: people, not process, are the problem.

Even so, he acknowledges Cameron’s concern:

One of the biggest fears that people have about process is that something new is going to disrupt their work, only to be replaced by yet another rule or technique.

I think we can all agree that pointlessly cumbersome processes are bad. The disagreement is about whether all processes are inherently bad, or whether some processes are not only necessary, but sometimes even beneficial.

When Cameron talks about the importance of company culture, he knows whereof he speaks. He’s been part of Canva’s journey from a handful of people to hundreds of people. They’ve managed to scale their (excellent) culture along the way. That’s quite an achievement—scaling culture is really, really challenging. Scaling design is hard. Scaling culture is even harder.

But you know what’s even more challenging than scaling culture? Changing culture.

What if your company didn’t start with a great culture to begin with? What if you’re not Canva? What if you’re not AirBnB? What are your options then?

You can’t create a time travel machine to go back to the founding of the company and ensure a good culture from the outset.

You can’t shut down your existing company and create a new company from scratch, this time with a better culture.

You’ve got to work with what you’ve got. That doesn’t mean you can’t change your company culture, but it’s not going to be easy. Culture is pretty far down the stack of pace layers—it’s slow to change. But you can influence culture by changing something that’s less slow to change. I would argue the perfect medium for this is …process.

Once you know what values you’re trying to embed into your culture, create processes that amplify and reward those values. I totally understand the worry that these processes will reduce autonomy and freedom, but I think that only applies if the company already has a strong culture of autonomy and freedom. If you’re trying to create a culture of autonomy and freedom, then—as counter-intuitive as it may seem—you can start by putting processes in place.

Then, over time, those processes can seep into the day-to-day understanding of how things are done. Process dissolves into culture. It’s a long game to play, but as Cameron points out, that’s the nature of culture change:

Where culture pays off is in the long run. It’s hard work: defining the culture, hiring for the culture and communicating the culture again, and again, and again. But if you want to make a company where people are empowered, passionate, and champions of your organisation then it’s the only path forward.

This was originally posted on my own site.

]]>
A fireside chat about scaling design https://clearleft.com/posts/a-fireside-chat-about-scaling-design Wed, 09 May 2018 14:01:05 +0000 https://clearleft.com/posts/a-fireside-chat-about-scaling-design Design isn’t a cost. Design is an investment. It’s also an opportunity.

Tackling design ops in order to scale design at your company isn’t about doing more faster. It’s about amplifying the return on investment that design gives you, making you more innovative, adaptable and competitive.

But a word of warning. Getting your ducks in a row in order to grow or scale the design capability at your company should be done with prudence as well as ambition. Because if you scale design in a way that doesn’t truly serve your business, you’ll do more damage in the long run.

Recently, some of us Clearlefties came together to collaborate on a mini content series on the subject. So whether you’re tackling issues around culture, people, process or product, we hope what follows will help you get to grips with the challenge.

First up, Jeremy hosted a Fireside Chat* with James Bates, James Box, Chris, Andy T and Rowena. Something of a starter for ten, we covered a range of related topics including design ops, design sprints, the opportunities, risks and pitfalls for businesses, success metrics, the trouble with quantifying design, and the challenge of finding and retaining great design talent.

Have a listen: 


*Disclaimer - this off-the-cuff recording includes the odd bit of background noise for added character… Sirens, door bells and the sound of Sharpies on sticky notes to make you feel right at home.

Follow us on Twitter to join the conversation and share your take on the topic with the hashtag #scalingdesign

]]>
The Sign-off Smoke Screen https://clearleft.com/posts/the-sign-off-smoke-screen Tue, 08 May 2018 08:00:00 +0000 https://clearleft.com/posts/the-sign-off-smoke-screen ​As a designer, the concept of “sign-off” annoys me. It comes from the age of print media, where somebody had to take final responsibility for the design and copy before it went to press.

This makes perfect sense. After all, it may cost tens of thousands of pounds to do a second print run, if you’re lucky enough to notice the error in the first place.

The concept of sign-off has resulted in a rather unfortunate culture, which sees design as an attempt to please a single important stakeholder; to get a project close enough to their original vision to gain their consent. This sets up a false expectation that there is one central source of truth, and the designer’s role is simply to chip away at the marble until they unveil the object the client had in their mind all along.

Digital technology and the rise of agile has put pay to this. Design and product development is no longer about navigating a project through a series of sign-off gates. It has become a mutual journey of discovery, where both designer and client work together to advance the project through a series of iterations, not to some pre-imagined goal, but as an attempt to constantly stress-test the idea in order to make it better. Or as Walt Disney used to say, “always be plussing”.

Designers should never ask for “sign-off”. It results in satisficing behaviour. It encourages the designer to do just enough to please the client, and no more.  Instead, designers need to stop asking for “sign-off” and instead ask for “input” or “feedback”. Asking “what can we do to jointly make the project better?”, rather than “provide me with a list of things you need me to change in order to make you happy”.

The request for “sign-off” is often a smoke screen for what the designer really wants to say. “We’re coming to the end of the project, we’re almost out of time, so this—barring a few tweaks—is what we’re going to end up with. I trust you’re OK with that?” Sadly this sentiment is rarely ever expressed. Instead the designer asks for “sign-off”, the client comes back with a litany of changes which there’s no time or budget to make, and everybody ends up frustrated.

This isn’t the client’s fault. This is poor project management. This is a failure to engage the client early enough, a failure to properly explain the agile process deeply enough, a failure to keep the client up-to-date with progress, and a failure to clearly communicate what you actually want from the interaction. The end result should never be a surprise to the client. It should always be the natural and logical conclusion to the ongoing conversation you’ve been having. In this way, projects are never signed-off; they simply come into being.

So “sign-off” is almost never the right thing to ask for. Either you’re asking for suggestions to make the project better, or you’re presenting your intention to progress the project to the next step in the process. I believe “sign-off” has no place in the modern agile process, and should be banned from the digital designer’s lexicon.

]]>
Good griddance https://clearleft.com/posts/good-griddance Thu, 03 May 2018 16:15:31 +0000 https://clearleft.com/posts/good-griddance I’m not great at estimation, but I still try to do it on any project I’m working, even if it’s just for my own benefit. I break down different bits of the work, and ask myself two questions:

  1. How important is this?
  2. How long will it take?

If I were smart, I’d plot the answers on a graph. I start doing the important stuff, beginning with whatever won’t take too long. Then I’ve got a choice: either do the stuff that’s not all that important, but won’t take long—or do the stuff that will take quite a while, but is quite important. Finally, there’s stuff that’s not important and will take quite a while to do. I leave that to the end. If it never ends up getting done, it’s not the end of the world.

I guess it’s not really about estimation; it’s more about prioritisation.

Anyway, I’m working on a fun little project right now—the website for one of Clearleft’s many excellent events. There was one particular part of the design that I had estimated would take quite a while to do, so I didn’t get around to it until today. It was a layout that I figured would take maybe half a day of wrangling CSS.

I used CSS grid and I was done in five minutes. That’s not an exaggeration. It was literally five minutes.

I thought to myself, “Well, I want these elements to be arranged in two rows of three columns, but I want that particular one to always be in the last column of the top row.”

Normally my next step would be to figure out how to translate those wishes into floats and clears, or maybe flexbox. But this time, there was almost no translation. I could more or less write the CSS like I would write English.

I want these elements to be arranged in rows of three columns.

display: grid;
grid-template-columns: 1fr 1fr fr

I want that particular one to always be in the last column of the top row.

grid-row: 1;
grid-column: 3;

That was it. I was done.

I think I may need to recalibrate the estimation part of my brain to account for just how powerful CSS grid is.

This was originally published on my own site.

]]>
Habits of high performing design teams https://clearleft.com/posts/habits-of-high-performing-design-teams Thu, 03 May 2018 09:42:20 +0000 https://clearleft.com/posts/habits-of-high-performing-design-teams As a digital design consultancy, we work highly collaboratively with our clients at their offices. As such, we’re naturally exposed to a wide variety of company cultures and ways of working.

Based on our experience, these are the things the most effective in-house design teams do consistently.

Workshops, not meetings

In our experience, too many businesses are victims of a culture of passive, unproductive and often unnecessary meetings. Inefficient use of time, a lack of ownership and absence of explicit objectives compound ineffective outcomes and lead to ever-increasing scepticism amongst participants. And yet, everyone still turns up for the next one. Apparently, even innovative companies like Tesla have this problem so we’re all in good company.

Today’s established ways of working have typically focused on a ruthless prioritisation of ‘efficiency’ at all costs. Working alone is perceived to be more productive. collaborating with others is seen as slow, wasteful, or even frowned upon. Not always entirely without due suspicion however.

Despite being more connected than ever, today’s workforce ironically seems to have adopted a default stance of reluctance or even inability to naturally collaborate with peers and colleagues. Siloed into narrow specialisms and over-reliant on passive technology channels, such as email and remote messaging services, communication with each other has become stunted. In extreme cases, entire businesses have bred a culture utterly incapable of productive dialogue in order to reach a consensus on decisions.

“Walk out of a meeting or drop off a call as soon as it is obvious you aren’t adding value. It is not rude to leave, it is rude to make someone stay and waste their time.”

- Elon Musk, CEO, Tesla

Whilst collaboration continues to be the ‘du jour’ buzzword of success in today’s dynamic and disruptive business world, there is clearly a long way to go. Are meandering and meaningless meetings going to remain the de facto approach for the foreseeable future? Hopefully not. Very often this is merely a symptom of an acute deficit in facilitation skills within the organisation.

This is an ideal opportunity for a good designer to step into the void, and why all designers need to get more familiar with the skill of leading and shaping meetings, ensuring they become participatory by default. By transforming meetings into active and decisive workshops where collaboratively resolving a problem or moving a solution forward is made an explicit purpose of each and every gathering, the organisation will see disproportionate benefits to these otherwise wasteful and costly uses of everyone’s time.

Clearleft Workshop
Clearleft workshop

Collaborative co-design

The days of designers handing down solutions from their ivory tower for others to implement are well and truly over. For design to succeed and thrive in an environment of rapid iteration and intense measurability, it needs to involve non-designers intensively. Not just in spirit, but in practice - methodically and repeatedly. Workshop collaboration is not enough.

Activities such as usability testing are nowadays expected as a given part of the user-centered design process. It’s also become an accepted truth that any credible design method will incorporate workshop activities to some degree: typically to brainstorm ideas or perhaps gather or prioritise features with business stakeholders as part of a cross-disciplinary team. Unfortunately these are still very often tokenistic gestures in order to tick the box of what is claimed to be ‘standard design practice’.

Although designers may have the expertise to explore ideas and bring them to life, it’s all too easy to fall back on the tired old stereotype of the creative genius - mysteriously ploughing away at their own esoteric furrow in solitude until the eureka moment hits. This process crutch is a familiar one: the designer will have all the answers if we just give them enough time and space to solve the problem.

6104

True co-design involves stakeholders, and ideally customers or end-users, actively working on design problems alongside designers day-in, day-out, no excuses. Today’s systems and cross-channel customer experiences are too complex for any one individual to be the fountain of all knowledge on a particular subject matter or touchpoint. Bringing in a wide range of expertise to become active and persistent members of a product or project team, whilst also extending collaborative activities beyond the workshop, is what’s required to truly deliver standout success in the market.

On-site collaboration at Clearleft HQ

Ritualised design critique

Vital to any design team, critique provides designers a framework for evaluating their work, helping speed up the decision-making process and improve the quality of solutions.

Yet critique isn’t always something that happens as routinely as it should, especially within inexperienced design teams. Designers may occasionally receive sporadic feedback on their work by design peers or business colleagues, but very rarely critique. It’s a subtle, but important difference.

Add to this the common excuse of “too busy” and you have the conditions for a perfect storm of ineffectiveness: a workload peppered with ‘business as usual’ design outputs and crowded calendars starts to chip away at the ideal of setting aside dedicated time for frequent and necessary community gatherings. Meetings are not seen as work (because, oh guess what, they’re not productive enough), thus discouraged from ever being accepted as a standard part of the weekly workload. These daily compromises reinforce a vicious circle which dilutes the effectiveness of coming together as a disciplinary team.

However by establishing a few simple routines and ensuring they’re adhered to, critique can be a disproportionately effective use of everyone’s precious time. Good critique helps to:

  1. Identify problems with solutions early in the process, when they’re still cheap and easy to rectify.
  2. Provide a diverse range of input and expertise that may offer routes to alternative solutions.
  3. Improve a designers’ critical thinking & communication skills.
  4. Provide support and the opportunity of knowledge sharing amongst your organisations design community.

As a general rule weekly design community sessions, acting primarily as a safe space for each of the design team to share work-in-progress and seek constructive feedback from their colleagues, work best. This protected time is also invaluable to share learnings, techniques and tools with disciplinary peers.

It’s worth remembering that critique is vital from non-designers also. Regular drop-in sessions for business stakeholders outside of the immediate design and product teams can be invaluable in bringing in external input and perspective, whilst also showcasing what the design team are doing. Great design teams don’t isolate themselves.

James Bates, Creative Director, Clearleft

Finally, in addition to any established routines, it’s easy to neglect the more ad-hoc, conversational critique that should occur naturally when working amongst other designers and peers. This ongoing dialogue between individuals should be encouraged as much as possible, whether by grabbing someone nearby or making use of your #design Slack channel (or equivalent).

Guerrilla usability testing

Even with minimal time or budget, usability testing offers an vital opportunity to test design solutions, validating assumptions about what customers and end-users will find valuable about your product or service before they become costly mistakes. As anyone who has conducted such activities will testify, 95% of the time usability testing will throw up previously unknown blind-spots and shortcomings worthy of addressing prior to launch, sidestepping any avoidable slip-ups.

But sophisticated and expensive lab testing environments with one-way mirrors, multiple video feeds or eye-tracking equipment can in many cases be luxuries to get to the necessary insights you need to design better products.

Today, every designer carries around a portable, fast and low-cost usability lab of their own: their Macbook.

Luke Darbyshire, Product Designer

Whilst there are challenges around expertise, impartiality and how to interpret or ignore feedback from participants who aren’t a perfect match of the behavioural characteristics of the target audience, the advantages of a bold and proactive design team unafraid to get their hands dirty in the wild greatly outweigh any potential shortcomings.

There are four crucial benefits to ad-hoc and improvised testing:

  1. The small scale and insignificant cost empowers the design team to test things themselves without any lengthy funding or approval process.
  2. Test facilitation done well can steel a designers objectivity, with direct and unavoidable first hand experience, helping them assess and respond to the effectiveness of their solutions in the future.
  3. Involving non-designers more directly in testing, synthesis and insights sharing builds greater empathy for the user across the organisation.
  4. Improved awareness and confidence of the practicalities of testing encourages a more natural culture of learning, ultimately helping to pave the way for paid testing on a more formal basis in the future.

6118

The early stages of designing a product provide the biggest opportunities to conduct guerrilla testing. When used between other more formally organised and professionally facilitated tests, and in combination with intensive collaboration, they help to accelerate the iteration cycle of any prototype and flush out potential issues well in advance of development.

If you’re looking to turbo charge your design team’s ability to workshop, collaborate, critique or user test, drop us a line and find out how we can help.

This article was a collaboration between Andy Thornton, James Bates, and Luke Darbyshire.

]]>
How Context is Bridging the Gap Between UX and Service Design https://clearleft.com/posts/how-context-is-bridging-the-gap-between-ux-and-service-design Wed, 02 May 2018 09:17:00 +0000 https://clearleft.com/posts/how-context-is-bridging-the-gap-between-ux-and-service-design We’re all familiar with the story by now.

Back in 1993, Don Norman founded a new team at Apple to create a unified experience for their software and hardware; from buying it at the store, unboxing it, plugging it in, and using it for the first time. The team was made up of multidisciplinary designers who focussed on the entire user journey, rather than a single touchpoint, through the lens of user-centered design. He called this team User Experience Architects.

What Don Norman and his team did was take a step back from the products Apple was designing to consider their context of use. Or as Architect Eliel Saarinen famously said…

Always design a thing by considering it in its next larger context - a chair in a room, a room in a house, a house in an environment, an environment in a city plan.

Eliel Saarinen

Jump forward to the turn of the millennium and agencies like Adaptive Path in the US and (a few years later) Clearleft in the UK, started to emerge as the first of a new wave of UX agencies, intent on pursuing this holistic view of design.

Back in the noughties, in-store experiences were still largely driven by advertising agencies and marketing departments. Digital technology was on the rise, but there wasn’t the proliferation of devices we have today. The devices we did have were largely designed in-house. The bulk of the work gravitated towards the Web, which was only just starting to hit the mainstream.

At the time, websites were primarily information sources, accessed through a home or work desktop computer. The resulting user journeys were fairly short, starting at a search engine and ending once the user’s information needs were hopefully met. In the early days this limited scope was fortunate. We were still inventing the interaction models and dealing with an immature technology stack.

New entrants to the field could have been excused for thinking UX designers simply designed screens, because that’s what the bulk of the work looked like. Things were about to get a lot more interesting.

As the technology matured, the context broadened, as did the resulting user journeys. The Web evolved from a simple information source to a platform supporting all manner of digital services. Early ecommerce sites expanded their user journeys to include payment, shipping, returns, and customer service. New smartphones allowed the sharing of photos, making mobile payments, and the use of location data. The rise of native apps and web apps only complicated user journeys further.

Take something as simple as travel. It was now possible to buy a flight, check-in en route to the airport, and download your boarding pass, all from the comfort of your phone. It was no longer good enough for UX designers to focus solely on the app they were designing. Instead they needed to understand—and manage—the entire journey, including what happened at the airport.

Take another example like car sharing services. The old model required making a booking, printing out your receipt, taking it to a physical depot with your driving licence and credit card, filling in a bunch of paperwork, having your details checked, getting the keys and checking the car for damage, all before you could go on your way. The rise of smartphones and NFC chips completely changed that. Now you could make the booking on your smartphone app, find the car parked on the street, unlock it with your NFC card or device, punch in a code and be driving in under 30 seconds.

As digitally-driven products and services began to grow in complexity, UX teams were naturally drawn into thinking about this broader context. For those who associated UX with screen design, this may have felt like a slightly unnatural fit. For those who understood the roots of UX, the market and ecosystem had finally caught up with the original promise—to design the entire user journey centered around a digital product or service.

I use the term “centered around” very deliberately here. After all, there are other design professions where the context of use is equally important. As the Saarinen quote indicates, architects need to understand how their buildings fit into the broader context of the city. Industrial designers—whether they are designing a chair or a laptop—need to understand how their products fit into the users’ lives.

The laptop example is an interesting one, as it brings us back to Apple. When designing a new laptop, it would be natural to have an industrial designer lead the process—after all, their skills are in the physical forming of objects. But it also makes sense for the UX team to be involved in the conversation, as they will almost certainly be designing many of the services delivered through the product. They will also be thinking about the first-use experience, and how the purchase, unboxing process, and boot-up sequence influences that. There will always be natural overlaps between one design practice and another.

This brings us onto the subject of Service Design. As you’re no doubt aware, the field of Service Design has its roots in the delivery of public services like transportation, healthcare and education. As services have become increasingly digital, it’s common to see Service Designers involved in the design of things like car sharing services, or the airport check-in experience; the very examples I used to illustrate the growing influence of User Experience Design. What’s going on here?

The answer is actually relatively simple. Service Designers generally approach digital as one of a number of interconnected touch points. They will usually figure out how all these touch-points work together as a cohesive ecosystem, before handing the design of the specific touch points over to experts.

UX Designers usually approach the problem from the other direction. They start with the core digital experience before exploring the connective tissue that joins their touch-points together. Service Designers tend to have a broader but shallower focus, while UX designers go narrower but deeper.

UX Design and Service Design comparison - by Sebastien Chung.

For service ecosystems that are primarily digital in nature—essentially where the bulk of interactions take place on or around the digital product or service—you’ll find that a good UX team will be able to bring everything together. Companies like AirBnB, ZipCar and Monzo fit nicely into this category.

For services where the digital experience is just one of a number of touchpoints, having a Service Designer orchestrate those touchpoints makes a lot of sense. An example of this could be a physical store offering click-and-collect facilities, phone support, mail-order repairs, and an in-store returns policy. In this situation the digital service is a much smaller part of the jigsaw. It’s still important for the UX team to understand and feed into the wider context, but writing phone scripts or bodystorming the returns experience is probably a step too far.

It’s worth noting that the gap between these two states is fairly fuzzy. It’s also worth noting that as services grow and mature, they have the tendency to accrete touchpoints. So while services like Monzo are currently driven by UX Designers and Digital Product Designers, you could imagine a time when they have a range of analog and digital touch-points that need greater coordination. Similarly, companies like AirBnB and ZipCar are getting to the size and scale where having a small Service Design team has become valuable.

Rather unsurprisingly, many of the people joining those Service Design teams are coming from the world of User Experience Design, demonstrating that the link between the two disciplines is much closer than people think. In fact, as Service Designers get more Digital and UX Designers get more service oriented, we’ve started to see organisations adopt the title Digital Service Design, to denote the overlap between the two.

For related reading, take a look at Seb Chung’s two-parter on UX and Service Design:

]]>
Workshops https://clearleft.com/posts/workshops Mon, 23 Apr 2018 15:55:47 +0000 https://clearleft.com/posts/workshops There’s a veritable smörgåsbord of great workshops on the horizon…

Clearleft presents a workshop with Jan Chipchase on field research in London on May 29th, and again on May 30th. The first day is sold out, but there are still tickets available for the second workshop (tickets are £654). If you’ve read Jan’s beautiful Field Study Handbook, then you’ll know what a great opportunity it is to spend a day in his company. But don’t dilly-dally—that second day is likely to sell out too.

This event is for product teams, designers, researchers, insights teams, in agencies, in-house, local and central government. People who are curious about human interaction, and their place in the world.

I’m really excited that Sarah and Val are finally bringing their web animation workshop to Brighton (I’ve been not-so-subtly suggesting that they do this for a while now). It’s a two day workshop on July 9th and 10th. There are still some tickets available, but probably not for much longer (tickets are £639). The workshop is happening at 68 Middle Street, the home of Clearleft.

This workshop will get you up and running with web animation in less time than it would take to read all the tutorials you have bookmarked. Over two days, you’ll go from beginner or novice web animator to having expert level knowledge of the current web animation landscape. You’ll get an in-depth look at animating with CSS, JavaScript, and SVG through hands-on exercises and learn the most efficient workflows for each.

A bit before that, though, there’s a one-off workshop on responsive web typography from Rich on Thursday, June 29th, also at 68 Middle Street. You can expect the same kind of brilliance that he demonstrated in his insta-classic Web Typography book, but delivered by the man himself.

You will learn how to combine centuries-old craft with cutting edge technology, including variable fonts, to design and develop for screens of all shapes and sizes, and provide the best reading experiences for your modern readers.

Whether you’re a designer or a developer, just starting out or seasoned pro, there will be plenty in this workshop to get your teeth stuck into.

Tickets are just £435, and best of all, that includes a ticket to the Ampersand conference the next day (standalone conference tickets are £235 so the workshop/conference combo is a real bargain). This year’s Ampersand is shaping up to be an unmissable event (isn’t it always?), so the workshop is like an added bonus.

See you there!

This was originally published on my own site.

]]>
Inside CSS https://clearleft.com/posts/inside-css Fri, 20 Apr 2018 08:33:00 +0000 https://clearleft.com/posts/inside-css Last week I was privileged to be invited into the heart of where the World Wide Web is defined – I was to be an observer in the latest CSS Working Group’s face-to-face meeting.

Our venue was a 100 year old former brewery; a tastefully converted five-story brick building on the eastern side of Berlin. Inside I was greeted by an early breakfast of coffee, fruit salad and pastries, and a group of 35 men and women from around the world, smiling and clearly happy to see each other again. Some of these folks I knew already: as friends, online acquaintances or by reputation. Others I would come to know over the next two days. I was an outsider to the group, but made to feel welcome as we settled down behind our laptops, arranged in a large horseshoe in the bright top floor meeting room.

The CSS Working Group (CSS WG) is the team of independent experts and employees from W3C member organisations (including Apple, Microsoft and Google) who write and maintain the standards for all the CSS we use on a daily basis. Almost everyone in the group is a volunteer, contributing in their spare time, or as a part of their day job with the blessing of their employers.

Six continents were represented by the folks in the room. This means that much of the CSS WG’s work is done remotely, but three or four times a year they get together to resolve particularly thorny, contentious or impactful issues face to face. Resolutions that will potentially affect us, as web designers, for years to come. It was fascinating to see how those decisions were arrived at, and to be able to make a modest contribution to some of them along the way (as anyone can do actually – more on that later).

Photo: Rossen Atanassov

I seated myself next to Rachel Andrew, an Invited Expert of CSS Grid fame. The first piece of advice Rachel gave me was to open up the IRC channel which would be used to share links and continually minute proceedings (thanks to the indefatigable Dael Jackson). If you’re unaware of IRC you can think of it as a lightweight precursor to WhatsApp groups or Slack channels, predating the Web.

The first activity performed by the group was the most efficient round of introductions I had ever encountered. With each person announcing themselves in the room and on IRC as “Rossen Atanassov, Microsoft”, “Richard Rutter, observer, Clearleft”, etc., we got through 35 people in less than 2 minutes.

The agenda for the three days had already been agreed and shared through the CSSWG wiki, so I was aware of what was to come. Almost all the issues addressed were opened in Github, with an hour or more allocated to a particular CSS module or other area of the overall specification. Each issue required a particular action or answer, such as “How do we allow for paragraph-level line breaking?” and “Should we implement or unship word-break:break-word?” and even “Who defines box-sizing?” (yes the box model ambiguity still rumbles on.)

The room was refreshingly quiet and respectful, with just one person speaking at a time (mostly). There were a few key voices who were ever-present in the discussions, but for the most part each person got involved when their area was raised. Otherwise folks were silent, keeping on top of things through IRC, with half an ear on proceedings, seemingly getting on with other business. Just occasionally the restrained voices would get raised, ears would prick up and heads would lift above laptops:

— There’s no need to make it personal, I'm making a forward looking statement where if we see this in the future it behooves us to pay attention.
— Right let’s just move on.
— We’ll resolve to add an issue and a fix for 2.1 to disambiguate width for inner and outer width. Any objections?

Just as in that snippet of conversation, all discussion worked towards a solution or a proposal. These were phrased very specifically as ‘resolutions’ with each one being opened up for objections and passed if there were none. It was a remarkably efficient way to gain consensus, almost certainly helped by much of the hard thinking being done prior to the meeting. In the spirit of openness – a founding principle of the Web, the resolution and the relevant part of the IRC log would then be posted to the originating Github issue.

The consensus building is vital. Representatives from all the major browsers were in the room, collaborating closely by proposing ideas and sharing implementations. But most fundamentally they were agreeing together what should go in the specifications, because what goes in the specs is what gets built and ends up in the hands of users.

A day and half of proposals, discussions and resolutions later, my turn came. It was time to resolve a whole afternoon’s worth of font and text issues. I chimed in with a few contributions and got to see first hand why some of my variable font tutorials would now need updating, as it was resolved to modify the CSS Fonts Module specification in a number of ways, and hence to change some current browser implementations (definitely for the better, so I’ve no complaints on that front).

All in all it was fascinating to see inside the CSS Working Group, and I’m extremely grateful to Elika for inviting me. We all have a lot to thank this group of smart, extremely hard working folk. One of the best ways any of us can do so is to contribute to the discussions on the W3C’s CSS WG Github issues. It was clear to me that all comments from web designers and developers (“authors” in W3C parlance) are welcome and form part of the debate leading to better CSS standards, so quietly and respectfully do join in the conversation.

* * *

For more CSS, typography and variable fonts fun join me and a fantastic line-up of design experts from around the world at Ampersand, the web typography conference, now in its fifth year.

]]>
Announcing UX London Office Hours https://clearleft.com/posts/announcing-ux-london-office-hours Tue, 17 Apr 2018 10:46:00 +0000 https://clearleft.com/posts/announcing-ux-london-office-hours Starting this June, I’m going to be running a UX focussed “Office Hours” drop-in session on the last Thursday of the month in London.

If you haven’t come across the concept of “Office Hours” before, it’s a practice that’s been popularised by venture capital firms, but has since spread to other areas of the industry.

How it works

I’ll block out my day for a series of 45 minute meetings, which you’ll be able to book in advance. During these sessions, we can discuss anything UX related that’s on your mind. Maybe you’re a startup founder looking for feedback on a recent design. Maybe you’re a design leader with a tricky internal challenge. Or maybe you’re looking for your next move in the industry and would appreciate some help with your portfolio. As long at it’s UX related, pretty much anything is on the table.

I’ve no idea how this is going to work, so it’s a bit of an experiment. I love meeting new folk and helping people out, so I’m keen to give it a try.

Get in touch to register your interest

Until I get a proper mechanism in place for managing bookings (suggestions are welcome), why don’t you drop me a line if you’d like my help, and we can get something booked in.

]]>
Beat the clock with Time Well Spent https://clearleft.com/posts/beat-the-clock-with-time-well-spent Fri, 13 Apr 2018 08:37:15 +0000 https://clearleft.com/posts/beat-the-clock-with-time-well-spent Every digital project is essentially a battle with time. It is simultaneously our most precious and finite resource, and our nemesis.

This fight against time is ongoing, and one where you need to find ways to not just win the odd battle but also the war.

The problem with time

This is true for in-house design teams as well as agencies. Sadly, time more often than not wins. This results in projects ending with some of the most inventive, interesting and potentially valuable ideas left languishing in the backlog.

The trouble with time is that we have become sophisticated at counting it, but maybe mis-directed in how we measure it.

We use Kanban boards like Trello and PivitolTracker to show when we will do something. We use time reporting tools such as 10,000ft Plans and Harvest to capture what we have done with our time. However, we don’t yet seem to have great tools to help answer the more vital and interesting question: Was our time well spent?

In wanting to make more of time - this most precious and finite of resources, I think we should move away from only asking ‘when’ and ‘what’ and include into the mix ‘why’.

What to do about it

I’ve been pondering ways to ensure the projects I work on stand a better chance of delivering that delightful or novel feature that will make it standout. The type of feature that materialises when time is protected to innovate and go the extra mile.

To explore if my time was being used in a valuable way, I recently created a canvas to do two things: help predict where time should be best spent, and help evaluate if it could had been used more effectively.

The simplicity of the framework belies its strength. I’ve used it on digital projects as well as in organising my weekends, and even planning what to do on a City break.

I now find that I have time to get round to more of the fun, inventive and unusual bits during projects, and on a Sunday evening I’m less likely to wish for another day of the weekend to be able to indulge a passion.

If you want to give it a go you can download a copy of the canvas. Feel free to share it and tag myself and Clearleft when you do – it’s under a Creative Commons licence.

Diagram of Time Well Spent Canvas
‘Time Well Spent’ created by Chris How

Take some time to make some time

Like many an economic model (after all, time is your most valuable resource), the sections are created from two axis–enjoyable and valuable–which forms four quadrants. Let me introduce each one in turn.

Don’t do - low value and low enjoyment

At the bottom left side is the ‘don’t do’ zone. This is inhabited by unnecessary tasks.

Miserable people do miserable work. There’s no time-rebate at the end of a project. Stop wasting your time on things that don’t make a difference. Challenge whether you really need to do a task. Start to make better use of your time.

Ask yourself and your team what they think sits here and see if you can bin it. You might be surprised how many habitual tasks in a project can be assigned to this quadrant.

Don’t overdo - low value but high enjoyment

This is an interesting and dangerous place. It’s where the tasks that you love doing but deliver low value live.

It’s easy to get distracted by shiny new things. It’s easy to slip into comfortable habits and use well trodden techniques that you find fun. It’s easy to fill your time and think you are working hard.

Beware the time-sinks and shiny distractions that lie in this quadrant. Resist the temptation to over polish your work where it adds little overall value to the project.

Ask yourself if you actually need a beautifully presented usability report, or will a list of observations and actions serve the project better? Do you need to create a presentation with a slidedeck, or can you get better results from spending the time facilitating a discussion instead? Do you need a 600dpi print-ready version of your customer journey map, or will a photo of your scribbles and Post-it® notes move the project forward just as well and quicker?

Need to do - high value but low enjoyment

Let’s move over to the side of the graph concerned with adding greater value. On the bottom right-hand side is the need to do activities. For tasks that fall into this quadrant, focus on finding ways to reframe, speed-up or mechanise them.

Some tasks give you less pleasure but are essential. For these find ways to reduce the time needed, break them up, or share them out.

Ever get the feeling of deja-vu from essentially writing the same usability testing facilitation guide or recruit screener? Save time in the long run by creating a library of successful boilerplate questions. Then, this task becomes reframed as revisiting and restocking your library.

Typing up Post-it® notes from workshops is a drag. Reduce the burden by sharing the work out. Make it more fun (and quicker) by making it a competitive race with your colleagues.

Nearly anything that is boring, repetitive and time-consuming to do can be better achieved by a computer. If you are editing text and page numbers in the contents page of a report or trying to mash together analytics data with output from a content audit, then go ask a colleague with programming skills to write a macro to automate the process.  

Ensure you do - high value and high enjoyment

The final quadrant is the place you want to be spending your time in.

This is the area where losses in time result in cuts being made to your MVP, turning it from a delightful experience into a miserable viable product.

This is where the potential for innovation, delight and meaningful design live. The items in here need space and time to think, create and iterate upon. They are often some of the trickiest challenges, but ones that offer most long-term value. Don’t leave them to the end and run out of time.

If you are using the canvas at the start of a project make sure you have at least one item in this quadrant. Then make time to explore, develop and deliver the idea. If you don’t, there’s a real danger your project will result in a cake with no icing.

How to use the canvas

1. As a team, or individually, write your user stories or tasks on blank playing cards.

2. Shuffle the deck.

3. Put each card in one of the quadrants.

4. Take action to review and re-adjust the time on tasks to get more time for the things that add value and you get pleasure from doing.

5. Repeat whenever you plan your next steps in a project.

Let me know how you get on

Tell me what things the canvas helped you find the time to do that would otherwise remain yet another missed opportunity. I’d love to hear from you. Get in touch via Twitter @chrishow @clearleft.

]]>
Announcing Going Offline from A Book Apart https://clearleft.com/posts/announcing-going-offline-from-a-book-apart Sat, 07 Apr 2018 00:19:10 +0000 https://clearleft.com/posts/announcing-going-offline-from-a-book-apart I decided that I wanted a new mug.

I already have one very nice mug. It was sent to me by A Book Apart because I wrote the book HTML5 For Web Designers back in 2010. If I wanted another nice mug, it was clear what I had to do. I had to write another book.

So I’ve written a book. It’s called Going Offline and it’s available to pre-order now. It will start shipping a few weeks from now.

I think you will enjoy this book. Here’s why…

You have a website or you make websites for other people. You’re comfortable with HTML and CSS, but maybe you’re a bit apprehensive about JavaScript (like me). You keep hearing lots of talk about service workers and progressive web apps. You’re intrigued. But you’re put off by the resources out there. They all assume a certain level of JavaScript knowledge. What you need is a step-by-step guide to help you make your website work offline …a guide that won’t assume you’re already comfortable with code.

Does that sound like you? Then Going Offline is for you.

Thinking about it, a more accurate title for the book would’ve been Service Workers For Web Designers …although even that would assume too much existing knowledge (like, what the heck a service worker is in the first place).

Pre-order Going Offline today and it will be in your hands in just a few weeks.

Alas, I have no idea when my new mug will be ready.

This was originally published on my own site.

]]>
Links from a talk https://clearleft.com/posts/links-from-a-talk Wed, 21 Mar 2018 16:59:45 +0000 https://clearleft.com/posts/links-from-a-talk In two weeks time, I’ll be in Seattle for An Event Apart. I’ll be giving a brand new talk. The title is The Way Of The Web (although perhaps a more accurate title would be The Layers Of The Web).

Here’s the description:

Do you ever get overwhelmed by the ever-changing nature of web design and development? Exhausting, isn’t it? How are you supposed to know which technologies and tools you should invest your time in? Will they stick around or will you just have to relearn everything in another few months? Join Jeremy as he takes a tour of the past, present, and future of working on the web. From the building blocks of HTML, CSS, and JavaScript through to frameworks and libraries right up to the latest and greatest Progressive Web Apps, this talk will examine our collective assumptions with a critical eye. By learning from the past, we can make sensible design decisions today to build the web of tomorrow.

There’s a direct evolution line from my previous talks—Resilence and Evaluating Technology—to this new one. (Spoiler: everything I talk about is in some way related to progressive enhancement …even if I never use the words “progressive” or “enhancement” in the talks.)

I’ve been preparing this new talk for months. It started with a mind map—an A3 sheet of paper with disconnected thoughts, like something from the scene in the crime movie where the enter the layer of the serial killer and find a crazy wall.

Then I set it aside and began procrastinating. But it was the good kind of procrastinating, right? I mean, I had made a start and all those thoughts were now bubbling around in my head.

Eventually I forced myself to put things in some sort of order and started creating slides. That’s the beginning of the horrible process bouncing between thinking “this is pretty good!” and “this is absolute crap!” To be honest, I never actually know if a talk is any good until I give it in front of an audience (practice runs at work are great for getting feedback but they’re not the same as doing the talk for real).

Anyway, I think the talk is ready to roll. If you see me giving this talk and you’re interested in diving deeper into the topics raised, I’ve gathered together some of sources I used.

Further Reading

Related posts on adactio.com

Progressive Web Apps

Books

Films

This was originally posted on my own site.

]]>
A workshop on building for resilience https://clearleft.com/posts/a-workshop-on-building-for-resilience Fri, 09 Mar 2018 16:57:36 +0000 https://clearleft.com/posts/a-workshop-on-building-for-resilience In February, I tried out a new workshop two times—once at Webstock in New Zealand, and once in Hong Kong.

The workshop is called The Progressive Web: Building for Resilience. Here’s an excerpt form the blurb:

This workshop will show you to to think in a progressive way that works with the grain of the web. Together we’ll peel back the layers of the web and build upwards, creating experiences that work for everyone while making the best of cutting-edge browser technologies. From URL design to Progressive Web Apps, this journey will cover each stage of technological advancement.

Basically, it’s the workshop version of Resilient Web Design. If that book is the theory, this workshop is the practice.

Tim recently posted his tips for running workshops and there’s a lot in there that resonates with me. Like Tim, I’ve become less and less reliant on slides. In fact, this workshop—like my workshop on evaluating technology—has no slides. Instead it’s all about the exercises and going with the flow.

After starting with a warm-up, I canvas the room to see if there any specific topics, tools or technologies that people are particularly interested in covering. I’ll note those (on post-its slapped on the wall) for reference throughout the day, to try to make sure that those particular things are touched on at some point. Then I start with a thought experiment…

First of all, I get everyone to call out websites, services and apps that they use almost every day: Twitter, Facebook, Gmail, Slack, Google Docs, and so on. Those all get documented on the wall. Then it’s time to ask of each product, “What is the core functionality?” The idea here is to get beneath the surface-level verbs like swiping, tapping and dragging to get to the real purpose of a service: buying, selling, sharing, reading, writing, collaborating, and so on.

At this point I inform the attendees that the year is 1995. And now we’re going to build these services using the technology of this time. This is a playful way of getting answers to the question “What’s the simplest technology to enable the core functionality?” It’s mostly forms, links, and lots of heavy lifting on the server.

Then the real fun begins. “Enhance!” Moving forward in time, we get to add styles, we add interactivity with JavaScript, then Ajax, and then we get to really have fun with technologies like web sockets, geolocation, local storage, right the way up to service workers, notifications, and background sync. And the beauty of it all is that, if any of those technologies aren’t supported in a particular browser or device, the core functionality is still available.

Next, we apply this layered mindset to a new service. I split the attendees into groups, and each of them gets a procedurally-generated startup idea …generated by shuffling some cards. This is an exercise I first tried when I was teaching in Porto:

I made five cards with types of sites on them: news, social network, shopping, travel, and learning. Another five cards had subjects: books, music, food, pets, and cars. And another five cards had audiences: students, parents, the elderly, commuters, and teachers. Everyone was dealt a random card from each deck, resulting in briefs like “a travel site about food for the elderly” or “a social network about music for commuters.”

The first few exercises are good creative fun: come up with a name, then a logo, then a business model. Then it’s time to build. It starts with URL design. Then it’s content prioritisation (for a representative URL). Then it’s layout (sketching!). The enhancements have begun. “How might this URL benefit from Ajax?” “How might this URL benefit from geolocation?” “How might this URL benefit from offline storage?” “How might this URL benefit from a service worker?”

Workshop team 4 Workshop team 3 Workshop team 2 Workshop team 1

At this point, we’ve applied the layered, progressive approach at the scale of an entire service, and at the scale of an individual URL. Finally, we apply the same approach at the level of a component. It might be a navigation, or a carousel, or an interactive widget. In each case, the same process applies: “What’s the core functionality? What’s the simplest technology to enable that functionality? Enhance!”

Along the way, there are plenty of rabbit holes we can go down. Whether it’s accessibility, or progressive web apps, or pattern libraries, I go along with whatever people are curious about. But all of it ties back to the progressive, layered mindset I’m hoping to foster.

By the end of the day, I’m hoping that an attendee has one of two reactions:

  1. “What a waste of time! Everything in that workshop was blindingly obvious!” (in which case, excellent!—they’re already thinking in a progressive way), or
  2. “That workshop has completely changed the way I think about building on the web!” (I’m being hyperbolic here, but at the very least I’m hoping to impart a new perspective).

Having given the workshop a few times, I’m really pleased with how it went (and more important, I’m pleased that people enjoyed it). If this sounds like something that your company or team would enjoy, get in touch and we can take it from there.

This was originally posted on my own site.

]]>
Minimal viable service worker https://clearleft.com/posts/minimal-viable-service-worker Tue, 06 Mar 2018 12:16:54 +0000 https://clearleft.com/posts/minimal-viable-service-worker I really, really like service workers. They’re one of those technologies that have such clear benefits to users that it seems like a no-brainer to add a service worker to just about any website.

The thing is, every website is different. So the service worker strategy for every website needs to be different too.

Still, I was wondering if it would be possible to create a service worker script that would work for most websites. Here’s the script I came up with.

The logic works like this:

  • If there’s a request for an HTML page, fetch it from the network and store a copy in a cache (but if the network request fails, try looking in the cache instead).
  • For any other files, look for a copy in the cache first but meanwhile fetch a fresh version from the network to update the cache (and if there’s no existing version in the cache, fetch the file from the network and store a copy of it in the cache).

So HTML files are served network-first, while all other files are served cache-first, but in both cases a fresh copy is always put in the cache. The idea is that HTML content will always be fresh (unless there’s a problem with the network), while all other content—images, style sheets, scripts—might be slightly stale, but get refreshed with every request.

My original attempt was riddled with errors. Jake came to my rescue and we revised the script into something that actually worked. In the process, my misunderstanding of how await works led Jake to write a great blog post on await vs return vs return await.

I got there in the end and the script seems solid enough. It’s a fairly simplistic strategy that could work for quite a few sites, but it has some issues…

Service workers don’t perform any automatic cleanup of caches—that’s up to you to do (usually during the activate event). This script doesn’t do any cleanup so the cache might grow and grow and grow. For that reason, I think the script is best suited for fairly small sites.

The strategy also assumes that a file will either be fetched from the network or the cache. There’s no contingency for when both attempts fail. So there’s no fallback offline page, for example.

I decided to test it in the wild, but I expanded it slightly to fix the fallback issue. The version on the Ampersand 2018 website includes a worst-case-scenario option to show a custom offline page that has been pre-cached. (By the way, if you haven’t got a ticket for Ampersand yet, get a ticket now—it’s going to be superb day of web typography nerdery.)

Anyway, this fairly basic script seems to be delivering some good performance improvements. If you’ve got a site that you think would benefit from this network/caching strategy, and it’s served over HTTPS, then:

  1. Feel free to download the script or copy and paste it into a file called serviceworker.js,
  2. Put that file in the root directory of your website,
  3. Add this in a script element at the bottom of your HTML pages:

if (navigator.serviceWorker && !navigator.serviceWorker.controller) { navigator.serviceWorker.register('/serviceworker.js'); }

You can also use the script as a starting point. You might find issues specific to your particular website. That’s okay—you can tweak and adjust the script to suit your needs.

If this minimal service worker script proves in any way useful to you, thank Jake.

This was originally published on my own site.

]]>
Offline itineraries with service workers https://clearleft.com/posts/offline-itineraries-with-service-workers Wed, 28 Feb 2018 17:58:00 +0000 https://clearleft.com/posts/offline-itineraries-with-service-workers The Trivago website is a progressive web app. That means it

  1. is served over HTTPS,
  2. has a web app manifest JSON file, and it
  3. has a service worker script.

The service worker provides an opportunity for a nice bit of fun branding—if you lose your internet connection, the site provides a neat little maze game you can play. Cute!

That’s a fairly simple example of how service workers can enhance the user experience when the dreaded offline situation arises. But it strikes me that the travel industry is the perfect place to imagine other opportunities for offline enhancements.

Travel sites often provide itineraries—think airlines, trains, or hotels. The itineraries consist of places, times, and contact information. This is exactly the kind of information that you might find yourself trying to retrieve in an emergency situation, like maybe in a cab on the way to the airport or train station. Perhaps you’re stuck in traffic, in a tunnel. Or maybe you don’t have a data plan for the country you’re currently in. Either way, wouldn’t it be great if you could hit the website for your airline or hotel and get your itinerary, even if you’re offline.

Alright, let’s think this through…

Let’s assume that an individual itinerary has its own URL. That URL is a web page of information, mostly text, with perhaps an image or two (like a map). Now when you make your booking, let’s have the service worker cache that URL (and its assets) for offline access.

Hmm …but there’s a good chance that the device you make the booking on is not the same device that you’d have with you out and and about. Because caches are local to the browser, that’s a problem.

Okay, but of these kinds of sites have some kind of log-in mechanism. So we could update the log-in flow a bit: when a user logs in, check to see if they have any itineraries assigned to them, and if they do, fire off an event to the service worker (using postMessage) to cache the URLs of the itineraries.

Now that the itineraries are cached, the final step is to create a custom offline page. As well as the usual “Sorry, the internet’s down” message, we can say “Sorry, the internet’s down …but here are your itineraries”. (This is kind of like the pattern you see on blogs like mine, Ethan’s, or Mike’s—a custom offline page that lists cached URLs of articles you’ve previously visited).

That’s just one pattern off the top of my head. It’s fun to imagine the different ways that service workers could be used to enhance the experience of just about any site, but they seem particularly relevant to travel sites—dodgy internet connections and travelling go hand-in-hand. At Clearleft, we’ve been working with quite a few travel-related clients lately so that’s why these scenarios are on my mind: booking holidays, flights, and so on. But, as I’ve said before and I’ll say again, every website can benefit from becoming a progressive web app.

This was originally posted on my own site.

]]>
Scaling design: the case for narrative transformation https://clearleft.com/posts/scaling-design-the-case-for-narrative-transformation Tue, 06 Feb 2018 08:28:00 +0000 https://clearleft.com/posts/scaling-design-the-case-for-narrative-transformation Digital transformation is something that we all wish we could boast to our friends and colleagues as something we have accomplished.

The covert challenge in this pursuit is hidden in the word ‘digital’, which implies we can achieve this fabled ‘transformation’ when we have the right technology. It is true that effectively employing the right technology is crucial. But there’s something else that’s important to address. In order to achieve digital transformation beyond just wearing the badge, design needs to play an equivalent strategic role.

For this to happen, our design practice must reach a tenable level of maturity.

When we think about maturing our design discipline within our company or organisation, the language that often dominates the digital transformation conversation tends to be about changing the processes, systems and behaviours. Design systems and design ops are part of the natural progression towards scaling design—and don’t get me wrong, these are necessary, fundamental steps. However, from my angle as a researcher and strategist, it’s as if we expect to be able to introduce change by redesigning the system alone, just like an engineer would upgrade a machine.

As someone who looks to inform strategy through evidence-based design, particularly from the human perspective—I’ve been thinking that in our current conversations we might have unconsciously overlooked the human element: the core narrative that each of us needs to embody in order to make change happen. These narratives make up the internal script that all of us run on: stories we tell ourselves about how we work, what we do, what we want to achieve—and why. These also include stories that we tell our peers and our colleagues.

To advance the design discipline, we must make adjustments to our collective version of truth, so that the scalable design systems we create reflect the story of transformation within. As a result, companies and users will benefit from the valuable outcomes design-led work brings. True change happens only when everyone involved accepts what “normal” is.  

The power of narratives

Do you know that exhilaration after you’ve read an amazing book or seen a brilliant film—the feeling of becoming a different person afterwards? There’s power in that feeling—when you are conscious that something has caused you to change the way you see yourself and the world around you. Something has changed the story you might tell. Borrowing from psychotherapy or social mediation, we can refer to this idea as a ‘narrative transformation’. In other words, the conscious act of changing our story.

While it would seem inappropriate to equate digital transformation to a form of therapy, if we look outside our own world, for example, to where professionals in mental health try to enact change in individuals, there’s a lot we can learn to help us establish a more mature design practice. Narrative transformation is also common where agents for social change – from political leaders to key workers on the ground – are tasked with healing rifts in communities.

And yet, when it comes to our industry, the concept of changing the narrative is not usually where the digital transformation conversation begins.

Frame the conversation.

Explore the context before the conversation

In the hubbub of the day-to-day and the business as usual, it’s often difficult to take the time to reflect on how we could most effectively incorporate new habits.

I’ve designed and run strategic training workshops for various clients at Clearleft. And when I’m working with design leaders who want to drive the influence and impact of design within their organisations, I’ve noticed that the initial conversation is often around upskilling a team on something specific, such as fundamental design research skills or Jobs-to-be-Done (JTBD).

That said, every design leader who wants to lift their team’s game also talks about the need for some degree of ‘change’, something that’s usually less tangible in practice. ‘Culture change’ is the nirvana on everyone’s lips.

Have you ever thought:

“We’ve done a workshop on X, but we struggle to know how to use it in practice?”

Or:

“Some of our team doesn’t buy into this process?”

The reality is, murmurs of hesitance are often found elsewhere in the company, where priorities are competing and colleagues need convincing that alternatives are better. Trying to make the argument that a different way of working may improve the end product or service is never quite so straightforward.

New skills are only as good as your team’s ability to use and apply them in the context of your team dynamics, the business objectives and organisational culture. As such, there needs to be an adjustment to the status quo, whether it’s mindset, process, or culture.

So how do you change the status quo and empower your team to not only upskill, but truly embody the culture change you’re aiming for?

Create culture change through narrative transformation

In order to seed change to lead to higher quality design, better outcomes for your customers and revenue for the business, it is essential to create a safe space, protect time, and frame the context for key conversations to happen within your team.

Often, these conversations:

  1. Enable your team members to gain individual insights so they grasp the effect they have on the outcome that impacts your customers
  2. Formulate a cohesive, shared narrative of why things currently happen the way they do
  3. Address skills gaps and uncover individual strengths—I think of these as “superpowers”
  4. Revisit the current narrative, and speculate: “with our new superpowers, how do we do things better?”

The Clearleft way to do this often involves workshops and design sprints of various flavours. We use our expertise to craft the workshop experience in collaboration with design leaders client-side, so that we can sow the seeds of longer term culture change whilst upskilling their teams. The focused nature of design sprints means teams can achieve product changes in a short space of time; participants come away with a new sense of empowerment and an awareness that they can truly make something happen. After the workshops and sprints have happened, and your team has gone back to the usual office rhythms, they should have better clarity on how these newly acquired skills can fit within their day-to-day context—towards a more mature design practice.

My way of addressing narrative transformation is through bespoke training on research. As I said earlier on, strategic research is my particular lens, but the focus on using narrative as a change driver can apply to other design disciplines as well.

Before you decide on embarking on this kind of intervention, there are a few things you can do to prepare ahead.

Shared reflections.

Plot the path to your north star

As you are trying to decide on what kind of skills you need in your team, it’s worth having a conversation with them to agree on what may be the best long-term outcome, together:

  • Dream up the ideal narrative. If you were to speak to another design leader and describe how you were successful, what kind of story would you want to tell?
  • Focus on the characters in your story. Look for the change-agents and influencers across your wider team — key players who can create a ripple effect in changing the narrative: who are the people you most need to influence? Who are the best people to spread the message?
  • Think about transforming individual journeys. Keep in mind the people you need to take along with you on your path: what might be the right combination of internal workshops, externally facilitated workshops or training workshops to help you change the culture? What other interventions might be possible?

I’d be interested to hear about the path you and your team may take to change your narrative, and what other kind of interventions you have used in order to accelerate design maturity within your organisation. Join our ongoing conversation about design thinking at @clearleft. Alternatively, you can reach me @sniffles on Twitter or steph@clearleft.com.

]]>
In support of MakerClub https://clearleft.com/posts/in-support-of-makerclub Fri, 02 Feb 2018 11:18:00 +0000 https://clearleft.com/posts/in-support-of-makerclub When Declan Cassidy approached Clearleft last year with a view to us supporting MakerClub, I was immediately hooked.

The Maker movement is something we’re very familiar with and aligned to - there’s nothing we like more than feeding our curiosity by tinkering around with technology. MakerClub opens up that world of play and innovation to young people. We jumped at the chance to support their BrightSparks scheme and help kids from underprivileged backgrounds get access to all the great learning and technology resources that MakerClub provides.

Earlier this week, Declan dropped by to share the latest news on MakerClub and to let us know what’s in the pipeline for this wonderful venture. Afterwards, he put pen to paper and answered a couple of interview questions, so we could spread the message beyond the four walls of the Clearleft studio!

Image courtesy of MakerClub. Photography: Chris Quigley.

Tell us about MakerClub and why it’s such an important project

DC: MakerClub was created to help encourage young people to become curious, lifelong learners. Our weekly clubs are based in ‘makerspaces’ across the UK - these are places that have access to advanced manufacturing equipment like laser cutters, 3D printers, craft materials and all kinds of cool electronics!

Children use this equipment to develop their invention and design skills through hands-on workshops and real-life briefs that use hardware and digital learning tools that we have developed in-house, to provide a rich discovery experience that allows them to creatively invent solutions to the challenges they face around them. We currently work with 300+ children a week, but hope to ramp this up as we move to scale in 2018, aiming by 2020 to be accessible throughout primary schools and local libraries.

Whether it’s a pollution detector, Internet of Things alarm systems for keeping bedrooms secure, or a robot just to keep a child company, it all starts with a young person’s imagination. We have worked for 4 years with educators and technologists to create a loose curriculum online learning environment that allows a child to create their own educational pathway attuned to their individual passions, while at the same time ensuring they get to grips with key creative technology skills like coding, 3D design and basic manufacturing.

According to the World Economic Skills Forum and NESTA, by 2030, skills like creativity, critical analysis and collaborative problem solving will be highly desirable by employers, especially given the current trend to automation and robotics in the workplace. This kind of learning ensures that young people develop the skills need to secure future work in a rapidly shifting market.

This kind of learning isn’t really available in schools due to restrictions in the curriculum and a lack of confidence in teaching STEAM (Science, Technology, Engineering, Art, Math). Over the next 12 months we will be rolling out a trial in every Primary school in Brighton, providing them all with the tools and equipment to run MakerClubs for free - we hope to then roll this out across the UK.

Image courtesy of MakerClub. Photography: Chris Quigley.

Why partner with Clearleft?

DC: Clearleft has always been a company that has led the charge for creativity, and we share many of the same values. The company has previously supported the local MakerFaire and run its own maker workshops for young people at its HQ - a partnership between us seemed like a brilliant fit.

So far, Clearleft has supported our BrightSparks programme, which works with schools to get children on free school meals access to MakerClub and provide them with a free laptop. Clearleft staff are also planning on volunteering in our local space, as well as providing some high-level support on the future design of our learning platform.

Image courtesy of MakerClub. Photography: Chris Quigley.

How can people get involved?

DC: To make the change we’re looking to affect, we need parents that care, teachers that want to facilitate this kind of learning and more companies like Clearleft to help support the next generation of makers and creatives.

If you believe that young people should be given the right skills to thrive in the 21st Century, no matter their background, please get in touch to join us on this exciting journey to transform education.

Contact Declan at makerclub.org

How are you supporting grassroots education and innovation projects in tech? We’d love to hear from you - tweet us @clearleft.

]]>
GDPR and Google Analytics https://clearleft.com/posts/gdpr-and-google-analytics Mon, 29 Jan 2018 12:58:46 +0000 https://clearleft.com/posts/gdpr-and-google-analytics Enforcement of the European Union’s General Data Protection Regulation is coming very, very soon. Look busy. This regulation is not limited to companies based in the EU—it applies to any service anywhere in the world that can be used by citizens of the EU.

It’s less about data protection and more like a user’s bill of rights. That’s good. Cennydd has written a techie’s rough guide to GDPR.

The Open Data Institute’s Jeni Tennison wrote down her thoughts on how it could change data portability in particular. While she welcomes GDPR, she has some misgivings.

Blaine—who really needs to get a blog—shared his concerns in the form of the online equivalent of interpretive dance …a twitter thread (it’s called a thread because it inevitably gets all tangled, and it’s easy to break.)

The interesting thing about the so-called “cookie law” is that it makes no mention of cookies whatsoever. It doesn’t list any specific technology. Instead it states that any means of tracking or identifying users across websites requires disclosure. So if you’re setting a cookie just to manage state—so that users can log in, or keep items in a shopping basket—the legislation doesn’t apply. But as soon as your site allows a third-party to set a cookie, it’s banner time.

Google Analytics is a classic example of a third-party service that uses cookies to track people across domains. That’s pretty much why it exists. We, as site owners, get to use this incredibly powerful tool, and all we have to do in return is add one little snippet of JavaScript to our pages. In doing so, we’re allowing a third party to read or write a cookie from their domain.

Before Google Analytics, Google—the search engine business—was able to identify and track what users were searching for, and which search results they clicked on. But as soon as the user left google.com, the trail went cold. By creating an enormously useful analytics product that only required site owners to add a single line of JavaScript, Google—the online advertising business—gained the ability to keep track of users across most of the web, whether they were on a site owned by Google or not.

Under the old “cookie law”, using a third-party cookie-setting service like that meant you had to inform any of your users who were citizens of the EU. With GDPR, that changes. Now you have to get consent. A dismissible little overlay isn’t going to cut it any more. Implied consent isn’t enough.

Now this situation raises an interesting question. Who’s responsible for getting consent? Is it the site owner or the third party whose script is the conduit for the tracking?

In the first scenario, you’d need to wait for an explicit agreement from a visitor to your site before triggering the Google Analytics functionality. Suddenly it’s not as simple as adding a single line of JavaScript to your site.

In the second scenario, you don’t do anything differently than before—you just add that single line of JavaScript. But now that script would need to launch the interface for getting consent before doing any tracking. Google Analytics would go from being something invisible to something that directly impacts the user experience of your site.

I’m just using Google Analytics as an example here because it’s so widespread. This also applies to third-party sharing buttons—Twitter, Facebook, etc.—and of course, advertising.

In the case of advertising, it gets even thornier because quite often, the site owner has no idea which third party is about to do the tracking. Many, many sites use intermediary services (y’know, ‘cause bloated ad scripts aren’t slowing down sites enough so let’s throw some just-in-time bidding into the mix too). You could get consent for the intermediary service, but not for the final advert—neither you nor your site’s user would have any idea what they were consenting to.

Interesting times. One way or another, a massive amount of the web—every website using Google Analytics, embedded YouTube videos, Facebook comments, embedded tweets, or third-party advertisements—will be liable under GDPR.

It’s almost as if the ubiquitous surveillance of people’s every move on the web wasn’t a very good idea in the first place.

This was originally posted on my own site.

]]>
How to use variable fonts in the real world https://clearleft.com/posts/how-to-use-variable-fonts-in-the-real-world Fri, 26 Jan 2018 11:28:00 +0000 https://clearleft.com/posts/how-to-use-variable-fonts-in-the-real-world Using variable fonts in the real world turns out to be tricky. This post explains how we achieved it for the new Ampersand website and what we learned along the way.

This article has been updated to reflect pending clarifications and modifications to the CSS Fonts Module Level 4 as resolved in the April 2018 CSS WG meeting.

A variable font is a single font file which behaves like multiple styles. (I wrote more about them here in an extract from my Web Typography book). There are plenty of sites out there demoing the possibilities of variable fonts and the font variation technology within, but for the new Ampersand conference website I wanted to show variable fonts being using in a real, production context. It might well be the first commercial site ever to do so.

Variable fonts in action on the Ampersand website

Two months ago browser support for variable fonts was only 7%, but as of this morning support is at over 60%. Safari 11, Chrome 62+, Firefox 57+ and Edge 17+ all support variable fonts (Firefox only on a Mac and if you set the correct flags). This means font variations is a usable technology right now. But not all support is equal, as you’ll see.

Variable font capable software is already more pervasive than you might think. For example, the latest versions of Photoshop and Illustrator support them, and if you’re using macOS 10.13+ or iOS 11+ the system font San Francisco uses font variations extensively. That said, the availability of variable fonts for use on the web is extremely limited. At the time of writing there are very few commercial variable webfonts available (Dunbar​ and Fit​ are notable exceptions), but there is a growing number of free and experimental variable webfonts, as showcased in the Axis Praxis playground and more recently listed on Variable Fonts.

From this limited palette of fonts, we (by which I mean Clearleft designer James Gilyead) chose Mutator Sans for the display text, and Source Sans for the body text in a Saul Bass-inspired design. Both fonts enabled us to make use of their variable weight axis. Fonts chosen now came the tricky, multi-step business of implementing variable fonts into the website. I’ll take you through how we (by which I mean Clearleft developer Mark Perkins) did it, using simplified code snippets.

1. Link to the fonts

Getting your variable fonts working in a basic fashion is fairly straight forward. At the time of writing Safari and Chrome have the most complete support. If you’re following along with these steps, you’ll need one of those browsers to start off with.

We downloaded the Source Sans variable font from its home on Github and used @font-face with a format of truetype-variations to link it up to the stylesheet:

@font-face {
  font-family: 'SourceSans';
  src: url('source-sans-variable.ttf') format('truetype');
}

We could then set the variable Source Sans font as the main typeface for the page in the usual way:

html {
  font-family: 'SourceSans', sans-serif;
}

2. Set the weights

The variable font implementation in CSS is designed to use existing properties for certain pre-defined variation axes. We’re using three weights within the body text: regular, semibold and black. We set the bold fonts using font-weight in the usual way:

.hero { font-weight: 900; }
.blurb { font-weight: 600; }

However this doesn’t work as expected without modifying the @font-face rule. When you include a font-weight descriptor in an @font-face rule, you are telling the browser that the font corresponds to that weight, and that weight only. When you omit the font-weight descriptor, the browser treats the rule as if you set font-weight:400. This is the case whether or not your font is variable with a weight axis - the font will be ‘clamped’ to a weight of 400.

To make use of the weight axis, and for the font-weight properties to work as you might expect, we needed to add a font-weight range to the @font-face rule:

@font-face {
  font-family: 'SourceSans';
  src: url('source-sans-variable.ttf') format('truetype');
  font-weight: 1 999;
}

The font weight range allows the variable font to be displayed at any weight from 1 to 999 (you could specify a more constrained range if you wanted). In the near future the CSS Fonts Level 4 spec will allow you to omit the range descriptor because the default value will become a new value of auto, thus enabling the full range of weights available in the variable font, and defaulting to normal for static fonts. (The same applies to other descriptors such as font-stretch.)

With variable fonts, your weight doesn’t have to be limited to intervals of 100. It can be any integer in the range 1-999. For the main heading, set in Mutator Sans, we used subtle differences in weight for each letter to give a more hand-drawn feel to the design:

b:nth-child(1) { font-weight: 300; }
b:nth-child(2) { font-weight: 250; }
b:nth-child(3) { font-weight: 275; }

3. Subset and create a WOFF2

The Source Sans variable font is pretty big: the TrueType file is 491Kb. This is mostly because it has a huge character set: nearly 2000 glyphs including Greek, Cyrillic, alternate characters and symbols. Your first step in reducing file size is to create a subset of the font so that it no longer contains characters you won’t ever need.

We decided to be fairly conservative in what we kept in, so we subsetted to include Basic Latin, Latin-1 Supplement and Latin Extended-A character ranges; a total of around 400 characters covering most European languages. In Unicode terms these are U+0020-007F, U+00A0-00FF and U+0100-017F.

There are plenty of online tools for subsetting fonts, such as Fontsquirrel. However all tools that I have seen strip out the variation data. This means you’ll need to turn to a command line approach. We subsetted the font using the open source pyftsubset, a component of fonttools (see Michael Herold’s tutorial for more info). If Node is more your thing, you could instead use Glyphhanger.

Both Glyphhanger and fonttools (if you install Brotli compression) will output the subsetted file as a WOFF2. We don’t need a regular WOFF as well because all browsers which support variable fonts also support WOFF2.

Running the subsetting routine and conversion to WOFF2 gave us a pleasingly tiny 29Kb file. We updated the @font-face rule accordingly:

@font-face {
  font-family: 'SourceSans';
  src: url('source-sans-variable.woff2') format('woff2');
}

So that’s the job done for browsers which support variable fonts. But that’s barely half the story.

4. Provide fonts for incapable browsers

Variable fonts do render on browsers which don’t support font variations, but you obviously have no control over which weight (or other axis instance) will be used.

To get around this, you need to serve non-variable (single-style) fonts to these browsers. At the time of writing, the CSS Fonts Module Level 4 specifies that variable fonts can be indicated with a specific format() value:

@font-face {
   font-family: 'SourceSans';
   src: url('source-sans-variable.woff2') format('woff2-variations');
 }

This enables you to create @font-face rules like this:

@font-face {
  font-family: 'SourceSans';
  src: url('source-sans-variable.woff2') format('woff2-variations'),
       url('source-sans-regular.woff2') format('woff2');
  font-weight: 400; 
}

@font-face {
  font-family: 'SourceSans';
  src: url('source-sans-variable.woff2') format('woff2-variations'),
       url('source-sans-black.woff2') format('woff2');
  font-weight: 900; 
}

The preceding code points to the single-style font files with an @font-face rule including the font’s weight, as you would normally. You can then repeat a reference to the variable font file in each rule. Browsers which support variable fonts will download the file marked as format('woff2-variations') (once only), and browsers which don’t will download the single-style font marked as format('woff2').

But. Only Safari supports format('woff2-variations') (and that syntax is changing) which rather messes things up if we want the other capable browsers to get their variable font. So we resorted to a different, rather more verbose tactic. Firstly we gave the variable font a different name to the single-style typeface, thus separating links to variable fonts from single-style fonts:

@font-face {
  font-family: 'SourceSansVariable';
  src: url('source-sans-variable.woff2') format('woff2');
  font-weight: 1 999;
}

@font-face {
  font-family: 'SourceSans';
  src: url('source-sans-black.woff2') format('woff2'),
         url('source-sans-black.woff') format('woff');
  font-weight: 900; 
}

@font-face {
  font-family: 'SourceSans';
  src: url('source-sans-semibold.woff2') format('woff2'),
         url('source-sans-semibold.woff') format('woff');
  font-weight: 600; 
}

We then needed to write an @supports rule to ensure the right fonts went to the right browsers:

html {
  font-family: 'SourceSans' sans-serif;
}

@supports (font-variation-settings: normal) {
  html {
    font-family: 'SourceSansVariable', sans-serif;
  }
}

In the above code, the single-style fonts are specified as standard, however if a browser supports variable fonts (it’s a reasonable assumption that can be judged by support for font-variation-settings) then it gets the variable font instead.

One final thing. For a belt and braces approach, every time you use variable fonts you should explicitly set the font weight even when the weight you want is 400 or normal. With a variable font, one browser’s idea of the default weight may differ slightly from another. In our testing Firefox rendered default text significantly lighter than Safari and Chrome, until we did this:

html {
  font-family: 'SourceSans' sans-serif;
   font-weight: 400;
}

@supports (font-variation-settings: normal) {
  html {
    font-family: 'SourceSansVariable', sans-serif;
    font-variation-settings: "wght" 400;
  }
}

And that’s it. Do check out how it came together on the Ampersand website, and don’t forget Ampersand is a conference dedicated to typography on the web - if that’s your thing you might want to check it out. There will be plenty of discussion of variable fonts, and much more besides.

This was first posted on my own site.

]]>
Putting the agency back in (your) business https://clearleft.com/posts/putting-the-agency-back-in-your-business Thu, 25 Jan 2018 17:07:00 +0000 https://clearleft.com/posts/putting-the-agency-back-in-your-business Agency: An organisation that offers a particular kind of assistance on behalf of another business, person, or group.

Whilst there are many different definitions of agency, in the context of the design industry this is one of the simplest and most appropriate to describe what it is that agencies actually do. Historically, they offer specialisms and skills that help their clients in some way - these can take years to master and by employing groups of people with these skills agencies are able to offer services that can take their clients a long time to develop internally.

But over the last few years there has been a paradigm shift in how these agency clients (let’s call them organisations) work and are structured. We’re all aware of the productisation that has become so prevalent in today’s organisations - in-house design and development teams are now the norm, with those previously out-sourced specialisms and skills being brought under the one roof to help build much more rounded and cross-functional departments, capable of delivering continually improving product visions and services.

This all makes great business sense and many organisations - indeed the design industry itself - have flourished from the successes of this shift - longterm investment in people and skills focussed solely on specific organisational needs seems ideal. But if this move to in-house is so successful, where does this leave the agency, and why is it that we as an agency are still working with so many of these organisations even after they have spent time and resources building up their own specialised departments?

We all need a little help from time to time

Many of the organisations we talk to and work with have a broad range of well-developed skills across their teams - their employees have spent years in agencies, product teams and organisations with similar challenges, and in short, they know their stuff. Capability certainly isn’t an issue - in fact many of these organisations have strong teams working with well-formed backlogs, continually improving their products and services. But this is often where we find that we as an agency can help - when work load and business as usual is strong and steady, finding the time, thought-space and drive to tackle problems, innovate or even take a step back to assess more often than not gets pushed to the bottom of that backlog.

Because we often operate outside the constraints of business as usual, it enables us to work in a space that can offer a fresh perspective on business as usual, or dedicate effort in a given area. Being afforded the time and remit to tackle a particular problem is usually something of a luxury when there are so many other ongoing operational challenges, but paradoxically tackling these problems often yields extremely beneficial results for those ongoing challenges. Increased efficiency, refocussing effort, assessing processes, adding, streamlining or redesigning features and functionality, even the not-so-small task of digital transformation - these are just a few examples of benefits resulting from work that we do with clients. The truth is that many experienced, cross-functional internal teams may well come to similar conclusions, but quite simply don’t have the capacity or space in which to do so.

We like to think of ourselves as an extension of an organisations’ own team(s) - we share similar skills, talk the same language, and love tackling those tricky problems, big or small. We have a wealth of experience between us, and over the years we’ve all rolled up our sleeves and got stuck in when needed, but where we really come into our own is in helping define and isolate a challenge. Often the diverse experience, skills and fresh perspectives that our tailored teams offer can be exactly the catalyst that helps an organisation shape and deliver solutions.

Well, this should be easy...

All said and done, it really all comes down to the fact that our particular kind of assistance is actually tailored to each organisation we work with - we help identify the shape of that assistance, create a space for it, bring processes, people and skills to embed it, then work closely with everyone involved to deliver it. Simple. 

So, the next time you are wondering how you’ll get through that backlog, have a great idea (even the inkling of a great idea) but don’t know how you’ll ever get some space, capacity or skills to tackle it, maybe it’s time to consider an agency - we for one would certainly welcome a chat about how we can help you.

]]>
Design ops for design systems https://clearleft.com/posts/design-ops-for-design-systems Thu, 25 Jan 2018 13:04:20 +0000 https://clearleft.com/posts/design-ops-for-design-systems Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.

Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.

Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.

There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.

Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:

None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.

There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:

Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.

I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:

Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.

Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.

This was originally posted on my own site.

]]>
Ampersand is back! https://clearleft.com/posts/ampersand-is-back Tue, 23 Jan 2018 16:14:00 +0000 https://clearleft.com/posts/ampersand-is-back It’s been a while – nearly three years, in fact – since we last brought our typography-fuelled Ampersand conference to the web designers and type enthusiasts of the world. I’m thrilled to announce that we’re bringing it back in 2018!

What is Ampersand all about?

For those that don’t know, Ampersand is an inspiring and affordable one-day web typography conference, bringing together leading thinkers and designers from the worlds of type and web design.

My love of typography led me to create the first Ampersand conference in 2011, held near Clearleft’s studio in Brighton. With webfonts having just been unleashed on the world, I wanted to put type designers and web designers on the same stage - something that had never been done before. It was clear other people shared my passion, because that first conference sold out, after which we ran the event every few years, including a stand-out year on the road, where we bought Ampersand to the Times Center in New York City!

AMPERSAND WILL RETURN IN JUNE 2018! (photo: Marc Thiele)

The conference always features a unique mix of voices and experts representing all aspects of typography on the web. In the past we’ve had type designers, browser makers, book designers, web developers, illustrators, visual designers, branding experts, font engineers and no fewer than three professors. Speakers have included Erik Spiekermann, Jonathan Hoefler, Jen Simmons, Mark Bolton and Jenn Lukas to name but a few.

Like the audience, all our speakers share a love of type and enjoy nothing more than getting into the nitty gritty, so get ready to geek out, folks!

Why bring it back?

We’ve taken a little break since 2015, mostly so I could write my book Web Typography. Lots has happened in the world of web typography since then, not least the arrival of variable fonts, which I’m sure will make an appearance in some of the talks this year. Funnily enough, the new Ampersand website showcases some variable fonts in action, so go take a look…

Need to knows

When

Friday 29th June 2018, 10am - 5pm

Where

Ampersand will be taking place at the beautiful and historic Duke of York’s Picturehouse in Brighton - it’s one of the UK’s oldest cinemas, and we’ll be rolling out the red carpet to celebrate all things Ampersand…

The Duke of York’s Picturehouse
Brighton
BN1 4NA
UK

Tickets

“When will tickets go on sale?!” I hear you cry. Well, today we’ve released 10 Super Early Bird tickets, saving you £85 off the full ticket price, so the keen amongst you can snap up a bargain before we announce the full schedule.

Get the latest Ampersand news

If you don’t want to miss the latest conference announcements, sign up to our mailing list (at the bottom of the Ampersand homepage) to receive ticket and schedule updates direct to your inbox. For real-time updates and web typography news, follow @ampersandconf too.

Stay tuned and we hope to see you there!

www.ampersandconf.com

Ampersand is a Clearleft event.

]]>
Analysing analytics https://clearleft.com/posts/analysing-analytics Thu, 18 Jan 2018 19:35:00 +0000 https://clearleft.com/posts/analysing-analytics Hell is other people’s JavaScript.

There’s nothing quite so crushing as building a beautifully performant website only to have it infested with a plague of third-party scripts that add to the weight of each page and reduce the responsiveness, making a mockery of your well-considered performance budget.

Trent has been writing about this:

My latest realization is that delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts.

He’s started the process by itemising third-party scripts. Frustratingly though, there’s rarely one single culprit that you can point to—it’s the cumulative effect of “just one more beacon” and “just one more analytics script” and “just one more A/B testing tool” that adds up to a crappy experience that warms your user’s hands by ensuring your site is constantly draining their battery.

Actually, having just said that there’s rarely one single culprit, Adobe Tag Manager is often at the root of third-party problems. That and adverts. It’s like opening the door of your beautifully curated dream home, and inviting a pack of diarrhetic elephants in: “Please, crap wherever you like.”

But even the more well-behaved third-party scripts can get out of hand. Google Analytics is so ubiquitous that it’s hardly even considered in the list of potentially harmful third-party scripts. On the whole, it’s a fairly well-behaved citizen of your site’s population of third-party scripts (y’know, leaving aside the whole surveillance capitalism business model that allows you to use such a useful tool for free in exchange for Google tracking your site’s visitors across the web and selling the insights from that data to advertisers).

The initial analytics script that you—asynchronously—load into your page isn’t very big. But depending on how you’ve configured your Google Analytics account, that might just be the start of a longer chain of downloads and event handlers.

Ed recently gave a lunchtime presentation at Clearleft on using Google Analytics—he professes modesty but he really knows his stuff. He was making sure that everyone knew how to set up goals’n’stuff.

As I understand it, there are two main categories of goals: events and destinations (there are also durations and pages, but they feel similar to destinations). You use events to answer questions like “Did the user click on this button?” or “Did the user click on that search field?”. You use destinations to answer questions like “Did the user arrive at this page?” or “Did the user come from that page?”

You can add as many goals to your site’s analytics as you want. That’s an intoxicating offer. The problem is that there is potentially a cost for each goal you create. It’s an invisible cost. It’s paid by the user in the currency of JavaScript sent down the wire (I wish that the Google Analytics admin interface were more like the old interface for Google Fonts, where each extra file you added literally pushed a needle higher on a dial).

It strikes me that the event-based goals would necessarily require more JavaScript in order to listen out for those clicks and fire off that information. The destination-based goals should be able to get all the information needed from regular page navigations.

So I have a hypothesis. I think that destination-based goals are less harmful to performance than event-based goals. I might well be wrong about that, and if I am, please let me know.

With that hypothesis in mind, and until I learn otherwise, I’ve got two rules of thumb to offer when it comes to using Google Analytics:

  1. Try to keep the number of goals to a minimum.
  2. If you must create a goal, favour destinations over events.

This was originally posted on my own site.

There are two follow-up posts:

  1. Heisenberg, and
  2. Needs must.
]]>
Business as unusual: a resolution for reinvention https://clearleft.com/posts/business-as-unusual-a-resolution-for-reinvention Wed, 10 Jan 2018 12:47:00 +0000 https://clearleft.com/posts/business-as-unusual-a-resolution-for-reinvention Do any one of these warning signs currently describe your business?

  1. Sales are steady.
  2. There’s plenty of tickets in the backlog.
  3. Continuity is favoured over change.

Why spend time and money on innovation when you are established in your market? Surely, it’s up to the competition to raise their game to compete with you.

In many well-known and established organisations I’ve worked with I’ve been left with the sense from senior management that innovation is for start-ups, business as usual generates the revenue, and nobody ever got fired for sailing a steady course.

These thoughts, expressed in similar terms, were likely to have once echoed around the now empty boardrooms of large and established companies such as Woolworth’s, Kodak, Pan Am, Blockbuster, Borders, General Motors, Friends reunited, Polaroid, Comet, Sony Ericsson phones, Game, Zavvi etc.

The fact is, no business is too big to fail. However, all businesses can be too small-minded to think big.

The times they have, are and will be a changin’

Changes caused by digital technology have been more rapid and radical than anything else in the history of business. If you work in retail, banking, travel, the cultural sector, education, publishing, the third sector… in fact I can’t think of a single industry that hasn’t faced and isn’t facing fundamental changes brought about from digital technology or the ‘tech revolution’, if you prefer.

Successful organisations view these changes as opportunities. The next bankrupt business sees them as threats.

Where we once saw digital start-ups culpable in the demise of their traditional bricks and mortar competition, we are now seeing digital native companies being disrupted by newer, digital ones.

The only constant is change. It’s just the speed of change and the impact from it that have become more profound. Every business needs a managed programme of innovation to embrace and exploit change.

65% of children entering primary school today will ultimately end up working in completely new job types that aren’t on our radar yet

World Economic Forum

The stability and life-span of every major businesses is in rapid decline. Richard Foster highlights in his study for Yale School of Management and book ‘Creative Destruction’ that at the current churn rate, 75% of the companies on the S&P 500 index will be replaced by 2027. Many of them will be overtaken by their competitors. Many of them will not even exist.

Along the same lines, research from the Business School at Imperial College in London reports of the 100 companies in the FTSE 100 in 1984 only 24 were still in business in 2012.

Change is nothing new. It is just happening at an accelerated rate. If you think back a decade they are many of today’s well known, successful companies and products that didn’t exist. Uber, Instragram, Airbnb, Alexa, WhatsApp, Google Drive, Google Chrome, Tinder, Slack, Siri, Kickstarter, Pinterest are all less than 10 years old.

The pace of change, and therefore the need to adapt, adjust and innovate to compete, looks like it is just starting to get going.

The World Economic Forum predicts ‘65% of children entering primary school today will ultimately end up working in completely new job types that aren’t on our radar yet’ and the Bank of England’s chief economist said last year that 80m US and 15m UK jobs might be taken over by robots.

The seismic shift caused by digital

Much of the change is being brought about, and certainly hastened by digital technology.

The result of which are three fundamental and concurrent shifts in how businesses operate:

  • The customer is in control. They have more choice and less loyalty than ever before, and are armed with the ability through social media to have their complaints or compliments influence other customers.
  • The power is now in the product. Once the organisation controlling the channels for distribution (the printing press, the radio masts, the gas pipe, the travel agent etc.) held the best cards. The internet provides (nearly) free distribution to all. So the game shifts to give advantage to those who have content, services and products that best solve customers needs.
  • The cost and time to scale has plummeted. At the press of a button you can spin up a new server to meet demand or upgrade software with the new killer feature. This allows you to rapidly go from a trial for an idea to take-off on a global scale. It leads to new business ideas springing up like moles from both your existing competitors as well as entirely new players.

With these changes to the business landscape, standing still, even for a moment, is not a viable option. The question facing senior leaders and managers in every organisation is this: Does your organisation have in place an effective plan, as well as the people and resources to carry out continuous reinvention?

You need to generate ideas before you can iterate upon them

There are some standout examples of large established organisations, many recently seen as behemoths, using design thinking and innovation to reinvent themselves in the age of the digital consumer. These include:

The 125-year old GE which has changed itself into a company for industrial digital transformation.

British Gas with its growing range of Hive products is using product and service design to reimagine the home.

IBM has adopted design thinking to change its fortunes by helping its business users to better solve their customers needs at speed and scale.

Gov.uk has revolutionised (and continues to do so) the way we interact and transact with government saving both the user and the state time and money.

There’s no better time than now to make change

Innovation doesn’t need to be time consuming to get going. At Clearleft we regularly help clients with a variety of rapid interventions to identify, accelerate, execute and evaluate digital change.

Here are some ideas to kickstart a resolution for change and to introduce an ongoing habit of digital reinvention.

Identify through research

Our research and UX teams frequently carry out structured research interviews with a client’s existing and potential customers to uncover new products and services to develop.

With the use of techniques such as Jobs to be Done interview questions and ‘day in the life’ mapping, we help identify unmet customer needs, pain points to fix, and opportunities to explore further.

Accelerate with design sprints

Last year we had the privilege of hosting Jake Knapp, author of ‘Sprint: How to Solve Big Problems and Test New Ideas’, in London at a Clearleft Presents event. It allowed our teams to build upon and hone their experience of facilitating short, intense and focussed design activities with clients and their teams.

We really enjoy the way design sprints, when run properly, take a team from a problem space, through ideas and iteration, and onto a tested solution in just five days. A design sprint is a proven way to unblock long-term issues and enables rapid headway to be made on business critical challenges.

A powerful by-product of working closely with a client and their team is the way it energises and trains all those involved in the use of design thinking skills.

Design thinking uncovers inventive ideas

Execute through prototyping

Being successful at innovation is about applied perseverance. The more bets you place, the more likely you are to find a winner.

When team resources are tapped into, there is often no shortage of ideas in an organisation. There is more often a lack of capacity to design, build, and evaluate solutions.

Don’t let a lack of people and resources stifle the ability to increase the number of design experiments you run. The use of an external agency is a cost-effective way to provide an injection of additional designers to create multiple solution for A/B and MVT testing, and developers to create prototypes to pilot new products and services.

Make 2018 a year for innovation

I’m not suggesting you abandon business as usual. However, without a complementary and supplementary stream of innovation and looking into the future there will soon come a time when your business as usual has been overtaken by a competitor.

Innovative companies see the process as ongoing. They focus on the needs of the customer and systematically identify opportunities, pilot ideas, iterate upon them and then take them to their customers before their competition.

Innovation isn’t hard. Innovation is a habit. So let’s make a resolution to turn 2018 into the year of business as unusual.

I’d relish the chance to hear your stories and advice on building a design-led practice of innovation, or to discuss further how design can be used to create greater value for your customers and your organisation. Drop me a line at chris@clearleft.com

Join the conversation about design thinking and innovation on Twitter, by tweeting us @chrishow and @clearleft.

]]>
Why (and how) to get senior stakeholders involved in project framing https://clearleft.com/posts/why-and-how-to-get-senior-stakeholders-involved-in-project-framing Wed, 03 Jan 2018 10:09:00 +0000 https://clearleft.com/posts/why-and-how-to-get-senior-stakeholders-involved-in-project-framing In my last post I looked at the importance of lists and used an example of a project initiation checklist. Naturally, I wanted my next post to follow in logical and chronological order.

After project initiation comes  project setup, so I thought I’d get writing again and share a method of ‘project framing’ which we ran recently with a major UK travel provider. The method proved to be an extremely useful part of the project set up, time efficient, and massively helpful in reducing any ambiguity in those crucial early stages. 

Picture the scene

The contract has been signed, the initiation checklist checked, and you’re all gathered in a conference room with coffee and pastries, ready to kick things off. And the senior stakeholders promptly leave the room (if they had even entered it in the first place). In my experience that’s pretty standard. It makes sense, right? The decision making around embarking on the partnership has been made, so everyone can just crack on. Sound familiar? So far so good.

Ordinarily, when the original brief came in, there will have been a load of back and forth around “deliverables”. The same old questions come up time and time again: “What exactly am I going to get for my money?”; “When will I start seeing value?”. Rightly so, and justifiable from a client’s perspective.

A good agency won’t be in a position to answer these questions in detail immediately, so will begin with responses around time and materials and immersion weeks. (It’s worth noting that partners who suggest they have all the answers and a pocket full of silver bullets from the off are the least likely to deliver both fast and long lasting business value.)

In some cases, this (sometimes) perceived lack of clarity can often bamboozle the senior stakeholders until they get to the point where they greenlight the project and handover to an internal team to deliver, who might understand the approach better.

Ambiguity = Disaster

Then, stealthy as you like, disaster strikes! You’re a few weeks or months into the project and rumblings of confusion and ambiguity are felt in the room. And it turns out that those rumblings set in when they snuck their way through the door left open by the departing senior stakeholders straight after that initial green light. ‘Disaster’ might sound a bit dramatic, but make no mistake, when ambiguity sets in, it becomes a big threat to the value the project will deliver to the client, regardless of the skills and experience in the room.

Fast forward to when the senior stakeholders reappear at first playback, or perhaps even at the end of the project. By this point, a whole host of decisions have been made by the project team and the original goalposts have shifted so much that the senior stakeholders are left puzzled at the output.

For me, this is a failure and should be avoided at all costs. If those who hold the purse strings are not confident on the deliverables, what chance do you have on securing future work?

Clear the path to a successful project

There are a ton of blog posts out there telling you that ambiguity is one of the leading reasons for project failure. There are also a load more offering tips on how to avoid it, as well as a whole bunch of posts devoted to suggesting that using an Agile methodology can actually cause ambiguity. This last point is of little surprise, especially if you’re a small agency working with a large corporation with too many stakeholders, most of whom are used to working in a traditional Waterfall method.

Never fear, there is a solution. Address these ambiguities early,with the right people, and you will ensure that everyone is on the same page from the off.

In the introduction above I mentioned that we used a particular approach to project framing with a recent client, and to great effect. During our Kickoff we sought to try and nip the ambiguity possibility in the bud and involve the key stakeholders and project sponsors in discussions around the approach and logistics. Interweaving these discussions with the big picture questions allowed us to address the often overlooked minutiae that lead to senior decision makers being kept in the dark.

We sandwiched these discussions in between two parts of the project setup: setting the project goal and looking at the KPIs. The approach that worked for us involved splitting the conversation in to four key areas; I’ve listed them below with a brief summary of the questions to ask and what the outcome should be.

1. Approach

This is the most important one and it should be handled with care - we are not trying to force ways of working, rather coax an approach that works for everyone. This may at first be unfamiliar to the client, but with the right guidance, a shared understanding can be easily achieved. In this instance we were hoping to run the project using a scrum framework. As a team, start by answering the following questions:

  • What methodology will we adopt?
  • What regular meetings or ceremonies will there be?
  • What are the key milestones?
  • Where will we be working?

2. Team

The key here is to identify who’s going to actually do the work and who will be needed from the client on a more regular basis. This is the time to establish a product owner and ensure they understand their role in the project. Answer these questions:

  • Who will form the core project team?
  • What are their roles?
  • Who’s responsible for delivery?

3. Stakeholders

You need to all be clear on who you need to keep updated on progress outside of the meeting room. There are a bunch of RACI (Responsible, Accountable, Consulted, Informed) exercises that can help with this. This will help back up the conversations around the team and highlight the roles of the stakeholders and what you expect from them as the project progresses. Ask yourselves:

  • Who do we need to keep consulted and informed throughout the project?
  • Who’s doing the work and who’s accountable?

4. Communication channels and tools

What tools does the client currently use? Are there any IT restrictions we should be aware of? Having a senior mind in the room really helps with this, as they are typically au fait with the restrictions in place. Answer these questions:

  • How do we contact each other throughout the project?
  • Who’s on the circulation lists?
  • What file storage system will we use?

When we did this with said recent client, each area was either a discussion or a small exercise with the aim of everyone agreeing on and answering the questions. By the end of the session, not only had we agreed on the vision and goal of the project but we’d also framed the logistics and roles within the wider team.

Get creative (and practical)

Involving the wider stakeholders allowed us to get a little creative about our ways of working. For example, it was suggested that we keep a private blog to document the work in progress which can be shared across the business, giving everyone of all departments a flavour of what we’re up to. This is exactly the sort of thing that can normally be overlooked by a core project team who are mainly focused on achieving sprint goals or working through a backlog.

We were also able to fast-track some of the, often time consuming tasks, such as finding desk space and ensuring we had building passes. These little (annoying) things often need senior stakeholder sign off which, once a project is underway, can take a while.

Yes, there is an argument that the small details should be kept between the core project team, because senior stakeholders don’t have the time to go in to the nitty gritty, but I say “NO!”

The nitty gritty is what helps clear the path for the big picture and nip any ambiguity in the bud before it takes hold.

Too often we shy away from inviting senior stakeholders to these kinds of meetings out of fear that they are too busy or it’ll be a waste of their time. Yes, they are often too busy, but no, it’s never a waste of time.

The key to getting this right is to keep it collaborative. Remember, from an agency perspective, you’re not forcing your ways of working on the client, you’re guiding them and easing them in to an agile way of thinking. By suggesting approaches and tools that help enforce these ideals, and compromising on areas that they are rigid about, you’re strengthening that partnership, which will help achieve better outcomes.

Senior stakeholders are the people that commission the project, so why keep them in the dark?

We’re keen to hear your thoughts, ideas and tips around project management - tweet us @clearleft- we’d love to hear from you!

]]>
Hot topics for Design Leaders in 2018 https://clearleft.com/posts/hot-topics-for-design-leaders-in-2018 Fri, 15 Dec 2017 17:26:00 +0000 https://clearleft.com/posts/hot-topics-for-design-leaders-in-2018 It’s that time of year (again). The festive season is upon us. The call of mince pies, rubbish TV, and awkward family gatherings grows louder.

But right now, the call of the holiday season isn’t as loud as the voice in my head that’s leapfrogging into 2018, curious about the world, and curious about the role design will play in all of our lives this coming year.

There are tonnes of important issues in design right now, covering the detailed nuances of hands-on delivery through to the sometimes abstract heights of strategy and leadership. If you’re a design or digital leader, these three focus areas (by the reckoning of the Clearleft team) will be amongst your chief concerns in 2018.

The rising importance of Artificial Intelligence and Machine Learning

Artificial Intelligence (A.I.) isn’t exactly the new kid on the block as far as hot topics go. There’s been an increasing amount of noise about it in 2017, and that noise will surely infiltrate our collective consciousness even more next year.

A.I. will be of particular importance to design and digital leaders who want to explore the bleeding edge of innovation and the effect that automation can have on productivity, cost and customer experience.

But this is about more than the seduction of new technology.

It might be history's greatest opportunity or its worst existential threat — or maybe it will only optimise what we’ve already got.

Andy Budd

Of course there are risks involved, because the technology is still so relatively early in its development. We’ve seen design leaders get sold on clever off-the-shelf machine learning tools that fail to deliver the improvements they promise, so it’s important not to see A.I. as simply a technology purchase, but as service innovation that helps empower your business.

Either way, the emergence of A.I. in the mainstream will move apace.

We explored the heady possibilities of a world of A.I. at our A.I. Retreat back in Norway earlier this year - take a look at the Juvet Agenda to discover a set of design principles you might like to use to inform your A.I. decision-making.

The rise of Design Ops

Design Ops, the infrastructure of teams, tools, governance and processes behind the design, still a relatively lesser-heard term in the field these days. But rest assured it will gain prominence and gather momentum in 2018 as more design leaders discover the business potential it has, and the value it adds to design projects.

Put simply, Design Ops empowers design leaders and teams to deliver better quality design, faster. Pretty pertinent in a world where the work is becoming more complex and more specialised, whilst companies are wanting to deliver faster and faster.

If you want to ensure that product improvements continue to be delivered, especially in the context of increasing demands on speed and quality, the only way to do it is to have good tools, processes and governance practices in place.

Rich Rutter

design system is the most visible representation of Design Ops—a toolkit that allows designers to work quickly and efficiently without compromising quality or consistency. But creating and maintaining a good design system takes up-front investment, and it can’t be delivered from the top down—the designers need to be invested in building the system.

The spotlight on user rights

2018 will be the year that GDPR comes into force.

I look at GDPR as like a ‘bill of rights’ for users, where the power balance between businesses and real people will see a tangible shift.

Jeremy Keith

That shift will be in the interests of the user, protecting all EU citizens from privacy and data breaches in an increasingly data-driven world.

People will have greater actionable control over their personal data. So of course this is an important issue for design leaders to tackle in the pursuit of human-centred design solutions.

For companies, the opportunity lies in nurturing trust with their customers, and enhancing company reputation in turn. I would argue that this is incredibly valuable. But beyond that there are no other great measures of success. Measures of failure, however, are tangible and of a reputational and financial nature.

The through thread

It struck me that there’s a central theme that runs through the heart of the focus areas above. Something bigger (and less tangible) is drawing these things together.

A.I. empowers business.

Design Ops empowers those who are using design thinking practices in their work.

GDPR empowers users.

These three hot topics, or ‘trends’ if you prefer, empower three different groups (albeit there’s plenty of crossover amongst them). In my opinion, true empowerment in these contexts requires a foundation of transparency and trust – ethical practice – surely the prominent  thread in these trends in the year to come.

So what can we all do, as individuals, teams, business and sectors, to engender that transparency and trust as we seek to tackle these issues and design challenges in our work and lives?

Acknowledge it and open up the conversation. That’s a positive step in the right direction, and a positive action in its own right.

One of our Leading Design 2017 speakers, Alberta Soranzo, tweeted about taking action on engendering trust recently, which seems pertinent to reference here too. If nothing else, it’s an action-based reminder for a basis on which to act and work with our peers on design challenges in the future. I was intrigued, too, to read about GDS’s recent data science ethical framework developments.

It will be interesting to see how these often elusive, intangible, and vital issues play a part and affect how we do things in design next year.

Let us know what design challenges you’ll be focusing on in 2018 - tweet us @clearleft - we’d love to hear from you!

]]>
Coming back to work https://clearleft.com/posts/coming-back-to-work Wed, 13 Dec 2017 11:24:00 +0000 https://clearleft.com/posts/coming-back-to-work Here on the Clearleft blog we share a lot about our experiences related to our client work, events, and different areas of expertise as practitioners. I want to take a moment to shift the focus and talk about culture, which affects everything.

My first couple of months back at work have come to an end and I’ve been reflecting on the transition from being a full-time mum of three to heading back into the world of work. (Well, paid work, three kids ain’t easy!)

Seeing as this is my first post, here’s a little back knowledge for you: I have a 6-year-old son, Oliver, and 11-month twins Albyn and Oren (as well as a 13-year-old step-son Sebastian, but he’s mostly self-sufficient these days).

This was my second time away from work on maternity leave, and so different to my experience first time round! Returning to work is so often a negative experience for both new mums and the employer. In my opinion, with very simple changes, it really needn’t be.

I recently read Jess Jebari’s post ‘Working Forward’ - all about removing barriers from the workplace and how Clearleft is proud to support working mums. I could not agree with this more - they have been with me every step of the way in making my return as smooth as possible.

Us mums, on the most part, go back to work because we want to, and would like to be able to come back confident that we still have career prospects. So often there is the feeling of becoming a burden, now that our time and attention is split between our two roles. The first few weeks leaving your baby are so scary, so it needs to be a comfortable transition or it won’t work.

Last time round

Looking back at my last time off on maternity leave six years ago, I was in a different career as a secondary school teacher. I returned to work when Oliver was only 5 months old. I felt pressured to go back as soon as possible for a combination of reasons: the feeling that I had increased the pressure and workload for my colleagues; my perceived disruption to the students; as well feeling the financial pressures of being a young mum of 25. I remember the feeling of complete and utter dread, right in the pit of my stomach, at the thought of going back and leaving my baby in a nursery so young.

Time off in term time was frowned upon, I relied on my mum and husband a lot, which wracked me with ‘mummy guilt’. I felt like I was letting my family down and letting my employer down, I couldn’t give enough of myself to either one.

Being in a job that is about educating children, you would expect there to be support for families. Yet I felt like I wasn’t allowed to be a mum. This was my experience of teaching. But teaching is not in the minority. I know many people in other industries that have felt the same on their return.

Eventually, the pressure to share myself between the two fairly, without one of them suffering, led to me leaving the profession altogether.

This time round

Let’s skip forward five years. I went into labour six weeks early and I hadn’t even started my maternity leave, but no one flinched. The team here wished me well and gave me oodles of support and some very nice choccies! I had been working for Clearleft for almost three years when I went on maternity leave and they gave me a great maternity package which allowed me to enjoy my time off with the twins.

I loved my time off, but felt excited to come back this time round - a completely different feeling from last time. I wasn’t worrying about teething issues with settling back in, and I knew that the team would understand. At Clearleft you get treated like an adult and the setup is flexible: no strict, set working hours, and when I am sick I’m not going to be penalised (you are actually encouraged to stay off and get well so you can work to your full potential, and not spread your germs to the rest of the office!). If I have childcare issues I know I can work around it, as long as you work hard and get the job done, the rest can be flexible. So in returning to work, I felt completely supported both in my job AND as a mum; what an amazing feeling!

Before my return, I had a few meetings, all positive and focusing on what Clearleft could do for me, what hours worked for me and how we could go about progressing my career.

I am on a fair few ‘mummy blogs’ and so many posts come up about how people go back to work to roles completely different to what they were doing before, with no prospects. Many mums have experience of being bullied in the workplace and made to think that they cannot have children and a career.

I am now into my second month back and there have been a few bumps along the way, but Clearleft has been nothing but supportive. As an employee this makes me feel valued and confident, which in turn gives me huge motivation and drive.

Three things that make a difference

Earlier in this post I spoke about the power of small changes in a situation like mine, and what a difference they can make.

In my experience, there are common feelings that crop up when you become a working parent and journey back to work - and these challenges, if left unchecked, can become seriously corrosive to the individual and to the company. Feelings like resentment if you’re returning before you’re fully ready, confusion (in communication and managing expectations and isolation), and feeling like you are failing, alone and not able to talk about it.

These are my top three changes to try and tackle these feelings:

  1. Manage expectations. Make sure that expectations from both sides are communicated, with the team and with clients. This way no one will be ‘let down’. This conversation should be ongoing. I always felt that I could get in touch and ask questions and update on my return to work situation.
  1. Support. I was supported in my right to take as much time off as I needed with my babies, no one made me feel that this was a burden and when I came back I was welcomed back into good position at work that suited me and the company. I feel valued so will work hard. Showing support and understanding in the transition back to work and allowing some ‘wiggle room’ in those early days is so important.
  1. A slightly bigger one - maternity package. I know for many companies this may be not possible, but in giving me a good maternity package Clearleft enabled me to enjoy my time off and be truly ready to come back, rather than be forced back before I was ready.

So in summary, not making me feel guilty about taking time out whilst having children and welcoming me back as an equal has empowered me to work harder. Surely that’s a win-win?

One last thing, if you’re interested in looking further into the life of a busy working mother this book by Tiffany Dufu is on my (ever increasing) reading list. http://tiffanydufu.com/.

]]>
What design teams are missing by doing everything in-house https://clearleft.com/posts/what-design-teams-are-missing-by-doing-everything-in-house Fri, 01 Dec 2017 08:56:00 +0000 https://clearleft.com/posts/what-design-teams-are-missing-by-doing-everything-in-house Over the past few years, we’ve seen more and more companies building internal design capabilities. This finally feels like the recognition our sector deserves; moving from an outsourceable commodity, to a core business competency.

But in the rush to prove their value, some companies are starting to suffer as a result…

In-house design presents a new set of problems.

I think it’s safe to say that the majority of companies still have more design work than they have designers. There’s a global shortage of designers at the moment, which makes it difficult to hire and retain the best talent. I regularly have conversations with design leaders who bemoan the challenges of growing, nurturing and retaining a team. It often takes six months to recruit a new designer and get them up to speed. With the average designer moving roles every 18 months, that leaves a very short window of productivity.

As a result, there will always be a market for pre-built design teams, made up of experienced designers who are able to deliver high quality work quickly. These sorts of teams are perfect when a company is facing a resource or time crunch, and needs to throw a project over the fence quickly.

I think this is how most organisations view design agencies, and it’s a sensible way of engaging. But I think internal design teams may be missing a trick here.

An agency can supercharge your in-house team.

In our experience, internal teams fall into a natural cadence of internal meetings, workshops, 1-on-1s and status updates. They also find themselves settling on tools, processes and procedures that maximise consistency and interoperability.

This all makes perfect sense. However, what starts as a logical and practical process of rationalisation, quickly becomes “the way we do things here”, and if you’re not careful, your team starts to atrophy.

Over the past six years, the bulk of our work has shifted from delivering standalone projects to augmenting internal teams. Sometimes this is just a capacity issue, but more often than not we’re being asked by design leaders to help them stretch the teams we’re embedded with and create an engine for internal innovation.

An agency can bring new tools, new processes and new ways of thinking.

In-house teams often get stuck in a particular cadence, and can feel trapped on the treadmill of Business As Usual. Injecting some external energy can do wonders for team moral, and their ability to deliver. So we usually leave teams with a renewed vigour and pace.

This is especially true for senior team members, who can quickly hit your internal glass ceiling. It’s hard to grow if you’re the most experienced professional in the room, so having an experienced external practitioner to bounce ideas off can be great for individual growth. By bringing somebody onto the team as a player-coach, it’s possible to provide new skills, speed up delivery and develop your key players all at the same time.

An agency can bring new perspectives and extensive operational experience.

Another benefit of partnering with an external agency is the sheer number of design teams they’ve worked over the years. So while a typical internal team member may have only worked with two or three other companies before, an external agency will have worked with dozens. That’s why external partners are in a great position to help recommend operational improvements.

Sometimes this is as simple as suggesting the creation of a new design language or pattern library. At other times it may be helping to improve internal workflow or governance strategy. Either way, having an external perspective–from somebody who has done the thing you’re struggling with a dozen times before– can be a boon to both newly minted and experienced design leaders alike.

An agency can help promote the value and impact of design around the organisation.

If design leaders are lucky, they’ll have a couple of senior practitioners they can work alongside on strategic initiatives. But more often than not their team are so focussed on product delivery that there is little time to strategise. We regularly find ourselves supporting design leaders with more strategic initiatives; everything from developing business cases and prototyping new product ideas, to creating a digital service manual and organisational vision.

These are the sort of things that internal teams often have going on the the background, but rarely find the time to execute. With a good agency partner delivering a whole program of improvements, these tasks become significantly easier.

This external support is especially helpful for design leaders looking to demonstrate the value of design to their board. In fact more of our coaching work is focussed on helping leaders manage up and out, than down. One of the reasons agencies like Clearleft are so effective at this is the fact that they’ve been selling the value of design to boards their entire life. So they’re well placed to work alongside internal design leaders to grow their influence and the impact design can have.

You don’t have to go it alone.

There are dozens of other ways a strategic design consultancy can help support internal teams, beyond simply outsourcing delivery. So when you’re considering partnering with an agency, don’t just think of them as a means of delivering a specific project, but as a team of individuals who have spent the past 12 years understanding, optimising and operationalising design-led teams.

I’d love to hear about your challenges and experiences of establishing design at the heart of your company–get in touch via Twitter or email to continue the conversation.

]]>
Travelling light https://clearleft.com/posts/travelling-light Mon, 20 Nov 2017 11:50:00 +0000 https://clearleft.com/posts/travelling-light Whenever I head off into the Great Outdoors I do like to be prepared, which is really just the Scouts way of saying ‘planning for the worst’.

Fortunately, ‘the worst’ for a few days away (certainly here in the UK) usually just means inclement weather with a fair certainty of rain, so with this in mind all of my ‘valuable’ (read not-exactly-waterproof items such as smartphone, car keys and wallet) go into a small dry bag which is duly stuffed into my rucksack.

The Light Phone

Unfortunately, the expensive brushed aluminium member of this group just doesn’t play well with being tossed around in the bottom of a pack and is certainly something I wouldn’t want to accidentally leave up a fell or behind a handy lunch-stop boulder. And one does have to question exactly what purpose my iWonder serves in the hills with guaranteed zero wifi, patchy mobile reception (at best) and no power source. Fancy camera and last-ditch emergency line?

One of main reasons I get away is to do exactly that – get away. Strip away all the trappings of modern life and escape to hills (or even just for a walk in the woods with our children) – perfect. Having an ‘emergency’ phone is often a good idea, but an expensive yet redundant-under-the-circumstances-computer-in-my-pocket, maybe not so. Do we really need all this functionality available all of the time? Will I be checking my email in the woods? Perhaps the question is really ‘should I be checking my email in the woods?’. Stepping back from our connected lives and providing ourselves the opportunity to disconnect is certainly a topic de jour, but maybe we need a little help in only being able to access the ‘right’ services at the ‘right’ time, guiding us to place our time and attention on the things that matter, when they matter?

As I sit and write this nursing a drink in the pub, glancing around the numerous groups of friends deep in conversations with their smartphones, it makes me wonder just how many situations could benefit from a reduction in tech availability – as much as I love technology, the changes in our social behaviours, skills and interactions have definitely suffered as a result of its prevalence.

It seems sadly ironic that we might ‘need’ technological solutions to encourage us to use technology less, but if we do need help getting offline, then a great place to start could be The Light Phone – a replacement phone that uses your existing phone number and allows you to leave your smartphone at home. The Light Phone only makes and receives calls and is ‘designed to be used as little as possible’, something which helps to reinforce the idea of switching off and getting away from it all. The entire design is produced to this end – light in physical form, but also a sleek piece of minimal engineering, ideally suited to the phone’s limited functionality. The result is not only aesthetically pleasing, but one that appears to seamlessly combine form, function and great intention all in one palm-sized package. Beautiful.

I was recently reminded of The Light Phone (and similar ‘less-tech’ projects such as the re-release of the iconic Nokia 3310) when packing my dry bag for a few days away, and it turns out that the original Kickstarter project from 2015 has been fully funded and orders are currently being fulfilled. So, if you’re in need of a connection break, more focussed pub conversation or a low(er)-cost-out-in-the-hills emergency option (although $150 does seems a touch steep) maybe The Light Phone is the thing for you.

However, this all said, you could always throw caution to the wind, leave your smartphone at home and follow in the words of the late, great J.J. Cale – “…travelling light – it’s the only way to be.”

This was originally posted on my own site.

]]>
A dive into serving brotli compressed assets https://clearleft.com/posts/a-dive-into-serving-brotli-compressed-assets Thu, 16 Nov 2017 17:02:00 +0000 https://clearleft.com/posts/a-dive-into-serving-brotli-compressed-assets Addy Osmani’s talk about performance at the last FFConf had a small segment on serving brotli compressed assets, as opposed to gzip.

The claims are that brotli produces smaller filesizes than gzip, so if you want to squeeze some extra performance out of your site, then just switch over and reap those rewards! The talk, however, was light on the implementation details. Well, I decided to take a look to see how easy the switch would be.

First, the TLDR. Skip ahead for the full details.

The compressed version

There is currently no simple switch for brotli compression. Brotli is only useful for text-based files and it requires HTTPS. WOFF2 fonts are already compressed using brotli as part of the file format. You need to use high compression settings to get any real benefit, which is slow, so you need to pre-compress assets as part of your build step.

Ultimately use a CDN like Cloudflare because, firstly, you get all the benefits of a CDN and, secondly, they automatically use brotli where applicable. I’m currently only aware of Cloudflare supporting brotli. YMMV.

The uncompressed version

Still here? You must be serious about compression (or you can’t use a CDN). Well then, let’s dig in!

Brotli is a relatively new compression algorithm developed by Google and released into open source back in September 2015.

Whisperings around the internet had lead various people to believe that while Brotli could result in compression improvements of 20-25% or more, it was also a lot slower. As usual, this doesn’t tell the whole story. Both gzip and brotli can compress at various levels, much like jpeg quality settings. gzip goes from 1-9 and brotli goes from 1-11 (yes it goes up to eleven). When you compress a file with gzip, it defaults to around 4, providing a good balance of compression and speed. Brotli, however, defaults to 11; the highest compression but much slower.

If you were to compare resulting filesizes you would only need brotli level 4 to achieve the same compression as gzip level 6, and the speed should be comparable (I’ll run some benchmarks in the near future to get a better idea). The main difference is that gzip’s higher compression levels take longer to compress but only produce minor improvements, whereas brotli scales better as you increase its level. So, going above gzip level 6 is simply inefficient, but pushing brotli to level 11 is more worthwhile.

A default server setup will compress assets on-the-fly. At gzip level 4, you will a good speed/compression balance and the performance hit to the server is negligable (unless you run a high-traffic site). Switching to brotli level 6 or 7 would net you minor gains at no real detriment. To get the real gains, though, you need to go up to eleven. And that means pre-compressing. More on that below.

As mentioned earlier, brotli is used to compress fonts in the WOFF2 file format. Browser support for other types of file compressed with brotli is actually pretty good these days. All the latest browsers on the latest OSes have support.

Server support is, however, weak. Depending on your server setup, you may not be able to use brotli at all yet. Some web hosts might be experimenting with brotli and may have it on by default. If you use a managed server then contacting their support is your next step. Otherwise, you’ll be needing a self-managed hosting provider like Digital Ocean, Linode, etc…

Adding Brotli support

It appears that Apache does have an official brotli module now (https://httpd.apache.org/docs/2.4/en/mod/mod_brotli.html), but only if you’re using one of the more recent releases (2.4.26+) which may not be available for your OS yet. Nginx still does not have brotli support built in. So that’s hurdle number one. Here, at Clearleft Towers, we use nginx with PHP being proxied to Apache. As nginx does all our heavy lifting I’ll be focusing there.

So, how do we get nginx to support brotli? If you compile your nginx from source then you can add the module during build. Full details here: https://www.babak.io/blog/how-to-build-nginx-with-brotli-support-ubuntu-1604-xenial-xerus.

We try not to compile packages if possible. It just adds extra headaches and we’re not sysadmins. Luckily, there is a way to get a pre-built module which can be dynamically loaded into nginx on our Ubuntu server (and most other linux OSes), which is to use a ppa; archives of unofficial pre-built packages which provide newer or custom builds beyond what the OS would recommend for the majority of users.

We can add this ppa with

sudo apt-add-repository -y ppa:hda-me/nginx-stable
sudo apt-get update

then install all brotli related packages with

sudo apt-get install brotli nginx nginx-module-brotli

the ppa will also take over your normal nginx package, so if you don’t install nginx here, then the next time you update your packages it will update nginx anyway.

Then, to activate brotli, load up your nginx.conf file and set the brotli modules to load in dynamically near the top of the file:

### ngx_brotli filter module - used to compress responses on-the-fly.
load_module modules/ngx_http_brotli_filter_module.so;
### ngx_brotli static module - used to serve pre-compressed files.
load_module modules/ngx_http_brotli_static_module.so;

Then underneath your gzip configuration in the http context, add the configuration:

# Brotli
brotli              on;
brotli_comp_level   6;
brotli_min_length   256;
# text/html is always compressed
brotli_types
  application/javascript
  application/json
  application/xml
  image/svg+xml
  text/css
  text/plain;

then restart nginx.

In the settings above, we set the compression level to 6, make sure we don’t compress files smaller than 256b (where the resulting file would be bigger) and limit the file types to those we can actually compress. Some guides on the internet tell you to use brotli_types *. Don’t do this.

Provided you’re serving your content over HTTPS, you’ll now be serving brotli compressed files! …mostly.

Actually, if you’re like us and proxy to Apache then the resulting HTML from PHP will be compressed by Apache first which means that nginx won’t attempt to recompress it. It will be served as gzip as usual. The easiest fix for this is to disable Apache’s compression module, deflate:

a2dismod deflate

Now nginx will compress the HTML too.

Precompression

To get the real benefit of brotli, we need to compress the assets ahead of time so that we can use the highest level of compression and then configure the server to look for these files.

The easiest way to generate the precompressed files is by rolling it into your front-end build. Using gulp as an example, first install the gulp-brotli package

npm install gulp-brotli

then load it in and configure a gulp task

const brotli = require('gulp-brotli');
 
//...

gulp.task('brotli', () => {

    let src  = "public/assets/**/*.{html,js,css,svg}";
    let dest = "public/assets";

    return gulp.src(src)
        .pipe(brotli.compress({
            extension: "br",
            quality: 11
        }))
        .pipe(gulp.dest(dest));
});

Run it with gulp brotli or add it to your task set (after all other tasks since you want to compress the post-processed css and js). The above code will check for all file of those types and then save the compressed versions back into the folder where it finds a file to compress.

Now you can turn on brotli static in your nginx.conf file by placing

brotli_static on;

underneath the other brotli configuration. By default it will look for files with a .br extension e.g. all.css.br. I don’t think you can change that behaviour.

I haven’t researched a way to pre-compress the html coming from Apache yet, so for now that will remain compressed on the fly.

I hope this has been informative and happy brotling… brotli-ing… brottling… compressing!

Originally published on my own site

]]>
12 Weeks at Clearleft https://clearleft.com/posts/12-weeks-at-clearleft Wed, 15 Nov 2017 13:34:00 +0000 https://clearleft.com/posts/12-weeks-at-clearleft I have to admit, I was a little nervous as I rang the doorbell of Clearleft on day one of my 12 week placement.

Such a smart and successful bunch of UX and digital design veterans had agreed to share their wisdom with l’il ole me, a mature student in the final phase of an MSc in UX design. My main priority was to get through the day without embarrassing myself or giving them cause to regret inviting me to join their ranks. 

The plan for my next three months was to complete my major degree project, which involved creating and testing a design prototype, on a topic that would provide value to the Clearleft team. James Bates and I had batted a few ideas around but nothing was concrete yet.

GETTING TO GRIPS WITH THE WORK AHEAD!

I spent some time in my first few weeks having one-to-ones with any member of the team that could spare 20 minutes, which was a great way to break the ice and understand how all the elements of the agency machine work together. I was impressed by how multi-skilled every team member is, with expertise reaching well beyond the scope their job titles might suggest. This ‘T-shaped’ approach is something that is at the heart of how Clearleft operates and has no doubt played a part in developing the high level of mutual respect and camaraderie that exists within the team.

One piece of sage advice I got in the first week - I forget whether from Jeremy or Richard (or both) - was “You might not be invited but you’ll always be welcome”. It became clear early on that there wouldn’t be any hand-holding at Clearleft, so if I wanted to get the most value out of this experience, I needed to find my own ways to get included. I started scanning through the meeting room calendars to see what projects or workshops were coming up that I could observe or participate in. This was a great way to get involved in projects that I wouldn’t have otherwise had the opportunity to work on - a useful learning hack for any juniors in a similar position.

WORKING WITH THE CLEARLEFT AND VIRGIN HOLIDAYS TEAMS.

I was fortunate to get the chance to participate in several design sprints, one with the BBC and two with Virgin Holidays (although one of the Virgin projects was actually three weeks long, so it’s arguable whether the term ‘design sprint’ strictly applies there). This gave me the opportunity to get fully immersed in these projects and observe how the team approach collaborative client sprints. I found it interesting to see which UX methods they chose to help us reach our project goals and I learnt a few useful new techniques along the way.

IN FULL STICKY NOTE MODE FOR THE VIRGIN HOLIDAYS DESIGN SPRINT!

After discussion with James Box and the UX team, I decided to focus my project on devising a toolkit to enable the sharing of materials on UX techniques. Initially my focus would be to develop an internal system for the team to use but with a longer term goal of opening it up to the wider UX community. This was a great opportunity to delve deeper into a wide range of techniques and learn how expert practitioners choose which ones to apply. Getting input from the Clearleft team was hugely valuable throughout the project and the advice I received really helped me to grow as a UX designer. I’m planning to build the toolkit over the next few months so hopefully it will be coming to a screen near you in 2018.

I learnt a huge amount in my time at Clearleft, observing practitioners at the top of their game, working with some fantastic clients and developing my own skillset as a result.

Here are a few more of my takeaways:

“It depends” can and will be used to answer almost any UX question.

I had realised that there are many shades of grey in the world of UX, but I gained a deeper appreciation of just how comfortable with uncertainty UXers need to be. “It depends” is actually the only responsible answer to many questions, as nobody can ever truly predict how users will behave.

Grey highlighters can improve literally any sketch.

My drawing skills are yet to be successfully fine tuned (I flunked my art GCSE), but in the meantime I have grey highlighters on my side. I don’t leave home without them.

Design sprints are exhausting.

Especially when they’re three-week long (sort-of) sprints. Focusing all your efforts on collaborating with your teammates is a tiring business, so if you’re not feeling drained by the end of the day you’re probably not doing it right.

Everybody works totally differently and that’s ok.

Each practitioner uses different tools, techniques, thought processes and styles, but they often achieve the same goals. I realised that as I develop as a UXer, I need to find my own path that resonates best for me, rather than trying to copy anyone else’s.

My time at Clearleft made a huge impression on me and I’m so grateful to have had that opportunity. I now have a clearer sense of how I want to develop my skills as a UX practitioner and I’m excited about the journey ahead.

Find Kate on Twitter @katerickard_x

]]>
Leading Design 2017: A Volunteer’s View https://clearleft.com/posts/behind-the-scenes-at-leading-design-2017-a-volunteers-view Thu, 09 Nov 2017 11:56:00 +0000 https://clearleft.com/posts/behind-the-scenes-at-leading-design-2017-a-volunteers-view This is an edited version of a post written by Kate Rickard, who recently did a three-month work placement at Clearleft whilst completing her MSc in UX Design. Kate also helped out as a volunteer at Leading Design 2017…

Leading Design 2017 was my first experience of a Clearleft conference and I had high expectations. As a team with such a sharp focus on quality, I knew the Clearlefties would hold the bar high for themselves to deliver a world-class event, but I didn’t realise just how high.

The speaker line-up for the two days of talks was stellar - even pulling in the legendary Tim O’Reilly - but what I found really encouraging was how many inspirational women were on the bill.

Janice Fraser gave a fascinating talk on women in leadership, which was the stand-out session for me. I spent much of it with my mouth gaping open in horror at how much harder it still is for women to succeed in senior roles.

Janice Fraser Leading Design 2017
Janice Fraser. Image by Luca Sage.

Another favourite speaker for me was Dan Willis, whose high energy and sharp wit made for an entertaining and enlightening talk. I particularly like this photo of one of his opening slides, giving his observations about the audience. 

Dan Willis. Image by Luca Sage.

Kim Lenox of LinkedIn also gave a ‘ruthlessly optimistic’ presentation, which clearly came straight from the heart. This was a surprisingly common theme, with many presenters baring their souls when sharing their experiences. The message that a balance of logic and empathy is the recipe for successful leadership came through strongly as a theme. This feels like sound advice, which can be applied by people at any level of seniority within any field.

Another valuable part of the Leading Design event was the networking opportunities. Both drinks parties were rammed with attendees for several hours (a rarity in this type of event in my experience) with many high-profile speakers choosing to mingle with the audience at length. Some of the advice I received and conversations I had were truly insightful and will no doubt prove invaluable in my career development. It was a privilege to spend time with such a smart, genuine and open bunch of people.

Busy times at the day one drinks party. Image by Luca Sage.

The final day of the conference was split into morning and afternoon workshops, with two to choose from in each slot. Julia Whitney talked about the science of influencing, providing evidence that inspiration is the number one method to encourage commitment from others*. The carrot, rather than the stick, clearly works much better in this regard. The afternoon workshop was run by Alberta Soranza and Martina Schell, who talked about how to measure the skill set of the team, structure roles effectively and recruit the right people. They showed this cheeky graphic to demonstrate how there may be less obvious aspects of work relationships that can impact on the team dynamic.

REAL ORGANISATION CHART - FROM MARTINA AND ALBERTA'S WORKSHOP.

The experience of volunteering at a conference like Leading Design is many things: surprising, fun, educational, motivating, exhausting, rewarding, stressful, waistline-expanding, humbling and inspiring. I got the opportunity to spend time with some fascinating attendees, inspiring speakers and fabulous volunteers. I learnt game-changing leadership techniques that will no doubt serve me well in the future, and I was able to reflect and understand situations from my past much more clearly. I know I wasn’t the only one, as more than one attendee described the event as ‘transformative’ to their working life. If that isn’t high praise then I don’t know what is.

Roll on Leading Design 2018!

Read the full edit of this post, which was originally posted here. Follow Kate on Twitter @katerickard_x

*Reference: http://amj.aom.org/content/35/3/638.short

]]>
The Life Saving Effects of List Making https://clearleft.com/posts/the-life-saving-effects-of-list-making Tue, 07 Nov 2017 10:03:00 +0000 https://clearleft.com/posts/the-life-saving-effects-of-list-making I’m just over a month in as a Clearleftie and it’s high time I got my first blog post out. Having pondered a few potential subjects for my first post, listing the merits of talking about different ways to run agile ceremonies, or exploring some role mapping exercises, I landed on (ahem) list making.

Welcome to Clearleft and the importance of a bloody good list.

There are several stages to writing a list. First there is the gentle thrill of anticipation as I contemplate the pristine paper in front of me. I may not yet have a subject for my list, but just the thought of one gives me a sense of purpose.

Extract from Jane O'Brien's BBC article: The art of list-making

As a project manager, setting up projects are my bread and butter, although everyone (and every place of work) does things differently. Having worked at a few agencies, I’ve noticed a pattern of the same boxes needing to be ticked before you can kick off a project. But what about those subtle nuances, the ones embedded in an agency’s specific process and culture? The little things that long serving veterans of the company have, over time, come to expect and take for granted. Missing one of these important preliminary actions from your setup can have a detrimental effect on the project team’s shared understanding and the overall success of the project.

List making is a dying art, but when you are starting out at a new agency, learning and adapting to it’s existing processes (and maybe adding a few of your own), it’s not only a box ticker, it’s a life saver!

Use a list to traverse the subtle nuances of agency process

Let’s start with the items we all know need to be complete before a project can be confirmed for kick off in almost any agency:

  • A Signed SOW from the client
  • A PO
  • Client’s account details
  • Booking the resource needed
  • KO date
  • Project tracking tool setup

Now, let’s look at the items we all know we need to complete before a project can be confirmed for kick off but the process behind them vary from agency to agency:

  • A Signed SOW from the client
  • A PO
  • Client’s account details
  • Booking the resource needed
  • KO date
  • Project tracking tool setup

No difference, right? Most agencies follow the same project setup checkpoints but the systems in place to perform those actions can vary wildly. Some agency’s require a 50% deposit on signature of the SOW, some agencies don’t, some request the full project amount be paid up front. What about tracking time and scheduling resource? Generally speaking, an agency and its finance, leadership and practitioner teams will have a preferred tool of choice along with a license to use it. And you can be sure that it’ll be deeply embedded in their reporting and finance set up, so any misuse can be disastrous. Then there’s the project management tools, Jira, Trello, Asana, Basecamp… The possibilities here are endless and worth a blog post in and of itself around the pros and cons. So, what better way to ensure these subtleties are captured then a project initiation checklist?

Use a list to avoid the pitfalls of a handover and fill in the gaps

Luckily for me, Clare and the the team at Clearleft were prepped and ready for a new starter and had created and honed a project initiation checklist that captured all of the subtleties in an easily digestible format. What’s the task, what’s it’s purpose and who’s responsible for it.

As any agency scales up, documenting these processes becomes necessary and as new people join, new lists form. We’ve mentioned the steps to initiate a project but what about closing a project or something more abstract, such as listing ideas for running agile ceremonies? As these lists are formed, a shared understanding of agency processes is developed and small but essential actions in a process, such as Has a team slack channel been setup, are given equal weighting and not left sidelined.

Use a list to keep bother to a minimum

It’s an age old line for new starters - “There is no such thing as a stupid question”. Yes this is true, but let’s try and provide an answer for it before it needs to be asked. Using the project initiation checklist as a to-do allowed me to confidently set up my project, without the need to hassle anyone on the minor details and safe in the knowledge that I was ticking all the right boxes along the way.

Final thoughts and a few handy tips...

It’s important to note at this point that lists such as these are not bibles. Lists in their essence can be added to, amended and further refined as processes become obsolete or more efficient methods become apparent. Allow for collaboration. Having these lists in a tool like google docs can help instil this idea or running a workshop and getting these ideas on post-it’s first can be a great starting point for mapping actions.

Keep your lists clear and to the point. The nature of a list is to address the key actions in a given process. Try not to over embellish the small stuff.

For the ultimate guide to list making, check out the Checklist Manifesto by Atul Gawande. Samuel Thomas Davis, in his blog summarises it nicely in three sentences:

  1. Checklists protect us against failure.
  2. Checklists establish a higher standard of baseline performance.
  3. In the end, a checklist is only an aid. If it doesn’t aid, it’s not right.

Fortunately for me, Clearleft have a culture of collaboration, autonomy and knowledge sharing, perfect conditions for an agile PM to flex his list making muscles and start putting some of his own experiences down on paper!

In case you’re interested… Jane O’Brien’s BBC Article: The Art of List Making

]]>
Components, Assemble! https://clearleft.com/posts/components-assemble Mon, 06 Nov 2017 15:41:00 +0000 https://clearleft.com/posts/components-assemble When we write HTML, we try to ensure that each fragment serves a specific purpose. Despite this, sometimes those fragments can end up being quite complex. They can have many levels of nested children. They might have a variety of content and states that interact in ways that are hard to predict.

Imagine, if you will, a typical navigation menu on a typical website, with submenus when we hover over a link. We might at first try to build it as a single isolated component. If we use a pattern library, this is easy to do. But how we choose to structure our component within the pattern library has a big impact on how easy it will be to test and update it.

A navigation menu in Enabled, Current Item, Selected Item, and Js-Disabled states. We can simplify testing by assembling it from smaller components, and creating separate variants for each state.

Building it as single component has the advantage of being quick - as long as you know the exact content. But if you’re using a CMS, your menu can contain an arbitrary number of links. The length of a given line of text can vary across a huge range. And of course, the component relies on Javascript for some of its states. Your component might work well for the initial set of content you’ve defined but in many other instances it will most likely misbehave. Testing each combination of state and content is a manual process, prone to error. We must add and remove links; hover over each item in turn; disable and re-enable javascript on the page. Finally we run accessibility checks after each change.

This state of affairs doesn’t seem ideal. What happens if we break down our components into their smallest constituent parts? If we structure them all with modularity in mind? If we set up our component preview files to account for missing resources? Our components will gain a super power: Ultra Testability!

Some of the parts that make up the navigation menu. I created and tested individual links, headers, sections, and list items.

We build from the smallest units up. We can now check each part with its own inherent states in isolation. We can immediately see where regressions, combinatory errors, or edge cases crop up. We make no assumptions about where these units fit within the larger structure. As a result, we can use these smaller pieces elsewhere without modification. Once we’ve created all the parts, assembling the whole is as simple as putting them together. Then we need test only the states of the larger assembly. The result is robust, flexible, and easy to change. Congratulations, you have created a Super Component!

Thunder Megazord, fully assembled

Tiny Lessons

I’ve found it useful to create content generators for creating specific text when you want it, or random text if not. You can set ranges of likely text or item lengths to keep things reasonable. The node library faker.js is helpful for this.

]]>
The dConstruct Audio Archive works offline https://clearleft.com/posts/the-dconstruct-audio-archive-works-offline Thu, 02 Nov 2017 15:47:00 +0000 https://clearleft.com/posts/the-dconstruct-audio-archive-works-offline The dConstruct conference is as old as Clearleft itself. We put on the first event back in 2005, the year of our founding. The last dConstruct was in 2015. It had a good run.

I’m really proud of the three years I ran the show—2012, 2013, and 2014—and I have great memories from each event. I’m inordinately pleased that the individual websites are still online after all these years. I’m equally pleased with the dConstruct audio archive that we put online in 2012. Now that the event itself is no longer running, it truly is an archive—a treasury of voices from the past.

I think that these kinds of online archives are eminently suitable for some offline design. So I’ve added a service worker script to the dConstruct archive.

The dConstruct Audio Archive is now a Progressive Web App: https://archive.dconstruct.org/ Now you can enjoy those great talks offline!

Caching

To start with, there’s the no-brainer: as soon as someone hits the website, pre-cache static assets like CSS, JavaScript, the logo, and icon images. Now subsequent page loads will be quicker—those assets are taken straight from the cache.

But what about the individual pages? For something like Resilient Web Design—another site that won’t be updated—I pre-cache everything. I could do that with the dConstruct archive. All of the pages with all of the images add up to less than two megabytes; the entire site weighs less than a single page on Wired.com or The Verge.

In the end, I decided to go with a cache-as-you-go strategy. Every time a page or an image is fetched from the network, it is immediately put in a cache. The next time that page or image is requested, the file is served from that cache instead of the network.

Here’s the logic for fetch requests:

  1. First, look to see if the file is in a cache. If it is, great! Serve that.
  2. If the file isn’t in a cache, make a network request and serve the response …but put a copy of a file in the cache.
  3. The next time that file is requested, go to step one.

Save for offline

That caching strategy works great for pages, images, and other assets. But there’s one kind of file on the dConstruct archive that’s a bit different: the audio files. They can be fairly big, so I don’t want to cache those unless the user specifically requests it.

If you end up on the page for a particular talk, and your browser supports service workers, you’ll get an additional UI element in the list of options: a toggle to “save offline” (under the hood, it’s a checkbox). If you activate that option, then the audio file gets put into a cache.

Now if you lose your network connection while browsing the site, you’ll get a custom offline page with the option to listen to any audio files you saved for offline listening. You’ll also see this collection of talks on the homepage, regardless of whether you’ve got an internet connection or not.

So if you’ve got a long plane journey ahead of you, have a browse around the dConstruct archive and select some talks for your offline listening pleasure.

Or just enjoy the speediness of browsing the site.

Turning another website into a Progressive Web App.

This was originally posted on my own site.

]]>
The Relationship Between Service Design and UX Design - Part 2 https://clearleft.com/posts/exploring-the-shared-spaces-of-service-design-and-ux-design-part-2 Tue, 24 Oct 2017 08:00:00 +0000 https://clearleft.com/posts/exploring-the-shared-spaces-of-service-design-and-ux-design-part-2 This post was written by former Clearleftie and intern extraordinaire, Sebastien Chung. Seb spent part of his internship exploring the relationship between Service Design and UX Design - an intersection with increasingly blurred boundaries…

Part 2 - Written by Sebastien Chung.

Exploring the Shared Spaces of Service Design and UX Design

In my last post I discussed how to the rise of digital services has lead to an increasing overlap in the areas of Service Design and UX design (if you haven’t read the previous post you can take a look at it here). One way of exploring this overlap is to begin to look at the shared tools, processes and methodologies that we designers use when approaching our projects.

An internal workshop was conducted with Clearleft’s design team to understand the tools and methods that UX designers use throughout their digital design process.

A Digital Service Design Toolkit

UNDERSTANDING PROCESSES AND METHODOLOGIES.
UNDERSTANDING PROCESSES AND METHODOLOGIES.

A blank board was created with a high-level outline of stages of the design process. Stages included Strategy, Research, Analysis, Design, Prototype & Launch. Clearlefties’ UX designers were asked to write methods individually on sticky notes before attaching to the board. Methodologies were then discussed, compared, and contrasted as a group.

Processes and methods commonly used in Service Design were then mapped onto a separate board of the same high-level project stages. These tools were gathered from a number of Service Design resources and conversations with Service Design practitioners as well as from my own experience and those of the Clearlefties’ design team.

COMPARING AND CONTRASTING DISCIPLINES.
COMPARING AND CONTRASTING DISCIPLINES.

The processes of Service Design and UX were combined on a single board and grouped according to their purposes and outcomes. The groupings revealed insights into common approaches, aims and practices throughout the design process.

The relationship between these elements can be seen on the infographic below. This visualisation shows the shared methodologies and processes used in Service Design and UX Design. Looking at the processes from Service Design and UX Design mapped in this way it does seem apparent that there are more similarities than differences between the disciplines.

AN ILLUSTRATION OF THE SHARED SPACE BETWEEN UX AND SERVICE DESIGN
THE SHARED SPACE BETWEEN UX AND SERVICE DESIGN.

In order to design meaningful Digital Services it’s becoming increasingly necessary to draw from the toolkits of both the Service Designer and the UX Designer.  

Combining the processes and methodologies used in Service Design and UX Design, I have collated a toolkit of helpful techniques that can be used throughout a Digital Service Design project. (Note: The tools in the Digital Service Design Toolkit are taken from a wide range of resources some of which have been listed below.)

This Digital Service Design Toolkit groups the tools under the familiar titles of strategy, research, analysis, prototype and launch/handover, suggesting the stages that tools might be useful for the designer. Enabling approaches to problems at various levels of zoom and focus, it covers techniques that can help to delve into the details of digital touch point or create a holistic end-to -end view of a customer journey.

DIGITAL SERVICE DESIGN TOOLKIT.
DIGITAL SERVICE DESIGN TOOLKIT.

Highlighting the shared space between disciplines can, hopefully, increase understanding and aid collaboration between the various design communities, whilst making available a variety of techniques aimed at creating services with meaningful, digital-focused customer experiences.

It could be the start of a collaborative piece of work to be be iterated, developed, and improved according to the emerging needs of Digital Service Design projects.

Perhaps it can help guide a Service Designer to better understand the customer’s experience of an important digital touch point or help a UX practitioner to find a usable process to see where a project fits within the wider context of a customer journey.  

It might just be viewed as trying to make sense of the huge mass of design tools and processes floating around in the ether but, however this toolkit is received, hopefully it will be used to aid the design of Digital Services and in some ways promote discussion and communication between design communities.

Read The Relationship Between Service Design and UX Design - Part 1, here. 

Resources used in the creation of this post include:

This is Service Design Thinking, Stickdorn & Schneider    Service Design, Polaine and Reason

http://servicedesigntools.org/  http://liveworkstudio.com/tool…  http://nform.com/cards

]]>