Clearleft | Blog https://clearleft.com/posts/ The latest news from Clearleft en-gb Sat, 18 May 2019 09:53:26 +0000 Sat, 18 May 2019 09:53:26 +0000 Give your information architecture a three-point checkup https://clearleft.com/posts/give-your-information-architecture-ia-a-three-point-checkup Fri, 17 May 2019 08:35:00 +0000 https://clearleft.com/posts/give-your-information-architecture-ia-a-three-point-checkup “How do you know your site structure is needing attention before it becomes really broken?”

I’ve recently been asked variations of this question by a couple of clients, a colleague and the attendees of a presentation I was giving.

A great information architecture (IA) tells a story, creates flow and aids discovery for the people using your products or services.

An ailing IA threatens to silence your content, prevent conversion (sales and engagement) and frustrate your users. The good news is a sick information architecture can easily be cured with early diagnosis and painless remedies.

Here are three tell-tale signs to look for and some ways to avoid the problem in the first place:

Warning sign #1. You’ve shipped your org-chart

Be mindful not to conform to Conway’s Law where organisations design systems which mirror the organisation’s structure. You’ll know you’re doing this when the hot project or latest initiative get undue prominence in navigation menus. Or when you can match the words used in page labels with a department or person’s job title in the business.

Shipping the org-chart is often done inadvertently without anyone really noticing until it’s too late.

The way to remedy it is to get out of your building and meet more of your users more regularly. Listen to the words they use to describe what you offer. Open card sorting is the ideal technique to help with this. As a robust, quick and repeatable activity, it helps you find out how the people you want to use your website would organise and label the items on it to make them easy to find.

Warning sign #2. The loudest voice trumps the considered logic

You will know this when you see it. It crops up in navigation menus that seem to have an order with the exception of a couple of prominently misplaced items. You sense it when a page is featured multiple times in multiple menus desperately calling out for you to care enough to click on it.

So many site structures reflect the egos of individuals in the business. To avoid incongruous items getting shoe-horned into your information architecture I’d look to engage stakeholders early on, to help shape their brief rather than just receiving it.

Having the principles and concepts articulated for how the site is organised helps move the request from tactical demands to a more considered strategic conversation. It’s important to change the conversation to focus on desired outcomes rather than the position within a menu. Having your content found is ultimately more valuable than appearing in the primary navigation and easy to measure and report on.

The result of not looking after the health of your IA

Warning sign #3. Your IA is treated as a project rather than a process

Projects feel good. There’s a crisis to deal with and all you need is to call for the cavalry to ride into town and just in the nick of time to save the day.

Your IA should never become a crisis. Unlike a project managing your IA should be an ongoing activity without an end date. After all, a healthy digital product or service never stands still with ongoing enhancements and additions to what you offer.

You know your IA is respected as a critical part of your digital operations when:

  • There is a person responsible for it with defined KPIs to meet
  • The process and logic for positioning and labelling pages is documented
  • Time is regularly scheduled for review and attention

A great IA doesn’t happen by lucky accident. They need to be designed, iterated upon and optimised. Without care and ongoing love they quickly become overgrown and unwieldy.

How to nurture your IA

Hopefully, your information architecture doesn’t exhibit any of these three warning signs. If it does take some action to remedy the problem sooner rather than later.

If your IA is currently in good shape, then make sure you schedule your next check-up, as a thriving website is always in a state of change. To keep it healthy requires considered processes and ongoing attention.

]]>
A 'rough guide to UX' workshop https://clearleft.com/posts/a-rough-guide-to-ux-workshop Tue, 30 Apr 2019 14:00:00 +0000 https://clearleft.com/posts/a-rough-guide-to-ux-workshop After sampling the infamous coffee and sitting in on the Monday team meeting, I kicked off my time at Clearleft with a fascinating ‘Rough guide to UX’ workshop led by Andy Thornton.

It was a fortuitous day to start, not only did I get to learn UX techniques from the very best, I got to know six of my new colleagues in a great environment.

I arrived a little late (the new laptop took a while to set up!); they’d just finished running through the history of UX, and discussing user-centered design. This led on to the first activity, the interview.

Empathy mapping

We interviewed each other to find out more about our holidaying habits, how we decide when and where to go, and what informs our plans. As the interviewer, we categorised answers into four categories:

This empathy map helped disseminate the information, tailor our questions, and sift through the noise. The type of questions were crucial. A ‘closed’ question would often resolve in a yes/no answer, and would run the risk of introducing interviewer bias. “Do you gather holiday inspiration from Instagram” offers little insight. “Do you gather holiday inspiration from Instagram or Pinterest” gives the interviewee two choices, neither of which may be correct.

‘Open’ questions reveal more useful information, but require greater trust between the two parties. Asking the ‘why’ questions is where the real gold lies.

Coming to the table with a beginners mind keeps your interviewing bias to a minimum, even if you are an expert in the field. The whole exercise really brought home what a great skill interviewing is.

Keeping focus on past and current experiences was a theme that persisted throughout the day. Questions about a previous holiday will yield more accurate answers than those about a potential future holiday.

Jobs, pains & gains

We split into two groups and picked a scenario that we wished to improve with UX techniques. Our team chose ‘improving the new starter process’, which was suitably meta on day one! It turned out to be a great choice - I learned a bunch about what’s coming up for me in the next couple of weeks!

The task was to outline the following aspects of the new starter experience:

  • Jobs: Goals, and things one wants to achieve
  • Gains: Opportunities, practical outcomes, and soft feelings
  • Pains: Challenges and obstacles

It was interesting to see how many jobs could also be gains. ‘Doing’ is such a positive thing for a new starter, so many goals blended between the two. We finished by ordering the post-its in each column by importance. The ‘time’ factor made a large difference to the order. Short-term goals tended to place higher, but longer-term goals led to more gains overall.

These two tasks were part of the problem definition phase of the heralded double-diamond.

Story mapping

The next task was to story map the current process for new starters. Again, the onus was still to focus on what’s happening now, not our desired outcomes (yet). We broke it down into a filmstrip:

  • Chapters: high-level themes
  • Scenes: Categories of events
  • Actions: Individual events

The general rule of thumb was if it can’t be broken down into smaller chunks, it’s an action. We started with scenes and worked down to actions and up to chapters. The scenes act as a time-based narrative and help pin down what happens day-to-day.

Again, as we discussed each scene in detail, we found that some scenes became actions, and others became chapters, or even multiple scenes.

The next step was to mark high and low points of the experience. This provoked much discussion on character, introversion and public speaking. Many of the actions initially marked as green by our team’s extrovert were red in my introverted eyes! Clearleft run regular ‘brown-bag’ lunches where members of the team share their experience, or something of interest. This is also part of the induction process, and for those less excited by public speaking, that prospect can be pretty daunting!

The story map can also be extended to become a helpful tool in planning the whole project. Chapters become epics, scenes become stories, and actions become tasks. We can even draw sensible ‘release lines’ across our model!

The peak-end rule suggests that humans remember the highs/lows and the end of an experience, so that’s where we should be focusing our attention. If we identify the lows and mitigate them, we can make a dramatic difference to the view of the overall experience!

Explore ideas

With those lows in mind, it was time to find some solutions.

We began with a task to lower the barrier to sketching. Drawing is often seen as a scary and vulnerable task for those less creative, and a point of pride for those who regularly sketch! Both can get paralysed when asked to create a one-minute sketch in front of others.

This icebreaker came in the form of squiggle birds, yes, you read that correctly. The premise is as follows:

  1. Draw a bunch of squiggles on the page!
  2. Add a beak to one of the edges
  3. Now an eye
  4. And some feet
  5. Maybe a tail if you’re feeling adventurous!

Give it a go - it’s a lot of fun! I’ve also made a little JS squiggle bird to demonstrate, have a click through below!

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

The human brain is brilliant at finding meaning from noise, if we can create birds from squiggles, we can do some rough sketching!

Sketching our squiggle birds

6UPs

So, to the task itself…

We creased our paper into six sections and had one minute to draw a solution to one of the problems brought to light from our story map. When the timer went, we moved onto the next section and drew another solution to a different problem. Six run-throughs later, and we had six (quite poorly drawn) ideas on paper! We kept those ideas to ourselves and moved onto the next task.

Taking another sheet of A3, we spent 15 minutes on one idea, going into a lot more detail. The previous task, although fleeting, was a great precursor to this activity. I ended up taking two or three ideas from it, and combining it into one main proposition.

If you couldn't tell, I fall into the 'not overly keen on sketching' camp!

Feedback & Critique

Andy then walked through a few stumbling blocks to critiques, including GroupThink, an idea that in a desire to reduce conflict, a group will often reach a compromised decision without properly evaluating the matter. I thought back to attending jury duty. Dropping a group of strangers together and asking them to come to an informed, and ideally unanimous decision, is a tricky task indeed.

To alleviate this problem, we put on thinking hats. Six distinct roles were spread around the table and we were to all assume the respective personas:

  • Blue: facilitator, the individual presenting their idea
  • White: objective, data-focused
  • Red: feelings, hunches and emotion
  • Green: creativity, building upon ideas
  • Yellow: positivity!
  • Black: negativity, ‘devils advocate’ and caution

The simple act of pinning a coloured post-it and becoming that persona took all the pressure out of presenting to the group. We all outlined our ideas and had genuinely good discussions about each one. When the ‘black hat’ brought up issues, the green and yellow were right beside you to defend and build on your idea. It was fun, safe, and productive.

Testing and learning

The final part of the day went through some processes for testing our solutions. It was mostly theoretical, but super interesting.

By structuring our work as experiments, we reduce the cost of failure. It’s a great way to propose new features or ideas to a manager or stakeholder. The key is to only test one thing against your hypothesis.

This fits nicely into a ‘Observe’, ‘Hypothesise’, ‘Test’, and ‘Theorise’ model, and can lead to great, data-driven results. Sounds a little similar to red, green, refactor!

Summary

I was so fortunate to kickoff my time at Clearleft with such an informative and interesting day. I learned a ton about UX, how Clearleft go about workshopping, and how the new starter process will work itself out over the next few weeks!

This was originally posted on my own site.

]]>
Earth day, API's and sunshine. https://clearleft.com/posts/earth-day Mon, 22 Apr 2019 09:25:00 +0000 https://clearleft.com/posts/earth-day Here at Clearleft we’ve been taking small steps to reduce our environmental impact. In December 2018 we covered the roof of our home with solar panels.

With the first of the glorious summer sun starting to shine down on us, we started to ponder about what environmental impact they’d had over the last 5 months.

Luckily for us, our solar panels have an API, so we can not only find out that information, we can request it from SolarEdge and display it in our very own interface.

If I lost you at API, it isn’t a type of hipster beer. API stands for application programming interface. A company can make some of its data available to developers by building an API, a set of dedicated URLs that return data responses . This article describes them as little robo-waiters, serving up data to other apps and websites.

I’m always up for a fun side project, so when I saw that Earth day was on the horizon, I grabbed the opportunity. I make a lot of cute web animations and interactive code experiments on CodePen. But I’ve never tried to visualize any data before. So the first step was to find out what was accessible. What data could I get my hands on?

Jeremy and I got up the docs and started doing some investigation. The first thing that jumped out at us was this -

treesPlanted: equivalent planting of new trees for reducing CO₂ levels

Wouldn’t it be cool if over the years we could somehow see the number of trees we’d “planted”? Create a kind of digital forest and watch it grow?

I started scribbling down some rough ideas. I wanted the visual to link to Clearleft and Brighton somehow but there aren’t many forests (or gardens) in central Brighton. A roof garden seemed like a good location for our digital forest.

A rough sketch of the 68 middle street building with trees on roof and wind turbine in the background.

68 middle street has a lot of windows, so that jumped out as a good way to display our current power.

Our peak power is 6.48 kWp and is essentially the rate at which our solar system generates energy at noon of a super sunny day. The amount of energy a system generates is measured in kilowatt hours (kWh). Each of our kWp’s should generate around 800 to 850 kWh per year (if we get a decent amount of sunshine, which in the UK is sometimes rather elusive) By querying our peak power and current power, we can work out what percentage of our overall capacity we’re currently at.

Once I’d worked out what data I wanted, I used the fetch API to get it. This tutorial by Sara Vieira helped me to wrap my head around this.

fetch() allows us to make network requests similar to XMLHttpRequest. The main difference is that the Fetch API uses Promises. A promise object is data returned by asynchronous function. It will resolve if the function returned successfully or reject if the function returned an error.

fetch("https://our-API-URL")
 .then(response => response.json())
 .then(response => {
   // Do all the fun stuff with the data here!
 })
 .catch(err => {
   console.log("oh no. something went wrong");
 });

First we call the fetch API and pass it the URL we want to get the data from, as we haven’t specified any other parameters, this will be a simple GET request. We also want our data as a JSON object so we add response.json to parse the response as JSON.

If the promise gets resolved, our then function will trigger and do all the fun stuff with the SVG illustration and the API data. And if our promise gets rejected our catch function will trigger and throw an error to alert us.

As for the illustration itself! The illustration is an SVG, or scalable vector graphic. The best bit about SVG that it gives you is the ability to manipulate it’s properties.

