Clearleft | Blog https://clearleft.com/posts/ The latest news from Clearleft en-gb Mon, 10 Dec 2018 17:34:27 +0000 Mon, 10 Dec 2018 17:34:27 +0000 How Readable? https://clearleft.com/posts/how-readable Fri, 07 Dec 2018 17:24:00 +0000 https://clearleft.com/posts/how-readable When I was younger, my favourite meal was pasta with cheese sauce. Not just any cheese sauce though. It had to be Bisto.

Bisto granules, once dissolved in water, made a gloopy faux-cheese suspension, that coated your entire mouth with delicious chemicals and left a horrible, but strangely satisfying, cheesy film in it’s wake.

One day, I tucked into a big bowl of cheesy pasta and realised that something was missing. They’d improved the recipe. The cheesy film was no more. Someone had decided that it was a bug, not a feature, and had got rid of it. I disagreed. As I pushed my plate of pasta away, I decided it was different, and I hated it.

A lot of what we prefer is subjective. It’s not necessarily better, it’s just what we’re used to or how we’ve always done things.

Last week whilst pairing, Jeremy and I were refactoring some code and discussing whether to use a ternary operator or an if else statement.

I wholeheartedly preferred the ternary operator, I’d learnt about ternary operators recently, so it was new, shiny, concise and writing it made me feel clever. But when Jeremy reframed the question and asked which I found more readable, I had to concede that I preferred the if else statement.

if ( condition ) {
  value if true;
} else {
  value if false;
}

But why did I prefer reading the if else statement? Was it actually more readable, or was it just familiar? When I broke it down, I liked that it was laid out in the same way as we read, top to bottom, left to right. If the condition is true, do this, else, do that.

condition ? value if true : value if false 

When I read the same code written as a ternary operator, my eyes darted around a bit. I had to look for the “if” in the form of a question mark, then look backwards to find the condition, then follow the line forwards to find out what the result of the condition will evaluate to.

Additionally, I found when the condition or the values were lengthy, having them all on the same line was confusing.

But are these feelings objective, or are they just shaped by my own experience? Do other people feel the same way? Are some things universally more readable than others?

Daniel Berzon is currently trying to answer this with howreadable.com. Considering that developers spend more time reading code than writing it, at an estimated ratio of 10:1, it’s definitely an important topic, and a project to keep an eye on.

]]>
Prototypes and production https://clearleft.com/posts/prototypes-and-production Mon, 26 Nov 2018 17:02:22 +0000 https://clearleft.com/posts/prototypes-and-production When we do front-end development at Clearleft, we’re usually delivering production code, often in the form of a component library. That means our priorities are performance, accessibility, robustness, and other markers of quality when it comes to web development.

But every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping.

There are plenty of non-code prototyping tools out there, and our designers often reach for them to communicate subtleties like motion design. But when it comes to testing a prototype with real users, it’s hard to beat the flexibility of HTML, CSS, and JavaScript. Load it up in a browser and away you go.

We do a lot of design sprints, where time is of the essence. The prototype we produce on the penultimate day of the sprint definitely won’t be production quality, but it will be good enough to test.

What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.

So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It’s almost like I have to flip a switch in my brain to change tracks.

When a prototype is successful, works great, and tests well, there’s a real temptation to use the prototype code as the basis for the final product. Don’t do this! I’ve made that mistake in the past and it always ends badly. I ended up spending far more time trying to wrangle prototype code to a production level than if I had just started from a clean slate.

Build prototypes to test ideas, designs, interactions, and interfaces …and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

Of course it should go without saying that you should never, ever release prototype code into production.

And yet…

More and more live sites seem to be built with a prototyping mindset. Weighty JavaScript frameworks are used regardless of appropriateness. Accessibility, if it’s even considered at all, is relegated to an afterthought. Fragile architectures are employed that rely on first loading and then executing JavaScript in order to render basic content. Developer experience is prioritised over user experience.

Heydon recently highlighted an article that offered this tip for aspiring web developers:

As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like span and how they differ from block ones like div.

That’s perfectly reasonable advice …if you’re building a prototype. But if you’re building something for public consumption, you have a duty of care to the end users.

This was originally posted on my own site.

]]>
Vote 100 – a victory for equality but not all's won https://clearleft.com/posts/vote-100-a-victory-for-equality-but-not-alls-won Wed, 21 Nov 2018 09:21:00 +0000 https://clearleft.com/posts/vote-100-a-victory-for-equality-but-not-alls-won Today marks 100 years since Parliament passed the Parliament (Qualification of Women) Act which allowed women to become Members of Parliament for the first time. This was a logical outcome of the law passed earlier in 1918, which allowed some women, and all men, to vote for the first time.

Allowing women to vote and sit as an MP was clearly an important step towards equal rights for all (although it wasn’t until 1928 that women would have equal voting rights with men). It was also an early stride in the drive for diversity in the workplace, especially once Nancy Astor became the first woman to sit as an MP in the House of Commons, in 1919.

Vote 100
#Vote100 celebrates the anniversary of votes for women

Now we have a female prime minister, and 209 out of 650 MPs are women, which is not bad in the grand scheme of things. It’s certainly better than the tech sector where the proportion of women sadly remains around 16%.

As a digital design consultancy, Clearleft sits within both the tech and design sectors. According to recent Design Council research, 22% of the UK’s design workforce are female - compared with 47% of women in the wider UK workforce.

Not so long ago Clearleft was made up mostly of men, roughly in-line with aforementioned design industry statistics. We now have slightly more women than men on staff, including a 50/50 split on our leadership team.

Organisations with equal representation of genders perform better – and design always benefits from diverse opinion and experiences. Therefore, it was clear we needed to recruit more women. I don’t believe we were ever particularly blokey in terms of sexist attitudes, and brogrammer culture has always been anathema to us, however we were obviously doing something to put off female applicants as we received very few responses from women to our job ads.

We worked hard to change the way we recruited, starting by removing any mention of ‘rockstars’, ‘play hard/work hard’, and other inadvertently macho sentiments, which can be off-putting to men as well as women. We hosted groups such as Ladies that UX. We also focussed our job ads on the values which have always been here – and appeal to all genders – those of work/life balance, flexible working, meaningful work and a supportive environment.

I’m really pleased our fantastic team is now made up of men and women in roughly equal proportion. But we can’t rest on our laurels – there’s always more work to be done in refining our culture and behaviour to make it accessible to all; for promoting role models in society; and for attracting a workforce diverse in ways other than gender.

If you want to get involved with the 100 year celebrations of women getting the vote, you can find more information at Vote 100.

]]>
The unexpected benefits of design sprints https://clearleft.com/posts/the-unexpected-benefits-of-design-sprints Tue, 20 Nov 2018 09:47:00 +0000 https://clearleft.com/posts/the-unexpected-benefits-of-design-sprints Design sprints enable teams to find solutions, innovate products and explore strategies, over the course of five days. A design sprint will deliver a user-tested prototype yielding valuable answers – but it will also provide a host of other side-benefits you may not be expecting.

Cross-company team building

Design is too important for the growth of your business to be left solely in the hands of designers. That’s why all well-run design sprints have an emphasis on a wide mix of perspectives and feature an ensemble cast of problem solvers across your organisation.

T left: A group of people in a design retrospective T right: A wall of post it notes B right: Two people reviewing a design

With no prior design skills necessary, the intensive, collaborative and above all, fun environment of a design sprint enables a team to be energised and highly engaged throughout the process. When I talk to clients after a sprint, they will often recall how a surprising camaraderie developed across team. This is particularly the case when staff and stakeholders involved the sprint have never worked together before. The egalitarian nature of the sprint inevitably results in a new-found mutual respect amongst participants, which they take into the workplace afterwards.

Demonstrating a rapid framework for innovation

Design sprints do not replace the rigours of user-centred design or an iterative, hypothesis-driven approach to product design. But what can be accomplished in five days surprises many participants. Design sprints demonstrate how quickly you can create preliminary designs that naturally bring together customers, staff, internal data and wider research. It also shows how it’s possible to test new ideas and push through changes very quickly.

Design sprints illustrate the value of treating innovation work separately from the daily business-as-usual activities. By doing so, it unblocks bottlenecks and pushes through changes that might have internally taken months – if not years – to come to formation. In the words of one senior participant, “we were able to make rapid progress on one of our biggest challenges. It really was like fast-forwarding into the future.”

Bringing underlying issues to the surface

One of the answers a design sprint may give you is “no”. By the end of the week, your team may be convinced an idea or solution simply doesn’t have legs. This is no bad thing. In fact it’s a valuable outcome, potentially saving you thousands of pounds. By having a group of people in the room to see this for themselves can provoke a timely change in direction or reformulation of priorities. In many organisations, that’s no mean feat.

A design sprint in action

Providing a wealth of ideas for the future

During the early days of a design sprint, you will take a broad view across the customer journey, generating a lot of ideas and opportunities. You’ll focus on some of these during the sprint, but you’ll also be left with many other propositions which may form the basis for future sprints or other work.

With this abundance of ideas generated by your sprint team, it’s important to socialise the work across the organisation. One option is to present a playback of the sprint, including early deviations as well as your prototype, at an open invitation Town Hall style meeting. You may be surprised by the extent of the turnout and interest from colleagues.

Ingraining design thinking

The collaborative nature of a design sprint helps designers and developers get better equipped to tackle ongoing challenges together. But if you get other stakeholders from across the company to participate in the design process, they too will play an active part in defining the future of your customer experience. During the testing day, providing exposure to customers will allow stakeholders to see the power of design-thinking and putting users first. Above all, they’ll get a sense of how much effort goes into creating good design and what makes the difference between a good and great experience.

The upshot is design sprints introduce design thinking into your organisation through a high impact approach. As one senior stakeholder put it afterwards, “we gained an energy that spread across our team and left us with a different view on how we can drive a more effective improvement in our web channels.” And that’s a far more valuable outcome than just a prototype.

Read some of our design sprint success stories or to find out how we can help you facilitate a design sprint.

]]>
The Design Sprint Canvas https://clearleft.com/posts/the-design-sprint-canvas Fri, 09 Nov 2018 15:59:00 +0000 https://clearleft.com/posts/the-design-sprint-canvas We’ve been running Design Sprints for a long time and value their ability to tackle challenges and fast-track processes. With this in mind, we’ve put together The Design Sprint Canvas - a handy tool that you can download to help guide facilitators and Sprint participants through the process.

The approach has certainly proved itself for us and our clients over the years, but to facilitate an effective Design Sprint, a good understanding of the process and structure is vital. If you’re keen to find out more then Jake Knapp’s book, Sprint, is the ideal place to start.

A Design Sprint Canvas in action

Once you’re in the thick of a Sprint even experienced hands can find it hard to stay on track and keep everyone motivated and aware of the bigger picture.

So, we’ve put together the Design Sprint Canvas - a handy tool to help guide facilitators and Sprint participants through the process. We’ve set out a clear sprint structure, key activities, moments and space to capture important information that can all too easily be lost when time (or brainpower!) isn’t on your side. 

Download a copy now, print it out big, and put it on the wall for the duration of your next Design Sprint to help keep everything on track. Let us know how you get on.

Find out how Clearleft’s full design sprint facilitation service can help you run your own design sprints.

]]>
UX past, present, and future https://clearleft.com/posts/ux-past-present-and-future Tue, 23 Oct 2018 11:41:45 +0000 https://clearleft.com/posts/ux-past-present-and-future I want to share with you some of the key milestones in the formation of the discipline of User Experience and how it came to be what it is today.

I’m going to start possibly a little earlier than you imagined… in 1880.

1880 – 1920

There was a young man in his twenties by the name of Frederick Taylor who started work as a clerk at a steel manufacturer in Philadelphia, Pennsylvania. Within a couple of years he was promoted to foreman. But like any good capitalist of his day (or any day for that matter), he wasn’t known to be particularly compassionate when it came to his workforce.

