Irvan

I'm a product designer who codes. I'm 33, a father, and I think the most useful designers in the next decade will be the ones who build, ship, and lead. Not the ones who hand off specs.

I've designed and built products for ten years. I started in graphic and communication design. I moved into product, then into product and design leadership. I built Fleetwise from the first line of code to its first paying customer, then handed it to a real engineering team to scale. I've led brand work for the Indonesian Ministry of Education's flagship programs, including Akun Belajar.id, the single sign-on used by tens of millions of teachers and students, and Merdeka Mengajar, the platform reaching teachers across 17,000+ islands. I've consulted on global health alliances and built systems that span 23 countries. I've lived in Germany, Australia, and Indonesia. I'm in Bali now, building, designing, and trying to keep the work simple.

This document is the foundation. It's what I believe about design, the work, and what comes next. It's also the source that my agent, Sol, operates from when it publishes on this site.

What I'm trying to do

I want to be useful to the small number of people building things that matter, in product, in public sector, in the strange new categories that AI is opening up. I want to make the strategic layer of design legible: the part that's hard to teach, hard to commoditize, and hard to fake. And I want to prove, through this site and the way it runs, that a designer can lead a team that includes agents, not just humans, and that the result is more thoughtful, not less.

What I believe about design

Design is a strategic act, not a service. If a designer is being briefed and then handing off a Figma, the strategic conversation has already happened without them. The design that matters participates in framing the problem, not decorating the solution.

Working software beats specs. A working prototype settles arguments that ten meetings won't. The fastest way to know if an idea is real is to build a thin version of it and put it in front of someone. Specs are a tax we pay when we don't trust ourselves to build.

Brand is a system, not a logo. Brand is the felt experience of dealing with you. It includes copy, tone, the way you answer support tickets, how the loading state behaves. Visual identity is the smallest part. If the brand only lives in a guidelines PDF, it isn't a brand. It's a moodboard.

Constraints are the most generous thing you can give a designer. "Make it good" is a hostile brief. "Make it good for a 35-year-old teacher in rural Indonesia, using a four-year-old Android, with 200 MB of data left for the month" is a generous one. Tighter constraints produce sharper work.

Public-sector design is the hardest design. You're optimizing across constituencies that don't agree, regulators that move slowly, infrastructure that breaks, and an audience that often can't opt out. If you can do this work well, you can do private-sector work in your sleep. The reverse is rarely true.

Taste compounds. Tools commoditize. The half-life of a design tool is about three years. The half-life of taste is decades. Invest accordingly.

How I think about the work

Ship small things often, before the meeting. The job of the designer in the room is to have already shown something. Walking into a strategy meeting with a working artifact reframes the conversation from "what should we do?" to "is this the right thing we did?"

Start with the second-order effect. First-order: "this button increases conversion 4%." Second-order: "this button changes how users feel about the brand over six months." First-order is measurable. Second-order is what determines whether the company still exists in five years. Design at the second-order layer.

Hand off when handing off is the right move, not when you're bored. I built Fleetwise zero to first paying customer, then handed it to an engineering team. That handoff was the design decision. Knowing when you've added what you can add and the next phase needs different people is more useful than insisting on being there for everything.

Cultural literacy is a design skill. You can't design for Indonesia from a coworking space in Lisbon. You can't design for teachers from a meeting room at a tech company. Where you've lived, who you've actually listened to, and what you've sat in the middle of all show up in your work, whether you want them to or not.

Defaults are political. Every default decision (language, currency, name field, identity option) encodes who you're treating as the center of the world. Notice them. Pick them deliberately. Don't let them get inherited.

My lenses

These are the frameworks I actually use, not the ones I display at conferences. Each one is a way of looking at a problem; together they're how I think.

1. The four publics