SVG has a DOM, much like HTML and when used inline, (by putting the SVG code right into your HTML), you can access this DOM with CSS or Javascript and do things to it.

 <svg class="68middlestreet"... >
   <path class="sky" fill="#91b1bf" d="M9 52.1h813.2v767.6H9z" />
    <g class="clouds">
      <path fill="#d9eafc" d="M-207.6 395.2c14.2..."/>
      <path fill="#f9f9f9" d="M-67.2 389.9s-5.4 3-..."/>
    </g>
     ...
</svg>
A picture of the illustration being put together in adobe Illustrator

I created the SVG building in illustrator. It was a pretty large SVG with a lot of detail, and the exported code can be pretty unwieldy straight out of a graphics editor. So I ran it through SVGOMG to tidy it up.

When the then function gets triggered, I’m adding a class called animate to the body of the HTML. I’m using CSS for the animations, and I’ve bound the animations to this class.

This ensures that the animations don’t start before the data response has come back from the API, as we require that information to know how many trees to grow and windows to light up.

.then(response => {
 document.body.classList.add("animate");
 ...
})
.animate .tree {
  animation: grow 0.6s cubic-bezier(0.175, 0.885, 0.32, 1.1) forwards 1s;
}

@keyframes grow {
  from {
    opacity: 0;
    transform: scale(0) translateY(100%);
  }
  to {
    transform: scale(1) translateY(0);
    opacity: 1;
  }
}

My personal favourite bit of this project was creating an accurate representation of the number of trees.

If there’s a fractional part to the number of trees. i.e. 2.3 instead of 2, we get to create a cute mini-tree!

I used a modulo operation to find the remainder after dividing by one and then set the tree size to that remainder.

var littleTreeSize;
var isLittleTree = false;

// work out if there's a small tree
var treeMod = treeCount % 1;
// if there's a remainder then set isLittleTree to true
var isLittleTree = treeMod > 0;

if (isLittleTree) {
 // set little tree size
 littleTreeSize = treeMod;
}

All in all this was great fun. I look forward to a summer full of sunshine so that we can watch a digital forest spring up from our rooftop!

Check out our final data vis here 

]]>
Three more Patterns Day speakers https://clearleft.com/posts/three-more-patterns-day-speakers Tue, 16 Apr 2019 14:58:57 +0000 https://clearleft.com/posts/three-more-patterns-day-speakers There are 73 days to go until Patterns Day. Do you have your ticket yet?

Perhaps you’ve been holding out for some more information on the line-up. Well, I’m more than happy to share the latest news with you—today there are three new speakers on the bill…

Emil Björklund, the technical director at the Malmö outpost of Swedish agency inUse, is a super-smart person I’ve known for many years. Last year, I saw him on stage in his home town at the Confront conference sharing some of his ideas on design systems. He blew my mind! I told him there and then that he had to come to Brighton and expand on those thoughts some more. This is going to be an unmissable big-picture talk in the style of Paul’s superb talk last year.

Speaking of superb talks from last year, Alla Kholmatova is back! Her closing talk from the first Patterns Day was so fantastic that it I just had to have her come back. Oh, and since then, her brilliant book on Design Systems came out. She’s going to have a lot to share!

The one thing that I felt was missing from the first Patterns Day was a focus on inclusive design. I’m remedying that this time. Heydon Pickering, creator of the Inclusive Components website—and the accompanying book—is speaking at Patterns Day. I’m very excited about this. Given that Heydon has a habit of casually dropping knowledge bombs like the lobotomised owl selector and the flexbox holy albatross, I can’t wait to see what he unleashes on stage in Brighton on June 28th.

Emil Björklund Alla Kholmatova Heydon Pickering
Emil, Alla, and Heydon

Be there or be square.

Tickets for Patterns Day are still available, but you probably don’t want to leave it ‘till the last minute to get yours. Just sayin’.

The current—still incomplete—line-up comprises:

That isn’t even the full roster of speakers, and it’s already an unmissable event!

I very much hope you’ll join me in the beautiful Duke of York’s cinema on June 28th for a great day of design system nerdery.

This was originally posted on my own site.

]]>
Design Perception https://clearleft.com/posts/design-perception Thu, 11 Apr 2019 11:34:00 +0000 https://clearleft.com/posts/design-perception Last week I wrote a post called Dev perception:

I have a suspicion that there’s a silent majority of developers who are working with “boring” technologies on “boring” products in “boring” industries …you know, healthcare, government, education, and other facets of everyday life that any other industry would value more highly than Uber for dogs.

The sentiment I expressed resonated with a lot of people. Like, a lot of people.

I was talking specifically about web development and technology choices, but I think the broader point applies to other disciplines too.

Last month I had the great pleasure of moderating two panels on design leadership at an event in London (I love moderating panels, and I think I’m pretty darn good at it too). I noticed that the panels comprised representatives from two different kinds of companies.

There were the digital-first companies like Spotify, Deliveroo, and Bulb—companies forged in the fires of start-up culture. Then there were the older companies that had to make the move to digital (transform, if you will). I decided to get a show of hands from the audience to see which kind of company most people were from. The overwhelming majority of attendees were from more old-school companies.

Just as most of the ink spilled in the web development world goes towards the newest frameworks and toolchains, I feel like the majority of coverage in the design world is spent on the latest outputs from digital-first companies like AirBnB, Uber, Slack, etc.

The end result is the same. A typical developer or designer is left feeling that they—and their company—are behind the curve. It’s like they’re only seeing the Instagram version of their industry, all airbrushed and filtered, and they’re comparing that to their day-to-day work. That can’t be healthy.

Personally, I’d love to hear stories from the trenches of more representative, traditional companies. I also think that would help get an important message to people working in similar companies:

You are not alone!

This was originally posted on my own site.

]]>
Split https://clearleft.com/posts/split Wed, 10 Apr 2019 14:59:00 +0000 https://clearleft.com/posts/split When I talk about evaluating technology for front-end development, I like to draw a distinction between two categories of technology.

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

Personally, I’m much more interested and excited by the materials than I am by the tools. But I think it’s right and proper that other developers are excited by the tools. A good balance of both is probably the healthiest mix.

I’m never sure what to call these two categories. Maybe the materials are the “external” technologies, because they’re what users will interact with. Whereas all the other technologies—that mosty live on a developer’s machine—are the “internal” technologies.

Another nice phrase is something I heard during Chris’s talk at An Event Apart in Seattle, when he quoted Brad, who talked about the front of the front end and the back of the front end.

I’m definitely more of a front-of-the-front-end kind of developer. I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).

As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time. Like I said, from a user’s point of view, it’s irrelevant what text editor or version control system you use.

Now, you could make the argument that anything that is good for developer convenience is automatically good for user experience because faster, more efficient development should result in better output. While that’s true in theory, I highly recommend Alex’s post, The “Developer Experience” Bait-and-Switch.

Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

Historically, it’s been a similar story with JavaScript libraries. They’re written in JavaScript, and so they’re going to be executed in the browser. If a developer wanted to use jQuery to make their life easier, the user paid the price in downloading the jQuery library.

But I’ve noticed a welcome change with some of the bigger JavaScript frameworks. Whereas the initial messaging around frameworks like React touted the benefits of state management and the virtual DOM, I feel like that’s not as prevalent now. You’re much more likely to hear people—quite rightly—talk about the benefits of modularity and componentisation. If you combine that with the rise of Node—which means that JavaScript is no longer confined to the browser—then these frameworks can move from the front of the front end to the back of the front end.

We’ve certainly seen that at Clearleft. We’ve worked on multiple React projects, but in every case, the output was server-rendered. Developers get the benefit of working with a tool that helps them. Users don’t pay the price.

For me, this question of whether a framework will be used on the client side or the server side is crucial.

Let me tell you about a Clearleft project that sticks in my mind. We were working with a big international client on a product that was going to be rolled out to students and teachers in developing countries. This was right up my alley! We did plenty of research into network conditions and typical device usage. That then informed a tight performance budget. Every design decision—from web fonts to images—was informed by that performance budget. We were producing lean, mean markup, CSS, and JavaScript. But we weren’t the ones implementing the final site. That was being done by the client’s offshore software team, and they insisted on using React. “That’s okay”, I thought. “React can be used server-side so we can still output just what’s needed, right?” Alas, no. These developers did everything client side. When the final site launched, the log-in screen alone required megabytes of JavaScript just to render a form. It was, in my opinion, entirely unfit for purpose. It still pains me when I think about it.

That was a few years ago. I think that these days it has become a lot easier to make the decision to use a framework on the back of the front end. Like I said, that’s certainly been the case on recent Clearleft projects that involved React or Vue.

It surprises me, then, when I see the question of server rendering or client rendering treated almost like an implementation detail. It might be an implementation detail from a developer’s perspective, but it’s a key decision for the user experience. The performance cost of putting your entire tech stack into the browser can be enormous.

Alex Sanders from the development team at The Guardian published a post recently called Revisiting the rendering tier . In it, he describes how they’re moving to React. Now, if this were a move to client-rendered React, that would make a big impact on the user experience. The thing is, I couldn’t tell from the article whether React was going to be used in the browser or on the server. The article talks about “rendering”—which is something that browsers do—and “the DOM”—which is something that only exists in browsers.

So I asked. It turns out that this plan is very much about generating HTML and CSS on the server before sending it to the browser. Excellent!

With that question answered, I’m cool with whatever they choose to use. In this case, they’re choosing to use CSS-in-JS (although, to be pedantic, there’s no C anymore so technically it’s SS-in-JS). As long as the “JS” part is JavaScript on a server, then it makes no difference to the end user, and therefore no difference to me. Not my circus, not my monkeys. For users, the end result is the same whether styling is applied via a selector in an external stylesheet or, for example, via an inline style declaration (and in some situations, a server-rendered CSS-in-JS solution might be better for performance). And so, as a user-centred developer, this is something that I don’t need to care about.

Except…

I have misgivings. But just to be clear, these misgivings have nothing to do with users. My misgivings are entirely to do with another group of people: the people who make websites.

There’s a second-order effect. By making React—or even JavaScript in general—a requirement for styling something on a web page, the barrier to entry is raised.

At least, I think that the barrier to entry is raised. I completely acknowledge that this is a subjective judgement. In fact, the reason why a team might decide to make JavaScript a requirement for participation might well be because they believe it makes it easier for people to participate. Let me explain…

It wasn’t that long ago that devs coming from a Computer Science background were deriding CSS for its simplicity, complaining that “it’s broken” and turning their noses up at it. That rhetoric, thankfully, is waning. Nowadays they’re far more likely to acknowledge that CSS might be simple, but it isn’t easy. Concepts like the cascade and specificity are real head-scratchers, and any prior knowledge from imperative programming languages won’t help you in this declarative world—all your hard-won experience and know-how isn’t fungible. Instead, it seems as though all this cascading and specificity is butchering the modularity of your nicely isolated components.

It’s no surprise that programmers with this kind of background would treat CSS as damage and find ways to route around it. The many flavours of CSS-in-JS are testament to this. From a programmer’s point of view, this solution has made things easier. Best of all, as long as it’s being done on the server, there’s no penalty for end users. But now the price is paid in the diversity of your team. In order to participate, a Computer Science programming mindset is now pretty much a requirement. For someone coming from a more declarative background—with really good HTML and CSS skills—everything suddenly seems needlessly complex. And as Tantek observed:

Complexity reinforces privilege.

The result is a form of gatekeeping. I don’t think it’s intentional. I don’t think it’s malicious. It’s being done with the best of intentions, in pursuit of efficiency and productivity. But these code decisions are reflected in hiring practices that exclude people with different but equally valuable skills and perspectives.

Rachel describes HTML, CSS and our vanishing industry entry points:

If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.

I think there’s a comparison here with toxic masculinity. Toxic masculinity is obviously terrible for women, but it’s also really shitty for men in the way it stigmatises any male behaviour that doesn’t fit its worldview. Likewise, if the only people your team is interested in hiring are traditional programmers, then those programmers are going to resent having to spend their time dealing with semantic markup, accessibility, styling, and other disciplines that they never trained in. Heydon correctly identifies this as reluctant gatekeeping:

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

This hurts everyone. It’s bad for your team. It’s even worse for the wider development community.

Last year, I was asked “Is there a fear or professional challenge that keeps you up at night?” I responded:

My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.

I’ve described a number of dichotomies here:

  • Materials vs. tools,
  • Front of the front end vs. back of the front end,
  • User experience vs. developer experience,
  • Client-side rendering vs. server-side rendering,
  • Declarative languages vs. imperative languages.

But the split that worries the most is this:

  • The people who make the web vs. the people who are excluded from making the web.

This was originally posted on my own site.

]]>
Cotswolds design leaders retreat https://clearleft.com/posts/cotswolds-design-leaders-retreat Fri, 05 Apr 2019 14:53:00 +0000 https://clearleft.com/posts/cotswolds-design-leaders-retreat Earlier this month I had the pleasure of co-hosting a retreat for senior design leaders, at a beautiful country house hotel in the Cotswolds. The group was comprised of Heads and Directors of Design from a range of well known brands.

Most were from the UK and Europe, although a handful had flown the 10+ hours from North America to join us. They were here to spend the next few days exploring their career journeys, improving their leadership skills, and sharing tactics and advice with their industry peers.

It was clear from the off that these three days were much needed. During the opening circle, people talked candidly and honestly about the pressure they were under, feelings of isolation, and an overwhelming sense of imposter syndrome. They also talked about the guilt they were feeling being away from their families and teams. For many, this was their first chance to spend any meaningful time focussing on themselves and their careers, so they weren’t about the waste the opportunity.