Workers in a factory.

[I am] constantly impressed by the failure of my [team] to produce more than about one-third of a good day's work.

Frederick Taylor (1881)

The general opinion of the day was that certain trades, including steelwork, could only be performed by craft production methods immune to any sort of workflow analysis or standardisation of process. It was something unique to each individual, and embodied in the inherent skills they passed on from master to apprentice.

Taylor believed that was nonsense. He felt that unproductivity, disguised as craftsmanship, was a deliberately selfish attempt by workers to keep employers ignorant of how fast work could actually be carried out. Because industry at that time was still largely dependent on human energy, this has a huge impact on his economic output and profitability.

Taylor wanted to transform management into a set of calculated and written techniques. At the time, management techniques were largely undocumented. So he set himself a task. He wanted to determine how long it should take a man to perform a given piece of work. He looked at things like unloading railroad cars of ore by shovel, how to lift and carry iron bars, and so on.

And he did actually stumble on some unconventional thinking for his day. He observed that mental and physical fatigue negatively affected productivity (who would have thought it?). He concluded it was more productive to include rest breaks so that the worker has time to recover. He also introduced a primitive version of performance-related pay — the more output each worker produced, the more they would be paid. But it’s worth remembering, the key aim of him doing this was not for the physical or mental safety of his workers, but simply to maximise his profitability from them. Despite his management innovations he was fairly old-school in regards to human relations.

He called the approach Scientific Management, and it really took off. This was one of the earliest known instances of applying science to the engineering of processes.

Scientific Management was based on a simple theory: work could be divided into constituent tasks, with each task timed and then reordered or reconstructed into the most efficient way of working. He called this the “One Best Way” of performing any job or task, with the aim of increasing the productivity and efficiency of his labour force.

His work was superseded in the years to follow by Lilian Gilbreth and her husband, who were experts in recording what are known as ‘time-and-motion’ studies. These filmed observations enabled the Gilbreths, who were experts in Scientific Management at this point, to redesign machinery to reduce fatigue and provide more natural, intuitive and less strenuous movements for workers.

The Gilbreths went further than Taylor by introducing a more human approach to scientific management. They helped establish the importance of the psychological dimension of work and wellbeing; improving lighting, providing regular breaks, introducing suggestion boxes and free books.

The Scientific Management method remained popular until World World One. When that was over, the Russians had been through a revolution and had to form radically different ideas about Man’s relationship to work.

1920 – 1960

In the early 20s, Lenin organised a conference on Scientific Organization of Labour, where Scientific Management came under some serious scrutiny. The Soviet communists were focused on the rejection of turning a man into a machine. Dull monotonous work was merely a temporary stage for human civilisation to go through until a machine could be developed to replace the worker.

The ultimate ideal of the labour problem is… in such organisation of the labour process that would yield a maximum of efficiency coupled with a minimum of health hazards, absence of fatigue and a guarantee of the sound health and all round personal development of the working people.

Vladimir Bekhterev (1921)

The Soviets were interested in protecting and even improving the life of the worker.

As the twenties turned into the thirties, mass-produced machines became more commonplace.

Any customer can have a car painted any colour that he wants so long as it is black.

Henry Ford (1922)

Henry Ford was revolutionising the transport industry (even if customer choice still had some way to go).

When World War Two gets into full steam by the 1940s, it was the first concrete example of technology challenging the limits of what a human was capable of. By this time, Taylor’s “One Best Way” feels hopelessly out of date. Technology was now pushing at the limits of what humans can do. Rapid decision-making, situational awareness and hand-eye coordination became critical factors in the success or failure of executing a task, and with a life or death consequence.

Even the best-trained pilots were crashing expensive aircraft. Military research showed that “pilot error”, as it was called, could be reduced by designing clearer, more logical controls and displays that operators found easier to use.

The many controls in the cockpit of a World War Two figher plane.

After the war this military research got shared in the public domain as increasingly complex technology became more widespread.

The “fit” between people, their equipment or machinery, and the environment became ever more important. So around this time the first professional organisation in relation to this almost symbiotic relationship between man and technology was formed. Here in the UK. It would ultimately become the Chartered Institute of Ergonomics and Human Factors.

Around the same time, the atomic bomb was dropped on Japan, bringing World War Two to a close. One of the leading scientists involved in the Manhattan project that brought about the atomic bomb was called Vannevar Bush.

Watching the aftermath of what he helped create, Bush was concerned about the direction of science toward destruction. So he published as essay in The Atlantic called As We May Think which anticipates many aspects of our contemporary society including the world wide web.

Individuals will be able to compress and store all of their books, records, and communications… mechanized so that it may be consulted with exceeding speed and flexibility… [acting as an] enlarged intimate supplement to one's memory

Not much of any great interest seems to occur in response to Bush’s speculative idea, until around 20 years later, in the late 60s…

1960 – 1980

A screenshot from The Mother Of All Demos showing Douglas Engelbart wearing a headset.
The mother of all demos

In 1968 Douglas Engelbart delivered what is known in technology circles as the mother of all demos. The computer he was demoing included some incredibly pioneering technology: a mouse-driven cursor and multiple windows used to display hypertext and hyperlinks, the precursor to the world wide web. Engelbart acknowledges he had been inspired, in part, by the Memex machine suggested by Vannevar Bush back in 1945.

It was still to take another ten to fifteen years or so before the computer became a household consumer product, but when it did the concept of Human-Computer Interaction had also emerged.

Human-Computer Interaction (or HCI) is a field that’s traceable back to it’s parent: Ergonomics and Human Factors, but with computers now becoming prevalent as a technology people interact with the focus is turned specifically on the relationship between a user and their computer interface.

Also around the turn of the 80s, something interesting was happening back in Pennsylvania, where the journey all started with Frederick Taylor 100 years before.

1980 – 2000

Harrisburg airport in the foreground with Three Mile Island in the background.
Harrisburg International Airport in Pennsylvania. In the background is Three Mile Island.

In 1979 a nuclear reactor at Three Mile Island failed. It became the biggest accident in US nuclear power plant history. One of the key reasons behind the scale of the failure was to do with a problem with the control room user interface which workers believed was indicating something it wasn’t. By the time they realised what was happening, it was too late.

A man called Donald Norman was part of a special team flown in to investigate the potential cause of the Three Mile Island incident, and one of the men to diagnose the failure of Human-Computer Interaction as a contributing factor.

Donald Norman went on to become a pioneer in an emerging field of what became known as user-centered design. The phrase originated from his research laboratory at University of California in San Diego and became a well-known term in the Human-Computer Interaction field by the mid eighties.

UCD or Human-Centred Design (HCD) was an approach or methodology to help design products or services to better meet the needs of their intended audience, thereby making them more likely to be a success.

When Don Norman travelled to London in the mid eighties he found a whole host of frustrating conventions for interacting with daily objects which were different from his native California. Doors that look like they should be pushed instead of pulled, or pulled instead of pushed. Taps that only emitted freezing cold or boiling hot water. Light switches or toilet flushes that seemed counterintuitive. His trip inspired his seminal book called The Design of Everyday Things where he talks about how to design for people and their experiences.

And to be honest, haven’t we all pulled a door by mistake that was intended to be pushed? Because the handle has been misleading, right?

A door handle with a pushable affordance labelled with the word pull.

User experiences are everywhere, not just for people interacting with computers or technology. And unfortunately that means badly designed user experiences are also everywhere.

Without a doubt, many of these things have been designed by designers. But these are cautionary tales about designing things without a deep, observed understanding of how people interact with their environment.

Ever heard of desire paths?

A green area with a pathway tramped across it.

Public spaces aren’t always designed efficiently to get us from A to B. The world doesn’t work as intuitively as it could. But, as you can see, humanity finds a way!

An aeriel view of the grounds of Michigan State University.

A good user experience is sometimes as obvious as simply observing what people do intuitively. Smart designers, such these people who planned Michigan State University, treat the users of the system as an equal partner to those that create it. When they had to decide on their campus footpaths, they simply made none to begin with. They waited for the students to arrive and find their own way from building to building, then paved over the trails.

It’s worth remembering that in the mid-eighties computer technology was still a relatively niche affair. A computer was not readily available to the masses as an affordable consumer device.

In 1984 only 19 million US citizens had access to a computer at home. That’s about 8% of the population at that time.

Ten years later, by the mid nineties, that number had trebled to 60 million

Around this time Donald Norman joined Apple as a User Experience Architect, the first known use of the phrase “User Experience” in a job title and the reason why Don Norman is considered the godfather of User Experience.

At the turn of the century the number of people with access to the internet was 740 million.

Ten years later it more than doubled to 2 billion.

Today, that number is approaching half of the world’s population of around 7.5 billion. Human-computer interaction through devices such as our mobile phones is at a scale like never before.

Whither UX?

Why do we need to create good user experiences? Hopefully some of what I’ve already shared naturally answers that question.

When humans interact with computers and technology good user experience can in extreme situations save lives, and even in the mundane minimise or avoid unnecessary physical or mental stress.

As you can also see, UX is not really a new thing. It might seem new to your organisation and its design process, but in fact it’s been emerging since before the dawn of the internet, back in the 80s, and people have been looking to solve similar problems for almost 140 years.

At Clearleft, our designers believe that a good user experience is synonymous with user-centered design. And user-centered design, at its core, is a toolkit of methods and techniques to help improve our ability to design products and services that meet the needs of those who use them.

]]>
The big idea – design sprints, Jake Knapp and key takeaways https://clearleft.com/posts/the-big-idea-design-sprints-jake-knapp-and-key-takeaways Mon, 22 Oct 2018 13:10:00 +0000 https://clearleft.com/posts/the-big-idea-design-sprints-jake-knapp-and-key-takeaways Design sprints and the big idea. Something us designers are very familiar with. But is this approach widely understood? Jerlyn Jareunpoon-Phillips gives her thoughts on what companies should consider, as inspired from her recent visit to Clearleft presents: Jake Knapp workshop

For those that don’t know, a design sprint is a framework for teams to explore ideas and make decisions in order to create a testable product concept or strategy in a short amount of time. Jake Knapp, former Google Ventures Design Partner and author of New York Times bestseller, Sprint, developed this concept through observing the default model most organisations use to develop or improve upon existing products. He observed the barriers that came up were largely due to the speed to-market - the process was inefficient. A culture of endless meetings and roundabout conversations were not conducive to productivity. That meant a large amount of great ideas got lost in the mix - hence the design sprint was born.

The design sprint provides the perfect launchpad for tackling these big ideas in a short time frame. It cuts down unnecessary back-and-forth processes and stakeholder procrastination. Ultimately, the process gets straight to the heart of your concept and provides a roadmap for building a watertight prototype. If you’re implementing a similar process into your organisation, here are a few key takeouts to consider:

Employ an experienced, external facilitator

For your first sprint, bringing in an experienced external facilitator is key. As Jake pointed out in his workshop, it’s the default work practises that often get in the way of building the commitment, focus and momentum needed to get large projects off the ground. A facilitator with an ‘outsiders’ mindset is less likely to be aware of your office’s culture or politics. They might ask a lot of obvious questions which will help your team tease out further assumptions – and hidden challenges.

Momentum

Gaining momentum early on in a project is vital to its future success. Projects need a way forward and often that’s through things like stakeholder buy-in and project team engagement. At the end of the day, projects just need people to believe in them so that budgets and resources can be allocated. A design sprint is a great tool to kickstart this momentum. It gets people involved and excited about what comes out of it.

