Writing

“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.

Hacking Your Product Requirement Documents to Encourage Better Design

Most product requirement documents (PRDs) are boring, transactional, and—let’s be honest—kind of useless. They tend to be a simple feature request with a rough deadline, putting all the thinking and risk on the product and design teams.

But what if your PRD could do more?

Seven Hard-Earned Lessons for First-Time Founders

Starting a company is a crash course in humility. You’re juggling 100 decisions a day, half of which you’ve never faced before. You’re trying to build a product, grow a business, and stay sane—all at once.

Here are seven principles I’ve seen trip up first-time founders (myself included). If you're just getting started, I hope this saves you some scar tissue.

The Founder’s Vision Trap: Why Culture Beats Tech Every Time

It starts, as these stories often do, with a bold vision.

A founder has an idea — one they’re convinced is going to change the game. It’s innovative. Disruptive. The kind of idea that turns heads and opens investor checkbooks. Before long, there’s money in the bank, a team in place, and the runway to bring this vision to life.

From the founder’s perspective, the stars are aligning. The idea has been validated — after all, someone just put money behind it. Now it’s just a matter of execution.

But this is where things often go wrong.

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?

Are You an Accidental Design Saboteur? (According to the CIA)

What WWII sabotage techniques can teach us about well-meaning designers (and why the rest of the org sometimes rolls their eyes).