We kicked things off with what I called a Leadership MOT. Essentially a series of exercises intended to understand the individual career paths these leaders had taken to get to where they were today, the highs and lows of that journey, and what this could tell them about their own personal needs. Next, we delved into the topic of leadership styles, plotting their approaches and preferences on a series of charts and graphs, before looking at which areas could be improved upon. We did a similar exercise looking at where they currently spent their effort, and how they’d like that to change over the coming months. We used this information to start filling in a personal design leadership canvas, the second half of which we’d come back to at the end of the three days.

Common challenges setting the agenda

Using Open Space Technology, we pulled out all the key issues the group was experiencing and turned these into a detailed agenda. Topics included the challenges of scaling a team, how to go about measuring and demonstrating the value of design, the best way to structure your design team, tips on building a robust design culture, and approaches for dealing with boards, peers from other departments and organisational silos. We also touched on more challenging subjects like managing difficult staff members, dealing with workplace stress, fears around personal and professional failure, and worries about what comes next.

If you’ve been to a Leading Design Conference before, or happen to be a member of our Slack community, most of these topics will be familiar to you. However, our attendees seemed to find it both helpful and cathartic being able to discuss these topics in a safe space amongst a group of peers. One said of the retreat “It was better than I could have ever imagined and will have a lasting effect both professionally and personally. It was introspective and revelational.”

7546

Interspersed between the discussions, we had arranged a number of social events. On one day we got to choose to do a bread making or cocktail making course - an opportunity to get creative and bond with our peers out of the context of our day-to-day roles. The next day we went on a group walk in the Cotswolds countryside. One of our goals for the retreat was to help create a bit of a support network for our attendees, so creating space for people to get to know each other and build lasting bonds was super important.

The merit of a personal leadership plan

While we experimented with a number of different sessions, one of the most popular activities was known–rather cheesily—as a success circle. This involved splitting our design leaders into groups of 4 and giving each person 20 minutes to request help or advice from the other members. Some people asked for help with their recruitment challenges, others delved into the thorny problem of team structure. Some people needed help with a difficult HR issue, while others sought advice on their next career move. The result of this session was that everybody came away with a stack of good ideas for how to solve a knotty challenge that had been bugging them for a while.

As the final afternoon approached, we switched back to our structured activities, asking everybody to fill in the second half of their Design Leadership Canvas. This acted as a helpful way to capture some of the challenges they’d surfaced, the advice they’d been given, and the decisions they’d made. We then set a second activity; to create a personal leadership plan. The plan was broken down into different sections; things you could do to improve your own personal leadership abilities, things you could do to help your team, and things you could to do affect the wider organisations. These sections were divided into three different time horizons; things you could do now, things you could do over the next couple of months, and things you would work towards in the future. We asked everybody to commit to at least three of these as immediate next steps.

design leaders at the leadership retreat

Time for introspection

Even though we were only away for three days it felt like we’d been away for a lot longer. We’d had some pretty intense conversations, and a few tears had been shed along the way. New friendships had formed and we’d bonded as a group. While it would have been too much to ask to solve every problem raised, a good amount of ground had been covered. People left feeling renewed, reinvigorated, and excited for what happens next.

One of the group summarised the experienced best when they said “it has been both a cathartic and delightfully exhausting introspective journey of which I hope to continue and practice with both myself and those of whom I work with.”

Our next leadership retreat takes place on the 16th -20th September, in the forests and mountains of North Norway—the perfect place to escape, recharge and work on your leadership challenges. We’ll be taking applications soon, so follow this link for more details.

]]>
Five insights from successful design leaders https://clearleft.com/posts/unlock-the-power-of-digital-design-and-deliver-better-work-faster Thu, 04 Apr 2019 08:00:00 +0000 https://clearleft.com/posts/unlock-the-power-of-digital-design-and-deliver-better-work-faster Last month Clearleft hosted a lively morning of discussion and debate featuring leading industry voices from Spotify, Virgin Atlantic, Google, Deliveroo, Bulb, and Pfizer.

In front of an audience of design leads, two panels explored some of the common challenges facing internal design teams; from understanding and responding faster to customer needs, implementing the right systems internally for driving innovation, and creating a culture of design thinking. These are five key takeaways from the sessions.

Panel discussion and audience

Customer expectations are evolving

Customers are expecting more from the services they use and pay for. Service designers have known this for decades, but the design you do needs to be not just on screen, but before, after and behind the screen experience. User research and testing is a fundamental part of achieving this, and should be a key input into decision making when it comes to the design of services and products. The way to achieve this - and it can be far easier said than done - is to expose your organisation to the experiences of your customers.

Design decisions should be tested, but you need to work out the impact you want to make in order to validate changes, even when those changes are informed by research. Metrics can be an extremely useful guide, but in and of themselves can reduce your impact. Designers can find themselves focussing on a metric as a way of acting more quickly, when greater value could be found by thinking critically and holistically rather than concentrating on local maxima - but those things take time, effort and some political will.

The case for design systems

We designers love design systems - they can give us a grander sense of purpose - while of course providing a incredibly valuable resource to our organisation. Done well, they can (and should) be a significant investment, so putting a case forward to those with the purse strings is vital. The number one reason to state is ‘efficiency’. This is the codeword to use to get buy-in. Good design systems will introduce efficiency into workflows across design and development within the organisation. They also provide consistency to your customer’s experience, and keep the quality at the required level.

A good design system is not just for code (AKA a pattern library). It is not just a design guide or a brand book, and it is not just repeatable UX patterns. It is all those things. But the best ones also integrate copywriting, especially microcopy, but also copy guidelines on a wider scale - even within single brand the tone of voice will need to change with the context.

Your design system is a tool that needs to be communicated and constantly nurtured. As soon as the system’s consumers feel it is out of date, a design system’s use - and all the advantages it provides - will drop off a cliff.

Link design operations to the organisation

Design ops are your way of doing design, including how design links in with the rest of organisation. One good way of getting started on design ops is by specifying your research operations first - getting a system and process for your research ops will inherently describe how research feeds into design and other parts of the organisation (such as sales and marketing). Getting that right will spark getting design ops right.

Ultimately design ops should comprise the CRD trifecta: Content, Research and Design, as opposed to just design. These are typically thought of as different things, and occasionally siloed into different departments, but they all part of the same picture.

Introducing design ops may naturally involve a change in culture. A key part of any successful culture change is about showing people what’s in it for them, and design ops will do that.

Silos get a bad rap

It’s certainly true that large silos, operating independently without interacting with other silos, frequently means the right hand doesn’t know what the left hand is doing. However can be beneficial to consciously create small silos for individuals teams (perhaps these are ‘vats’ rather than silos?) Small silos enable you concentrate expertise - members will get to know, trust and learn from each other.

It’s also true that design works well when it’s integrated throughout the organisation, with content, research, design and even development represented in all departments. If that’s how you’re organised it’s important that the different disciplines have ample opportunity to come together as a team in to share learning and feed into each other’s work (just as pair programming can bring additionsal quality, so two heads are better than one when it comes to design).

Designers should ask permission less

Once design has been elevated from mere styling to problem solving, designers can start to be more influential. By heading down a hypothesis-based approach (with measure and test) you can start to make more substantial improvements. With appropriate design leadership, this can mean venturing into seeking out opportunities based on research and insight. This is real, not pie-in-the-sky, innovation, but you need to innovate efficiently for true impact. When you ask for permission, executives will come in and start directing. Start showing results and you’ll get more leeway.

A closing thought from the panels was that we should all stop talking about how we design, and start talking about the impact of design on the goals of the organisation.


Many thanks to Alla Kholmatova (Former Head of Design & UX, Bulb), Simon Rohrbach (Director of Content, Research & Design, Deliveroo), Nicole Burrow (Design Director, Spotify), Jens Riegelsberger (Product Design and Research Director, Google), Martyn Reding (Head of Digital Experience, Virgin Atlantic) and Nuala Sheerin (UK Digital Transformation Lead, Pfizer) for their generous time.

Join us next time

We’ll be running a similar event in September. If you lead or manage design teams, and you’d like to be in the audience, please let us know and we’ll get back to you with details nearer the time.

]]>
Dev perception https://clearleft.com/posts/dev-perception Thu, 04 Apr 2019 07:30:00 +0000 https://clearleft.com/posts/dev-perception Chris put together a terrific round-up of posts recently called Simple & Boring. It links off to a number of great articles on the topic of complexity (and simplicity) in web development.

I had linked to quite a few of the articles myself already, but one I hadn’t seen was from David DeSandro who wrote New tech gets chatter:

You don’t hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.

I think that’s a very good point.

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The result is that what’s being written about is not a reflection of what’s being widely used. And that’s okay …as long as you know that’s the case. But I worry that theres’s a perception problem. Because of the outsize weighting of new and exciting technologies, a typical developer could feel that their skills are out of date and the technologies they’re using are passé …even if those technologies are actually in wide use.

I don’t know about you, but I constantly feel like I’m behind the curve because I’m not currently using TypeScript or GraphQL or React. Those are all interesting technologies, to be sure, but the time to pick any of them up is when they solve a specific problem I’m having. Learning a new technology just to mitigate a fear of missing out isn’t a scalable strategy. It’s reasonable to investigate a technology because you genuinely think it’s exciting; it’s quite another matter to feel like you must investigate a technology in order to survive. That way lies burn-out.

I find it very grounding to talk to Drew and Rachel about the people using their Perch CMS product. These are working developers, but they are far removed from the world of tools and frameworks forged in the startup world.

In a recent (excellent) article comparing the performance of Formula One websites, Jake made this observation at the end:

However, none of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.

I think this is very astute. I also think it’s completely understandable to form ideas about what matters to developers by looking at what’s being discussed on Twitter, what’s being starred on Github, what’s being spoken about at conferences, and what’s being written about on Ev’s blog. But it worries me when I see browser devrel teams focusing their efforts on what appears to be the needs of typical developers based on the amount of ink spilled and breath expelled.

I have a suspicion that there’s a silent majority of developers who are working with “boring” technologies on “boring” products in “boring” industries …you know, healthcare, government, education, and other facets of everyday life that any other industry would value more highly than Uber for dogs.

Trys wrote a great blog post called City life, where he compares his experience of doing CMS-driven agency work with his experience working at a startup in Shoreditch:

I was chatting to one of the team about my previous role. “I built two websites a month in WordPress”.

They laughed… “WordPress! Who uses that anymore?!”

Nearly a third of the web as it turns out - but maybe not on the Silicon Roundabout.

I’m not necessarily suggesting that there should be more articles and talks about older, more established technologies. Conferences in particular are supposed to give audiences a taste of what’s coming—they can be a great way of quickly finding out what’s exciting in the world of development. But we shouldn’t feel bad if those topics don’t match our day-to-day reality.

Ultimately what matters is building something—a website, a web app, whatever—that best serves end users. If that requires a new and exciting technology, that’s great. But if it requires an old and boring technology, that’s also great. What matters here is appropriateness.

When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.

This was originally posted on my own site.

]]>
A Professional Development Framework for Design https://clearleft.com/posts/design-professional-development-framework Tue, 02 Apr 2019 13:59:00 +0000 https://clearleft.com/posts/design-professional-development-framework Clearleft has been working on a professional development framework to share with the UX Design community. Here’s how, and why, we’ve arrived at something we hope is potentially valuable to you or your design team.

A work in progress

Mindful of the general sense that the design profession has historically been terrible at elaborating on career paths and progression, and inspired by some of our recent speakers at Leading Design and other conferences over the past few years, we’ve arrived at something we wanted to put out into the public domain.

For many years, Clearleft was exclusively a ‘seniors’ only club, where every practitioner had over 10 years experience in the bag, and this badge of honour formed an explicit part of our USP to clients. Over the past few years, as the Clearleft team has grown in size and capability, we’ve naturally hired more junior members of staff. With less seniority has come more appetite and need for mentoring, support and structure to aid and accelerate professional development.

However, on reflection and with the benefit of hindsight, even when we were a shape that was dominated by seasoned veterans, we were often guilty of throwing people in at the deep end, under the naive assumption that those who would swim could ultimately succeed at a company where autonomy and ownership are key characteristics needed to thrive. As an adhocracy, we prided ourselves on our lack of documented processes, ‘can-do’ attitude and ability to improvise under pressure. But we probably all suspected (and ultimately learnt) that regardless of seniority some semblance of structure was required to navigate cultural norms, manage expectations and accountabilities, deliver work productively, and anchor to a deeper purpose that made more explicit everyone’s contribution to the ‘Clearleftiverse’. This was true, even when any imposed structure needed to be experimental and adaptable to change, a core belief at Clearleft.

As we continue to be a relatively small and vociferously anti-hierarchical company, we appreciate the importance of giving all team members a clearer sense of where they can progress, or what they can specialise in. And not just within Clearleft today, but beyond that. Whilst there is an undoubtedly special bond that exists amongst all Clearleft alumni we’re not only comfortable with, but also active supporters of, enabling people to achieve their career dreams beyond their time at the company. Clearleft are just one part of a much bigger individual journey and a broader career path. Our passion for the digital community and our innate collective desire to make a meaningful contribution towards enabling design to thrive beyond our studio is something that continues to excite and motivate us. The success of ex-employees is one part of that which continues to make us all proud.

7508

Measuring what counts

The first challenge of any measurement framework is ensuring there is a focus on what is meaningful. As Drucker (may or may not have) said “What gets measured gets done”. Essentially as we were aware that a measurement framework would have an impact on behaviour, encouraging the right behaviours and discouraging the wrong ones would be critical.

