When having Agents study existing interfaces, how to transform source code into your own design methodology?

How specific should research questions given to an Agent be?

Start from the step where users get stuck, such as not knowing if processing has started after uploading, failing to find the return entry after searching, or buttons being cramped on mobile devices. Hand the current page, intended action, and encountered difficulties to the Agent, then ask it to research how reference interfaces handle similar tasks. Limiting to one question makes it easier for the research report to focus on areas you can modify.

If a codebase is provided, let the Agent mark locations related to this interaction and explain where each judgment basis comes from. The output does not need to cover the entire project; first answer how to enter, how the current state is represented, and what feedback is given after operations. Here we only propose feasible research requirements; we have not actually read the codebase mentioned in the heated discussions, nor confirmed the implementation of specific components within it.

Besides normal footage, what other states need to be studied?

Break the operation process into stages: not yet started, in progress, results obtained, and issues encountered, recording what users can see and do at each stage. Then check how the interface helps continue operations when wait times lengthen, content is empty, or tasks interrupt. This yields a status list directly usable for designing and accepting your own pages.

Layout decisions can be judged based on your own content volume: Are operations still clear when titles get longer, buttons increase, lists have no data, or screens narrow? Reference projects' users may differ from your own; studies should state applicable conditions. For example, tools requiring continuous editing versus result pages opened only once may need different return and save entry points.

How to turn research conclusions into verifiable prototypes?

First, select a change and create a prototype using your own names, copy, and realistic-length data. Have someone seeing the page for the first time complete the intended task, observing where they pause, click incorrectly, or need explanation. Map problems to modifications, then decide whether to introduce other designs. This checks whether research conclusions fit the current product, avoiding decisions based solely on a showcase image.

How to Draw the Line Between Learning Methods and Directly Reusing Code?

This type of research is suitable for solving clearly defined interface issues. If the product's core tasks and content structure are still undetermined, first clarify what users need to accomplish before selecting reference objects. Agents can help find and organize materials, but the final choice of design rules and why they suit the current page should be clearly documented to facilitate future revisions.

Turn the discussion into a checkable task

Choose one interaction, such as a send button changing from waiting to complete. Draw its states and triggers, then implement an independent test page. Check slow, failed and cancelled paths and retain source-file locations as study notes. Similar recordings do not establish identical logic. No Telegram code was copied or derivative app published here.