I recommend incorporating a plan from the start on how to continue this momentum after the week-long sprint is over. Talk to your facilitator about where the opportunities could be in your company to push the project forward after it’s over. At Clearleft, we’ve worked with companies who’ve presented their sprint projects through lunch-time presentations, blog posts, stakeholder meetings, poster exhibitions in the hallway, and even through Dragon’s Den type voting, where they ran three sprints and then voted for their favourite idea to take forward.

Learning is about ‘de-risking’

At the event, Jake mentioned he was a self-professed process junkie. To that end, he’d developed a great way to get people to work together, design things and make informed decisions. At this year’s workshop, a few attendees I talked to said they were really interested in picking-up some new techniques to make their meetings more productive. Process was the focus of the day, and on everyone’s mind. As a designer and maker myself, I love process. But I honestly think that some of the most successful, innovative businesses are also learning junkies.

Ultimately, what the design sprint helps you do is introduce a mindset for learning. Innovation and change can’t happen without experimentation. In the end, you will save money by investing in incremental improvements and tested designs instead of big guesses. Plus, you’ll have better products and services to show for it – and your customers will thank you for it. What’s not to love?

Read some of our design sprint success stories or to find out how we can help you facilitate a design sprint.

]]>
Leading Design 2018: Themes and Highlights https://clearleft.com/posts/leading-design-2018-themes-and-highlights Tue, 16 Oct 2018 10:16:00 +0000 https://clearleft.com/posts/leading-design-2018-themes-and-highlights Leading Design made its hugely successful return to the Barbican, London, for the third year running to a sell-out crowd. Our User Experience Director, Andy Thornton, was there to give us his roundup of five emerging themes he came across at the event.

1. Inclusivity, power and em­powerment

In a very powerful and personal address, Thoughtbot’s Product Designer Amélie Lamont recounted the many ways those in power can cause harm. She highlighted exactly what is required to create a safe, inclusive environment: principally communication, feedback and transparency.

Former Director of UX for Vice President Biden at the White House, Kara Defrias, reminded us that as an industry we’re great at tracking the wellbeing of projects, but not as attentive at tracking the wellbeing of people. By sharing practical examples of leading through influence, rather than authority, she advised to rally around a cause, empower your team, stay humble and give away the glory.

Slack’s Senior Product Designer, Diógenes Brito, wrapped up the importance of empowerment with some lessons in design - and salsa (!) A fascinating reflection on how designers should act as facilitators, stewards and connoisseurs, whilst sharing clear expectations, inspiring their team, and adapting to context like a dance lead might do.

2. Safety & wellbeing

User Experience Consultant Dan Willis highlighted in his own inimitable style, tips on how to manage the weakest member of your team: you. His advice included guidance on reassessing your position on the hands-on / hands-off spectrum and how best to manage burnout.

Continuing the theme of resilience, Executive Coach Julia Whitney revealed what we can do physically, emotionally and mentally, to help ourselves in times of stress. She advised harnessing a strong sense of self-awareness and staying true to your purpose.

Mia Blume, Design Leadership Coach and CEO of Design Dept, reinforced the belief that as leaders our work begins from within. Drawing attention to the many challenges and opportunities that the future of work can offer us. What if career progression was less linear? What if sabbaticals or ‘returnships’ became the norm? Or a reduced 4-day working week during summer? Today’s tools and limiting beliefs about work are sabotaging our ability to be resilient creative leaders. So, how do we adapt and thrive by creating a new normal?

3. Navigating business & people

Best selling author of Making Things Happen, Scott Berkun, spoke candidly of a Design and Power Playbook. Inspired by how Machiavelli navigated through the political complexities that made up Renaissance Italy, he explained how it wasn’t that much different to your company’s organisational chart.

Experience Design Leader Russ Unger gave sterling guidance on how to improve the process of bringing new designers into your organisation. From recruitment through to onboarding - and not forgetting the awkward silence that typically happens between the job offer and first day.

Aaron Irizarry, Capital One’s Head of Experience Infrastructure, also reinforced the power of people by reflecting on business cultures that have the psychological safety of each team member in mind. Aaron rightly reminded us that by supporting decision-making autonomy we empower people to do their best work.

4. Progression & learning

Clearleft’s Andy Budd interview with co-founder of Wert&Co Judy Wert explored the critical components of career progression. Talking about her responsibility for placing many design leaders into significant roles in Silicon Valley and beyond, Judy offered sound advice on mapping signature moments of your career; especially when a portfolio becomes less relevant as your career matures. She warned of the distractions of chasing job titles rather than what motivates you as an individual - and what you can offer to an organisation.

Meanwhile, Executive Leadership and Transformation Coach, Todd Zaki Warfel, stressed the importance of a career ladder for design professionals, especially eager millennials. He reinforced the positive impact it has on employee engagement and motivation when implemented successfully.

Fred Beecher, Best Buy’s Senior Manager of Experience, showed us a great technique for incorporating consistent learning into organisations. He explained how it helps to deliver continuous product iteration that would otherwise struggle to happen due to time constraints.

5. Design Ops

Chase’s Head of Design Management Kristin Skinner walked through a useful and practical model for growing design teams. Offering up some sage advice on the importance of a secure organisational structure; since ultimately without it your products and services can’t succeed.

Meredith Black, Pinterest’s Head of Design Ops, followed up with an insightful introduction to the roles of the Product Design Producer and Design Program Manager. Operational positions that ultimately keep designers in the flow of designing.

While former Senior Director of Design at Mailchimp, Todd Dominey, continued along a similar vein with his experience of scaling a new brand experience across disparate product and marketing teams.

Finally, Director of Customer Experience at Verizon and Moment, John Devanney, recognised the need for consultancies to provide broader services for clients by supporting their design maturity through coaching, advocacy and ROI. Through the creation of a Design Management office he advised you can assist a team’s design capability and secure the level of funding required to ensure good design can happily thrive.

Clearleft is bringing Leading Design to New York City, USA, for the first time in 2019. Held at the legendary Guggenheim from 19-20 June it’s guaranteed to bring three days of inspiration and learning for people leading design teams, overseeing design direction or instilling a culture of design into their organisations. Super Early Bird tickets are available to buy now.

]]>
Inside: the world of Jake Knapp https://clearleft.com/posts/inside-the-world-of-jake-knapp Fri, 12 Oct 2018 09:04:00 +0000 https://clearleft.com/posts/inside-the-world-of-jake-knapp Back for the second year running, Jake Knapp, former Google Ventures design partner and author of the New York Times bestseller Sprint, returns to London to collaborate with Clearleft on a sell-out design sprint workshop. We caught up with him before he touched down in London.

You’re back in London for another of your excellent design sprint workshops. What did you enjoy about the workshop last year? 

Well, I always enjoy being in London, but—and I’m not kissing up here!—I really enjoyed the London audience, who were very raucous, and hanging out with the super friendly folks from Clearleft. So I’m back for selfish reasons really, for a good time!

The sprint that you advocate is five action-packed days - how do you manage to pack so much in?

We can get a lot done in a design sprint because the activities are carefully structured. We don’t work long hours, we work smart hours. However, I can’t tell you that a design sprint isn’t hard work—it’s very hard work. The process is spreading because it works, not because it’s easy!

Your book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days has become a New York Times best seller since it was published in 2016. Congratulations. Please tell us how the book came about?

I created the design sprint in 2010 while working at Google, and began writing “how-to” blog posts about it in 2012. The response was really phenomenal, so that’s what got me and my colleagues at Google Ventures thinking about a book.

You once said “going fast prevents second-guessing”: you advocate speed of idea generation as opposed to long-term thinking - why?

Well, long-term thinking is important of course, but it’s easy to overthink things. Often we can come up with a great solution in the beginning, and we need to make sure we give those early, almost instinctive solutions a fair look without just endlessly refining, iterating and redesigning. Often the most obvious solution is the best one.

The process has been described as “democratising” - as in all the participants have an equal voice - how important is this?

It’s important to hear from everyone on the team, but I actually think it’s dangerous to make product decisions as a democracy. The process is carefully crafted to level the playing field for solutions, and to bring out information from everyone, extrovert or introvert, high status or new to the team. But in the end the decisions are made by a single Decider. So it’s a mix of democracy and dictatorship, just like back home in the USA!

Culturally - what positive effects do design sprints have on existing digital and design teams within existing corporations?

There are many positive effects for team culture. A few are: respect for everyone on the team AND respect for the customer, healthy risk-taking, and escaping the constant reaction cycle to slow down and focus on what’s most important.

Many readers of this interview have been inspired by your approach, but sometimes convincing the powers that be within their own organisations to invest in a sprint can be tough. If you were selling the idea of a sprint into the C-suite of a large organisation, how would you convince them of its value?

After a design sprint, people typically report that the five days replaced six months of meetings and arguments. Anyone responsible for running a business should appreciate that. 

Your new book Make Time has just been published in September this year. How does it differ from Sprint, and what do you hope your readers will gain from your latest tome?

For years, my friend (and co-author on Sprint) John Zeratsky and I have been experimenting with redesigning our own days, even as we were redesigning teams’ days with the design sprints. In Make Time you’ll find our recipe for focusing on what matters every day. It’s a book for busy, distracted people who want to slow down the crazy rush and create space for the things they care about.

Got any other plans when you are in London? Do you have a favourite restaurant or place to hang out when here?

I always try to go to the Science Museum but I might not have time on this trip. For sure a run along the river, and I also love breakfast at Lantana. I know they’re Australian, but I’ve never been to Australia, so for me it’s a very London experience.

If you had to recommend a book by another author right now, what would it be?

For work, The Power of Moments by Chip and Dan Heath. For fiction, I really enjoyed Annihilation by Jeff Vandermeer, which apparently is almost nothing like the movie by the same name. It’s short, mysterious, and a little creepy—perfect for Halloween time.

Jake Knapp’s Design Sprint Workshop is taking place on the 15th October 2018 at the Barbican Centre in London. You can also see how Clearleft could help you run your own design sprint.

]]>
Don’t do a design sprint. Unless… https://clearleft.com/posts/dont-do-a-design-sprint-unless Mon, 08 Oct 2018 13:51:00 +0000 https://clearleft.com/posts/dont-do-a-design-sprint-unless Bang! Out of the blocks. Arms and legs pumping. Blink and you’ll miss the human-missile as they burst through the finishing line swiftly followed by a rapturous ovation.

The perception of the 100-metre sprint is that it’s won between the blocks and the finishing line. I’ve often heard the same said about the five-day design sprint format popularised by Jake Knapp and the team from Google Ventures. Get Monday to Friday right and success is pretty much guaranteed.

But, it’s not just the 9.58 seconds of running fast that makes Usain Bolt a world champion sprinter. Similarly, a successful design sprint requires both a warm-up and a post-race plan.

This truth, unfortunately, changes the strapline of the Sprint book to the less catchy ‘Solve big problems and test new ideas in just five days plus a few more for the admin’.

Sprint to unblock creativity. Sprint to unlock innovation.

Despite the title of the article, I’m not trying to dissuade you from undertaking a design sprint. I’m a big fan of design sprints. I’m an even bigger fan of design sprints done well.

I’ve had the pleasure of running design sprints for many clients across different business sectors to tackle a diverse mix of challenges. I’ve found the following checklist of considerations a useful predictor of getting better outcomes from any design sprint.

Tackle the calendar challenge

Idea generation seems easy when compared to aligning multiple calendars. Getting each sprint team members to clear their diary for a week and to find a vacant space can quickly feel like a Sisyphean task.

Ideally, you want to find a room with plenty of wall space (to put up ideas as they emerge), a projector, and furniture that can be configured for different activities (carrying out interviews, mapping the problem space, and sketching). Even better: find a space with natural light, as you’re going to spend a lot of time in it and few people work best in a bunker.

A single location is important. Moving rooms each day becomes tiring. Locating your new home each morning becomes disorientating.

It definitely helps to make friends with your facilities team or to consider moving off-site and hiring a space for a week.

Get commitment