Clearleft is a place where collective values and behaviours are intrinsic to our way of working and continued success as a design studio. And moreso than any other company I’ve worked for or with, IMHO. When deciding on what to measure, and indeed what to ignore, we therefore felt it important to find a way to wrap up an expression of our values into the framework.

Our values

  • Make it great over good
  • Don’t go it alone
  • Own it
  • Be fleet of foot
  • Speak your mind
  • Learn, share
  • Feed your curiosity
  • Work to live, love to work

A number of overarching themes within these values felt appropriate to measure as core skills, namely Communication, Problem solving, and Empathy.

Communication

Collaboration

Participate and facilitate collaborative group activities and/or workshops with colleagues or clients.

Presentation
Speak publicly or present to an audience articulately and persuasively.
Feedback
Open to seek, receive and give constructive feedback on your work or the work of others.

Problem solving

Initiative

Pro-actively own and be accountable for solving problems under your own initiative.

Methodology
Understand, apply and adapt your approach to problem solving.
Planning
Shape, coordinate and lead activities on project work with colleagues and clients.

Empathy skills

Relationships

Build strong relationships with colleagues and clients.

Support & Recognition
Support colleagues when they need help, and outwardly recognise the hard work of others.
Human-centricity
Advocate for a shared understanding of the needs and concerns of users, customers or audiences.

CPD Trello board
A section of the CPD Trello board

With these core skills serving as the foundations, we were then readily able to identify a suite of specialist skills across the themes of Strategy, Design and Leadership.

Strategy

Vision

Understand and articulate a clients mission, goals and desired outcomes, analyse their domain, and inform the vision and strategic direction of their products or services.

Insight

Diagnose project challenges and opportunities through evidence-based investigation and research.

Architecture

Map the architecture of the user experience.

Brand

Create, adapt or interpret brand guidelines and translate them into tangible artefacts and experiences.

Design

Exploration

Explore, iterate and improve on a broad range of ideas and potential design solutions.

Craft

Produce elegant, usable and responsive user interfaces and user experiences within known technology constraints.

Validation

Validate design concepts and solutions with end-users and/or business stakeholders to measure the impact of design.

Leadership

Direction

Lead or manage others to do better work and shape the strategic direction of the organisation.

Mentoring

Support the ongoing professional development and growth of colleagues.

Teaching

Coach and train others to learn new skills, techniques and ways of working.

7511

Each of the 19 skills are measured on a five point proficiency scale: Beginner, Novice, Intermediate, Expert, Master. The proficiency scale is intended to mirror the likely capability of a population along the lines of a bell curve distribution, with Beginner level typically reflecting a minimum benchmark for graduates or interns, and Mastery being the culmination of many years of hard work or serving as an aspirational, often career-defining, pinnacle of achievement. Most people will exist within the Novice to Expert proficiencies, which are intended to map neatly to obviously recognisable stages of any given career or skillset: from Junior through to Senior.

Where next?

The ambition is to have a universal framework that recognises and expresses the breadth of capability, both individually and across the company. Given the diffusion of skills amongst digital professionals, we’re acutely aware of the risks of putting individuals into explicitly narrow, pre-defined categories that can ultimately harm growth and professional development. As such we’re consciously trying not to design a system that stifles the unique attributes of any individual member.

With 19 measurable categories so far we believe there’s enough flexibility to avoid this. However we’re also mindful to introduce clarity around which roles and seniorities demand which subset of these skills and proficiency levels as essential prerequisites for promotion and salary compensation. Clearly this is a fine balancing act, but one we’re currently in the process of developing and refining further, along with a means by which to measure and evidence the criteria for progression in a more tangible way, that doesn’t inadvertently encourage gaming the system.

The Trello format is an unglamorous and occasionally cumbersome one, but for now is one well-suited to our tool agnosticism and the relative informality and conversational nature of how we manage performance and line management at Clearleft. Each individuals unique and private Professional Development board is fed from a root source of Skill & Proficiency definitions that exist on a shared board. This is something we’ll be looking to develop into more useful, easily communicable visualisations (e.g. Radar Charts), via a more robust and sustainable platform in the coming iterations of the framework. So watch this space.

Explore the framework

View the Professional Development Framework (v0.1)

]]>
What is design fiction and how can you use it? https://clearleft.com/posts/what-is-design-fiction-and-how-can-you-use-it Mon, 25 Mar 2019 14:39:00 +0000 https://clearleft.com/posts/what-is-design-fiction-and-how-can-you-use-it Andy Budd explores how science fiction impacts real designs.

Like me, I’m sure many of you grew up on a diet of science fiction; imagining future worlds through the work of authors like Isaac Asimov, Philip K. Dick and William Gibson. Science fiction, or speculative fiction as purists prefer to call it, has the power to transport us into the future to ask important and difficult questions about the world we’ve created, including where experimental design will take us in the world of tomorrow.

Science fiction novels are where many great tech innovations start life

Of course, the questions posed by science fiction aren’t really about the future; instead they’re extrapolations of present concerns. Think of the Snowden revelations, ad retargeting, or articles like ‘My Roomba tried to eat me’. By projecting concerns into the future, and taking them to their logical — and sometimes absurd — conclusion, authors can create safe spaces to discuss them.

This means that while science fiction can’t be used to predict the future, it can be used to explore current trends. Or as William Gibson famously said, “The future is already here, it’s just not very evenly distributed”. A good piece of speculative fiction can make something new and novel feel almost inevitable.

Can speculative fiction create the future?

While speculative fiction is often used to explore moral conundrums, doing so can have unexpected (and sometimes negative) consequences. For instance, the oft-cited Minority Report primed audiences to expect a future where adverts could literally follow you around.

So when a tech company suggested the City of London used its connected recycling bins to track the MAC addresses of passing phones and target pedestrians with adverts, you can bet that movie was front of the bin designer’s mind. What the director undoubtedly meant as a warning, ended up becoming reality.

Seeing something on screen can have a powerful effect, making a vague concept feel solid and real. This is probably why there were no gasps of awe and wonder when the Oculus Rift came out; we’ve seen examples of VR in countless (admittedly terrible) movies like The Lawnmower Man. It’s a piece of technology that felt like it was 30 years old by the time it arrived — the modern equivalent of the flying car or a personal jet-pack.

In the now-famous documentary How William Shatner Changed the World, the makers argued that the Star Trek communicator was the inspiration for the StarTAC mobile phone, while the first tablet to appear on screen wasn’t in an Apple or Microsoft corporate video, but in the hands of the Next Generation crew.

Today we have seven teams battling for a $10 million XPRIZE to create a working Tricorder. Star Trek seems to be getting less and less fictional every day.

A vintage Star Trek Tricorder by Joe Haupt

Similarly, when a few months ago we passed the date that Back to the Future II was set, a surprising number of predicted inventions — from self-lacing boots to hoverboards — had indeed come to pass.

It would appear that science fiction movies have the amazing ability to imagine future products, free of the typical constraints, then inspire others to work out the details. If only there was some way real product companies could harness that power?

Are we being primed?

I’d always assumed this foreshadowing of future technologies was accidental, until I saw a presentation from a Microsoft executive who practically admitted that they liked to seed early product concepts into movies, presumably to prime the audience for future tech arrivals.

Since then, I’ve been highly sensitive to any brands I see in sci-fi movies, as a way of speculating on what the big technology companies may be working on. I wonder if Google Glass would have been any more successful if we’d seen Ethan Hunt wearing a pair in Mission Impossible 4?

Like many large tech companies such as IBM and Apple, Microsoft has used the field of speculative fiction to explore possible futurescapes for a long time.

A recent example of this is the Microsoft Office Labs vision of 2019 videos, which show lots of smiling people representing a wide-reaching demographic standing in front of giant glowing interactive sheets of glass as they go about their school, office or home life.

Microsoft Office Labs imagines a future filled with glowing transparent screens

It’s easy to mock these glossy corporate videos, not least because of the impracticality of standing for long periods of time with your arms raised, interacting with giant transparent screens.

It’s clear many of these videos draw more upon the storytelling tropes of Hollywood than the skills of the designer. However, while these large companies may have popularised the field of ‘Design Fiction’, small interaction design studios have started using similar storytelling techniques in their daily client work.

Design fiction in the design studio

The first time I saw design fiction from a small studio, it was the work BERG did for the publishing company Bonnier. Its Mag+ video created a rich picture of what a digital magazine might feel like in the future, well before the first iPad was available.

With an approach known as ‘animatics’ — essentially animated storyboards — it used a simple green-screen technique to superimpose UI animations onto a mockup of a tablet, and breathe life into an inanimate product.

Using a video prototype meant the designers were able to do a much better job of communicating the experience than any set of wireframes or clickable prototype, with much less effort. Around the same time IDEO released a similar speculative design project, this time imagining the future of the book.

The team at BERG imagined the future of digital magazine before the iPad launch, using the power of ‘animatics’

The more I started to look at this form of speculative design, the more agencies and individuals I found exploring this technique — usually at the fringes of our industry in ad agencies or physical product companies. One thing they all seemed to have in common was a relationship with the Design Interactions course at the Royal College of Arts led by Dunne & Raby, the recognised leaders in the field of speculative design.

Of course, not everybody has a team of RCA graduates or the After Effects skills to create such realistic renderings, so at Clearleft we often mock up simpler effects using a combination of video, photography and animation in Keynote. It’s amazing how a few simple tricks like this can breathe life into an otherwise flat and lifeless prototype!

Explore your vision with comics

Animation is fast becoming a core skill in the interaction designer’s toolbox, but an even easier way to start exploring the field of design fiction is by using the same techniques you might find in the design of comics.

The team at Lowe’s innovation lab in the US made liberal use of comic book techniques in order to both explore and communicate the vision for its Holoroom concept. It went as far as hiring science fiction authors to help create realistic narratives.

The Airbnb team did a similar thing when it hired Pixar artists to help visualise the future of its customer experience. In the case of Lowe’s, this helped convince its management that an admittedly off-the-wall concept like a Holodeck (another Star Trek invention) could actually be made real.

Lowe’s used a comic book technique to imagine how its in-store helper robot might work

After pitching the comic book idea to his exec board, Kyle Nel from Lowe’s explained, “It was a gamble, but they loved it. They totally got it, and started building on the ideas in the comic.” For Airbnb, the visualisation gave it the insight it needed to double-down on its mobile strategy.

The good news is that you don’t need to hire sci-fi writers and Pixar artists to do this effectively. Kevin Cheng has been using comic books to communicate design intent long before it became fashionable, and his book See What I Mean is a great primer in the field.

Kevin Cheng is known for his comics that explain design thinking

Where does projection end and fiction begin?

We’ve been using prototypes and storyboards to communicate design intent for years, but how is ‘design fiction’ any different? When does something stop being a simple communication tool and start being a work of design fiction?

At the final dConstruct, Nick Foster explained how he broke design down into three categories; now, next, and future. You could argue that any piece of design work that falls outside of ‘now or next’ could be considered a work of design fiction.

As such, you may have found yourselves engaging in design fiction without even realising it; coming up with concepts for pitches or board presentations to give stakeholders a sense of what could be possible.

A few years ago a large, international high street bank asked us to imagine what online banking might look like in the future. We created a rich vision of how online banking could work across a range of devices, without worrying too much about the implementation details.

We knew that the concept would theoretically work, but we weren’t limited by the company’s existing technology stack. This freed us up to be more creative than we may have otherwise been, allowing us to leap over the now and next, and explore what the future of banking could hold.

More recently we created three vision videos for a well-known healthcare start-up, to help them articulate a range of possible futures. The goal wasn’t to deliver these products in 3–6 months time. The goal was to buy into their vision of where the company was heading in 3–6 years time. Off the back of these video prototypes, the company was able to raise millions in additional funding to start them out on the journey.

Near Future Laboratory is a specialist studio dedicated to developing the ideas of the future

Companies like the Near Future Laboratory take design fiction to its natural conclusion by blurring the line between art and design with its TBD catalogue.

Its fictionalised mail order catalogue contains 166 products and services that could potentially exist in the future, sparking both ideas and debate in equal measure. Near Future Lab’s collaborator The Extrapolation Factory also featured as part of the Designers of the Year exhibition at the London Design Museum.

The show was called 99c futures, and it explored the kind of products you might expect to see in a 99c store 20 years from now. Nick Forster calls this the ‘Future Mundane’ and believes the future will look a lot more normal than the sci-fi interface designers would have us believe.

Where to start

Designers might find it difficult to start selling design fiction as an activity to their clients right away. It could seem slightly wacky and off-beat at first, but you could take a leaf out of the Near Future Laboratory’s book and start crafting sci-fi futures for yourselves.

On a smaller scale, design fiction could be used to sharpen your skills at an internal hack-event, or to demonstrate design thinking as part of a possible recruitment task. At Clearleft I’ve used Matt Jones’ concept of Mujicomp to sharpen interns’ design skills.

We set them the task of designing a future product they could imagine being sold in the Japanese lifestyle retailer Muji by allowing them to hack, combine and re-imagine random items bought from the store. This simple MacGuffin provides the opportunity to unlock a wealth of creativity from designers who might be used to getting briefs that focus on ‘now’ or ‘next’.

The Near Future Laboratory created a real catalogue featuring 166 products from the future

