Design Practice

The Two Futures of Software: Fast and Cheap vs. Painstakingly Good

In 1950s post-war America, an advertising executive named Rosser Reeves proposed a simple formula: you could have it fast, cheap, or good — but only two at a time. This “Project Management Triangle” quickly became corporate gospel, the kind of phrase you’d find taped to the side of a developer’s monitor or printed on a mug in a product manager’s cupboard. It was neat. It was true. And like most good slogans, it masked a deeper, more complex story.

Are We All Just Figma Operators Now?

As thousands of designers settled into a cavernous event space on the outskirts of London—laptop bags slung over shoulders, Stanley cups of cold brew in hand, waiting to hear about the latest feature roadmap from Figma—it struck me how familiar this all felt. Not just the scale and spectacle, but the underlying dynamic.

“I’m Just Being Helpful” – How Designers Accidentally Come Across as Disagreeable (and What to Do About It)

A lot of designers, especially those with a strong systems-thinking mindset, pride themselves on being rigorous problem-solvers. We stress-test ideas. We poke holes in weak assumptions. We say things like “That won’t work because…” or “The problem with that is…” and we think we’re doing our job — helping move the team forward, protecting users, flagging risks.

But let’s be honest: a lot of the time, we just come across as… difficult.

What Design Teams Can Learn from Air Traffic Control

When pilots call up air traffic control (ATC), they don’t just announce their presence—they request a specific level of service based on their needs. For small aircraft, this often starts with a basic service, where controllers keep track of the flight and notify emergency services if something goes wrong. If pilots need more, they can ask for a traffic service, where ATC provides warnings about nearby aircraft. For even greater support, there’s a deconfliction service, where controllers actively give instructions to help pilots avoid collisions.

This structured approach got me thinking: Should design teams operate in a similar way?