Tags: process

419

sparkline

Wednesday, August 3rd, 2022

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.

Wednesday, July 27th, 2022

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.

Thursday, July 14th, 2022

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.

Wednesday, July 13th, 2022

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

Thursday, June 23rd, 2022

The Demo → Demo Loop - daverupert.com

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

Sunday, June 12th, 2022

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.

Monday, June 6th, 2022

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.

Tuesday, May 31st, 2022

Declarative design systems

When I wrote about the idea of declarative design it really resonated with a lot of people.

I think that there’s a general feeling of frustration with the imperative approach to designing and developing—attempting to specify everything exactly up front. It just doesn’t scale. As Jason put it, the traditional web design process is fundamentally broken:

This is the worst of all worlds—a waterfall process creating dozens of artifacts, none of which accurately capture how the design will look and behave in the browser.

In theory, design systems could help overcome this problem; spend a lot of time up front getting a component to be correct and then it can be deployed quickly in all sorts of situations. But the word “correct” is doing a lot of work there.

If you’re approaching a design system with an imperative mindset then “correct” means “exact.” With this approach, precision is seen as valuable: precise spacing, precise numbers, precise pixels.

But if you’re approaching a design system with a declarative mindset, then “correct” means “resilient.” With this approach, flexibility is seen as valuable: flexible spacing, flexible ranges, flexible outputs.

These are two fundamentally different design approaches and yet the results of both would be described as a design system. The term “design system” is tricky enough to define as it is. This is one more layer of potential misunderstanding: one person says “design system” and means a collection of very precise, controlled, and exact components; another person says “design system” and means a predefined set of boundary conditions that can be used to generate components.

Personally, I think the word “system” is the important part of a design system. But all too often design systems are really collections rather than systems: a collection of pre-generated components rather than a system for generating components.

The systematic approach is at the heart of declarative design; setting up the rules and ratios in advance but leaving the detail of the final implementation to the browser at runtime.

Let me give an example of what I think is a declarative approach to a component. I’ll use the “hello world” of design system components—the humble button.

Two years ago I wrote about programming CSS to perform Sass colour functions. I described how CSS features like custom properties and calc() can be used to recreate mixins like darken() and lighten().

I showed some CSS for declaring the different colour elements of a button using hue, saturation and lightness encoded as custom properties. Here’s a CodePen with some examples of different buttons.

See the Pen Button colours by Jeremy Keith (@adactio) on CodePen.

If these buttons were in an imperative design system, then the output would be the important part. The design system would supply the code needed to make those buttons exactly. If you need a different button, it would have to be added to the design system as a variation.

But in a declarative design system, the output isn’t as important as the underlying ruleset. In this case, there are rules like:

For the hover state of a button, the lightness of its background colour should dip by 5%.

That ends up encoded in CSS like this:

button:hover {
    background-color: hsl(
        var(--button-colour-hue),
        var(--button-colour-saturation),
        calc(var(--button-colour-lightness) - 5%)
    );
}

In this kind of design system you can look at some examples to see the results of this rule in action. But those outputs are illustrative. They’re not the final word. If you don’t see the exact button you want, that’s okay; you’ve got the information you need to generate what you need and still stay within the pre-defined rules about, say, the hover state of buttons.

This seems like a more scalable approach to me. It also seems more empowering.

One of the hardest parts of embedding a design system within an organisation is getting people to adopt it. In my experience, nobody likes adopting something that’s being delivered from on-high as a pre-made sets of components. It’s meant to be helpful: “here, use this pre-made components to save time not reinventing the wheel”, but it can come across as overly controlling: “we don’t trust you to exercise good judgement so stick to these pre-made components.”

The declarative approach is less controlling: “here are pre-defined rules and guidelines to help you make components.” But this lack of precision comes at a cost. The people using the design system need to have the mindset—and the ability—to create the components they need from the systematic rules they’ve been provided.

