Tags: process

461

sparkline

Tuesday, March 18th, 2025

Design processing

Dan wrote an interesting post with a somewhat clickbaity title; This Competition Exposed How AI is Reshaping Design:

I watched two designers go head-to-head in a high-speed battle to create the best landing page in 45 minutes. One was a seasoned pro. The other was a non-designer using AI.

If you can ignore the title (and the fact that Dan still actively posts on Twitter; something I find very hard to ignore), then there’s a really thoughtful analysis in there.

It’s less about one platform or tool vs. another more than it is a commentary on how design happens, and whether or not that’s changing in a significant way.

In particular, there’s a very revealing graph that shows the pros and cons of both approaches.

There’s no doubt about it, using a generative large language model helped a non-designer to get past the blank page. But it was less useful in subsequent iterations that rely on decision-making:

I’ve said it before and I’ll say it again: design is deciding. The best designers are the best deciders.

Dan finishes by saying that what he’d really like to see is an experienced designer/decider using these tools to turbo-boost their process:

AI raises the floor for non-designers. But can it raise the ceiling for designers?

Meanwhile, Matt has been writing about Vibe-designing. Matt is an experienced designer, but he’s not experienced with Figma. He’s found that he can work around that using a large language model:

Where in the past 30 years I might have had to cajole a more technically adept colleague into making something through sketches, gesticulating and making sound effects – I open up a Claude window and start what-iffing.

The “vibe” part of the equation often defaults to the mean, which is not a surprise when you think about what you’re asking to help is a staggeringly-massive machine for producing generally-unsurprising satisfactory answers quickly. So, you look at the output as a basis for the next sketch, and the next sketch and quickly, together, you move to something more novel as a result.

Interesting! Just as Dan insisted, the important work is making the decision and moving on to the next stage. If the actual outputs at each stage are mediocre, that seems to be okay, as long as they’re just good enough to inform a go/no-go decision.

This certainly seems more centaur-like than the usual boring uses of large language models to simply do what people are already doing.

Rich gets at something similar when he talks about using large language models for prototyping, where it’s okay if the code is kind of shitty:

If all you need is crappy code to try out a concept or a solution, then an LLM might well enable you (the designer) to do that.

Mind you, even if you do end up finding useful and appropriate ways to use these tools, you’re still using a tool built on exploitation and unfairness:

It’s hard (and reckless) to ignore the heartfelt and cogent perspective laid out by Miriam on the role of AI companies in the current geopolitical crisis:

When eugenics-obsessed billionaires try to sell me a new toy, I don’t ask how many keystrokes it will save me at work. It’s impossible for me to discuss the utility of a thing when I fundamentally disagree with the purpose of it.

Design for a Small Planet – Scott Jenson

So, let’s start with a simple premise: how can we make design less opaque and encourage teams to make small changes more efficiently? Not every product decision needs to be a big, complicated design process.

This checklist, in four parts, is meant to be a simple, lightweight way for the team to get the ‘gist’ of the issue and make a shared decision quickly. It’s a starting point, a way to get the critical information in once place so the entire team can understand and discuss. The four parts are:

  • Gather: Bring the right info together into a single place
  • Impact: List the size of the problem and possible risks
  • Sketch: Create a preliminary sketch of a solution
  • Team Huddle: Get the product team to discuss and agree on a solution.

Another uncalled-for blog post about the ethics of using AI | Clagnut by Richard Rutter

This is a really thoughtful piece by Rich, who’s got conflicted feelings about large language models in the design process. I suspect a lot of people can relate to this.

What I do know is that I find LLMs useful on occasion, but every time I use one I die a little inside.

Wednesday, February 26th, 2025

Why I Like Designing in the Browser – Cloud Four

This describes how I like to work too.

Thursday, February 13th, 2025

Putting the ink into design thinking | Clearleft

The power of prototyping:

Most of my work is a set of disposables rather than deliverables, and I celebrate this.

I like the three questions that Chris asks himself:

  1. What’s the quickest, cheapest thing I can create to help make the next design decision?
  2. What can I create to best demonstrate the essence of the concept?
  3. How can I most effectively share the thinking behind the design with decision-makers?

Sunday, September 8th, 2024

Manual ’till it hurts

I’ve been going buildless—or as Brad crudely puts it, raw-dogging websites on a few projects recently. Not just obviously simple things like Clearleft’s Browser Support page, but sites like:

They also have 0 dependencies.

Like Max says:

Funnily enough, many build tools advertise their superior “Developer Experience” (DX). For my money, there’s no better DX than shipping code straight to the browser and not having to worry about some cryptic node_modules error in between.

Making websites without a build step is a gift to your future self. When you open that project six months or a year or two years later, there’ll be no faffing about with npm updates, installs, or vulnerabilities.