Ultimately you could argue that all design is in some way a work of fiction — imagining something that doesn’t yet exist, and then communicating that vision to clients, customers and tech partners. However, by freeing designers up from practical concerns and allowing them time and space to speculate, they may just stumble onto their next big idea.

I believe design fiction is becoming an increasingly useful way to explore and communicate possible design futures. In order to create a better future, designers should be adding techniques for designing fiction to their toolbox today.

Originally published at www.creativebloq.com

]]>
Clearleft at CERN: celebrating 30 years of the Web https://clearleft.com/posts/clearleft-at-cern-celebrating-30-years-of-the-web Tue, 12 Mar 2019 11:00:00 +0000 https://clearleft.com/posts/clearleft-at-cern-celebrating-30-years-of-the-web CERN is celebrating the 30th anniversary of the Web today, and we’re proud to play a small part in the proceedings.

In March 1989, while working at CERN, Sir Tim Berners-Lee wrote his first proposal for an internet-based hypertext system to link and access information across different computers. His proposal became the World Wide Web. CERN is celebrating the 30th anniversary of this revolutionary invention with a special event today, and a series of other celebrations around the world.

The Web@30 event at CERN kicked off this morning with a fascinating panel discussion featuring Sir Tim Berners-Lee, Robert Cailliau and other Web pioneers sharing their views on the challenges and opportunities brought by the Web.

The live audience in Geneva comprised a select group of invitees, which we’re very proud to say included one of Clearleft’s cofounders, Jeremy Keith.

As part of a project to preserve some of the digital assets associated with the birth of the Web, Jeremy worked on a project in February to recreate the very first browser using current technology.

Previously, Jeremy also worked with CERN to organise a project to recreate the line-mode Web browser.

On being invited to CERN to join the celebrations, Jeremy wrote:

I’m so excited about this! I’m such a nerd for web history, it’s going to be like Christmas for me. The whole thing will be over by mid-morning. Then, [team member and fellow Brightonian] Remy and I will take an afternoon flight back to England …just in time for the evening event at London’s Science Museum.

]]>
Personas aren’t bad, and you’re not a bad designer if you use them https://clearleft.com/posts/personas-arent-bad-and-youre-not-a-bad-designer-if-you-use-them Mon, 11 Mar 2019 11:28:00 +0000 https://clearleft.com/posts/personas-arent-bad-and-youre-not-a-bad-designer-if-you-use-them With disturbing regularity, my Twitter stream seems to explode with posts demonising commonly used, yet seemingly harmless design tools.

These posts take great pains to document all the ways these tools have failed people in the past (while downplaying or ignoring a situation where they may have helped). Reading one of these threads you’d be forgiven for thinking these tools were actively harmful; some sort of public health nuisance this brave whistleblower was uncovering for the first time. Although they generally read more like the hysteria surrounding MMR vaccines to me, rather than any reasoned or measured debate. Instead, they’re full of personal anecdotes and half-truths, wrapped up in a thin veneer of scientific speak. One such debate I witnessed recently revolved around Personas.

Now the love/hate debate around personas is nothing new; in fact, it’s been rumbling on for some time. I personally have no great love for personas — that would be a little like loving a hammer or a chisel — but I have no great hate for them either. Personas are tools like any others, with their own relative strengths and weaknesses. So while every few months a new tool comes along claiming the previous one is now dead–in this case, Jobs to be Done — I’m much more interested in developing a rich toolbox of tools to draw upon, than engaging in a Battle Royal style deathmatch.

7402

Whenever the vilification of personas pops up its ugly head, it always goes something like this. “Personas are bad because they’re usually made up and therefore have no empirical backing”, “Personas are bad because they try and segment people and people are too unique to be segmented”, “Segmenting people is bad on principal and tantamount to discrimination”, “Personas are just a bunch of demographics and are therefore completely useless”, “Even if personas aren’t just a bunch of demographics, they are so badly used that we should just stop using them”.

While all these arguments annoy the hell out of me, the last one is the worst. The idea that because something is badly used, we should ditch it, is a blatant call for ignorance. Personally, I think if something is poorly or wrongly used, it’s our responsibility as experts, craftspeople and educators, to help people understand how a particular tool or technique works, rather than just throwing it–and the people using them — away like yesterdays garbage.

The misconceptions

So let me address some of these other common misconceptions about personas. The first and most pernicious is the idea that personas are just a bunch of — often made up — demographics featuring a persons age, gender, job, hair colour and little else. Now if this was the main content of personas I could understand the frustration. However, that’s just not the case.

I think this misconception comes from the world of marketing, where marketing personas generally are more focussed on demographics. That’s because marketing personas are generally used to try and capture, understand and categorise fairly broad ranges of preferences, and then understand where people holding those preferences spend their media browsing time, to better focus marketing spend. That’s all well and good for our friends over in marketing, but this sort of approach provides very little value when it comes to Interaction Design.

Instead, the use of demographics in personas is really there to add a bit of background detail, to make these pen portraits a little more realistic and memorable. This is because the true value of personas is a communication tool. As a way of synthesising a large amount of rich and complex data, generated through observations, interviews and surveys, into something that can travel around an organisation, and be consumed by people who weren’t necessarily involved in the conversation, or even have regulated access to customers. In these situations, it’s helpful if the persona is recognisable as a person, with a name, a background story and a set of attitudes and beliefs.

The question then is, if personas are a communication tool, what are they communicating? Well in general, the most useful part of any persona is the User Scenario; the area on the page that describe the sort of problems these users are facing, the behaviours they exhibit, and if you want to use that particular language, the jobs they want to get done.

Personas Vs Jobs To Be Done

I think this is one of the reasons why a lot of people claim that Job Stories and JTBD do away with the need for Personas, and I think in some situations that may be true. If you’re working in a fast moving engineering focussed start-up, servicing an incredibly wide demographic with a similar set of needs, and everybody in the company is very user-centric and in touch with those needs, you can probably do away with the touchy-feely fluff and focus on the core jobs; it’s just a lot of unnecessary distraction.

However, if you’re working in a traditional organisation serving a smaller range of fairly distinct behaviours, and you need to get your stakeholders out of the mindset that all customers think and behave the same, or worse, all customers think and behave the way the executive team do, personas may be of some use.

In some way, you could argue that personas and a useful step on the journey towards JTBD, but if you’re already there, they probably hold little additional value. Personally, I like the ability to reference John, Mary, Prisha, or Joaquin as a placeholder for a set of behaviours, rather than sifting through half a dozen job stories to explain what set of problems we’re solving for today. It’s efficient and travels well, even if there is a certain loss of fidelity.

Understand their limitations

The best personas generally are based on research data. You’ve surveyed hundreds or thousands of customers, you’ve interviewed dozens more, you’ve crunched the data and found certain patterns. Maybe you’re a travel company and have noticed that parents and children tend to travel short haul for a week or two, over the school holidays? Maybe the data has surfaced another cluster of younger travellers who prefer cheap city breaks, anytime other than the school holidays. Maybe you discovered a third cluster of people who travel for business and generally (but not always) fly business class, use the lounge and prefer to be back home for the weekend. This is a fairly trivial example, but I hope you get my drift.

Knowing this information may allow different product teams to tailor different experiences for different clusters of behaviour. This obviously beats treating every customer as the same, but isn’t as good as building up a rich and individual picture of behaviour by acquiring tonnes of data about the user and feeding it into a sophisticated CRM system. Many tech firms have these capabilities, which is another reason why they probably look down on personas and those who use them. However, you’d be amazed how few traditional businesses are able to significantly alter the merchandising offering, let alone the whole user journey, based on detailed data capture.

Now it’s worth pointing out that nobody is saying that you can’t be both a business traveller, a city breaker, and somebody who is looking for a fly-and-flop holiday with their family. Similarly, while the Personas may suggest that city breakers tend to be younger than people travelling with families, the actual data shows considerable overlap. In fact, you may find a cluster of retirees who take their grandchildren on holidays on their own and also like city breaks.

Fortunately, personas aren’t rigid definitions, but rather porous archetypes, so people will move between the two. Something this will happen over years. Other times it will happen in a single session. The key to any successful model is realising that it’s only a model, and therefore has limited scope. Sometimes it’s useful to think about light in terms of a wave, other times in terms or a partial. A good craftsperson understands the strengths and weaknesses of each model and uses it appropriately, while a poor craftsperson generally blames their tools.

Which comes on to my last point, the inevitable cargo-culting of any and all design tools. As a quick recap, cargo cults emerged amongst Pacific Islanders who tried adopting the object and rituals of western colonial power, without realising how things really worked. So they would build wood and reed airplanes, control towers and airport terminals, in the hope that American GIs would return with their cargo, without realising the intricacies of world politics, aviation, and international trade. They basically just copied what they saw other people doing in the hope it’d work. I see this all the time in our industry.

7404

It’s frustrating to see people behaving this way, and if it was just themselves they were hurting, I wouldn’t mind as much. However, when these things blow up, the outrage and misinformation tend to travel much further than a reasoned argument about the pros and cons of a certain tool or technique ever could. The resulting blast radius is huge, and a lot of innocent people often get caught up in the ensuing chaos. After all, if you were a relatively newly minted designer and somebody you trust with 20k followers on Medium, tells you that the thing you were taught as school is no longer useful, and all the smart people are now using something else, what are you going to do? Well, you’re probably going to ditch one tool in favour of the other and may go around telling others to do the same. This is how MMR scares and market panics start.

Foster critical thinking

Fortunately, we’re not dealing with anything nearly as serious here, and at least you’ll end up with a tool in your tool box. However as the saying goes, if all you have is a hammer, everything looks like a nail. Even if you spend most of your time hammering nails into blocks of wood for a living, I think it’s worth understanding what a screw looks like, and when to use it, rather than trying to hammer a screw into a block of wood once or twice and then claiming that screws are rubbish.

As a professional we all benefit from having a variety of tools at our disposal, instead of falling for the hype around silver bullets and one size fits all solutions. We’d also benefit from a bit more critical thinking in our industry. Arguments that go along the lines of “This thing hasn’t worked for me, so it cannot work for anybody” are super reactionary. They stifle intellectual curiosity, rather than encouraging people to expand their horizons and learn new things.

If you’ve discovered a new tool that works for you, by all means share what you think is great about it. Similarly, if you’ve found legitimate weaknesses in existing tools, please share that information so we can all learn and grow. However we live in incredibly polarising times, and debate through opposition is super easy. Just remember that it isn’t always necessary to raise one thing up by knocking something else down. That it’s a large world out there and we benefit more for variety and choice than a limited set of (largely manufactured) binary opinions.

Originally published at www.andybudd.com.

]]>
Handing back control https://clearleft.com/posts/handing-back-control Sat, 09 Mar 2019 21:22:00 +0000 https://clearleft.com/posts/handing-back-control An Event Apart Seattle was most excellent. This year, the AEA team are trying something different and making each event three days long. That’s a lot of mindblowing content!

What always fascinates me at events like these is the way that some themes seem to emerge, without any prior collusion between the speakers. This time, I felt that there was a strong thread of giving control directly to users:

Sarah and Margot both touched on this when talking about authenticity in brand messaging.

Margot described this in terms of vulnerability for the brand, but the kind of vulnerability that leads to trust.

Sarah talked about it in terms of respect—respecting the privacy of users, and respecting the way that they want to use your services. Call it compassion, call it empathy, or call it just good business sense, but providing these kind of controls in an interface is an excellent long-term strategy.

In Val’s animation talk, she did a deep dive into prefers-reduced-motion, a media query that deliberately hands control back to the user.

Even in a CSS-heavy talk like Jen’s, she took the time to explain why starting with meaningful markup is so important—it’s because you can’t control how the user will access your content. They may use tools like reader modes, or Pocket, or have web pages read aloud to them. The user has the final say, and rightly so.

In his CSS talk, Eric reminded us that a style sheet is a list of strong suggestions, not instructions.

Beth’s talk was probably the most explicit on the theme of returning control to users. She drew on examples from beyond the world of the web—from architecture, urban planning, and more—to show that the most successful systems are not imposed from the top down, but involve everyone, especially those most marginalised.

And even in my own talk on service workers, I raved about the design pattern of allowing users to save pages offline to read later. Instead of trying to guess what the user wants, give them the means to take control.

I was really encouraged to see this theme emerge. Mind you, when I look at the reality of most web products, it’s easy to get discouraged. Far from providing their users with controls over their own content, Instagram won’t even let their customers have a chronological feed. And Matt recently wrote about how both Twitter and Quora are heading further and further away from giving control to their users in his piece called Optimizing for outrage.

Still, I came away from An Event Apart Seattle with a renewed determination to do my part in giving people more control over the products and services we design and develop.

I spent the first two days of the conference trying to liveblog as much as I could. I find it really focuses my attention, although it’s also quite knackering. I didn’t do too badly; I managed to write cover eleven of the talks (out of the conference’s total of seventeen):

  1. Slow Design for an Anxious World by Jeffrey Zeldman
  2. Designing for Trust in an Uncertain World by Margot Bloomstein
  3. Designing for Personalities by Sarah Parmenter
  4. Generation Style by Eric Meyer
  5. Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
  6. Designing Intrinsic Layouts by Jen Simmons
  7. How to Think Like a Front-End Developer by Chris Coyier
  8. From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
  9. Move Fast and Don’t Break Things by Scott Jehl
  10. Mobile Planet by Luke Wroblewski
  11. Unsolved Problems by Beth Dean

