I have a lot of ideas.

Probably far too many.

Some will eventually become part of a project, others will take a different shape, and many will simply remain in my notes. For a long time, whenever I had an idea, my first instinct was to start developing it immediately.

Today, I work differently.

I’ve realised that my projects rarely move forward simply because I’ve had a good idea. They move forward because, at a particular moment, I need to produce something.

It All Starts with a Need

When I’m working on a project, I usually reach a point where a specific need arises.

I need to explain a mechanic. Present a world. Communicate a design intention. Make a structure understandable. Show something that, until then, has existed only in my head.

That’s when the deliverable comes into the picture, and only then does my design work truly begin.

This distinction has become important to me: the idea isn’t the starting point. The need is.

I can have dozens of ideas waiting in the wings without ever developing them. When a need arises, some of those ideas suddenly become relevant.

Explore Before Choosing

My first solution is rarely the one I settle on straight away. I explore several possibilities.

Not necessarily because the first one is wrong, but because another might address the problem more effectively. I consider different ways of presenting information, different structures, and different formats.

It’s a fairly open-ended phase, during which I might revisit old ideas or come up with new ones. Then comes the moment to choose.

I start listing what I actually need to build my deliverable. This list helps me move from exploration to construction.

Building the Framework

Before creating a polished version, I need a structure.

So I put together an initial framework: the necessary information, its order, how the different elements relate to one another, and sometimes their hierarchy.

At this stage, nothing needs to look beautiful. What matters most is that it works.

Once the framework is in place, I review the entire process: does the deliverable actually address the original need? Is any information missing? Will someone unfamiliar with my reasoning understand what I’m trying to communicate?

Only after checking these points do I move on to producing the final version.

Create First, Then Shape the Presentation

Finally come the polished writing and the visual elements.

Depending on the deliverable, this might involve an image, a chart, an infographic, a mock-up, or simply a layout that makes the information easier to read.

The visual aspect therefore comes relatively late in my process.

It doesn’t determine what I want to say. It helps me communicate it.

Ultimately, my process looks like this:

Need → Deliverable → Exploration → Selection → Framework → Review → Production → Presentation.

I didn’t deliberately develop this method. I discovered it by observing the way I work.

And, more importantly, it helped me understand something: having an idea doesn’t mean I have to turn it into a project.

An idea can wait.

The need tells me when it’s time to put it to use.