Need to edit the CSS? You edit the CSS. Need to change the markup? You change the markup.

It’s remarkably freeing. It’s also very, very performant.

If you’re thinking that your next project couldn’t possibly be made without a build step, let me tell you about a phrase I first heard in the indie web community: “Manual ‘till it hurts”. It’s basically a two-step process:

  1. Start doing what you need to do by hand.
  2. When that becomes unworkable, introduce some kind of automation.

It’s remarkable how often you never reach step two.

I’m not saying premature optimisation is the root of all evil. I’m just saying it’s premature.

Start simple. Get more complex if and when you need to.

You might never need to.

Tuesday, April 2nd, 2024

Elizabeth Goodspeed on the importance of taste – and how to acquire it

AI image generation is essentially a truncated exercise in taste; a product of knowing which inputs and keywords to feed the image-mashup machine, and the eye to identify which outputs contain any semblance of artistry. All that is to say: AI itself can’t generate good taste for you.

Saturday, February 17th, 2024

“‘AI’ is pretty much just shorthand for mediocre” — Piper Haywood

Continuous partial ick …or perhaps continuous partial cringe.

Anyways, maybe we’ll eventually get to the point where AI has that human “spark”, who knows. Maybe it’ll happen next month and I’ll eat my words. Until then, as most of the content we experience online becomes more grey and sludgy, the personal will become far more valuable.

Can Apple Win Back Music | Vulf Opinion | Brad Frost

There’s no AI substitute for a human-produced drawing of someone on the subway, even if a similar-or-even-better result could be produced in seconds by AI. The artifact is often less important than the process — the human process — that made it. That’s why I suspect videos of creative processes are so attractive; we are captivated by seeing humans doing human things.

Thursday, December 21st, 2023

Eigensolutions: composability as the antidote to overfit • Lea Verou

I love, love, love the deep thinking that Lea has put into this, really digging into the guts of what design does.

Overfitting happens when solutions don’t generalize sufficiently and is a hallmark of poor design. Eigensolutions are the opposite: solutions that generalize so much they expose links between seemingly unrelated use cases. Designing eigensolutions takes a mindset shift from linear design to composability.

Lea ties this into web standards too. It’s really helped clarify for me why I want more declarative options for common use cases (like a share button)—it’s about raising the ceiling without raising the floor.

Monday, December 11th, 2023

How Certain Algorithms to Improve the Human Condition Have Failed – The Markup

A terrific piece from Aaron Sankin that goes from Waldsterben to software development via firefighting and the RAND corporation.

Bureaucracies use measurements to optimize and rearrange the world around them. For those measurements to be effective, they have to be conducted in units as relevant as possible to the conditions on the ground.

Tuesday, December 5th, 2023

On Principles – technogoggles

The value of design principles done right:

What I’ve learnt is that principles are not a luxury. Making explicit and conscious what drives your behaviour can be incredibly powerful as a means to critically shape a team and organisation to be who they want to be.

Thursday, November 23rd, 2023

Hixie’s Natural Log: Reflecting on 18 years at Google

On leaving the company, Hixie compares the Google of old to what it has become today:

Google’s culture eroded. Decisions went from being made for the benefit of users, to the benefit of Google, to the benefit of whoever was making the decision. Transparency evaporated. Where previously I would eagerly attend every company-wide meeting to learn what was happening, I found myself now able to predict the answers executives would give word for word. Today, I don’t know anyone at Google who could explain what Google’s vision is. Morale is at an all-time low. If you talk to therapists in the bay area, they will tell you all their Google clients are unhappy with Google.

Tuesday, November 14th, 2023

Benjamin Parry~ Writing ~ Marking the homework of a twelve year old ~ @benjaminparry

Don’t get me wrong, there are some features under the mislabeled bracket of AI that have made a huge impact and improvement to my process. Audio transcription has been an absolute game-changer to research analysis, reimbursing me hours of time to focus on the deep thinking work. This is a perfect example of a problem seeking a solution, not the other way around. The latest wave of features feel a lot like because we can rather than we should, because.

Thursday, November 9th, 2023

Creativity

It’s like a little mini conference season here in Brighton. Tomorrow is ffconf, which I’m really looking forward to. Last week was UX Brighton, which was thoroughly enjoyable.

Maybe it’s because the theme this year was all around creativity, but all of the UX Brighton speakers gave entertaining presentations. The topics of innovation and creativity were tackled from all kinds of different angles. I was having flashbacks to the Clearleft podcast episode on innovation—have a listen if you haven’t already.

As the day went on though, something was tickling at the back of my brain. Yes, it’s great to hear about ways to be more creative and unlock more innovation. But maybe there was something being left unsaid: finding novel ways of solving problems and meeting user needs should absolutely be done …once you’ve got your basics sorted out.