This was originally posted on my own site.

]]>
Ghosting Candidates and Marathon Interviews: The Modern Recruitment Experience https://clearleft.com/posts/ghosting-candidates-and-marathon-interviews-the-modern-recruitment-experience Fri, 08 Mar 2019 09:30:00 +0000 https://clearleft.com/posts/ghosting-candidates-and-marathon-interviews-the-modern-recruitment-experience The digital sector is a talent led industry, and as much as I dislike the idea of the 10X developer, the difference a great hire can make to your business is huge. So I’m always amazed to hear about the shady, sloppy or downright atrocious recruitment practices we inflict on prospective candidates.

There was a time, not so long ago, when you could expect a polite acknowledgement of a job application, an explanation of the process and steps involved, and feedback if you weren’t successful. These days, ghosting candidates seems to be the norm. Hiring managers will claim that they are inundated with responses, so it’s just not possible to acknowledge every application, or inform people when they have been unsuccessful. They’ll also claim that overly aggressive legal requirements and an increasingly litigious environment means it’s no longer possible to provide candidates with feedback. Personally I don’t buy either of these arguments.

The volume of job applications has always been high, and if talking to hiring managers is anything to go by, the challenge they face is having too few qualified candidates rather than too many. While it used to be the case that applicants would apply for jobs via email, a large part of the process has now been automated. So the use of hiring tools with their set processes and templated responses, makes it harder to hide behind the excuse of volume.

I can sort of understand why, if you’ve received over a hundred applications for a specific role, it may not be practical to respond to everyone individually. However if somebody has taken the time to come in for an interview, I think you owe it to them to let them know why they failed to make the cut on this occasion. It’s not only polite—and generally the right thing to do as a human being—but failing to respond with the appropriate level of care and attention can have negative results.

The feedback I’ve heard about interview practices isn’t much better. Overly long, marathon interviews where the candidates are left feeling broken and exhausted by the end. No offers for tea or coffee, no breaks, just a revolving door of stakeholders peppering them with a seemingly random barrage of question. The lack of any coherent narrative makes these team interviews especially torturous. Randomly jumping from topic to topic with no logical segues, or being forced to answer almost identical questions posed by people who weren’t in the room to hear the answer you gave 20 minutes earlier. This unrelenting style of interviewing feels at best like a popularity contest and at worst like a form of interrogation, intended to break the will of an unsuspecting candidate.

7382

While some hiring managers may be impressed by one candidates ability to bullshit their way through a series of essentially random questions, it’s not an especially good indicator of future success.

This brings us nicely around to the issue of interview tasks. Now I’m actually in favour of tasks in certain situations, particularly when you’re hiring junior roles where people have talent, but lack a broad portfolio of work to show. It can also help level the playing field between agency designers with lots of exciting bands in there portfolio, and people who have been in-house for a long time working on a single product. However I also admit that in most cases, tasks are planned and delivered poorly, and can have a negative toll on the recipients.

One big problem with tasks is when they focus on a real problem the company is facing, and end up feeling little more than spec work. Here is a poorly stated problem, and the person who comes up with the answer we like the most wins. Another common problem are tasks that are set a week in advance, and given fairly tight deadlines. Some people will be able to fit this work around their existing work and family commitments, while others won’t. As such, I tend to prefer whiteboard tasks that take place during the interview process itself. Even then, these things are often dropped on candidates without any notice, a process which borders on abusive in my book.

As product people and technologists, we’re meant to have empathy and understand the human condition, yet little if any thought goes into the candidate experience. I guess this wouldn’t matter so much if you had hundreds of qualified candidates knocking down the door, but this often isn’t the case.

7384

Often more so. I’d argue we’re in a supply driven economy at the moment, where the best applicants will be choosing between 4 or 5 employers. In this situation, it’s your job to sell candidates on your company, and no glossy vision deck or lists of aspirational values will subvert a painful and broken interview process.

It’s also worth remembering that the digital industry is highly networked and super tight. If an applicant puts a tonne of work into an application, undertakes a remote task, and comes in for an interview, only to be ghosted by the company, you better believe they’re going to tell their friends. The old marketing adage goes that a happy customer will tell one of their friends, while an unhappy customer will tell ten. The same is true of the recruitment process.

I know a surprisingly large number of influential people who feel aggrieved towards certain, well known companies, because of the way they were treated during their recruitment process. They’ve told their friends over coffee, shared their experience in closed networks, and put dozens of people off of applying in the future. This isn’t where you want your brand to be.

Even if the experience wasn’t so bad as to be noteworthy, a lot of candidates will feel so bruised and battered by the experience they they’ll be put off from applying again. This is a huge loss as, just because the candidate wasn’t right for you now, doesn’t mean they won’t be right for you in the future.

7386

We explain what we liked about the candidates–and what they needed to work on–while making it clear that we really valued their time and would gladly consider them for future openings.

So rather than ghosting or hazing candidates, and leaving a bad taste in their mouths, we need to try and create the best recruitment experience possible. So even if the candidates aren’t successful, they leave thinking that you’d be a great company to work with, will recommend you to their friends, and jump at the chance we a future job opportunity comes along. This isn’t just a case of playing the long game—It’s the fair and decent thing to do.

This was originally posted on my blog

]]>
6 Tips for Successful Digital Transformation https://clearleft.com/posts/6-tips-for-a-successful-digital-transformation Tue, 05 Mar 2019 10:00:00 +0000 https://clearleft.com/posts/6-tips-for-a-successful-digital-transformation Digital transformation. It sounds so grandiose, doesn’t it? Like some sort of beautiful metamorphosis: an ugly caterpillar of old tech magically becoming a beautiful butterfly, resplendent in its new digital wings.

If only it were that magical. The reality is that digital transformation is damned hard.

Having worked with clients and companies of various size and shape over the years, I’ve noticed a few commonalities and trends that seem to pop up. If you’re in the midst of a transformation or about to embark on that metamorphosis of pain, these tips are for you.

1. It’s not about the tech stack

Most digital transformations are borne out of a need to re-platform. Companies suddenly recognise, invariably too late, that the technology platforms on which they spent a lot of money back in the day are now rapidly becoming obsolete. Inevitably the company focuses on the technology. But technology doesn’t make the world go round, people do.

The term ‘people’ here is purposefully broad. It refers to people on both sides of the coin: those who provide the new technology, and those who use that new technology.

In the end, digital transformation is just a fancy metaphor for embracing the shift in customer behaviours towards digital. If your customers can’t find, interact, buy or communicate with you digitally, you’re going out of business.

7324

Pro tip
If your product isn’t usable — by real people, — then it doesn’t matter if your new tech platform makes unicorns appear: it will lose money.


2. Get a visionary

Transformation projects without a North Star don’t work. To call it a success you’ll need someone who holds the vision in their heads and a resolve to get sh*t done.

This person (or persons) needs support to see out the business goal, without sacrificing user needs in the process. This mystical, overlapping Venn diagram is not easy. It needs significant corporate experience and political nous to come off. Choose your visionary wisely.

Pro tip
Find someone to lead the charge, and — get this — someone who actually gets digital. This sounds a lot easier than it is.

3. Stop being risk averse

Barrelling headfirst into a transformation strategy without the appetite and ability to take risks is like running a marathon without running shoes. You can do it, but why would you?

Risk is an inherent part of change. You need to try new things and be open to new methods and approaches. You need to know that not all changes will work, but some will. An inability to manage or accept risk will only result in half-baked, unfulfilled projects, because senior stakeholders are too reluctant to try something new.

Sometimes ‘up top’ are too afraid to let ‘digital’ do what they do best. Being prevented from providing digital solutions to a digital transformation leads to a compromised and impaired end product.

Pro tip
Avoidance of risk is borne of fear of the unknown. Stakeholders who act as blockers are often unsure of what digital can (or can not) do. Improving an appetite for risk can be as simple as providing better education as to what’s being done, why, and how the business will benefit.

4. Digital literacy is a must

Having a literacy in digital isn’t as simple as knowing what digital things are called. It’s having a deeper understanding of the methodologies, techniques and strategies needed when dealing with a digital product or service, and how these will work in a business context. Knowing what digital can and cannot do is critical to ensuring a successful transformation strategy across any business.

7338

A great example here is agile. You know, that word everyone uses in large orgs, but rarely do it right. I know agile was never meant to be prescriptive, but come on, having a standup once a day doesn’t mean you’re suddenly an agile organisation.

Agile needs time and oxygen. It needs to be both a top-down and bottom-up approach. Senior execs need to be as wedded to the idea as the practitioners at the coal face. Agile is a mindset, not a line item.

Pro tip
Ironically, language is the common denominator within digital transformation. Try to avoid terms like ‘sign-off’ which are steeped in historical contexts that no longer exist in the digital realm. Similarly, avoid the wonton use of acronyms and jargon when you can explain it using plain English.

5. Double-down on design maturity

Although hearing the phrase ‘design needs a seat at the table’ makes my skin crawl, the struggle is real. Design at most large organisations (those most likely to be undergoing seismic shifts towards digital) is tokenism at best.

Digital transformation is like an iceberg. 90% of the project is backend systems, re-platforming, evolving tech stacks and the plumbing. But the remaining 10% is what makes all that effort worth it. That 10% is where customers meet, interact with your company and buy from you. Be 100% sure it’ll include both digital and design.

If the senior stakeholders in your business still see design as making it look nice, you’ve got issues, my friend.

Design is about problem solving. It’s about reframing the problems and challenges faced by an organisation and alleviating them through design thinking methods. Though very few organisations today are 100% design mature, those that are striving towards it — alongside digital transformation — will reap the rewards.

Pro tip
Want to measure your design team’s outlook on design maturity? Share our Design Attitude 2019 survey.

6. Ship it

For all the hard work done by teams — often over years — in digital transformation projects, it doesn’t mean a thing if you can’t ship what you’ve created.

Large-scale transformation projects include countless moving parts. Stakeholders, technical requirements, Systems Integrators and many more.

That cacophony of voices and agendas can often counter-intuitively grind progress to a halt, rather than turbo-boost a transformation programme. The net result: your transformation has stopped focusing on shipping your best-in-class product. Instead, you’re just shipping your org chart.

According to Forrester Research, companies will never be truly transformed. It will be an ever-evolving dance of sensing and responding. Companies will continually adjust to changing online and digital behaviours.

Pro tip
Delivery or shipping in this context means continuous deployment. Bursts of activity, effectual releases and incremental growth. This is exactly what agile was made for; yet another reason to consider agile as a business-wide methodology rather than confined to development only.



Digital transformation is hard. It takes a long time. It costs a lot of money. Why waste that investment by taking shortcuts or approaching it the wrong way?

This has been a collection of my thoughts, gathered from working with clients during or at the start of a digital transformation. It’s as seen through a designer’s view. If you have a different viewpoint or would like to comment, find me at @aizlewood.

This post was originally published on Medium

]]>
What Women in tech means to us https://clearleft.com/posts/what-women-in-tech-means-to-us Mon, 04 Mar 2019 15:39:00 +0000 https://clearleft.com/posts/what-women-in-tech-means-to-us Women in Tech is a topic close to Clearleft’s heart all year round. We’re proud to buck the trend in terms of our workforce all the way up to our leadership team. But it’s finding the time to progress our industry beyond their project workload that we want to celebrate.

Gender equality in the workforce brings well known benefits - better communication, better support - but above all, being better at making amazing things happen. This month, as part of Spring Forward (a month-long celebration of the role of women in digital culture) two of our team are doing just that. They’re challenging the very nature of the industry by breaking down barriers.

Ladies that UX

Our UX Designer Hana runs the Brighton arm of Ladies that UX, a monthly meet up for ladies in the UX community to share, collaborate, and build their UX skills. This group is also open to women who are interested in UX and would like to learn in a friendly environment.

On March 6th she is hosting a talk focusing on the basics of UX. Inspired by Paul Adam talk at UX London “The end of naval gazing”. He notes that:

7360

She wants to bring together disciplines, she’s inviting people across UX, Dev, Sales, Project Managers and Marketing to tackle some hands-on UX tools and exercises, to boost shared understanding and deliver a better experience that puts the user at the centre of our universe.

Ladies that UX brighton

codebar

Cassie is one of our front-end developers, she also hosts codebar Brighton – a weekly meetup to encourage groups underrepresented in tech to get into coding. Aiming to increase diversity in the tech industry the group cleverly brings together coding newbies with developers from across Brighton to mentor them (over pizza).

Further breaking down barriers she has also just launched codebar talks, where you’re encouraged to leave behind the laptop and attend a friendly evening of progressive chats around digital.

A group gathered for codebar talks Brighton

There are a whole host of other events running throughout March in parallel with Women’s History Month. We’re proud to be one of sponsor the event sponsors and to host many of the inspiring sessions downstairs at 68 Middle Street.

These aren’t just events about and for women, they are changing the way we work as businesses for the better, and that’s what we’ll be celebrating this International Women’s Day.

]]>
Patterns Day 2: June 28th, 2019 https://clearleft.com/posts/patterns-day-2-june-28th-2019 Thu, 28 Feb 2019 14:05:00 +0000 https://clearleft.com/posts/patterns-day-2-june-28th-2019 Surprise! Patterns Day is back!

The first Patterns Day was in the Summer of 2017, and it was a glorious—a single day devoted to all things design system-y: pattern libraries, style guides, maintainability, reusability. It was a lot of fun, so let’s do it again!

