Link tags: process

366

sparkline

Open sourcing the Product Planning Prompt Pack

This is very generous of Anna! She has a deck of cards with questions she asks in product planning meetings. You can download the pack for free.

How Florence Nightingale Changed Data Visualization Forever - Scientific American

The design process in action in Victorian England:

Recognizing that few people actually read statistical tables, Nightingale and her team designed graphics to attract attention and engage readers in ways that other media could not. Their diagram designs evolved over two batches of publications, giving them opportunities to react to the efforts of other parties also jockeying for influence. These competitors buried stuffy graphic analysis inside thick books. In contrast, Nightingale packaged her charts in attractive slim folios, integrating diagrams with witty prose. Her charts were accessible and punchy. Instead of building complex arguments that required heavy work from the audience, she focused her narrative lens on specific claims. It was more than data visualization—it was data storytelling.

Procrastination and low motivation make productivity difficult. Body-doubling might help - ABC Everyday

I’ve done this and I can attest that it works, but I never knew it had a name.

Body-doubling is simply having another person in the room with you, working quietly alongside you. They can work on something similar, or something completely different.

The Grug Brained Developer

If only all thinkpieces on complexity in software development were written in such an entertaining style! (Although, admittedly, that would get very old very fast.)

A layman’s guide to thinking like the self-aware smol brained

The Demo → Demo Loop - daverupert.com

I’m 100% convinced that working demo-to-demo is the secret formula to making successful creative products.

The collapse of complex software | Read the Tea Leaves

Even when each new layer of complexity starts to bring zero or even negative returns on investment, people continue trying to do what worked in the past. At some point, the morass they’ve built becomes so dysfunctional and unwieldy that the only solution is collapse: i.e., a rapid decrease in complexity, usually by abolishing the old system and starting from scratch.

Reflections on Design Systems and Boundaries - Jim Nielsen’s Blog

Jim shares his thoughts on my recent post about declarative design systems. He picks up on the way I described a declarative design systems as “a predefined set of boundary conditions that can be used to generate components”:

I like this definition of a design system: a set of boundaries. It’s about saying “don’t go there” rather than “you can only go here”. This embraces the idea of constraints as the mother of invention: it opens the door to creativity while keeping things bounded.

The Case for Design Engineers - Jim Nielsen’s Blog

This is really interesting. I hadn’t thought too much about the connection between design engineering and declarative design before now, but Jim’s post makes the overlap very clear indeed.

On Design Thinking

Design Thinking didn’t change business at all, rather it changed Design into business, adopting its language, priorities and techniques. It sold out Design in an attempt to impress those in power, and in so doing lost its heart.

Changing with the times · Chris Burnell

I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.

You Don’t Need A UI Framework — Smashing Magazine

We noticed a trend: students who pick a UI framework like Bootstrap or Material UI get off the ground quickly and make rapid progress in the first few days. But as time goes on, they get bogged down. The daylight grows between what they need, and what the component library provides. And they wind up spending so much time trying to bend the components into the right shape.

I remember one student spent a whole afternoon trying to modify the masthead from a CSS framework to support their navigation. In the end, they decided to scrap the third-party component, and they built an alternative themselves in 10 minutes.

This tracks with my experience. These kinds of frameworks don’t save time; they defer it.

The one situation where that works well, as Josh also points out, is prototyping.

If the goal is to quickly get something up and running, and you don’t need the UI to be 100% professional, I do think it can be a bit of a time-saver to quickly drop in a bunch of third-party components.

Blogging and the heat death of the universe • Robin Rendle

A cautionary tale on why you should keep your dependencies to a minimum and simplify your build process (if you even need one):

If it’s not link rot that gets you then it’s this heat death of the universe problem with entropy setting in slowly over time. And the only way to really defend against it is to build things progressively, to make sure that you’re not tied to one dependency or another. That complex build process? That’s a dependency. Your third party link to some third party font service that depends on their servers running forever? Another dependency.

Agile and the Long Crisis of Software

Time and again, organizations have sought to contain software’s most troublesome tendencies—its habit of sprawling beyond timelines and measurable goals—by introducing new management styles. And for a time, it looked as though companies had found in Agile the solution to keeping developers happily on task while also working at a feverish pace. Recently, though, some signs are emerging that Agile’s power may be fading. A new moment of reckoning is in the making, one that may end up knocking Agile off its perch.

Notes, links, etc | 28 March - 2 April weeknotes

There’s a difference between creativity and production. I knit things but it’s not a creative process for me, it’s a physical one. I’m not interested in doing ‘something new’ with knitting (I don’t even call myself a ‘knitter’ to be honest. I don’t really think I’ve earned it). I haven’t learned the methods of construction. I’ve never tried to make something new out of the stitches I’ve learned. It’s not why I knit. I knit to relax. There’s joy in following a pattern and knowing that a more accomplished, knowledgeable person has done the hard creative work for me, and if I just do what they say, thing’s will probably work out fine. And I love the things I make. I put care into the production process - I take care to get the stitches neat, if I can. But when people look at the things I make and say “you’re so creative” - it’s just not true. In that context I can only ever say “no, I followed a pattern - it’s a good pattern. Do you want the link?”

The difference between correct-ness and useful-ness in a design system • Robin Rendle

I remember Lara telling me a great quote from the Clarity conference a few years back: “A design system needs to be correct before it’s complete.” In other words, it’s better to have one realistic component that’s actually in production than to have a pattern library full of beautiful but unimplemented components. I feel like Robin is getting at much the same point here, but he frames it in terms of correctness and usefulness:

If we want to be correct, okay, let’s have components of everything and an enormous Figma library of stuff we need to maintain. But if we want to be useful to designers who want to get an understanding of the system, let’s be brief.

Chesterton’s Fence: A Lesson in Second Order Thinking - Farnam Street

Unless we know why someone made a decision, we can’t safely change it or conclude that they were wrong.

Modern CSS in a Nutshell - Cloud Four

I like this high-level view of the state of CSS today. There are two main takeaways:

  1. Custom properties, flexbox, and grid are game-changers.
  2. Pre- and post-processers are becoming less and less necessary.

This is exactly the direction we should be going in! More and more power from the native web technologies (while still remaining learnable), with less and less reliance on tooling. For CSS, the tools have been like polyfills that we can now start to remove.

Alas, while the same should be true of JavaScript (there’s so much you can do in native JavaScript now), people seem to have tied their entire identities to the tooling they use.

They could learn a thing or two from the trajectory of CSS: treat your frameworks as cattle, not pets.

Why you should prioritise quality over speed in design systems by Amy Hupe, content designer.

Speed for the sake of speed means nothing. If our design systems don’t ultimately lead to better quality experiences, we’re doing it wrong.

When we rush to release one-size-fits-all components, without doing the work to understand different contexts before curating and consolidating solutions, we sacrifice quality at the hands of speed.

The irony? In the long run, this will slow us down. We end up having to undo the work we’ve done to fix the problems we’ve created.

Ultimately, when we prioritise speed over quality, we end up with neither.

The Gap

Design engineering explained, with diagrams.

I have never worked anywhere where there wasn’t someone trying to close the gap. This role is often filled in accidentally, and companies are totally unaware of the need. Recruiters have never heard of it, and IT consultancies don’t have the capability in their roster. We now name the role “Design Engineer” because the gap is widening, and the role has become too complex to not exist.