Ryo Lu, original portrait retained from the existing Lizheng guest archive
Conversations · An edited account of Yuzheng Sun’s conversation with Ryo Lu, published February 20, 2026. Lu was Head of Design at Cursor in this conversation. This article draws on the opening discussion, approximately 00:00–15:30.
Ryo Lu describes a change in where his design work happens. At the beginning of the previous year, he was still starting mostly in Figma. By the time of this conversation, he was working in a version of an experimental Cursor interface built as an Electron app, connected to Cursor’s CLI and able to run real chat.
The difference mattered because the prototype could behave like software. He could work on its state, views, and interactions in the material the finished product would use.
In the interview, Lu said this prototype took about two weeks to build. He contrasted that with the months he thought a traditional Figma process, followed by discussions, might have taken. It is his comparison for a particular piece of work. The more general point is about the distance between designing an idea and finding out how it behaves.
Watch the original conversation
Start with the concepts
Lu describes software as a collection of concepts and the relationships among them. Those concepts have expressions at multiple layers: data structures, the movement of data into the interface, the interface itself, and the pixels someone sees.
His examples are deliberately concrete. Notion has blocks, pages, and databases. Cursor has agents, editors, and models. A video feed can be understood as a list of videos.
That way of looking at a product leads to different design questions. Which things should behave as the same concept but currently do not? Which relationships can be simplified? Could a change to one underlying concept make several new uses possible?
A visual design tool can help explore those questions. But a file that does not run leaves part of the answer elsewhere: in the implementation, in the handoff, or in a later conversation about what is feasible.
When a designer can work directly on code, some of those questions can be answered by changing the product and seeing what happens.
Flexibility creates its own design problem
A product can become complicated by accumulating features. It can also become so general that people struggle to understand what it is for.
Lu’s account treats both as design problems. The task is to develop a small set of concepts that remains coherent as people find more things to do with the software. Adding another button is one response to a new need. Revisiting the underlying structure is another.
This also clarifies a distinction within the word “taste.” A pleasing curve, animation, or sound can change how a product feels. So can a structure whose parts fit together and whose possibilities are easy to discover. The conversation explores both, without reducing design to either surface polish or pure functionality.
The first screen still matters
Making software easier to change does not automatically make the tools easy to enter.
Lu points to the opening experience of a professional coding tool. “Open Projects,” “Clone Repo,” and “Connect SSH” are familiar to engineers. To a designer arriving from a different workflow, each can introduce a new concept before anything has been made.
The same is true of terminals, package managers, branches, pull requests, local servers, and ports. AI may be able to help with the work, but a person can still encounter a wall of unfamiliar concepts on the way in.
Lu describes a useful direction: let someone make something first, then help them understand more of the machinery as it becomes relevant. His immediate starting point is modest—create a folder, open it as a project, and begin.
A practical question for your next prototype
The conversation suggests asking what your prototype lets you learn directly. Can you try the interaction? Can you change the relationship between two concepts? Can you see the consequences in the working system?
For Lu, the opportunity is that designers can increasingly take responsibility for those changes themselves. The work still requires a view of what the product should become. Code provides a more direct place to develop and test that view.
Source: Yuzheng Sun’s conversation with Ryo Lu, published February 20, 2026. This is a focused editorial adaptation of the opening discussion, not a full transcript. English phrasing has been edited from the existing translation; the short interface labels above are the labels discussed in the source.