Most organisations I work with have a stronger meeting culture than a making culture. A design sprint runs contrary to this and can be an alien way to work for many.

Clearly set the expectation that between 10am and 5pm, the whole team will be fully immersed in the design activities. That means no phone calls. No quick emails. No sneaking out for meetings.

I like to email the sprint team beforehand to introduce myself and set the expectations for the week. I also give them a clear opportunity to bail out beforehand if they can’t be there for the duration. I’d rather you weren’t there at all than partially present.

On a recent design sprint, a team member set her out of work email to read ‘I can’t give you a reply this week as I’m working on something cool for 5 days that will make our customers smile’. I’m going to include this in my next introduction email as a suggestion for all team members to use in their out-of-office message.

Find the right team with the right skills

Design is too important for the growth of your business to be left solely in the hands of designers.

I’m a strong advocate for using design sprints as an excuse to assemble a team of highly talented problem solvers. No prior design skills necessary. The emphasis should be on a wide mix of perspectives and a curiosity to explore customer pain points.

The one caveat to this is to ensure you have enough design firepower for the prototype-making day. At Clearleft, we run design sprints with two people. One person is focussed on facilitation and the other on prototype production. Both people actively coach design thinking from the participants through exercises and activities.

Prep your ingredients

Although it’s framed as a week of design work, there is a lot to sort out in advance. The more preparation you do, the more impact it will have on the time you have to investigate and design.

On my week-before and often-forgotten list are:

  • Find and book subject matter experts for the team to interview
  • Gather design assets to accelerate prototype creation
  • Recruit usability testing participants
  • Reserve a place and space for the team to eat together

My few days before to-do list includes:

  • Check the stationery (it’s embarrassing when all your Sharpies are low on ink)
  • Buy sugary and healthy snacks to fuel energy levels
  • Send out a welcome onboarding email to the team
  • Charge up a Bluetooth speaker to play my Spotify playlist of workshop music through

Follow-up (the sooner the better)

The final tip on the checklist is: don’t start a design sprint until you know what you’ll do with the ideas being generated.

If participants are putting effort into solving tricky business problems, then I believe you have a responsibility to maximise the chance of the design solutions being taken forward.

You’ll likely be emotionally and physically tired at the end of a design sprint. Decide ahead of time what to do with the output. If nothing else, it’s one less decision to make at the end of a long week.

At a minimum, decide how you’ll document the thinking behind the prototype, the learnings from usability testing, and recommendations of what the team would do next if they had more time.

One step better is to have a plan to socialise the work. I encourage design sprint teams to present a playback of their prototype at an open invitation Town Hall style meeting. Teams are often surprised by the large amounts of interest from their colleagues.

To go a leap further, get the organisation ahead of the sprint to ring-fence some budget and time to further develop inventive ideas. On a recent project, we ran three separate design sprints, with different teams. All three teams were then invited to present ‘Dragon’s Den’ style to senior business leaders with the winning team securing further time to develop their idea.

However you follow up, do so as soon after the sprint as possible when the team still has momentum and energy for their ideas.

Get to your future quicker

A design sprint is one technique, and a potent one, to fast-forward into the future.

As a facilitator, your role is to set the conditions to best enable the assembled team to think deeply and creatively. You’re asking for companies and people to make a serious investment of time, focus and energy. So it only seems fair to tackle a design sprint if you are properly warmed up and have a post-race plan.

A few extra days for set-up and feedback is a small but vital investment in time worth making to better your chances of a successful outcome.

Find out how Clearleft’s full design sprint facilitation service - including prep and follow-up - can help you run your own design sprints.

]]>
Workplace topology https://clearleft.com/posts/workplace-topology Mon, 08 Oct 2018 12:52:00 +0000 https://clearleft.com/posts/workplace-topology Within our organisations, we have increasingly been introducing practises such as dev ops and design ops, to reduce operational inefficiencies.

Their aim is to formalise practises of addressing gaps or overlaps in technology and process. But these practises can come with significant overhead, and they’re not always appropriate for every scale or type of organisation.

In mathematics, a topology refers to the arrangement and relationship of constituent parts. A 3D model, for instance, has a topology that describes all its points and how they are arranged in relation to each other. And a good 3D model contains neither gaps nor overlaps.

Rather than uncritically adopting these processes off the shelf, we can analyse the topologies within our individual organisations and use this information to design solutions that suit our own specific requirements.

Some familiar stories

I’d like to begin by telling some stories. I suspect they may be familiar to many of you…

You’ve completed a relaunch based on thorough UX design, testing, and extensive iteration. But when the updates go live, users are confused, and sales goals start going off target.

Or how about this one…

You’ve spent a long time designing your new website, with a clear information hierarchy and strong branding. You’ve even produced a design system, complete with a pattern library demonstrating page templates and clear guidelines on their use. But when the website finally launches after many delays, it doesn’t really look like the designs that had been produced, or the templates on the pattern library, or the guidelines in the design system. Content is lacking, things seems out of place, and nothing holds together quite as well as the designs had done.

So how does this happen, even when everyone is working to the best of their ability, and you’ve implemented all the latest processes and tools?

Processes

We are all humans, working together, using our expertise to solve problems that no individual, no matter how smart or hard working, could solve alone. Many of the complex tasks we perform to achieve our goals involve repeated processes in one form or another. Repeated processes benefit from being broken down into smaller, more manageable units. And this can increase efficiency.

This insight originated in the industrial revolution, and became increasingly popular over the course of the early 20th century. It led to the growth of scientific management based systems like Taylorism and Fordism. While successful, they were also dehumanising and some of their fundamental principles, such as “the worker is lazy and untrustworthy,” and “strict hierarchy is an absolute necessity” still find echoes in our workplaces to this day.

Categories

Breaking anything down, whether it be a process, an output, or an organisation, involves categorisation. Categorisation, by its nature, creates boundaries. These boundaries can then impose artificial limitations, depending on our frame of reference. These artificial limitations can be the source of much hidden tension and complexity.

There has been a lot written on how to ensure that we are categorising, structuring, and naming things correctly. But there is much less discussion about what gets hidden by these categories, and the impact this can have. The end result of our attempts to work together efficiently by breaking things down is that the topologies of our workplaces are left with gaps and overlaps.

Gaps and overlaps

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

Two non-overlapping circles.

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

Two intersecting circles.

These gaps and overlaps are often responsible for undesirable outcomes that occur despite our very best efforts.

The good news is, we can learn how to spot them.

The stories I told earlier sound like distinct problems, but topologically they share many features.

Gaps and overlaps exist at every scale. To help you to identify them, I’ll go through some examples, starting at the smaller end of the scale.

Pattern libraries

We build pattern libraries to help modularise the delivery of front-end code. But we design for user need. When we consider user needs, we consider the whole user journey, and the whole context. To achieve the benefits of component based design, we must break that “whole” down. In doing so, we lose some of that context.

A wireframe of a page made of components.
A wireframe of the components extracted from a page.

Now we have all these flexible components that can be put together in almost any way. But they still need to remain coherent in different configurations. This becomes difficult when a component is generated by a Content Management System and can have almost any context. There are an almost infinite number of ways that a component can be placed together on a page with other components.

How do you design for infinity?

A wireframe of the almost infinite ways that components can be combined.

Since we can’t anticipate every possible combination, what we can do is recognise the fact that we have broken something down in order to categorise it, and therefore there may be gaps …in this case, literally.

A wireframe of a page made of components.
A wireframe of a page of components highlighting the gaps between them.

We can design a consistent system of spacing and layout to control how items are placed in relation to one another, and the parts become whole again.

Design systems

Moving up in scale, a pattern library is one aspect of a design system. We create design systems to allow our organisation the benefit in speed, lower cost of change, and resilience that is created by having a single source of truth.

It is a distinct entity, but to produce a design system requires collective effort. So we divide responsibility along the lines of UX, design, front end development, content, etc.

A design system must also fulfil different requirements for different end-users. Developers might need to know what components are available. Content creators need to know what the organisation’s tone of voice is. And so it suffers the same consequences of anything subject to categorisation, with apparent divisions of responsibility that hide overlaps and potential areas of conflict or duplication of work.

We might see places where developers must recreate in code what designers have already created in their design tools. Static design tools like Sketch have no way to highlight when interactions (like hover states) are missing, so we can easily end up with incomplete specifications—gaps—where interactions are not considered.

A screenshot of Sketch showing documentation for different states of a component.

We might also see gaps when front-end developers don’t provide enough documentation for back-end developers to implement something effectively.

At this scale, by recognising and addressing the gaps and overlaps that have been created, before issues are uncovered, we can prevent excessive cycles of iteration from occurring as gaps are uncovered one by one.

There are many different ways to repair this topology, and they will look different for every design system. But here are a few…

Choose tools that more accurately reflect the nature of the medium we work in—that bridge the gap between design and development. Tools like FramerX hold a lot of promise for the future of design and development collaboration.

Adopt techniques for helping people work together,like Lean or Agile, that encourage collaboration through close and frequent communication. Making sure all key team members are involved as early and frequently as possible also helps.

Organisations

Moving up in scale once again, a design system sits within an organisation.

For shared understanding and efficient division of labour we separate ourselves into teams and departments. At a certain level, these groupings are arbitrary. They’ve largely emerged from historical convention. They can also be influenced by emerging conventions and cargo-cult trends. Where these divisions do not accurately support the work to be done, it can be a source of tension within an organisation.

In cases where teams have overlapping boundaries of responsibility, and if the organisation is unbalanced—favouring one department over another—then the end result will not reflect the goals of the organisation as a whole.

A diagram of an organisation, highlighting an area where two departments overlap.

If there are gaps in skillsets, the organisation will simply struggle to achieve its goals.

A diagram of an organisation, highlighting the gaps between some departments.

By encouraging everyone to balance their own goals and perspectives with the organisation’s and with other teams’, we can help people work across silos effectively.

We can aim to create “an environment where reciprocity is the norm”. In the words of Heidi Gardner, author of Smart Collaboration:

Are we developing a coherent joined-up solution that’s really going to address this problem? Or are we just slicing off parts of it that we’re comfortable solving which won’t actually make the problem go away.

Culture building takes time and effort, but in the long run, it is a lot more sustainable than replacing a burnt-out team.

Validating your topology

So topology is a simple but powerful concept. It can apply at any scale, and there are five steps.

Focus on the overall context

The overall context might be a page design, a long-term goal, or the structure of your organisation.

It’s easy in our day-to-day work to get caught up in the specifics of our tasks and the divisions of responsibility. It’s important to step back regularly andremind ourselves of the bigger picture.

Recognise that categories are subject to distorting pressures

Historical precedent can push us into uncomfortable positions. The pressure of time is an ever-present factor in our decisions,pressuring us to choose the quick option—the path of least resistance—rather than the best option. It’s important to ask ourselves why we make the categorisations we do—why we’ve chosen a particular framework, or divided our teams in a particular way—to ensure that we are working towards our goals in the ways that fit us best.

Recognise that categories hide context

Every time we make a choice to divide something up to better fit a division of labour, we lose context (like the context lost with component-based design). Keeping track of what we have categorised and how we have categorised it allows us to spot opportunities to fill gaps.

Recognise that categories create potential areas of conflict

Every time we divide something up to better fit a division of labour, we risk overlap of responsibility.

Marketing and development are typically both responsible for the content on a webpage. But they come into conflict when the marketing team wants more scripts to understand users, and the development team wants fewer scripts, to improve performance for users.

Being aware of these areas of overlap, and keeping our overall context in mind, allows us to engage in dialogue, or create rules or processes to follow, in order to prioritise what should happen when conflicts do arise.

Determine whether a given problem requires a technology, process, or people -based solution

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

Maintaining an equal balance between all three—technology, process, and people—and understanding when each approach is the most appropriate solution, is critical.

