Tags: process



The People Part of Design Systems – Related Works – Medium

I like the idea of “design bugs”:

Every two weeks or so, a group of designers would get together for a couple of hours to fix what we called “design bugs.” These were things that didn’t hinder functionality and wouldn’t have been filed as an engineering bug, but were places where we were using an old component, an existing one incorrectly, or a one-off alteration.

V6: Color | Rob Weychert

Go deep, deep down the rabbit hole of Rob’s brain in all its colourful glory. Seriously, this is simultaneously a great write-up of how he came up with his site’s lovely colour scheme(s), and it’s a terrific primer on colour theory and why the HSL value in CSS is so, so wonderful!

Design, system. — Ethan Marcotte

Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.

It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.

Complexity | CSS-Tricks

We talk about complexity, but it’s all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don’t just break.

Food for thought (process)

I love, love, love Sam’s comparison’s between cooking and front-end development.

We should embrace the tools we have access to and appreciate our ability to learn, but also realize that maybe a gas stove or a certain design tools might not be for everyone. We have to find what works for our cooking or designing/coding style or the project/meal at hand.

How I design with CSS grid

Always mark-up first. Regardless of what the kids are doing these days, I stick by my guns and start with mark-up first. A fun experiment (maybe not for you, but definitely for me) is to see how your site reads on Lynx. It does serve as a good gauge of whether the content on the site is structured properly or not.

I finally made sense of front end build tools. You can, too.

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:

  1. Install things
  2. Do things

So bower, npm and yarn install things, whereas grunt, gulp, and webpack do things.

I think.

Everything Easy is Hard Again – Frank Chimero

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.

Sketching in the Browser – SEEK blog – Medium

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 data-sketch- attributes.

People and tooling | susan jean robertson

I can’t help but also wonder if we’re using tools to solve problems they weren’t meant to solve, like how to communicate with or manage a team.

Saving Your Web Workflows with Prototyping · Matthias Ott – User Experience Designer

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.

Back to Bradshaw’s / Paul Robert Lloyd

I really like getting Paul’s insights into building his Bradshaw’s Guide project. Here he shares his process for typography, images and geolocation.

Build a culture for better design – insights from the Leading Design Conference 2017

A great round-up of Leading Design—one of the best events I attended in 2017.

The User Experience of Design Systems

When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve.

In this talk transcript, Rune Madsen enumerates the reasons for his informed scepticism towards design systems:

  1. The first concern, which is also the main argument of this talk, is that humans – especially designers and engineers – are obsessed with creating systems of order. This is not really driven by a demand from users, so they often tend to benefit the designer, not the user.
  2. My second concern relates to what I believe design systems is doing to our digital experience. We’ve always had trends in graphic design (Swiss design, Flat UI, etc), but I’m getting increasingly concerned that this broad adoption of design systems is creating a design monoculture that really narrows the idea of what digital products can be.
  3. My third concern is that with all this talk about design systems, there’s very little talk about the real problem in digital design, which is processes and tools. Designers love making design manuals, but any design system will completely and utterly fail if it doesn’t help people in the organization produce faster and better products.

Tips for in-house teams in a free market software culture

A great in-depth report from Alice on creating, running, and most importantly, selling an in-house design system. This makes a great companion piece to her Patterns Day talk.

Where internal teams seem to go wrong is not appreciating that the thing they’re building is still a product and so it needs to compete with other products on the market.

Another Lens - News Deeply x Airbnb.Design

Little interventions for designers in the form of questions designed to challenge assumptions. Kind of like Brian Eno’s oblique strategies.

The Burden of Precision | Daniel T. Eden, Designer

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.

Relative Requirements – CSS Wizardry

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.

Inside Design: Clearleft

A profile of Clearleft from the nice people at InVision.

Although there is this:

The Art of Comments | CSS-Tricks

Great advice on writing sensible comments in your code.