If your current offering is slow, hard to use, or inaccessible, that’s the place to prioritise time and investment. It doesn’t have to be at the expense of new initiatives: this can happen in parallel. But there’s no point spending all your efforts coming up with the most innovate lipstick for a pig.

On that note, I see that more and more companies are issuing breathless announcements about their new “innovative” “AI” offerings. All the veneer of creativity without any of the substance.

Tuesday, October 10th, 2023

Making the Patterns Day website

I had a lot of fun making the website for Patterns Day.

If you’re interested in the tech stack, here’s what I used:

  1. HTML
  2. CSS

Actually, technically it’s all HTML because the styles are inside a style element rather than a separate style sheet, but you know what I mean. Also, there is technically some JavaScript but all it does is register a service worker that takes care of caching and going offline.

I didn’t use any build tools. There was no pipeline. There is no node_modules folder filling up my hard drive. Nothing was automated. The website was hand-crafted the long hard stupid way.

I started with the content. I wrote out the words and marked them up with the most appropriate HTML elements.

A screenshot of an unstyled web page for Patterns Day.

Time to layer on the presentation.

For the design, I turned to Michelle for help. I gave her a brief, describing the vibe of the conference, and asked her to come up with an appropriate visual language.

Crucially, I asked her not to design a website. Instead I asked her to think about other places where this design language might be used: a poster, social media, anything but a website.

Partly I was doing this for my own benefit. If you give me a pixel-perfect design for a web page and tell me to code it up, either I won’t do it or I won’t enjoy it. I just don’t get any motivation out of that kind of direct one-to-one translation.

But give me guardrails, give me constraints, give me boundary conditions, and off I go!

Michelle was very gracious in dealing with such a finicky client as myself (“Can you try this other direction?”, “Hmm… I think I preferred the first one after all!”) She delivered a colour palette, a type scale, typeface choices, and some wonderful tiling patterns …it is Patterns Day after all!

With just a few extra lines of CSS, the basic typography was in place.

A screenshot of the web page for Patterns Day with web fonts applied.

I started layering on the colours. Even though this was a one-page site, I still made liberal use of custom properties in the CSS. It just feels good to be able to update one value and see the results, well …cascade.

A screenshot of the web page for Patterns Day with colours added.

I had a lot of fun with the tiling background images. SVG was the perfect format for these. And because the tiles were so small in file size, I just inlined them straight into the CSS.

By this point, I felt like I was truly designing in the browser. Adjusting spacing, playing around with layout, and all that squishy stuff. Some of the best results came from happy accidents—the way that certain elements behaved at certain screen sizes would lead me into little experiments that yielded interesting results.

I’m not sure it’s possible to engineer that kind of serendipity in Figma. Figma was the perfect tool for exploring ideas around the visual vocabulary, and for handing over design decisions around colour, typography, and texture. But when it comes to how the content is going to behave on the World Wide Web, nothing beats a browser for fidelity.

A screenshot of the web page for Patterns Day with some changes applied.

By this point I was really sweating the details, like getting the logo just right and adjusting the type scale for different screen sizes. Needless to say, Utopia was a godsend for that.

I was also checking back in with Michelle to get her take on design decisions I was making.

I could’ve kept tinkering but the diminishing returns were a sign that it was time to put this out into the world.

A screenshot of the web page for Patterns Day with the logo in place.

It felt really good to work on a web page like this. It felt like I was getting my hands into the soil of the web. I don’t think it’s an accident that the result turned out to be very performant.

Getting hands-on like this stops me from getting rusty. And honestly, working with CSS these days is a joy. There’s such power to be had from using var() in combination with functions like calc() and clamp(). Layout is a breeze with flexbox and grid. Browser differences are practically non-existent. We’ve never had it so good.

Here’s something I noticed about my relationship to CSS; my brain has finally made the switch to logical properties. Now if I’m looking at some CSS and I see left, right, top, or bottom, it looks like a bug to me. Those directional properties feel loaded with assumptions whereas logical properties feel much more like working with the grain of the web.

Sunday, October 1st, 2023

Burn baby burnout by Amy Hupe, content designer.

Here’s the transcript of a great talk by Amy on the realities of working on design systems.

Wednesday, September 20th, 2023

Get it shipped — building better relationships with Devs

This advice works both ways:

  1. Collaboration
  2. Communication
  3. Respect

Monday, July 31st, 2023

Friday, July 14th, 2023

Why design systems fail by Karen Vanhouten

  1. No shared (and contextual) sense of purpose
  2. Overbuilding, or scaling too early
  3. Inability to make decisions and move forward quickly
  4. Lack of clear ownership and dedicated resources
  5. Lack of cultural alignment

The common thread among these issues is that none are related to technical or tooling decisions —or even to the components themselves.