Tags: change

3

sparkline

Choosing tools for scaling design

Tools and processes are intertwined. A company or a department or an individual has a way of doing things—that’s the process. They also have software to carry out the process—those are the tools.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Process and culture

Cameron has a bone to pick. Why, oh, why, he wonders, are we so quick to create processes when what we really need is a good strong culture?

Strong culture = less process

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

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

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

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

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

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

Mark writes:

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

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

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

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

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

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

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

Even so, he acknowledges Cameron’s concern:

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

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

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

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

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

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

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

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

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

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

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

Where to start?

A lot of the talks at this year’s Chrome Dev Summit were about progressive web apps. This makes me happy. But I think the focus is perhaps a bit too much on the “app” part on not enough on “progressive”.

What I mean is that there’s an inevitable tendency to focus on technologies—Service Workers, HTTPS, manifest files—and not so much on the approach. That’s understandable. The technologies are concrete, demonstrable things, whereas approaches, mindsets, and processes are far more nebulous in comparison.

Still, I think that the most important facet of building a robust, resilient website is how you approach building it rather than what you build it with.

Many of the progressive app demos use server-side and client-side rendering, which is great …but that aspect tends to get glossed over:

Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering, but this is only one of many options.

I think it’s vital to not think in terms of older browsers “falling back” but to think in terms of newer browsers getting a turbo-boost. That may sound like a nit-picky semantic subtlety, but it’s actually a radical difference in mindset.

Many of the arguments I’ve heard against progressive enhancement—like Tom’s presentation at Responsive Field Day—talk about the burdensome overhead of having to bolt on functionality for older or less-capable browsers (even Jake has done this). But the whole point of progressive enhancement is that you start with the simplest possible functionality for the greatest number of users. If anything gets bolted on, it’s the more advanced functionality for the newer or more capable browsers.

So if your conception of progressive enhancement is that it’s an added extra, I think you really need to turn that thinking around. And that’s hard. It’s hard because you need to rewire some well-engrained pathways.

There is some precedence for this though. It was really, really hard to convince people to stop using tables for layout and starting using CSS instead. That was a tall order—completely change the way you approach building on the web. But eventually we got there.

When Ethan came out with Responsive Web Design, it was an equally difficult pill to swallow, not because of the technologies involved—media queries, percentages, etc.—but because of the change in thinking that was required. But eventually we got there.

These kinds of fundamental changes are inevitably painful …at first. After years of building websites using tables for layout, creating your first CSS-based layout was demoralisingly difficult. But the second time was a bit easier. And the third time, easier still. Until eventually it just became normal.

Likewise with responsive design. After years of building fixed-width websites, trying to build in a fluid, flexible way was frustratingly hard. But the second time wasn’t quite as hard. And the third time …well, eventually it just became normal.

So if you’re used to thinking of the all-singing, all-dancing version of your site as the starting point, it’s going to be really, really hard to instead start by building the most basic, accessible version first and then work up to the all-singing, all-dancing version …at first. But eventually it will just become normal.

For now, though, it’s going to take work.

The recent redesign of Google+ is true case study in building a performant, responsive, progressive site:

With server-side rendering we make sure that the user can begin reading as soon as the HTML is loaded, and no JavaScript needs to run in order to update the contents of the page. Once the page is loaded and the user clicks on a link, we do not want to perform a full round-trip to render everything again. This is where client-side rendering becomes important — we just need to fetch the data and the templates, and render the new page on the client. This involves lots of tradeoffs; so we used a framework that makes server-side and client-side rendering easy without the downside of having to implement everything twice — on the server and on the client.

This took work. Had they chosen to rely on client-side rendering alone, they could have built something quicker. But I think it was worth laying that solid foundation. And the next time they need to build something this way, it’s going to be less work. Eventually it just becomes normal.

But it all starts with thinking of the server-side rendering as the default. Server-side rendering is not a fallback; client-side rendering is an enhancement.

That’s exactly the kind of mindset that enables Jack Franklin to build robust, resilient websites:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. Server-side rendering was the default; client-side rendering was added later.

The key to building modern, resilient, progressive sites doesn’t lie in browser technologies or frameworks; it lies in how we think about the task at hand; how we approach building from the ground up rather than the top down. Changing the way we fundamentally think about building for the web is inevitably going to be challenging …at first. But it will also be immensely rewarding.