Chiffonwind: Always Building.

Building products across design and engineering

I like taking a vague problem and turning it into something people can actually use

That usually means moving through interface, interaction, implementation, systems, and architecture without treating them as completely separate layers

How a product works shapes how it should be designed, and design decisions often reshape the implementation in return

I increasingly care not only about how to build it, but also what should be built, and why

Building Things That Work

I like pragmatism, but practical does not mean taking the shortest path to “done”

Sometimes another layer of abstraction is the practical choice

Sometimes it means fixing an architecture that keeps creating the same problems

Sometimes it means throwing away an interaction that simply does not work and starting again

I care about systems and logic, but not architecture for architecture's sake, and not speed that knowingly leaves tomorrow with today's problems

Good engineering should make a product easier to move forward, not just make the solution itself look clever

What actually works matters more

Real Products, Real Constraints

I like studying products that already exist, especially the ones used by a lot of people

With ChatGPT, Claude, Cursor, Doubao, and other mature products, what interests me is often not what looks impressive, but why they ended up making a particular choice

An ordinary interface can carry the result of user behavior, A/B tests, engineering constraints, business goals, legacy decisions, or years of iteration

I like working backward from those outcomes to the product decisions behind them, and comparing how different products make different trade-offs around similar problems

That is also why I like Mobbin

To me, it is less a gallery of polished UI and more a huge real-world product dataset

Real products rarely have a perfect solution

They are shaped by choices made under real constraints

Across Design and Engineering

I do not like defining myself by a framework or a stack

Tools change, and technologies that feel important today may become ordinary a few years from now

I care more about why something works than what it was built with

So I write code, design interfaces, discover product problems during implementation, then go back and change the assumptions that led there in the first place

Design and engineering feel less like separate stages to me, and more like different forces shaping the same product

I want to keep expanding that scope and take more responsibility for what gets built and why, rather than only owning one already-defined part of the process