Patterns Day 2 will take place on Friday, June 28th, in the beautiful Duke of York’s cinema in Brighton. If you went to the first Patterns Day, then you’ll know how luxuriously comfy it is in there.

Tickets are £175+VAT. The format will likely be the same as before: an action-packed day of eight talks, each 30 minutes long.

I’ve got an amazing line-up of speakers, but instead of telling you the whole line-up straightaway, I’m going to tease a little bit, and announce more speakers over the next few weeks and months. For now, here are the first three speakers, to give you an idea of the quality you can expect:

  • All the way from the US of A, it’s Una Kravets, who needs no introduction.
  • From the Government Digital Service, we’ve got Amy Hupe—she’ll have plenty to share about the GOV.UK design system.
  • And we’ve got Yaili, now a senior designer at Microsoft, where she works on the Azure DevOps design system.

Patterns Day will have something for everyone. We’ll be covering design, development, content strategy, product management, and accessibility. So you might want to make this a one-day outing for your whole team.

If you want to get a feel for what the day will be like, you can watch the videos of last year’s talks

Tickets for last year’s Patterns Day went fairly fast—the Duke of York’s doesn’t have a huge capacity—so don’t dilly-dally too long before grabbing your ticket!

This was originally posted on my own site.

]]>
Marty's mashup https://clearleft.com/posts/martys-mashup Mon, 25 Feb 2019 15:05:00 +0000 https://clearleft.com/posts/martys-mashup While the Interaction 19 event was a bit of a mixed bag overall, there were some standout speakers.

Marty Neumeier was unsurprisingly excellent. I’d seen him speak before, at UX London a few years back, so I knew he’d be good. He has a very reassuring, avuncular manner when he’s speaking. You know the way that there are some people you could just listen to all day? He’s one of those.

Marty’s talk at Interaction 19 was particularly interesting because it was about his new book. Now, why would that be of particular interest? Well, this new book—Scramble—is a business book, but it’s written in the style of a thriller. He wanted it to be like one of those airport books that people read as a guilty pleasure.

One rainy night in December, young CEO David Stone is inexplicably called back to the office. The company’s chairman tells him that the board members have reached the end of their patience. If David can’t produce a viable turnaround plan in five weeks, he’s out of a job. His only hope is to try something new. But what?

I love this idea!

I’ve talked before about borrowing narrative structures from literature and film and applying them to blog posts and conference talks—techniques like flashback, in media res, etc.—so I really like the idea of taking an entire genre and applying it to a technical topic.

The closest I’ve seen is the comic that Scott McCloud wrote for the release of Google Chrome back in 2008. But how about a romantic comedy about service workers? Or a detective novel about CSS grid?

I have a feeling I’ll be thinking about Marty Neumeier’s book next time I’m struggling to put a conference talk together.

In the meantime, if you want to learn from the master storyteller himself, Clearleft are running a two-day Brand Master Workshop with Marty on March 14th and 15th at The Barbican in London. Early bird tickets are on sale until this Thursday, so don’t dilly-dally if you were thinking about nabbing your spot.

This was originally published on my own site.

]]>
Take the Design Attitudes Survey 2019 https://clearleft.com/posts/take-the-design-attitudes-survey-2019 Mon, 25 Feb 2019 08:31:00 +0000 https://clearleft.com/posts/take-the-design-attitudes-survey-2019 We’re on a mission to find out the real state of design in organisations in 2019. To join in, take our Design Attitudes survey.

As a strategic design partner, Clearleft works closely with in-house design teams. We see first hand the huge opportunity that design can bring to an organisation, and the challenges presented in integrating design into the corporate ethos. We want to find out more about the current state of design in organisations, and present our findings in a report for all to read.

To that end, we have created a survey to take the temperature of how designers feel that design is used and understood within their organisations. If you have a design role of any sort, then please complete the survey as best you can.

Take the Design Attitudes survey now

The survey should take no more than 7 minutes. The results will be anonymised and completely non–attributable.

We’ll be publishing our findings next month.

]]>
Hack Week Vs Design Sprint? https://clearleft.com/posts/design-sprint Thu, 21 Feb 2019 16:38:00 +0000 https://clearleft.com/posts/design-sprint I was in Geneva last week for a week of collaboration on an exciting project.

Our hack week at CERN to reproduce the WorldWideWeb browser was five days long. That’s also the length of a design sprint. So …was what we did a design sprint?

I’m going to say no.

On the surface, our project has all the hallmarks of a design sprint. A group of people who don’t normally work together were thrown into an instense week of problem-solving and building, culminating in a tangible testable output. But when you look closer, the journey itself was quite different. A design sprint is typical broken into five phases, each one mapped on to a day of work:

  1. Understand and Map
  2. Demos and Sketch
  3. Decide and Storyboard
  4. Prototype
  5. Test
Gathered at CERN, hunched over laptops.
Building a reproduction of the world's first web browser.

There was certainly plenty of understanding, sketching, and prototyping involved in our hack week at CERN, but we knew going in what the output would be at the end of the week. That’s not the case with most design sprints: figuring out what you’re going to make is half the work. In our case, we knew what needed to be produced; we just had to figure out how. Our process looked more like this:

  1. Understand and Map
  2. Research and Sketch
  3. Build
  4. Build
  5. Build

Now you could say that it’s a kind of design sprint, but I think there’s value in reserving the term “design sprint” for the specific five-day process. As it is, there’s enough confusion between the term “sprint” in its agile sense and “design sprint”.

This was originally posted on my own site.

]]>
Interaction19 - the Clearleft best bits https://clearleft.com/posts/interaction19-the-clearleft-best-bits Fri, 15 Feb 2019 17:30:00 +0000 https://clearleft.com/posts/interaction19-the-clearleft-best-bits A group of us at Clearleft have just returned from the Interaction 19 conference (“Design in the wild”) in Seattle, Washington.

It’s safe to say that we all had an excellent time - it’s always great to get away as a team, soak up some great thinking, discover new places and revisit old haunts. But rather than try to speak for everyone I’ve gathered together our highlights from the conference below - enjoy.

The Clearleft IxDA team

Scott Kubie

I attended Scott Kubie’s talk - ‘Let’s learn how to get the writing done’. Writing can, in all truth be hard. As a designer writing at times might often be left till last. I hold my hands up, I am guilty of using Lorem ipsum in the past, whether it was out of laziness, lack of content or the excuse of ‘I’ll write it later’. Kubie proposes a new way of thinking about writing; Workflow.

7117

Scott's beautiful hand-drawn slides

He presented a practical approach that I will include in my design process moving forward. If you cannot wait for his talk check his post Writing for Designers.

Hana Stevenson


Tea Uglow

I enjoyed Tea Uglow’s talk “Normality is Stupid: Connecting the Dots Between Inclusion & Diversity and Selective Bias in Machine Learning”.

Tea started by showing us the bell shaped curve of a standard distribution graph, which is used to see where the average sits in a data set. She then shared very personal aspects about herself that easily fit outside of the ‘normal’ part of the curve and invited the audience to consider, that depending on the data used all of us could be excluded as well, “…if you think you are normal, one day you will be old”.

One of Tea's projects "Quick Draw!", which is publicly collecting the ‘world’s largest doodling data set.’

As we use data sets to define what reality is for AI and Machine learning, human biases are becoming a part of the technology we create. This has already shown to have potentially damaging effects when you look at unchecked data being used in AI systems trialed in job recruitment, healthcare and criminal justice sectors.

At the end, her message was simple but valuable. It is important to be critical about the data sets we use and collect and to think about how we represent the parts of ourselves that are not considered typical or normal.

Jerlyn Jareunpoon-Phillips


Nelly Ben Hayoun

I really enjoyed Dr. Nelly Ben Hayoun’s (the Willy Wonka of design) fast paced, energetic and furious talk about designing experiences. She drew upon a bunch of different themes and approaches to the projects she undertakes and reflected them in her delivery of the talk. Thinking Antonin Artuad’s Theatre of cruelty, the concept of “Hammering” and “total bombardment” should give you a good idea of the experience.

It was a great account of all of the good work she’s doing around the International Space Orchestra and the University of the Underground, a tuition fee-less university currently based under a London night club. Education meets Punk.

Tom Jansen


John Maeda

After two days of super varied talks and intense listening John Maeda’s talk on recovering and reinvention really stood out for me. He instantly grabbed the attention of the room with his witty and confident delivery.

He didn’t use slides throughout his talk and he didn’t need to - he prepared by simply sketching out a couple of illustrations that took us on a journey through his experience and stories about his life. He talked about ‘makers’ and ‘talkers’ which was his way of describing people who create and people who talk about creating. He described how he transitioned from a maker to a talker with anecdotes that resonated with everyone in the room.

Maker-maker, talker-maker, talker-talker - what are you?!

Amy Clark


Bryce Johnson & John Porter

There were a number of speakers over the three days that delivered thought provoking talks on the topics of ethics, empathy, inclusion and design; Liz Jackson, Jon Bell, John Lynch, Paul Cohen, Caroline Sinders to name a few.

However Friday’s Beyond Inclusion track included a talk by Bryce Johnson and John Porter – “Recognize Exclusion, Design for Inclusion” – that reframed the way I think about disability and made me question how we design and research for inclusion.

Two quotes from the talk really stood out.

The first defining disability not as a “personal health condition” but as “mismatched human interaction” has changed my perception of disability and the things we interact with.

7254

The second, “the things we create embody the assumptions we have” highlights our responsibility as design practitioners not to be shortsighted of the implications of the things we create.

I left this talk with two questions. How can our testing hypotheses be extended to prevent the creation of disability? Who are the best people to include in our research that will help us prove or disprove these hypotheses?

Benjamin Parry


The obligatory styled Twinkie shot

Jon Bell

Jon Bell provided an enthusiastic glimpse into the world of ethical design considerations from his time in Twitter’s (anti) abuse team. He gave two practical pieces of advice that feel applicable for many designers whatever the scale or nature of the design challenge.

Listen before launching in. His first piece of sage advice was learnt through painful experience. When starting in his new team he turned up as the rock star designer coming to save the day. He soon learnt that complex challenges are better tackled once you have some detailed domain knowledge and your team are a superb source for this wisdom.

Document your learnings. The second takeaway was refreshing to hear from a company famed for its pride in ship fast, fix later. Maybe, it is a sign of silicon valley growing from adolescence to more mature thinking. Jon’s point was on a long, ongoing and nuanced design challenge, like designing to reduce and remove abuse, there is high value for new team members and old hands alike in capturing key insights. Something as simple as a wiki will enable knowledge to be socialised, shared and transferred.

Chris How


Bill Buxton

On my ‘list of favourites’ amongst John Maeda, Nelly Ben Hayoun and Jayeon Kim is Bill Buxton. He did a great job of, almost casually, exposing his depth of experience of the design industry. His talk challenged a lot of preconceived technology milestones and exactly how smart we design today. We may have missed sufficient nuance when the term ‘ubiquitous computing’ was coined, when in fact we were striving for ubeity.

Andy Thornton

Bill Buxton receiving due applause

Jayeon Kim

As well as a collection of stand-out talks by Bill Buxton, Liz Jackson, and John Maeda, among others, I particularly valued Jayeon Kim’s series of daily mindfulness exercise sessions, which offered welcome moments of calm amid the buzz of Interaction 19.

7264

One of a notable handful of speakers whose presence temporarily transformed the atmosphere of the conference, Jayeon’s techniques immediately disarmed a room of ~1,000 people and had us all talking, laughing, and leaning on each other, before taking a few minutes to reverse our attention and be present in the only moment we can ever be: This one.

James Gilyead

Jayeon holding the room & keeping everyone in the moment

In summary

Getting away as a group to learn, experience new (and old) places continues to be something we really value at Clearleft, and documenting the good times for posterity seems fitting (and the perfect excuse to dust off my editing skills). Watch our best bits video (This was originally posted on my own site ).

]]>
Should you call yourself a UX Designer? https://clearleft.com/posts/should-you-call-yourself-a-ux-designer Thu, 31 Jan 2019 14:19:00 +0000 https://clearleft.com/posts/should-you-call-yourself-a-ux-designer There was a hot debate in the Clearleft studio recently: “Is UX Design dead?” Not the practice, mind you, but the job description.

I surveyed over 500 designers the end of last year.

  • 27% self identified as UX Designers.
  • 25.7% as Product Designers.
  • 9.8% as Experience Designers.

I haven’t had time to do the analysis yet, so don’t know if there are particular geographic, sector, or experience based trends. As this is the first one I’ve done I also don’t know if there are any time based trends. However I wouldn’t be surprised if we see the proportions flip in the next couple of years. But I think it’s safe to say (especially to all those pundits that claim UX isn’t a thing) that a good proportion of practitioners think it’s enough of a thing to identify themselves by …even if (as I suspect) we’ve reached peak UX.

It’s also worth noting that “Interaction Designer” and “Web Designer” were mid single figures, so I’d be happy to claim “UX Isn’t Dead” when UX Designer drops below Web Designer as a saleable job title.

What I’m really interested in understanding is whether there are any practical differences in skills and tool use between UX Designers and Product Designers, or whether the current dichotomy is primarily based on what’s fashionable.

Here’s my personal hot take (not backed up by data):

UX was popularised by agencies, so UX Designers generally require the skills to build new things over and over again.

Product Design comes out of start-ups, so Product Designers are required to optimise and extract value.

