"He knows what is before them and what will be after them, and they encompass not a thing of His knowledge except for what He wills."
— Surah Al-Baqarah 2:255

People occasionally ask what kind of designer I am. I usually answer, "I design systems." That answer is technically correct, but it is incomplete.

The systems I care about are not limited to graphic design process, interfaces, brand development, or system architecture. They are systems that help people understand a situation well enough to make better decisions. Looking back, that interest didn't begin with technology. It began with repeatedly encountering the same coordination problem in very different projects. Over time, I realised that many design problems were not actually design problems. They were context problems.

Where This Perspective Comes From

Everything in this article comes from two sources, and I think it is important to distinguish between them.

The first comes from my own experience working across humanitarian branding, publishing, and retail leasing. In each environment, I found myself working between different groups with different responsibilities. Management looked at strategy, operations dealt with execution, designers focused on communication, vendors worried about production, and users experienced only the final outcome.

The second comes from observation. I spend a fair amount of time reading books, following product discussions, listening to podcasts, and observing developments in artificial intelligence and technology. Those industries are not my professional background, so I treat them as references rather than evidence. They often help me compare patterns, but they are not the foundation of my conclusions. The ideas that follow are based primarily on what I have experienced firsthand, with observations from other industries used only where they help explain a broader pattern.

Three Projects, One Recurring Pattern

The first time I noticed this was during a humanitarian branding project. The brief was to revitalise the organisation's identity and improve how it communicated with the public. As the project progressed, it became clear that visual design alone would not solve the underlying issues. Decisions about communication were connected to organisational goals, public trust, fundraising, volunteers, beneficiaries, and internal operations. The logo was only one visible outcome of a much larger system.

Later, I became involved in improving the publishing workflow of a publishing company. Although readers eventually see only a finished book, the work behind it involves authors, editors, designers, production teams, printers, distributors, and management. Decisions made during planning often surfaced weeks or months later during production. Improving the workflow required understanding how information travelled between these groups rather than focusing only on the visual outcome.

Today, my work in retail leasing presents a similar challenge on a larger operational scale. A single tenant opening may involve leasing officers, designers, operations teams, contractors, suppliers, and marketing teams. Something as simple as changing an opening date can affect digital directories, printed signages, installation schedules, floor plans, promotional campaigns, and site readiness. Much of my time is spent understanding how one change influences many others before any design work begins.

These three industries have different objectives and different ways of working, yet they exposed the same underlying problem. Information was rarely missing. It was fragmented.

Context Isn't the Solution

One conclusion gradually became clear: context is not something we create. It already exists. The market has its context, an organisation has its own, a customer has another, and operations introduce yet another layer. Design, engineering, finance, regulations, timing, and resources each contribute their own context as well.

The challenge is not collecting more information. The challenge is recognising which context matters, how different contexts influence one another, and whether the people making decisions are looking at the same reality.

I did not invent this idea. I simply kept encountering it until I could no longer ignore it, until eventually I felt the need to give structure to something I had been observing for years.

Giving the Problem a Place to Live

Eventually I started building something to hold all of this, mostly because I was tired of watching the same context slip between people who each held only a piece of it. I called it PRODE. I am hesitant to describe it as a platform or a product, because that is not really what it set out to be. Plenty of tools already help teams manage tasks, track progress, and communicate well. What none of them did, at least in the work I was doing, was organise context before a decision was made rather than after.

I can point to the moment that convinced me it was worth building. In leasing, someone once moved a tenant's opening date by two weeks — a small, reasonable change. Nobody had a clear view of everything that date was quietly holding together. It surfaced later, one consequence at a time: the printed directory was already at the printer, the signage install was scheduled around the old date, a campaign had gone out with the wrong week. None of it was hidden. It was simply scattered across people who never saw the full shape of it at once. Had we been able to look at that single decision and see what leaned on it, the change would have taken a conversation instead of a scramble.

That is the only thing I really want the tool to do: make the current situation easier to see before anyone commits resources to it. Not predict the future — just answer the questions that tend to go unasked. What are we assuming? Which of those assumptions has anyone actually checked? Who is affected by this? And if one assumption turns out to be wrong, what else moves? Those questions existed long before I gave them a home. The tool mostly gives them somewhere to sit together, early, where they can still change the outcome.

A Thought Experiment

While sketching the early concepts, I imagined something that reminded me of the Thanos glove. Not because it could erase ideas, but because it could refuse to move weak ideas forward.

Imagine presenting an idea to a system. Instead of immediately creating a roadmap or assigning tasks, the system asks: what evidence supports this, what assumptions remain untested, who benefits, and what happens if we do nothing? It cannot guarantee that an idea will succeed — neither can people — but it can encourage more disciplined thinking before significant time, money, and effort are invested. For me, the glove became a reminder that good judgment is often less about having better answers and more about asking better questions.

Looking Beyond My Own Work

Outside my own projects, I have noticed that discussions around artificial intelligence increasingly revolve around decision-making rather than automation. One comment from Tristan Harris stayed with me: he suggested that building advanced intelligence resembles building something with enormous influence over human decisions. Whether that comparison is accurate or not is open to debate. What interested me was not the comparison itself, but the intention behind it.

If technology becomes better at helping us make decisions, what should those decisions optimise for? Greater profit? Greater efficiency? Or greater responsibility? I do not have a definitive answer. Personally, I find myself drawn toward reducing unnecessary waste — wasted effort, wasted meetings, wasted assumptions, and wasted opportunities to serve people well. That motivation is what continues to shape how I think about systems.

Returning to the Beginning

Looking back, I no longer think I have spent my career designing only visual outputs. Brand identities, books, signages, campaigns — those were visible deliverables. The more valuable work often happened earlier, when people with different perspectives were trying to understand the same situation together. That is where I believe design begins: not with sketches, not with software, not with prototypes, but with context.

We can connect the past, but we cannot control the future, and we should be careful not to behave as though we can. We observe, organise, validate, discuss, and make the best decisions we can with the knowledge available today. The opening verse reminds me why that humility matters. Our knowledge will always be incomplete, our methods can always improve, and our intentions should always be examined.

For me, designing systems is ultimately an exercise in stewardship: helping people see their situation more clearly before deciding what to build next. Perhaps that is all a good system should ever aspire to do.