My gut feeling is that the imperative mindset is a good match for most of today’s graphic design tools like Figma or Sketch. Those tools deal with precise numbers rather than ranges and rules.

The declarative mindset, on the other hand, increasingly feels like a good match for CSS. The language has evolved to allow rules to be set up through custom properties, calc(), clamp(), minmax(), and so on.

So, as always, there isn’t a right or wrong approach here. It all comes down to what’s most suitable for your organisation.

If your designers and developers have an imperative mindset and Figma files are considered the source of truth, than they would be better served by an imperative design system.

But if you’re lucky enough to have a team of design engineers that think in terms of HTML and CSS, then a declarative design system will be a force multiplier. A bicycle for the design engineering mind.

Monday, May 30th, 2022

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.

Monday, May 16th, 2022

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.

Thursday, May 12th, 2022

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.

Wednesday, May 4th, 2022

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.

Friday, April 22nd, 2022

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.

Monday, April 11th, 2022

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.

Sunday, April 3rd, 2022

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?”

Sunday, February 6th, 2022

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.

Tuesday, January 11th, 2022

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.

Sunday, December 5th, 2021

Getting back

The three-part almost nine-hour long documentary Get Back is quite fascinating.

First of all, the fact that all this footage exists is remarkable. It’s as if Disney had announced that they’d found the footage for a film shot between Star Wars and The Empire Strikes Back.

Still, does this treasure trove really warrant the daunting length of this new Beatles documentary? As Terence puts it:

There are two problems with this Peter Jackson documentary. The first is that it is far too long - are casual fans really going to sit through 9 hours of a band bickering? The second problem is that it is far too short! Beatles obsessives (like me) could happily drink in a hundred hours of this stuff.

In some ways, watching Get Back is liking watching one of those Andy Warhol art projects where he just pointed a camera at someone for 24 hours. It’s simultaneously boring and yet oddly mesmerising.

What struck myself and Jessica watching Get Back was how much it was like our experience of playing with Salter Cane. I’m not saying Salter Cane are like The Beatles. I’m saying that The Beatles are like Salter Cane and every other band on the planet when it comes to how the sausage gets made. The same kind of highs. The same kind of lows. And above all, the same kind of tedium. Spending hours and hours in a practice room or a recording studio is simultaneously exciting and dull. This documentary captures that perfectly.

I suppose Peter Jackson could’ve made a three-part fly-on-the-wall documentary series about any band and I would’ve found it equally interesting. But this is The Beatles and that means there’s a whole mythology that comes along for the ride. So, yes, it’s like watching paint dry, but on the other hand, it’s paint painted by The Beatles.

What I liked about Get Back is that it demystified the band. The revelation for me was really understanding that this was just four lads from Liverpool making music together. And I know I shouldn’t be surprised by that—the Beatles themselves spent years insisting they were just four lads from Liverpool making music together, but, y’know …it’s The Beatles!

There’s a scene in the Danny Boyle film Yesterday where the main character plays Let It Be for the first time in a world where The Beatles have never existed. It’s one of the few funny parts of the film. It’s funny because to everyone else it’s just some new song but we, the audience, know that it’s not just some new song…

Christ, this is Let It Be! You’re the first people on Earth to hear this song! This is like watching Da Vinci paint the Mona Lisa right in front of your bloody eyes!

But truth is even more amusing than fiction. In the first episode of Get Back, we get to see when Paul starts noodling on the piano playing Let It Be for the first time. It’s a momentous occasion and the reaction from everyone around him is …complete indifference. People are chatting, discussing a set design that will never get built, and generally ignoring the nascent song being played. I laughed out loud.

There’s another moment when George brings in the song he wrote the night before, I Me Mine. He plays it while John and Yoko waltz around. It’s in 3/4 time and it’s minor key. I turned to Jessica and said “That’s the most Salter Cane sounding one.” Then, I swear at that moment, after George has stopped playing that song, he plays a brief little riff on the guitar that sounded exactly like a Salter Cane song we’re working on right now. Myself and Jessica turned to each other and said, “What was that‽”