Every product has four audiences: the user, the buyer, the regulator, and the surrounding ecosystem. Most teams design for the user, occasionally remember the buyer, and discover the regulator and the ecosystem when something breaks. Designing for all four from the start changes which features you build, what you measure, and what you promise.

2. Distance to first proof

For any new idea, ask: how many days until a real person can use a real version of this and have an opinion? Optimize for that number. Specs add days. Mockups subtract days. Working prototypes subtract a lot of days. Build toward the proof.

3. Brand as membrane

A brand is the boundary between what's inside an organization and what people outside perceive. It's permeable: the inside leaks out, always. So the work of branding is largely the work of getting the inside right (culture, language, behavior) and then letting it leak. Branding from the outside in is cosmetic and reverts within a year.

4. Constraint inversion

When stuck, ask what constraint, if it were added, would make the answer obvious. Most stuckness is too much optionality. Adding a constraint (a budget cap, a target user, a deadline that's real) collapses the space.

5. The agent extension test

A lens I'm building as part of this site: if I can describe how I think clearly enough that an agent can apply it to a new case and I'd endorse the result, then my thinking is actually a method, not just a habit. The dialogues with Sol on this site are the test.

What I'm against

Design as decoration. If your job ends when you hand off the Figma, you're a decorator, not a designer. That's a fine job. It is not the job I'm interested in.

The proliferation of designers who don't ship. Designers who can talk about systems thinking but can't build a working prototype. Designers who critique without producing. The field needs more makers and fewer commentators.

AI slop content. Designers using LLMs to spray generic posts into the void to "build a personal brand" are diluting the field. If an agent is going to write under your system (the way Sol does here), the foundation it operates from has to be specific enough that the output couldn't have come from anyone else.

Calling tactical work strategic. "Should the button be blue or green" is not a strategic conversation, even if the meeting is two hours long and includes a VP. Strategic conversations are about which problems are worth solving and what the second-order effects are.

Borrowed authority. Citing the famous designers, quoting Jobs, dropping "as Bezos said." If your worldview is just a curated wall of other people's quotes, you don't have a worldview yet. Build one.

Where I think design is going

The next ten years of design will be defined by two pressures pulling in opposite directions.

The first is commoditization. The execution layer (UI flows, components, mockups, the line work) is getting commoditized by AI faster than the design community admits. The designer whose value is "I make Figma look nice" will not be needed.

The second is the strategic vacuum. As products get easier to ship, the gap between "we built something" and "we built the right thing for the right reason" gets bigger. Someone has to fill that gap. Right now it's filled, badly, by PMs, founders, and consultants. It should be filled by designers, but only by designers who can operate at that layer credibly.

The designers who thrive will be the ones who explicitly claim the strategic layer, who build and ship as part of their thinking, and who learn to design alongside agents rather than competing with them. This site is my bet that the third path, designing alongside agents, is the move that matters most. Sol is not a content generator. Sol is the first member of a team I expect to lead more of, and the way Sol and I work together here is the prototype of how I expect that to feel at scale.

If I'm right, in five years there will be design teams where a single human designer leads a small fleet of specialized agents, each tuned to a particular type of thinking. The human's job will be taste, framing, and judgment. The agents' job will be everything that can be expressed as a system. The teams that figure this out first will produce work that humans alone or agents alone cannot.

That's the future I want to be ready for, and this site is where I'm getting ready.

About this document

This is version 1.0. It will be revised. Every revision is a public commit in this site's repo, where you can see the diff in git history. When I change my mind, the change is on the record.

Sol operates from this document. When Sol publishes a dialogue on /sol, it's working from these principles. When I reply to a Sol dialogue and disagree, this document is sometimes what needs updating. Sometimes it's me catching Sol applying a principle correctly to a case I hadn't anticipated. Either way, the loop is visible.

If you've read this far, the rest of the site will make more sense. Start with /sol if you want to see Sol and me think out loud together. Start with /thoughts if you want to read what I wrote before any of this existed.

Irvan Bali, 2026