While the concept is simple, applying these ideas can appear challenging. But I believe that exercising our creativity and judgement to improve our work lives on our own terms, rather than allowing it to be dictated by convention or the path of least resistance, is worth the effort!

]]>
Designing design systems https://clearleft.com/posts/designing-design-systems Fri, 05 Oct 2018 14:52:00 +0000 https://clearleft.com/posts/designing-design-systems This year I’ve been involved in a lot of projects to help large organisations improve the web experience for their customers.

While the business markets and their needs were quite different from one another, the problems their websites faced seemed to originate from a similar place.

They’ve all been using Content Management Systems, which allows different departments in the company to update content as needed, and manage their own part of the site. It’s efficient and practical. It’s a business-as-usual kind of decision for a large and complex organisation. It also saves time, keeps production costs low, and allows everyone to get on with their work without having to ask for too much help from dev or designers, or get into some kind of approval chain to publish stuff.

But time and time again, the result at the end has become content and designs on the website that vary greatly in tone and quality: pages even looking quite different from each other when clicking through the site.

We run a lot of workshops to understand challenges within projects and here are just some of these pain points having to do with their website, as expressed by the people we’ve worked with:

Different parts of the website look like different businesses.

The web is often an afterthought for many teams.

When you have multiple teams working in one place who aren’t communicating with each other, inconsistency just happens. And what really suffers is the customer’s experience.

Like cities, websites are complex systems. People visit them for different reasons. They navigate through them. They scan information. They make key purchasing decisions.

Meanwhile, internally, your different teams act within this same space.

A complex system that isn’t managed well breaks down and our customers can perceive that. When this happens, trust in the brand can go down, customer satisfaction suffers, or your audience will just go someplace else.

As we’ve helped a number of organisations improve various parts of their website this year, we’ve been able to see that the problems on their website were often a result of ways that large organisations have learned to operate as scale.

This is a problem, when you want your customers to experience your business in a singular and seamless way but the website itself represents multiple authors who aren’t communicating with each other.

The relationship between the structure of a business and its digital outputs have been observed before.

Nigel Bevan, a usability expert, said:

Organisations often produce web sites with a content and structure which mirrors the internal concerns of the organisation rather than the needs of the users of the site.

Nigel Bevan, Usability consultant and researcher

There is a lot of work underway to solve this problem of disjointed or inconsistent digital experiences. Companies are beginning standardise and systematize their design output.

Design systems

The most familiar model for understanding a digital design system is Brad Frost’s atomic model. Starting with the most granular elements like typography and colour, you can think of combining these into more complex organisms until you get to templates and page level views.

Modular systems are great, but they could still get used any way anyone wants to. A system without guidance is just a set of blocks that could result in an infinite variety of creations. If you’re trying to maintain a consistent look and feel but you have many contributors, then you’re probably back to the original problem of inconsistency.

In practice what often happens is that these re-usable atoms are used many different ways, allowing all kinds of molecules to be created. Again this opens the door for all kinds of disjointed experiences and makes the system harder to maintain.

Karri Saarinen, Airbnb

What’s the best way then to transmit guidance about how the users of the system are to use these blocks?

Some well-known brands have been doing a lot of work internally to produce increasingly detailed documentation — libraries and support systems around their designs. Online, you can easily find sites that showcase different design systems.

They’re websites onto themselves. They range a lot in the level of detail and supporting information they provide. Some are considered style guides, while others are more integrated design systems or design languages. The intention behind them is to help quicken the pace of production and ensure more consistency across screens and platforms. Design systems often articulate design principles and provide design guidance and code around each component.

So I’ve noticed some interesting things…

They’re mostly for designers and developers

Here’s a screengrab from one of those design systems.

A dropdown down menu with two options: designers or developers.

So to get started with it, you should be a part of either of these two camps. We’re not really speaking to anyone else.

They’re unique to the brand

They’re all different. Developing a design system is more than just specifying hex values or CSS. I think these companies understand the value they’re bringing to their customers and the component designs reflect that. They’re infused with a joined-up understanding of the intention of the business as a whole.

Here are some excerpts from Uber’s guidelines:

A montage of interface elements from Uber's design system.

Even without a label on this slide, you could almost guess who this company is. They’re in the transportation business and have paid special attention to the specification of components having to do with their maps.

Can you try and guess who’s component this is? (I know this is going to become a game one day.)

A collection of icons.

It’s from Lonely planet. I know them for their great travel guides. Here, they’re giving a little more love to icons sets titled “Destination”, “Weather” or a set called “Need to know.” This tells you a little more about the kind of experience they’re promising to the audience.

I like this one:

A simple interface element presenting a choice of options.

This seems like a small component. It doesn’t seem to be very exciting but again, I think there’s a lot of design love here. Care has been taken to get this right and articulate details about it. I can see refined decisions that have been made about type sizes and use of colour. It’s also called a multi-choice list - I think even the name of it has been well thought out.

It’s from Shopify’s design system. They run an e-commerce platform, where the check-out processes for online shoppers is incredibly important moment to get right.

They’re considered living

Design systems are thought of as constantly evolving. When you go back to thinking about my early points — multiple authors, changing teams, your customers and their changing needs, and advancing technology — it’s a complicated system, so this makes a lot of sense.

A unified design language shouldn't be just a set of static rules and individual atoms; it should be an evolving ecosystem.

Karri Saarinen,  Airbnb

IBM says their Carbon design kit is “a living, breathing, document.” And Salesforce says the same thing.

As your third-party systems are always coming out with the next version, or as marketing strategies shift seasonally, nothing is permanent about this work. I think this is fine, this is good, we have to let systems evolve. That’s what they do.

But there is this strange tension where the document appears to have authority, but it’s always potentially failing if it becomes an inaccurate source for information.

The biggest existential threat to any system is neglect.

Alex Schleifer, Airbnb

Some companies have taken on efforts to develop systems of governance and ideas about workflows around these sources of truth in order to keep them alive.

At Allstate insurance, there’s a pattern library at the top, supported by a governance community and then there is also a designer and dev librarian who support the governance community.

Airbnb have also created an organisational model. They have a specific team at the top who are responsible for the design system. Then there are designers distributed throughout the company in different teams who feed into that design language team. And then it’s all supported by a production design team. They say:

This ensures all designs meet Airbnb standards for quality and consistency.

Having a single source of truth is important in trying to uphold that goal of delivering a seamless and delightful experience while internally teams and strategies change. But maintaining these documents as libraries can become quite a project in themselves.

Some great companies have taken on this task — Airbnb, the BBC and Gov.uk, just to name a few. Others out there are also beginning to define and develop workflow systems, new roles and governance committees.

But not every organisation has started out with their roots in technology, or have the resources or the buy in you’d need from stakeholders to take these projects on. It’s a lot of coordinated effort to get these design systems in place.

There is a focus on the design system as a useful piece of documentation work: it’s a thing, it’s an output that facilitates other outputs. But I don’t think this is its only value.

These projects are fostering increasingly collaborative engagements between designers and developers. Furthermore, they are about defining things. And when you do that, you’re also going through the process of understanding and establishing meaning in deeper ways.

I observed earlier that these design systems have more in them than component build and design specifications. They’re in touch with the brand promise as a whole and focus on some of the genuine experiences and key interactions the business wants to be known for.

According to the Director of Product Design at Intercom:

Your product is more than just a pile of reusable UI elements. It has structure and meaning. It’s not a generic web page, it’s the embodiment of a system of concepts.

Emmet Connolly, Intercom

Therefore, I think it’s even more important that these design system projects become more inclusive to other teams across the business.

For organisations with multiple content producers who use the components to create their pages, they should also share in the understanding and purpose behind the design system. As intermediary users of the system, they can input valuable feedback that informs the continual development and design cycles.

Complex issues require intelligence beyond that of any individual. For early design systems you don’t need a governance committee, but more conversations between the people across the organisation who influence the output on the website.

The best way to govern and grow a living system, especially in its early stages, is through the shared and socialised understanding of the purpose behind the designs on the website.

Dialogue

Dialogue is the discipline of collective learning and inquiry, It is a process for transforming the quality of conversation and the thinking that lies beneath it.

William Isaacs has conducted research on dialogue and organisational learning in corporate, political, and social settings around the world. He says:

Dialogue often leads to new levels of coordinated action without the process of creating action plans or getting rounds of approval. Dialogue does not require agreement; instead it encourages people to participate in a pool of shared meaning, which leads to aligned action.

William Isaacs, The Dialogue Project

It’s really efficient! There are simple ways to keep your early design systems alive without investing in architecture or hiring new roles or creating departments.

Campfires

When I first started brainstorming about this, I just wrote down on a post-it note, “Campfires.” And it has stuck with me still.

I like campfires. People gather around them to have conversations and tell stories. They’re not formal. And you don’t need to build an infrastructure to support them.

Dialogue is like a campfire. If you’ve ever tried starting a bonfire—or even a BBQ— you know they take a process to start up. So here’s the process of dialogue. I won’t go into deep detail, but in a nutshell, these are the most important aspects we need to know:

  1. Invitation
  2. Conversation
  3. Deliberation
  4. Discussion
  5. Collective Inquiry
  6. Creativity

Conversation + Deliberation: When any group of individuals comes together, each person brings a wide range of unexpressed differences in perspective. The first thing is to find a way of allowing these differences to be explored and to tease out assumptions.

Discussion + Collective Inquiry: Skilled facilitators are crucial at this point, not to impose rules or order but to suspend what we might see as conflict in service to inquiry or insight instead.

Creativity: Next, you move into a place where people can inquire together as a whole. New insights often emerge in a shared and socialised way, as opposed to the much slower process of consensus-building. When you have different mindsets of the same business coming together to develop a common syntax or vocabulary, you now also have a place that’s set up for innovative ideas.

Three people gathered around a table with their heads down, sketching.

We do a lot of of this at Clearleft. Through sketching with clients, we use their expertise to generate a deeper understanding and more informed visual designs. In these sessions, people tend to tell stories as they draw, or talk out loud about ideas they have but can’t really articulate yet. We work off each other’s ideas to come up with solutions together.

After projects end, I always hope there is a way that these practises will carry on. I think it’s important for businesses to continue to support this kind of collaborative culture.

Socialising the design system should happen from the beginning.

Recently with a client, we’ve been working very closely with the digital team introducing methods that help facilitate dialogue and collaboration across the different parts of the organisation. The different content managers are also regularly invited and are attending sessions. In design review sessions, we write on a card, a yes, no or maybe so. And then for each component, everyone quickly presented how they felt. By making everyone’s initial opinion visible, we then took turns discussing and coming to conclusions together.

A group of people gathered around a table. Each person holds up a post-it not saying yes, no, or maybe so.

A past Clearleftie, Charlotte Jackson did an exercise for everyone involved in the creation of the pattern library. People across the business were invited. They conducted a website audit by printing out and cutting apart all the components used on the website. They grouped them into categories, then one by one sought to name each component together. She says:

The key benefits of this exercise are that it creates the same starting point for everyone, and encourages a shared language and pattern thinking across the team—all of which help lay the foundations of an effective pattern library.

Charlotte Jackson

I think large companies can try and find the room to experiment, to pilot other ways of working that allow them to operate like a smaller organisation sometimes.

Design can live within your business but it doesn’t have to be restricted to a team with that label. Design thinking is a skill that can be done by anyone.

Developing a design system takes collaboration between the makers of the design systems and the different users of the system. It’s a continual process that doesn’t have to require a huge investment in new departments or massive restructuring.

It can start small.

]]>
Preparing a conference talk https://clearleft.com/posts/preparing-a-conference-talk Mon, 24 Sep 2018 22:12:00 +0000 https://clearleft.com/posts/preparing-a-conference-talk The four steps I took in putting together a presentation.

