Good design is simple

We tend to confuse good design with how much it gives us. The more buttons and options on the screen, the more powerful it must be. In some markets that is exactly the read: in China, an interface packed with entry points feels trustworthy, because you can sense that everything you might need is right there. The super-apps like WeChat are built on that logic, and in that context it works.

Now think about the products you actually love using, the ones you open without thinking. They tend to be the opposite, almost empty. Google put a search box on a blank page. Paying with your phone is a tap and your face. Stripe made paying online feel like almost nothing. They feel simple, right?

And simple here does not mean cheap or thin. Usually it is the harder, more expensive thing to build, because someone had to decide what you did not need to see.

People like to credit a guru for this. Rick Rubin is the closest I have to one, and The Creative Act is the book I keep going back to. Dieter Rams put it in three words decades ago: less, but better. I read them, I quote them. But the honest version is less flattering to all of us: you do not need either of them to make something simple. You need common sense and some respect for the person on the other side of the screen. The famous names just gave it words.

Simple things last because of how people are, not because a designer with a following said so. Nobody has ever complained that a form was too short. Simplicity feels rare for one boring reason: it is hard to defend in a room where everyone wants to add one more thing.

Fighting is expensive. It bruises relationships, puts you on the wrong side of a roadmap, and usually means going back to the PM who asked for the extra field with research they have already seen.

The cheap path is the additive one. You add the field. You add the button. You add the upgrade pitch. Nobody loses face. The product gets a little uglier. Repeat for two years and you do not recognize the surface.

Here is a real one, from work. At Jimdo, the first thing a new user does is create an event. Right after that, my team's part kicks in: connecting payments so they can actually get paid for it. In the current flow those are two separate moments. You finish creating the event, and then a new screen pops up asking you to connect a payment provider.

We set expectations on the screen before, so it is not a surprise. But it still lands like a second task, a gate between you and the thing you just made.

What I proposed is simple: fold the payment connection into the same flow, as the last step of creating the event. It is one more step in something you are already doing, it stays optional, and you can still set it up later.

The reason to push this is not only that it feels nicer. It is a business decision. Jimdo is becoming a payments-first company. The public line is "get found, get booked, get paid", and the last part is where the money moves. Every merchant who turns on online payments adds to the volume running through the platform, which is the number the company actually steers by. A calm, optional, in-flow step gets more people to turn it on than a separate screen that drops on them once they think they are done. The friction was costing the business money and annoying the user at the same time.

None of this happens by decree. I floated the idea in a thread and it got pushback straight away, which is how it should work. An engineer pointed out something I had glossed over: the existing screen quietly does two jobs at once. It tells you that you can run the event without online payments, and it lets you defer the setup. Collapse it too eagerly and you lose a state some people actually need.

He also made a fair point that the current step already performs well. My answer, and I will put it plainly: a step already converting well does not mean it cannot convert better.

I wanted to test it with users, with an A/B test. But for that you need a clear metric in mind. My proposal, the payment funnel from end to end: booking created, psp connected, payment webhook captured. You compare the new flow against the old one on those events. If the simpler one carries more people all the way through, it ships. If not, I was wrong and we keep the screen.

The most important thing is to understand that the work is not about us. It is about the person who is going to use the product, and we are just the ones who turn it into something they can actually use. Once a team believes that, the arguments get shorter, because the question stops being whose idea wins and becomes what the user needs.