Funnily enough, when we told this to Chris, the singer in Salter Cane, he mentioned how that was the scene that had stood out to him as well, but not for that riff (he hadn’t noticed the similarity). For him, it was about how George had brought just a scrap of a song. Chris realised it was the kind of scrap that he would come up with, but then discard, thinking there’s not enough there. So maybe there’s a lesson here about sharing those scraps.

Watching Get Back, I was trying to figure out if it was so fascinating to me and Jessica (and Chris) because we’re in a band. Would it resonate with other people?

The answer, it turns out, is yes, very much so. Everyone’s been sharing that clip of Paul coming up with the beginnings of the song Get Back. The general reaction is one of breathless wonder. But as Chris said, “How did you think songs happened?” His reaction was more like “yup, accurate.”

Inevitably, there are people mining the documentary for lessons in creativity, design, and leadership. There are already Medium think-pieces and newsletters analysing the processes on display. I guarantee you that there will be multiple conference talks at UX events over the next few years that will include footage from Get Back.

I understand how you could watch this documentary and take away the lesson that these were musical geniuses forging remarkable works of cultural importance. But that’s not what I took from it. I came away from it thinking they’re just a band who wrote and recorded some songs. Weirdly, that made me appreciate The Beatles even more. And it made me appreciate all the other bands and all the other songs out there.

Sunday, November 28th, 2021

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.

Wednesday, November 17th, 2021

Priority of design inputs

As you may already know, I’m a nerd for design principles. I collect them. I did a podcast episode on them. I even have a favourite design principle. It’s from the HTML design principles. The priority of constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

It’s all about priorities, see?

Prioritisation isn’t easy, and it gets harder the more factors come into play: user needs, business needs, technical constraints. But it’s worth investing the time to get agreement on the priority of your constituencies. And then formulate that agreement into design principles.

Jason is also a fan of the priority of constituencies. He recently wrote about applying it to design systems and came up with this:

User needs come before the needs of component consumers, which come before the needs of component developers, which come before the needs of the design system team, which come before theoretical purity.

That got me thinking about how this framing could be applied to other areas, like design.

Designers are used to juggling different needs (or constituencies); user needs, business needs, and so on. But what I’m interested in is how designers weigh up different inputs into the design process.

The obvious inputs are the insights you get from research. But even that can be divided into different categories. There’s qualitative research (talking to people) and qualitative research (sifting through numbers). Which gets higher priority?

There are other inputs too. Take best practices. If there’s a tried and tested solution to a problem, should that take priority over something new and untested? Maybe another way of phrasing it is to call it experience (whether that’s the designer’s own experience or the collective experience of the industry).

And though we might not like to acknowledge it because it doesn’t sound very scientific, gut instinct is another input into the design process. Although maybe that’s also related to experience.

Finally, how do you prioritise stakeholder wishes? What do you do if the client or the boss wants something that conflicts with user needs?

I could imagine a priority of design inputs that looks like this:

Qualitative research over quantitative research over stakeholder wishes over best practices over gut instinct.

But that could change over time. Maybe an experienced designer can put their gut instinct higher in the list, overruling best practices and stakeholder wishes …and maybe even some research insights? I don’t know.

I’ve talked before about how design principles should be reversible in a different context. The original priority of constituencies, for example, applies to HTML. But if you were to invert it, it would work for XML. Different projects have different priorities.

I could certainly imagine company cultures where stakeholder wishes take top billing. There are definitely companies that value qualitative research (data and analytics) above qualitative research (user interviews), and vice-versa.

Is a priority of design inputs something that should change from project to project? If so, maybe it would be good to hammer it out in the discovery phase so everyone’s on the same page.

Anyway, I’m just thinking out loud here. This is something I should chat more about with my colleagues to get their take.