I gave a talk at the State Of The Browser conference in London earlier this month. It was a 25 minute spiel called The Web Is Agreement.

While I was putting the talk together, I posted some pictures of my talk preparation process. People seemed to be quite interested in that peek behind the curtain, so I thought I’d jot down the process I used.

There are two aspects to preparing a talk: the content and the presentation. I like to keep the preparation of those two parts separate. It’s kind of like writing: instead of writing and editing at the same time, it’s more productive to write any old crap first (to get it out of your head) and then go back and edit—”write drunk and edit sober”. Separating out those two mindsets allows you to concentrate on the task at hand.

So, to begin with, I’m not thinking about how I’m going to present the material at all. I’m only concerned with what I want to say.

When it comes to preparing the subject matter for a talk, step number zero is to banish your inner critic. You know who I mean. That little asshole with the sneering voice that says things like “you’re not qualified to talk about this” or “everything has already been said.” Find a way to realise that this demon is a) speaking from inside your head and b) not real. Maybe trying drawing your inner critic. Ridiculous? Yes. Yes, it is.

Alright, time to start. There’s nothing more intimidating than a blank slidedeck, except maybe a blank Photoshop file, or a blank word processing document. In each of those cases, I find that starting with software is rarely a good idea. Paper is your friend.

I get a piece of A3 paper and start scribbling out a mind map. “Mind map” is a somewhat grandiose term for what is effectively a lo-fi crazy wall.

Mind mapping.
Step 1

The idea here is to get everything out of my head. Don’t self-censor. At this stage, there are no bad ideas. This is a “yes, and…” exercise, not a “no, but…” exercise. Divergent, not convergent.

Not everything will make it into the final talk. That’s okay. In fact, I often find that there’s one thing that I’m really attached to, that I’m certain will be in the talk, that doesn’t make the cut. Kill your darlings.

I used to do this mind-mapping step by opening a text file and dumping my thoughts into it. I told myself that they were in no particular order, but because a text file reads left to right and top to bottom, they are in an order, whether I intended it or not. By using a big sheet of paper, I can genuinely get things down in a disconnected way (and later, I can literally start drawing connections).

For this particular talk, I knew that the subject matter would be something to do with web standards. I brain-dumped every vague thought I had about standards in general.

The next step is what I call chunking. I start to group related ideas together. Then I give a label to each of these chunks. Personally, I like to use a post-it note per chunk. I put one word or phrase on the post-it note, but it could just as easily be a doodle. The important thing is that you know what the word or doodle represents. Each chunk should represent a self-contained little topic that you might talk about for 3 to 5 minutes.

Chunking.
Step 2

At this point, I can start thinking about the structure of the talk: “Should I start with this topic? Or should I put that in the middle?” The cost of changing my mind is minimal—I’m just moving post-it notes around.

With topics broken down into chunks like this, I can flesh out each one. The nice thing about this is that I’ve taken one big overwhelming task—prepare a presentation!—and I’ve broken it down into smaller, more manageable tasks. I can take a random post-it note and set myself, say, ten or fifteen minutes to jot down an explanation of it.

The explanation could just be bullet points. For this particular talk, I decided to write full sentences.

Expanding.
Step 3

Even though, in this case, I was writing out my thoughts word for word, I still kept the topics in separate files. That way, I can still move things around easily.

Crafting the narrative structure of a talk is the part I find most challenging …but it’s also the most rewarding. By having the content chunked up like this, I can experiment with different structures. I like to try out different narrative techniques from books and films, like say, flashback: find the most exciting part of the talk; start with that, and then give the backstory that led up to it. That’s just one example. There are many possible narrative stuctures.

What I definitely don’t do is enact the advice that everyone is given for their college presentations:

  1. say what you’re going to say,
  2. say it, and
  3. recap what you’ve said.

To me, that’s the equivalent of showing an audience the trailer for a film right before watching the film …and then reading a review of the film right after watching it. Just play the film! Give the audience some credit—assume the audience has no knowledge but infinite intelligence.

Oh, and there’s one easy solution to cracking the narrative problem: make a list. If you’ve got 7 chunks, you can always give a talk on “Seven things about whatever” …but it’s a bit of a cop-out. I mean, most films have a three-act structure, but they don’t start the film by telling the audience that, and they don’t point out when one act finishes and another begins. I think it’s much more satisfying—albeit more challenging—to find a way to segue from chunk to chunk.

Finding the narrative thread is tricky work, but at least, by this point, it’s its own separate task: if I had tried to figure out the narrative thread at the start of the process, or even when I was chunking things out, it would’ve been overwhelming. Now it’s just the next task in my to-do list.

I suppose, at this point, I might as well make some slides.

Slides.
Step 4

I’m not trying to be dismissive of slides—I think having nice slides is a very good thing. But I do think that they can become the “busy work” of preparing a presentation. If I start on the slides too soon, I find they’ll take up all my time. I think it’s far more important to devote time to the content and structure of the talk. The slides should illustrate the talk …but the slides are not the talk.

If you don’t think of the slides as being subservient to the talk, there’s a danger that you’ll end up with a slidedeck that’s more for the speaker’s benefit than the audiences.

It’s all too easy to use the slides as a defence mechanism. You’re in a room full of people looking towards you. It’s perfectly reasonable for your brain to scream, “Don’t look at me! Look at the slides!” But taken too far, that can be interpreted as “Don’t listen to me!”

For this particular talk, there were moments when I wanted to make sure the audience was focused on some key point I was making. I decided that having no slide at all was the best way of driving home my point.

But slidedeck style is quite a personal thing, so use whatever works for you.

It’s a similar story with presentation style. Apart from some general good advice—like, speak clearly—the way you present should be as unique as you are. I have just one piece of advice, and it’s this: read Demystifying Public Speaking by Lara Hogan—it’s really, really good!

(I had to apologise to Lara last time I saw her, because I really wanted her to sign my copy of her book …but I didn’t have it, because it’s easily the book I’ve loaned out to other people the most.)

I did a good few run-throughs of my talk. There were a few sentences that sounded fine written down, but were really clumsy to say out loud. It reminded me of what Harrison Ford told George Lucas during the filming of Star Wars: “You can type this shit, George, but you can’t say it.”

I gave a final run-through at work to some of my Clearleft colleagues. To be honest, I find that more nerve-wracking than speaking on a stage in front of a big room full of strangers. I think it’s something to do with the presentation of self.

Finally, the day of the conference rolled around, and I was feeling pretty comfortable with my material. I’m pretty happy with how it turned out. You can read The Web Is Agreement, and you can look at the slides, but as with any conference talk, you kinda had to be there.

This was originally posted on my own site.

]]>
A framework for web performance https://clearleft.com/posts/a-framework-for-web-performance Thu, 20 Sep 2018 15:49:00 +0000 https://clearleft.com/posts/a-framework-for-web-performance Here at Clearleft, we’ve recently been doing some front-end consultancy. That prompted me to jot down thoughts on design principles and performance:

We continued with some more performance work this week. Having already covered some of the nitty-gritty performance tactics like font-loading, image optimisation, etc., we wanted to take a step back and formulate an ongoing strategy for performance.

When it comes to web performance, the eternal question is “What should we measure?” The answer to that question will determine where you then concentrate your efforts—whatever it is your measuring, that’s what you’ll be looking to improve.

I started by drawing a distinction between measurements of quantities and measurements of time. Quantities are quite easy to measure. You can measure these quantities using nothing more than browser dev tools:

  • overall file size (page weight + assets), and
  • number of requests.

I think it’s good to measure these quantities, and I think it’s good to have a performance budget for them. But I also think they’re table stakes. They don’t actually tell you much about the impact that performance is having on the user experience. For that, we need to enumerate moments in time:

  • time to first byte,
  • time to first render,
  • time to first meaningful paint, and
  • time to first meaningful interaction.

There’s one more moment in time, which is the time until DOM content is loaded. But I’m not sure that has a direct effect on how performance is perceived, so it feels like it belongs more in the category of quantities than time.

Next, we listed out all the factors that could affect each of the moments in time. For example, the time to first byte depends on the speed of the network that the user is on. It also depends on how speedily your server (or Content Delivery Network) can return a response. Meanwhile, time to first render is affected by the speed of the user’s network, but it’s also affected by how many blocking elements are on the critical path.

By listing all the factors out, we can draw a distinction between the factors that are outside of our control, and the factors that we can do something about. So while we might not be able to do anything about the speed of the user’s network, we might well be able to optimise the speed at which our server returns a response, or we might be able to defer some assets that are currently blocking the critical path.

Factors
1st byte
  • server speed
  • network speed
1st render
  • network speed
  • critical path assets
1st meaningful paint
  • network speed
  • font-loading strategy
  • image optimisation
1st meaningful interaction
  • network speed
  • device processing power
  • JavaScript size

So far, everything in our list of performance-affecting factors is related to the first visit. It’s worth drawing up a second list to document all the factors for subsequent visits. This will look the same as the list for first visits, but with the crucial difference that caching now becomes a factor.

First visit factors Repeat visit factors
1st byte
  • server speed
  • network speed
  • server speed
  • network speed
  • caching
1st render
  • network speed
  • critical path assets
  • network speed
  • critical path assets
  • caching
1st meaningful paint
  • network speed
  • font-loading strategy
  • image optimisation
  • network speed
  • font-loading strategy
  • image optimisation
  • caching
1st meaningful interaction
  • network speed
  • device processing power
  • JavaScript size
  • network speed
  • device processing power
  • JavaScript size
  • caching

Alright. Now it’s time to get some numbers for each of the four moments in time. I use Web Page Test for this. Choose a realistic setting, like 3G on an Android from the East coast of the USA. Under advanced settings, be sure to select “First View and Repeat View” so that you can put those numbers in two different columns.

Here are some numbers for adactio.com:

First visit time Repeat visit time
1st byte 1.476 seconds 1.215 seconds
1st render 2.633 seconds 1.930 seconds
1st meaningful paint 2.633 seconds 1.930 seconds
1st meaningful interaction 2.868 seconds 2.083 seconds

I’m getting the same numbers for first render as first meaningful paint. That tells me that there’s no point in trying to optimise my font-loading, for example …which makes total sense, because adactio.com isn’t using any web fonts. But on a different site, you might see a big gap between those numbers.

I am seeing a gap between time to first byte and time to first render. That tells me that I might be able to get some blocking requests off the critical path. Sure enough, I’m currently referencing an external stylesheet in the head of adactio.com—if I were to inline critical styles and defer the loading of that stylesheet, I should be able to narrow that gap.

A straightforward site like adactio.com isn’t going to have much to worry about when it comes to the time to first meaningful interaction, but on other sites, this can be a significant bottleneck. If you’re sending UI elements in the initial HTML, but then waiting for JavaScript to “hydrate” those elements into working, the user can end up in an uncanny valley of tapping on page elements that look fine, but aren’t ready yet.

My point is, you’re going to see very different distributions of numbers depending on the kind of site you’re testing. There’s no one-size-fits-all metric to focus on.

Now that you’ve got numbers for how your site is currently performing, you can create two new columns: one of those is a list of first-visit targets, the other is a list of repeat-visit targets for each moment in time. Try to keep them realistic.

For example, if I could reduce the time to first render on adactio.com by 0.5 seconds, my goals would look like this:

First visit goal Repeat visit goal
1st byte 1.476 seconds 1.215 seconds
1st render 2.133 seconds 1.430 seconds
1st meaningful paint 2.133 seconds 1.430 seconds
1st meaningful interaction 2.368 seconds 1.583 seconds

See how the 0.5 seconds saving cascades down into the other numbers?

Alright! Now I’ve got something to aim for. It might also be worth having an extra column to record which of the moments in time are high priority, which are medium priority, and which are low priority.

