- Know where you stand before starting the journey
- Make sure everyone is speaking the same language
- Integrate the right tools into your team’s workflow
Wednesday, June 20th, 2018
Thursday, June 7th, 2018
Six steps to kickstart a web performance culture:
- Your dev environment is not your user’s environment
- It’s better to learn the fundamentals than the library
- Get the time to experiment and validate
- Educate your colleagues
- Share and celebrate success (and failure) stories
- Make performance part of your workflow
Tuesday, May 29th, 2018
Rachel gives a terrific explanation of CSS layout from first principles, starting with the default normal flow within writing systems, moving on to floats, then positioning—relative, absolute, fixed, and sticky—then flexbox, and finally grid (with a coda on alignment). This is a great primer to keep bookmarked; I think I’ll find myself returning to this more than once.
Saturday, May 19th, 2018
Agile itself provides us with the ability and opportunity to correct course, it allows us to steer, but it does nothing as such to help us steer correctly.
This observation about (some) agile projects is worryingly familiar:
I was suddenly seized by a horrible thought: what if this new-found agility was used, not teleologically to approach the right outcome over the course of a project, but simply to enshrine the right of middle management to change their minds, to provide a methodological license for arbitrary management? At least under a Waterfall regime they had to apologise when they departed from the plan. With Agile they are allowed, in principle, to make as many changes of direction as they like. But what if Agile was used merely as a license to justify keeping the team in the office night after night in a never-ending saga of rapidly accumulating requirements and dizzying changes of direction? And what if the talk of developer ‘agility’ was just a way of softening up developers for a life of methodologically sanctioned pliability? In short, what if Agile turned out to be worse than Waterfall?
Wednesday, April 11th, 2018
The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.
Saturday, March 24th, 2018
Interviews with designers, where they talk about their backgrounds, tools, workflows, and day-to-day experiences.
Saturday, February 17th, 2018
Maybe I’m weird, but it just feels good. It feels good to reclaim my turf. It feels good to have a spot to think out loud in public where people aren’t spitting and shitting all over the place.
Friday, February 9th, 2018
I still find the landscape of build tools completely overwhelming, but I found this distinction to be a useful way of categorising the different kinds of build tools:
Build tools do two things:
- Install things
- Do things
So bower, npm and yarn install things, whereas grunt, gulp, and webpack do things.
I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times.
I saw Frank give this talk at Mirror Conf last year and it resonated with me so so much. I’ve been looking forward to him publishing the transcript ever since. If you’re anything like me, this will read as though it’s coming from directly inside your head.
In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant. Experience, on the other hand, creates two distinct struggles: the first is to identify and unlearn what is no longer necessary (that’s work, too). The second is to remain open-minded, patient, and willing to engage with what’s new, even if it resembles a new take on something you decided against a long time ago.
I could just keep quoting the whole thing, because it’s all brilliant, but I’ll stop with one more bit about the increasing complexity of build processes and the decreasing availability of a simple view source:
Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. It’s the main thing that keeps the door open to independent, unmediated contributions to the network. If you can write markup, you don’t need Medium or Twitter or Instagram (though they’re nice to have). And the best way to help someone write markup is to make sure they can read markup.
Friday, February 2nd, 2018
A step-by-step account of trying to find a way to keep Sketch files in sync with the code in a pattern library. The solution came from HTML Sketchapp, a more agnostic spiritual successor to AirBnB’s React Sketchapp.
The contract was incredibly straightforward—as long as you generated HTML, you could import it into Sketch.
After some tinkering, Mark Dalgleish came up with a command line tool to automate the creation of Sketch libraries from HTML elements with
Thursday, January 25th, 2018
Design ops for design systems
Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.
Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.
Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.
There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.
Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:
- Styleguides, Pattern Libraries and Design Languages
- Design Systems vs. Pattern Libraries vs. Style Guides – What’s the Difference?
- Design Systems, Style Guides, and Pattern Libraries: Oh My!
- What’s the difference between style guides, pattern libraries, and design systems?
None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.
There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:
- Why Design Systems Fail
- Tips for in-house teams in a free market software culture
- Putting your design system into practice
Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.
I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:
Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.
Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.
Friday, January 12th, 2018
A well-written (and beautifully designed) article on the nature of the web, and what that means for those of us who build upon it. Matthias builds on the idea of material honestly and concludes that designing through prototypes—rather than making pictures of websites—results in a truer product.
A prototyping mindset means cultivating transparency and showing your work early to your team, to users – and to clients as well, which can spark excited conversations. A prototyping mindset also means valuing learning over fast results. And it means involving everyone from the beginning and closely working together as a team to dissolve the separation of linear workflows.
Thursday, November 16th, 2017
I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.
With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.
Wednesday, November 15th, 2017
I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”
By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.
Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.
Wednesday, November 8th, 2017
Great advice on writing sensible comments in your code.
Friday, October 27th, 2017
I am responsible for the code that goes into the machine, I do not want to shirk the responsibility of what comes out. Blind faith in tools to fix our problems is a risky choice. Maybe “risky” is the wrong word, but it certainly seems that we move the cost of our compromises to the client and we, speaking from personal experience, rarely inspect the results.
Monday, October 9th, 2017
All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.
Monday, October 2nd, 2017
Great advice from Jen on writing a book:
- Write emails to Ted. Try to find a little comfort zone inside the larger uncomfortable task.
- Don’t write a Book. Write Chapters. Break a large chore into smaller tasks and focus on one at a time.
- Trap yourself. Set up a workspace that limits distraction and procrastination.
- Don’t despair the zero-word-count days. Give yourself credit for behind-the-scenes work, even self-care.
- Get amnesia. Keep your eye on the prize.
Thursday, July 6th, 2017
Geek humour is no laughing matter, as Chris demonstrates here with his thorough dissection of that coffee mug.
CSS is weird. It’s unlike any other code, and that makes a lot of programmers uncomfortable. But used wisely it can, in fact, be awesome.
It’s not often I say this, but read the comments.
Monday, May 22nd, 2017
Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:
Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.
I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:
I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.
But we can all agree that the web is a wonderful thing:
Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.