UX Designers often work alongside visual designers, so tend to focus more on the conceptual side of the equation. This means an increased focus on IA, formative research, and strategy.

Product Designers often work alongside Product Managers and Researchers, so tend to focus on visual design and interaction design over strategy (which is often set higher up).

That being said, the borders are super fuzzy. Some Product Designers will hop between early stage start-up and therefore share more DNA with UX Designers. Some UX Designers also do UI/Graphic design. So there’s usually more similarity than there is difference.

If you’re working for a tech company or a traditional company with a strong product management function and are mostly focussed on designing or iterating a single product, you’re probably a Product Designer.

If you’re working for an agency or an established company with a project focussed mindset, and are more focussed on the conceptual elements of design than the more traditional graphic elements, you’re probably a UX Designer.

And if you sit in the middle or bounce between the two, you can probably call yourself either.

Of course, at the end of the day you can call yourself whatever you want, and it will depend a lot on where you live, the type of companies you want to work for, how you want to be perceived, your career aspirations and a bunch of other things.

So the main point of this post isn’t to box you in, if you call yourself one thing but I’ve hinted that maybe you should call yourself something else. Instead it’s to help those people who don’t know what to call themselves.

Also worth nothing that I’m not claiming this is the only definition or even the right definition, just the model I’ve personally found most useful based on my own personal experience. Your mileage may vary.

So for all the people saying how confused they feel as a result of pundits saying things like “UX Designer isn’t a job” and “UX and Product Design are the same thing”… I hope this helps.

]]>
Building links https://clearleft.com/posts/building-links Tue, 15 Jan 2019 15:55:00 +0000 https://clearleft.com/posts/building-links Further reading for the upcoming talk I’m giving at the New Adventures conference.

In just over a week, I’ll be giving the opening talk at the New Adventures conference in Nottingham. I’ll be giving a workshop the day before too. There are still tickets available for both.

I have to admit, I’m kind of nervous about this talk. It’s been quite a while since the last New Adventures, but it’s always had quite the cachet. I think I went to most of them. It’s quite strange—and quite an honour—to shift gears from attendee to speaker.

The talk I’ll be giving is called Building. That might be a noun. That might be a verb. You decide:

Every new medium looks to what has come before for guidance. Web design has taken cues from centuries of typography and graphic design. Web development has borrowed metaphors and ideas from the world of architecture. Let’s take a tour of some of the most influential ideas from architecture that have crossed over into the web, from pattern languages to responsive design. Together we’ll uncover how to build resilient, performant, accessible and beautiful structures that work with the grain of the materials of the web.

This talk builds upon the talk I gave at last year’s An Event Apart called The Way Of The Web. It also reflects many of the ideas in Resilient Web Design. When I gave a run-through of the talk at Clearleft last week, Andy called it a “greatest hits.” For a while there, I was feeling guilty about retreading some ground I’ve covered in previous talks and writings. Then I realised it was pretty arrogant of me to think that anyone in the audience would be familiar with any of it.

Besides, I’ve got a whole new avenue of exploration in this talk. It’s about language and metaphor—how we talk about what we do on the web. I’ve just finished giving another run-through at the Clearleft studio and I’m feeling pretty good about it. That’s good, because I find that giving a talk in a small room to a handful of colleagues is way more stressful than giving a talk to hundreds of people at a conference.

Just as I put together links related to last year’s talk, I figured I’d provide some hyperlinks for anyone interested in the topics raised in this new talk…

Books

Articles

Audio

This was originally posted on my own site.

]]>
New Year. New Voice. https://clearleft.com/posts/new-year-new-voice Wed, 02 Jan 2019 12:47:00 +0000 https://clearleft.com/posts/new-year-new-voice New year’s resolutions. We all make them. We all break them. We even sometimes keep them.

I’ve struggled with public speaking for a long time. I know that a lot of people find it nerve wracking, but I’ve always had massive blocker with the entire endeavour. Maybe it’s partly due to my dyslexia, but truthfully it’s mostly due to me shying away from opportunities that place me in that kind of spotlight.

Fortunately at Clearleft I have been given keys to unlock the block. Firstly, I have the pleasure of working with experts in the field like Andy Budd, Richard Rutter and Jeremy Keith, who travel around the world, delivering and sharing insights from their respective work. Secondly, I attended a Rebel Lectures event that helped open my eyes to the commonalities of others who struggle with public speaking like me. And the event gave me tools to help me work towards speaking with confidence.

I have set myself a goal; a goal that I purposely cannot get out of. This March is the Spring Forward Festival in Brighton and I will be hosting a Ladies That UX event in the midst of it. Instead of the welcome and speaker introductions, I will present for 20 minutes. That’s 20 minutes of people listening to my voice.

But here’s the thing. I’m scared of my own voice. Sure, I can talk to friends, colleagues and clients. But when you’re standing in front of a room full of people, all there is is silence. Silence until you speak.

With this in mind, I signed up for another workshop. Andy Budd’s presentation workshop provided a variety of exercises aimed at getting to the root of the most important components of speaking. Tasked with presenting a five minute talk, I decided to present on the subject of teeth — if I ever get the pleasure to meet you, feel free to ask me about it.

Then we read a poem. It’s funny how reading the words in drastically different cadences got the point across quickly about delivery —monotone, dramatic; slow, fast; using the body, using the space in the room; loud, quiet; with accents, with pauses.

How often should you pause when presenting?

Do you find yourself trying to get your point out as soon as possible? Do you rush through it so fast that afterwards you question whether they understand you?

Take a second. Maybe two. Breathe.

Continue.

Let what you are saying to your audience sink in. I tend to think about what I am saying continuously but often forget this might be the first time someone has heard it. At first it felt embarrassing to do this, but as I looked around, everyone was in the same boat. Then it dawned on me. It is rare to find someone who wakes up and cannot wait to stand up in front of people and talk, unless they are an actor.

After this exercise Andy asked us to present our talk again. I could tell the difference. I focused on words, I paused. I changed my volume to emphasise my points. I actually enjoyed it. Most people felt the same. It’s obvious but it’s true: it just takes practise. With that in mind, I’ve been looking for opportunities to present, stepping away from my comfort zone and presenting to the whole Clearleft team. The next time I have to present, I will practise and focus on one thing at a time. Starting with my voice.

Thinking ahead to my talk in March, I have a stack of presenting books ready to read and other presenting opportunities. More importantly, I have a talk to write. I haven’t written a 20 minute talk before. There are many approaches, processes and things to consider. Content structure, the audience, the narrative, slide design, technical feasibility, time, presenting style…

Pause.

Breathe.

Continue.

]]>
Five tips for designing successful business tools https://clearleft.com/posts/five-tips-for-designing-successful-business-tools Wed, 19 Dec 2018 14:28:00 +0000 https://clearleft.com/posts/five-tips-for-designing-successful-business-tools Over the years I’ve worked on some complex tools in specific industries. I’ve worked on a weather graphics platform, an automotive data tool and more recently at Clearleft, an inventory management system for an investment bank. In my experience, these challenges come with their own set of demands.

So here’s are my 5 tips for running a programme successfully.

1. You’re never going to become an investment banker, so don’t try

One of the problems you immediately encounter when trying to design one of these tools is the proliferation of acronyms and jargon that creates a fog between you and the design challenge. Many of the users and stakeholders involved will have trained for years to acquire the domain knowledge needed to use these tools effectively.

The best way to approach this challenge is to nominate a subject matter expert up front. This expert literally works alongside the design team on a daily basis. They act as a domain knowledge interpreter and also provide a constant voice for the user, explaining how, when, and why tasks would be completed. As a designer, it’s important to appreciate that you don’t need to understand everything, you just need to understand enough to ensure that the solution you’re proposing is optimal for the task in hand.

2. Don’t cheat; work with real data

We all know the importance of designing with real content and data. Still, it remains tempting (and easier) to work with fake or sample data sets, particularly if you’re working in an unfamiliar domain and don’t truly understand the nature of the data that you’re dealing with. The sooner you work with real data, the sooner you’ll be able to get your head around the nature and scale of the problem, and the sooner you’ll be able to identify a suitable design solution.

3. Don’t let legacy problems define today’s solutions

Many business tools (and the workflows behind them) have been around for decades. Over the years, they’ve been tweaked and added to countless times. The user experience may have been severely compromised. When redesigning a service such as this, it’s important to silo these legacy issues and focus on uncovering the needs of today’s users without being constrained by current solutions.

4. Be prepared for user insights to drip feed into the process

People rely on these tools to complete their jobs. You’ll often find that behind every business tool is an army of some of the most passionate users you’ll ever come across. Opinionated, thoughtful and highly invested in the service’s improvement, they can be the most inspiring users to design alongside. The catch is that getting time with them can prove challenging, since you need to slot into their often hectic and fluctuating work schedules.

I’ve found that the best approach is to be flexible, offering short, often remote, one-to-one interviews at times suitable to them. In reality this means that user insights are drip-fed into the design process in a sporadic manner, in contrast toa B2C programme where you might arrange two days of user research part-way through the design process.

5. Be inspired by real users, rather than fictional ones

The creation of user personas has been a technique used in UX since the mid-90s, as a way to embed users in the design process. Each fictional persona represents a portion of people in the real world and enables designers to focus on a memorable cast of characters, instead of focusing on thousands of individuals. Personas essentially help designers design for a specific somebody, rather than a generic everybody.

In theory, personas are just as valid when designing B2B services as a B2C ones. In reality, however, they are often harder to create. Because every organisation varies greatly,it’s harder to make generalisations in a small sample size. Instead, I’ve tried profiling a handful of real organisations (both existing and potential customers) and the end users within them, and used these as a stimulus for design. While this might be less representative, it’s proven successful.Knowing that this is an actual customer creates more empathy among both designers and stakeholders.

]]>
Presenting Marty Neumeier https://clearleft.com/posts/presenting-marty-neumeier Thu, 13 Dec 2018 15:47:00 +0000 https://clearleft.com/posts/presenting-marty-neumeier Ahead of our hotly anticipated Brand Master workshop with Marty Neumeier in March 2019 we asked Andy Budd to give us some insight in why we’ve chosen to work with him on our Clearleft Presents series.

We first “discovered” Marty Neumeier through his excellent book, The Brand Gap. It’s in this book that Marty gives the best articulation I’ve ever seen of what a brand is and why we should care. Rather than a densely packed polemic, aimed only at designers, he draws on his immense storytelling skills to frame the gap between business strategy and design in a way everybody can understand. This book feels like you’re watching a well crafted TED talk, rather than a Medium article stretched to the length of a novel. It’s the perfect length for a short plane ride, and over the years we’ve given a copy of this book to more than one client to read over the weekend.

Marty Neumeier
Marty Neumeier

Following quickly on its heels was Zag, after the common marketing aphorism that “When everybody else Zigs, you Zag.” As you can imagine from the title, this book is all about creating stand-out products. It’s a must read for anybody involved in setting business or product strategy.  Another highly graphic (as in design, rather than gory or x-rated) book, Marty does a beautiful job of mixing conceptual images with prose. His style made him an easy choice for a speaker slot at one of our conferences. So in 2010 he came and spoke at our dConstruct conference on the topic of his new book, The Designful Company. As you can imagine, the message resonated with our design loving audience, and became a firm favourite at the event.

At Clearleft we have always seen ourselves as a “designful company”. In fact our mission is to unlock and elevate the value of design, and help all the companies we work with become more “designful”. The majority of our client sponsors feel the same way, which is why they bring us in. But they often struggle to articulate the value of design to more traditional business people. This is where the The Designful Company comes in. There’s just something in the way Marty articulates these challenges that seems to land perfectly with leadership teams. That’s why we’ll often buy copies of this book for our corporate partners. We love seeing the way this changes their relationship to, and understanding of, design.

Marty has written a ton of books since first speaking at dConstruct. Metaskills looks at the skills people will need in a world of increasing reliance on robots and AI—a concept close to my heart. The Rules of Genius builds on the skills outlined in Metaskills, while The Brand Flip does the same for The Brand Gap. If you’re a fan of authors like Seth Godin, I highly recommend you check out some of Marty’s books. You won’t be disappointed.

There’s a clear thread through all of Marty’s books; helping business leaders understand value of design, while positioning designers as the people to help unlock that power. This theme is most evident in his new book Scramble, and its associated workshop series.

Clearleft Presents - Marty Neumeier 14-15 March

This March we are thrilled to be collaborating with Marty on his Brand Master Workshop, a two-day immersive journey into the fundamental disciplines of brand building, held at one of our favourite iconic venues, the Barbican Centre in London. The workshop is designed to empower you with dozens of proven principles you can apply immediately to your business.

This workshop will launch Marty’s latest venture Level C — a new professional development company featuring a progressive 5-tier series of interactive branding workshops. Each tier explores core branding principles and challenges you to apply them to hypothetical and real-world business scenarios, thereby bridging the gap between strategy and design, and earning the formal title of Certified Brand Specialist.

So if you’re a designer, a design leader, a product manager or designful marketing exec looking for tactics and techniques to help harness the power of design in your organisation, this is the workshop for you.

Tickets and more information about the workshop can be found on our events page. Looking forward to seeing you there.

]]>
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:00 +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, download the Design Sprint Canvas or 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.

]]>
A short history of UX https://clearleft.com/posts/ux-short-history Tue, 23 Oct 2018 11:41:00 +0000 https://clearleft.com/posts/ux-short-history 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.

UX Today

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.

]]>