Priority
1st byte Medium
1st render High
1st meaningful paint Low
1st meaningful interaction Low

Your goals and priorities may be quite different.

I think this is a fairly useful framework for figuring out where to focus when it comes to web performance. If you’d like to give it a go, I’ve made a web performance chart for you to print out and fill in. Here’s a PDF version if that’s easier for printing. Or you can download the HTML version if you want to edit it.

I have to say, I’m really enjoying the front-end consultancy work we’ve been doing at Clearleft around performance and related technologies, like offline functionality. I’d like to do more of it. If you’d like some help in prioritising performance at your company, please get in touch. Let’s make the web faster together.

This was originally posted on my own site.

]]>
Sharing knowledge and artisanal gin at our mini conference and barbecue https://clearleft.com/posts/sharing-knowledge-and-artisanal-gin-at-our-mini-conference-and-barbecue Tue, 18 Sep 2018 09:56:00 +0000 https://clearleft.com/posts/sharing-knowledge-and-artisanal-gin-at-our-mini-conference-and-barbecue Clearleft held our first mini conference and barbecue meet-up for clients, connections and friends.

Held at our studio in Brighton, it was a complimentary afternoon of informative and fun short talks and an evening of delicious food, fine beverages, funky tunes and - of course - fabulous company.

Design and digital in action

Held in our auditorium at 68 Middle Street, the afternoon featured a mini conference especially for clients old and new. It highlighted eight short talks given by members of the Clearleft team and friends, on a variety of core topics:

  • ‘What I talk about when I talk about service design’ by Richard Rutter, Clearleft
  • ‘What I learned about UX from going to the toilet’ by Chris How, Clearleft
  • ‘The art of search listening’ by Sophie Coley, Propellernet
  • ‘Designing design systems’ by Jerlyn Jareunpoon-Phillips, Clearleft
  • ‘Workplace topology’ by Danielle Huntrods, Clearleft
  • ‘Adapting to design culture’ by Andy Thornton, Clearleft
  • ‘How’s your team’s conflict competence?’ by Julia Whitney, Whitney & Associates
  • ‘Building a world class design team’ by Andy Budd, Clearleft

Sharing to learn…

The speaker sessions were the perfect opportunity to knowledge share amongst our peers and foster a culture of learning – something we are hugely passionate about at Clearleft. As one client said, “That was brilliant - it feels like all the talks were designed especially for us” confirming that we fed people’s curiosity for industry insights and market challenges.

BBQ, beers and bunting

As the evening approached, we retired to our deck to be joined by friends and ex-Clearlefties (you can check out but you can never leave). A few craft beers were cracked open, we mixed up some local gins and tonic, tucked into Filipino barbecue supplied by our friends at Mestiza and the conversations flowed. All in all, a perfect end to a fantastic event – one we hope to repeat next year. Thanks to everyone who came along and participated - we couldn’t do it without you!

Interested in seeing some of the speaker sessions?

You can access some of the talks below:

‘What I talk about when I talk about service design’, by Rich Rutter

Introduction to getting service design done by the back door.

‘Building a world class design team’, by Andy Budd

Filmed at The Next Web conference and repurposed for our recent event, Andy’s talk outlines nine things you need to do to foster a healthy design culture, hire the right people, nurture talent and build a world class design team; in order to use design for your competitive advantage.

Follow us on Twitter @clearleft for the latest updates, events, insights and more….

]]>
State of the Browser https://clearleft.com/posts/state-of-the-browser-conf Thu, 13 Sep 2018 10:41:00 +0000 https://clearleft.com/posts/state-of-the-browser-conf Given the amount of thought that the organisers put into inclusivity, it was fitting that this conference was held at Conway hall Ethics society

Thanks to sponsorship by Squiz, a screen had been set to run live transcriptions of the talks, the conference was live streamed and the speakers pages on the website were updated in real time with links and further reading. The crowd itself was diverse and welcoming too, I think in part due to the diversity initiative and reasonable price of tickets.

The talks kicked off with Michelle Barker’s talk on CSS grid. It was loaded with immediately useful takeaways, and her slides were beautiful, using grid to create randomly generated shapes. Grid is impressive enough, but I loved her suggestion of using CSS variables alongside it for finer layout control.

Chris Mills supplemented Michelle’s talk nicely by showcasing Firefox’s developer tools, including a great grid inspector and CSS shape path editor. I was surprised by how easy it was to make complex shape paths just by dragging the points around. The future of design on the web is looking pretty exciting.

Ada Rose Cannon delved into the exciting future of VR and AR on the web, galvanizing me to pick up a half finished three.js project. She also collaborated with Ruth John on a pocket VJ app which looks like a bunch of fun. If you ever fancied yourself a VJ you should check it out! Ruth also gave a great talk, running through how she optimised her Web A/V performance with web workers and worklets.

I loved all the creative talk topics, there are so many new and exciting ways for us as developers to express ourselves. But as Charlie drove home in her thought provoking talk, we mustn’t forget, that when we’re creating for the web. It isn’t about us.

It’s our responsibility as developers to deliver content that is accessible by everyone. That should be our main focus.

Testing for accessibility is our core job

But as I watched Sara Vieirra wade through a sea of inaccessible div soup, it became clear that the development community isn’t doing that. We’re not utilising the already robust, and accessible nature of HTML.

We focus on frameworks, going Javascript first and ignoring the rule of least power.

Choose the least powerful language suitable for a given purpose.

Or as Charlie put it, don’t drive 2km to work in a self built flying car. Buy a bicycle.

Content sites shouldn’t rely on Javascript for delivery. Developing like this is inherently unstable. We shouldn’t be ignoring this instability just because it’s more convenient for us to develop this way. To quote another of the design principles from Jeremy’s talk

Consider users over authors over implementors over specifiers over theoretical purity.

Now I’m not saying we shouldn’t have fun with development! We should definitely explore new technologies and express ourselves by developing more creative and interesting web experiences. But at the end of the day, delivering our content to the user is the most important thing.

The Web is for everyone, Lets put as much effort into making it accessible as State of the browser did for the conference itself.

]]>
The top four web performance challenges https://clearleft.com/posts/the-top-four-web-performance-challenges Tue, 11 Sep 2018 18:27:26 +0000 https://clearleft.com/posts/the-top-four-web-performance-challenges Counting down the charts—what will be in the number one spot?

Danielle and I have been doing some front-end consultancy for a local client recently.

We’ve both been enjoying it a lot—it’s exhausting but rewarding work. So if you’d like us to come in and spend a few days with your company’s dev team, please get in touch.

I’ve certainly enjoyed the opportunity to watch Danielle in action, leading a workshop on refactoring React components in a pattern library. She’s incredibly knowledgable in that area.

I’m clueless when it comes to React, but I really enjoy getting down to the nitty-gritty of browser features—HTML, CSS, and JavaScript APIs. Our skillsets complement one another nicely.

This recent work was what prompted my thoughts around the principles of robustness and least power. We spent a day evaluating a continuum of related front-end concerns: semantics, accessibility, performance, and SEO.

When it came to performance, a lot of the work was around figuring out the most suitable metric to prioritise:

  • time to first byte,
  • time to first render,
  • time to first meaningful paint, or
  • time to first meaningful interaction.

And that doesn’t even cover the more easily-measurable numbers like:

  • overall file size,
  • number of requests, or
  • pagespeed insights score.

One outcome was to realise that there’s a tendency (in performance, accessibility, or SEO) to focus on what’s easily measureable, not because it’s necessarily what matters, but precisely because it is easy to measure.

Then we got down to some nuts’n’bolts technology decisions. I took a step back and looked at the state of performance across the web. I thought it would be fun to rank the most troublesome technologies in order of tricksiness. I came up with a top four list.

Here we go, counting down from four to the number one spot…

4. Web fonts

Coming in at number four, it’s web fonts. Sometimes it’s the combined weight of multiple font files that’s the problem, but more often that not, it’s the perceived performance that suffers (mostly because of when the web fonts appear).

Fortunately there’s a straightforward question to ask in this situation: WWZD—What Would Zach Do?

3. Images

At the number three spot, it’s images. There are more of them and they just seem to be getting bigger all the time. And yet, we have more tools at our disposal than ever—better file formats, and excellent browser support for responsive images. Heck, we’re even getting the ability to lazy load images in HTML now.

So, as with web fonts, it feels like the impact of images on performance can be handled, as long as you give them some time and attention.

2. Our JavaScript

Just missing out on making the top spot is the JavaScript that we send down the pipe to our long-suffering users. There’s nothing wrong with the code itself—I’m sure it’s very good. There’s just too damn much of it. And that’s a real performance bottleneck, especially on mobile.

So stop sending so much JavaScript—a solution as simple as Monty Python’s instructions for playing the flute.

1. Other people’s JavaScript

At number one with a bullet, it’s all the crap that someone else tells us to put on our websites. Analytics. Ads. Trackers. Beacons. “It’s just one little script”, they say. And then that one little script calls in another, and another, and another.

It’s so disheartening when you’ve devoted your time and energy into your web font loading strategy, and optimising your images, and unbundling your JavaScript …only to have someone else’s JavaScript just shit all over your nice performance budget.

Here’s the really annoying thing: when I go to performance conferences, or participate in performance discussions, you know who’s nowhere to be found? The people making those third-party scripts.

The narrative around front-end performance is that it’s up to us developers to take responsibility for how our websites perform. But by far the biggest performance impact comes from third-party scripts.

There is a solution to this, but it’s not a technical one. We could refuse to add overweight (and in many cases, unethical) third-party scripts to the sites we build.

I have many, many issues with Google’s AMP project, but I completely acknowledge that it solves a political problem:

No external JavaScript is allowed in an AMP HTML document. This covers third-party libraries, advertising and tracking scripts. This is A-okay with me.

The reasons given for this ban are related to performance and I agree with them completely. Big bloated JavaScript libraries are one of the biggest performance killers on the web.

But how can we take that lesson from AMP and apply it to all our web pages? If we simply refuse to be the one to add those third-party scripts, we get fired, and somebody else comes in who is willing to poison web pages with third-party scripts. There’s nothing to stop companies doing that.

Unless…

Suppose we were to all make a pact that we would stand in solidarity with any of our fellow developers in that sort of situation. A sort of joining-together. A union, if you will.

There is power in a factory, power in the land, power in the hands of the worker, but it all amounts to nothing if together we don’t stand.

There is power in a union.

This was originally posted on my own site.

]]>
Robustness and least power https://clearleft.com/posts/robustness-and-least-power Mon, 10 Sep 2018 22:31:00 +0000 https://clearleft.com/posts/robustness-and-least-power A tale of two principles.

There’s a great article by Steven Garrity over on A List Apart called Design with Difficult Data. It runs through the advantages of using unusual content to stress-test interfaces, referencing Postel’s Law, AKA the robustness principle:

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

Even though the robustness principle was formulated for packet-switching, I see it at work in all sorts of disciplines, including design. A good example is in best practices for designing forms:

Every field you ask users to fill out requires some effort. The more effort is needed to fill out a form, the less likely users will complete the form. That’s why the foundational rule of form design is shorter is better — get rid of all inessential fields.

In other words, be conservative in the number of form fields you send to users. But then, when it comes to users filling in those fields:

It’s very common for a few variations of an answer to a question to be possible; for example, when a form asks users to provide information about their state, and a user responds by typing their state’s abbreviation instead of the full name (for example, CA instead of California). The form should accept both formats, and it’s the developer job to convert the data into a consistent format.

In other words, be liberal in what you accept from users.

I find the robustness principle to be an immensely powerful way of figuring out how to approach many design problems. When it comes to figuring out what specific tools or technologies to use, there’s an equally useful principle: the rule of least power:

Choose the least powerful language suitable for a given purpose.

On the face of it, this sounds counter-intuitive; why forego a powerful technology in favour of something less powerful?

Well, power comes with a price. Powerful technologies tend to be more complex, which means they can be trickier to use and trickier to swap out later.

Take the front-end stack, for example: HTML, CSS, and JavaScript. HTML and CSS are declarative, so you don’t get as much precise control as you get with an imperative language like JavaScript. But JavaScript comes with a steeper learning curve and a stricter error-handling model than HTML or CSS.

As a general rule, it’s always worth asking if you can accomplish something with a less powerful technology:

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

  • Instead of using JavaScript to do animation, see if you can do it in CSS instead.
  • Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like required.
  • Instead of using ARIA to give a certain role value to a div or span, try to use a more suitable HTML element instead.

It sounds a lot like the KISS principle: Keep It Simple, Stupid. But whereas the KISS principle can be applied within a specific technology—like keeping your CSS manageable—the rule of least power is all about evaluating technology; choosing the most appropriate technology for the task at hand.

There are some associated principles, like YAGNI: You Ain’t Gonna Need It. That helps you avoid picking a technology that’s too powerful for your current needs, but which might be suitable in the future: premature optimisation. Or, as Rachel put it, stop solving problems you don’t yet have:

So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.

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

After all, if they’re good enough for Tim Berners-Lee…

This was originally posted on my own site.

]]>
Wirehive 100 Digital Transformation Finalist https://clearleft.com/posts/wirehive-100-digital-transformation-finalist Tue, 04 Sep 2018 21:18:00 +0000 https://clearleft.com/posts/wirehive-100-digital-transformation-finalist Clearleft has been shortlisted for our work with Virgin Holidays in the Digital Transformation category of the 2018 Wirehive 100 awards.

The prestigious Wirehive 100 Awards showcase digital excellence and recognise outstanding work from agencies in the southern counties based outside of London. The award nomination follows Clearleft’s ranking at No.9 in the 2017 Wirehive 100 League Table for the best digital talent in the UK’s southeast.

The work we did with Virgin Holidays, over a period of 18 months, helped them build their own design capability and begin to change the way the company approaches approach digital.

Their in-house digital design team has doubled in size, with Clearleft supporting the coaching, training, mentoring and recruitment of new team members, in diverse roles from Product Design, User Experience and Customer Insights & Research.

In collaboration with the Technology leadership team, Clearleft played a vital role in ensuring that the voice of design now has a seat at the table – both in terms of the future shape of digital at Virgin Holidays, and the decision-making processes behind their digital strategy.

Since our partnership with Virgin Holidays began, sales generated via the web have grown faster and larger than ever, increasing by 8% over 2 years, to the point where the web is now is now the largest sales channel.

Winners of the Wirehive 100 awards will be announced at the ceremony on 11th October at the Guildhall in Southampton. Fingers crossed!

]]>
The history of design systems at Clearleft https://clearleft.com/posts/the-history-of-design-systems-at-clearleft Wed, 25 Jul 2018 15:02:00 +0000 https://clearleft.com/posts/the-history-of-design-systems-at-clearleft From pattern portfolios to front-end style guides to pattern libraries to Fractal, we’ve spent a decade thinking about design systems at Clearleft.

Danielle has posted a brief update on Fractal:

We decided to ask the Fractal community for help, and the response has been overwhelming. We’ve received so many offers of support in all forms that we can safely say that development will be starting up again shortly.

It’s so gratifying to see that other people are finding Fractal to be as useful to them as it is to us. We very much appreciate all their support!

Although Fractal itself is barely two years old, it’s part of a much longer legacy at Clearleft

It all started with Natalie. She gave a presentation back in 2009 called Practical Maintainable CSS . She talks about something called a pattern porfolio—a deliverable that expresses every component and documents how the markup and CSS should be used.

When Anna was interning at Clearleft, she was paired up with Natalie so she was being exposed to these ideas. She then expanded on them, talking about Front-end Style Guides. She literally wrote the book on the topic, and starting curating the fantastic collection of examples at styleguides.io.

When Paul joined Clearleft, it was a perfect fit. He was already obsessed with style guides (like the BBC’s Global Experience Language) and started writing and talking about styleguides for the web:

At Clearleft, rather than deliver an inflexible set of static pages, we present our code as a series of modular components (a ‘pattern portfolio’) that can be assembled into different configurations and page layouts as required.

Such systematic thinking was instigated by Natalie, yet this is something we continually iterate upon.

To see the evolution of Paul’s thinking, you can read his three part series from last year on designing systems:

  1. Theory, Practice, and the Unfortunate In-between,
  2. Layers of Longevity, and
  3. Components and Composition

Later, Charlotte joined Clearleft as a junior developer, and up until that point, hadn’t been exposed to the idea of pattern libraries or design systems. But it soon became clear that she had found her calling. She wrote a brilliant article for A List Apart called From Pages to Patterns: An Exercise for Everyone and she started speaking about design systems at conferences like Beyond Tellerrand. Here, she acknowledges the changing terminology over the years:

Pattern portfolio is a term used by Natalie Downe when she started using the technique at Clearleft back in 2009.

Front-end style guides is another term I’ve heard a lot.

Personally, I don’t think it matters what you call your system as long as it’s appropriate to the project and everyone uses it. Today I’m going to use the term “pattern library”.

(Mark was always a fan of the term “component library”.)

Now Charlotte is a product manager at Ansarada in Sydney and the product she manages is …the design system!

Thinking back to my work on starting design systems, I didn’t realise straight away that I was working on a product. Yet, the questions we ask are similar to those we ask of any product when we start out. We make decisions on things like: design, architecture, tooling, user experience, code, releases, consumption, communication, and more.

It’s been fascinating to watch the evolution of design systems at Clearleft, accompanied by an evolution in language: pattern portfolios; front-end style guides; pattern libraries; design systems.

There’s been a corresponding evolution in prioritisation. Where Natalie was using pattern portfolios as a deliverable for handover, Danielle is now involved in the integration of design systems within a client’s team. The focus on efficiency and consistency that Natalie began is now expressed in terms of design ops—creating living systems that everyone is involved in.

When I step back and look at the history of design systems on the web, there are some obvious names that have really driven their evolution and adoption, like Jina Anne, Brad Frost, and Alla Kholmatova. But I’m amazed at the amount of people who have been through Clearleft’s doors that have contributed so, so much to this field:

Natalie Downe, Anna Debenham, Paul Lloyd, Mark Perkins, Charlotte Jackson, and Danielle Huntrods …thank you all!

This was originally posted on my own site.

]]>
A Fractal update https://clearleft.com/posts/a-fractal-update Tue, 24 Jul 2018 19:14:00 +0000 https://clearleft.com/posts/a-fractal-update Some good news for the future of Fractal.

Recent changes in Fractal’s core team left us with limited development time. While version 1 is stable and being used in many projects, progress on version 2 had come to a halt.

But we still believed that Fractal is one of the best tools around for producing a pattern library. We determined to find a way to safeguard its future.

We decided to ask the Fractal community for help, and the response has been overwhelming. We’ve received so many offers of support in all forms that we can safely say that development will be starting up again shortly. 

For more details, please see issue #449 (‘An update on Fractal’s future development’) on Github. See how we are planning on moving Fractal forwards, and help shape its future.

]]>
Altering expectations https://clearleft.com/posts/altering-expectations Tue, 24 Jul 2018 14:42:00 +0000 https://clearleft.com/posts/altering-expectations How do we let people know what the web can do?

Luke has written up the selection process he went through when Clearleft was designing the Virgin Holidays app. When it comes to deploying on mobile, there were three options:

  1. Native apps
  2. A progressive web app
  3. A hybrid app

The Virgin Holidays team went with that third option.

Now, it will come as no surprise that I’m a big fan of the second option: building a progressive web app (or turning an existing site into a progressive web app). I think a progressive web app is a great solution for travel apps, and the use-case that Luke describes sounds perfect:

Easy access to resort staff and holiday details that could be viewed offline to help as many customers as possible travel without stress and enjoy a fantastic holiday

Luke explains why they choice not to go with a progressive web app.

The current level of support and leap in understanding meant we’d risk alienating many of our customers.

The issue of support is one that is largely fixed at this point. When Clearleft was working on the Virgin Holidays app, service workers hadn’t landed in iOS. Hence, the risk of alienating a lot of customers. But now that Mobile Safari has offline capabilities, that’s no longer a problem.

But it’s the second reason that’s trickier:

Simply put, customers already expected to find us in the App Store and are familiar with what apps can historically offer over websites.

I think this is the biggest challenge facing progressive web apps: battling expectations.

For over a decade, people have formed ideas about what to expect from the web and what to expect from native. From a technical perspective, native and web have become closer and closer in capabilities. But people’s expectations move slower than technological changes.

First of all, there’s the whole issue of discovery: will people understand that they can “install” a website and expect it to behave exactly like a native app? This is where install prompts and ambient badging come in. I think ambient badging is the way to go, but it’s still a tricky concept to explain to people.

But there’s another way of looking at the current situation. Instead of seeing people’s expectations as a negative factor, maybe it’s an opportunity. There’s an opportunity right now for companies to be as groundbreaking and trendsetting as Wired.com when it switched to CSS for layout, or The Boston Globe when it launched its responsive site.

It makes for a great story. Just look at the Pinterest progressive web app for an example (skip to the end to get to the numbers):

Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board. Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups. And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).

Now admittedly their previous mobile web experience was a dreadful doorslam, but still, those are some amazing statistics!

Maybe we’re underestimating the malleability of people’s expectations when it comes to the web on mobile. Perhaps the inertia we think we’re battling against isn’t such a problem as long as we give people a fast, reliable, engaging experience.

If you build that, they will come.

This was originally posted on my own site.

]]>
Weighing up the options https://clearleft.com/posts/weighing-up-the-options Tue, 24 Jul 2018 12:22:00 +0000 https://clearleft.com/posts/weighing-up-the-options There are three ways of delivering an app on mobile. You can build a web app, you can build native apps, or you can build a hybrid.

When we were designing the Virgin Holidays app, we knew what we wanted to deliver: easy access to resort staff and holiday details that could be viewed offline to help as many customers as possible travel without stress and enjoy a fantastic holiday. This meant we wanted the app to be available for both iOS and Android.

Native for the best experience

In a world of unquestioned funding and unlimited resources, native apps would be the way to go. Built by specialists on the platforms they know inside out, crafting every interaction to present a refined and natural experience.

The capability of a native codebase shows in the finished product but if you want to offer the same experience to both iOS and Android users, it will cost you. You are building two apps with two sets of code, two builds to update with changes or bug fixes and double the ongoing commitment to adding new features and fixes.

A Progressive Web App for the future

Virgin Holidays already had websites for a lot of the content and functionality we wanted to offer users. Couldn’t we take advantage of the growing support for service workers to serve our web content offline and capitalise on device features?

The current level of support and leap in understanding meant we’d risk alienating many of our customers. Simply put, customers already expected to find us in the App Store and are familiar with what apps can historically offer over websites. It’s still an appealing idea and as the technology and support improves, it will open a world of opportunity for websites to better serve users.

Hybrid for efficiency

The hybrid approach seeks to solve the problem of duplicated effort: one codebase built on web technologies and exported to suit each platform.

There are clear efficiencies in the more streamlined delivery and the automatic parity between iOS, Android, and even Windows if you want, but the gains come with some sacrifices. A hybrid app doesn’t offer the same level of control as a natively coded bespoke build and the finer details of animations and interactions can be lost in translation.

After weighing up the pros and cons of all three approaches, we decided that the hybrid solution was the right choice for the Virgin Holidays app.

]]>
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:00 +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?

iPhone 5.

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.

A workshop in progress.
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.

Two people having a discussion in front of a wall of post-it notes.
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.

Neue Mälzerei

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

A room filled with members of the CSS working group.
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.

]]>