After leaving CapCut to start her own business, she aims to integrate the full capabilities of a professional design team into an AI workbench.

According to GeekPark, Zhang Qizhi, former head of Jianying China, has left her position to launch her own startup, founded the AI product prototype design workspace OJO, and recently closed a nearly 100 million yuan Series A round of financing, with joint investment from Shunwei Capital and Lenovo Capital, while Gaohe Capital served as the exclusive financial advisor.

This is Zhang Qizhi's first entrepreneurial project after leaving ByteDance. She joined FaceManga as a product manager in 2017, moved to ByteDance with the team in 2018, and has long been involved in the products and business related to Jianying ever since.

From an outside perspective, her experience at Jianying serves as a critical background for understanding this new venture: she has gone through the full lifecycle of a tool product, from 0 to 1, then to large-scale growth, and finally to the search for a new growth curve. As coding agents such as Claude Code, Codex and Cursor make "building a product" increasingly accessible, she has shifted her focus to another underresolved breakpoint in the product development pipeline — design judgment, and how such judgment can be continuously transmitted across product, design and development teams.

OJO positions itself as a "Design Agent Team Workspace". Users can complete product thinking, interface design, iteration and code delivery in a single workspace using natural language. The question it aims to answer is: as UI generation, design editing and design-to-code conversion become increasingly widespread, why is a dedicated workspace connecting design and development still worth building as an independent product?

Zhang Qizhi's answer is that the more powerful the model is, the more a system is needed to deploy its capabilities to specific scenarios. OJO hopes to integrate product definition, visual design, interaction iteration and code delivery into a continuous workflow, reducing the dilution of judgment during handovers between different roles.

This remains an answer yet to be validated by the market.

01. Leaving Jianying, waiting for "both myself and the technology to be ready"

Before 2025, Zhang Qizhi's career path at ByteDance was very smooth. Although she had long worked on the Jianying business line, she kept facing new challenges: from tool product development to globalization, from product growth to revenue building and user mindshare cultivation. The turning point came in 2025, when the business entered a relatively stable phase, and for the first time she clearly felt that her input began to fall behind her output.

The idea of starting a business emerged at that point, but she remained cautious. Large companies already have mature organizational networks, and the core responsibility of a business head is to judge the direction and push forward the pace of development; starting a business, by contrast, means building the entire organization from scratch. What she was truly waiting for was two conditions to mature at the same time: she was willing to build a new team, and the model capabilities were sufficient to reshape the way product and design teams collaborate.

Image source: OJO

Jianying gave her a "map" of product scaling. In her view, the 0-to-1 phase and the 1-to-100 phase are two completely different states. When Jianying launched its overseas version CapCut and its PC client, many decisions were made by the team after capturing early signals, quickly testing and launching new features, and then judging whether to increase investment based on user feedback. The key to the 0-to-1 phase is to match the speed of development to the time window, while keeping the cost of trial and error under control.

After entering the 1-to-100 phase, speed is no longer the only priority. As the business matures, the marginal benefit of the old growth methods begins to decline, and the team needs to shift from short-term feature competition to long-term changes in content formats and production methods.

This experience made her highly sensitive to time windows, early signals and growth bottlenecks. The technical node that ultimately confirmed her direction came between September and October 2025. The new round of capability upgrades of Gemini made her strongly feel for the first time that the once solid boundary between code and aesthetics was beginning to loosen.

Code has relatively clear right and wrong answers, but design has no standard correct solution. The same set of visual language may produce completely different effects in different cultures, industries and consumption scenarios. In the past, this ambiguity formed a wall between design and code.

But AI models are changing the starting point of product collaboration. Previously, product managers usually described their ideas with requirement documents first, then designers completed static pages and connected interactions in Figma, and demonstrated dynamic effects through preview mirroring. Whether a solution is feasible often cannot be truly verified until the design or even development phase.

Now, product managers and designers can use AI models to quickly generate a runnable dynamic prototype. Zhang Qizhi is used to checking dynamic interactions first; for her, this means product managers can turn abstract requirements into a clickable, experienceable and discussable version first, verify the product structure and interaction direction in advance, and then hand it over to designers and developers for further refinement.

It is not just efficiency that has been improved. Product managers can express their judgments with actionable results, and designers no longer need to wait passively for upstream requirements. Every role can push the work that used to rely on downstream colleagues to a passing level first, before starting professional collaboration.

"I'm ready, and the technology is ready too," Zhang Qizhi said. Different from her time at Jianying, this time not only the product needs to be designed from scratch.

02. OJO does not want to generate a single image, but to simulate a full design team

The first solution OJO came up with was not the current Agent Team.

In the early days of the startup, the team hired two freelance designers to make the landing page: one was good at execution, but was not willing to spend much time understanding the brand; the other was able to discuss brand strategy, but the visual implementation failed to meet expectations. A large amount of work eventually fell back to the internal team.

This experience made Zhang Qizhi re-understand design collaboration: what long-link tasks lack is often not an "all-round designer", but a collaboration mechanism that can recombine brand, vision, motion effects and system design according to different tasks.

The team therefore abandoned the idea of "one Agent completing the whole process". The reason is simple: there is no unified standard for aesthetics, and users will not follow the exact same workflow.

Some people want to go all the way from product strategy and page structure to high-fidelity prototypes; others only need a discussable dynamic solution, and then will return to Figma or coding tools. Typesetting, fonts, motion effects, and brand storytelling all require different professional capabilities. Pre-setting a fixed workflow will only limit users.

Therefore, OJO does not adopt the product form of a single Agent completing the full process, but splits design tasks into combinable Agent Teams and Skills.

The limitation of a single Agent is that it easily compresses the entire design process into one question and one answer. But real design is not generated in one go: some people define the problem and product goals, some determine the visual direction, some handle typesetting and motion effects, and others constantly check whether the results deviate from the original requirements. Design results often come from the judgments and revisions of different roles in continuous collaboration.

OJO tries to simulate this process with Agent Team. Users can select Agents responsible for different tasks, and inject more specific capabilities into them through Skills; the main Agent is responsible for judging when to call which Skill or tool, and transmits context between different links. It hopes that AI will not just directly generate a single answer, but organize and advance the entire design process.

Image source: OJO official website

These Agents are packaged as easy-to-understand characters such as Steve Jobs, Van Gogh and Leonardo da Vinci. The character names lower the threshold for user understanding, but what the product really needs to prove is whether there are substantial differences in the working methods behind these roles, and whether multi-role collaboration can deliver more appropriate and stable results than a single general-purpose Agent.

On the issue of aesthetics, OJO currently avoids obvious distortion by presetting Skills and tools first, and leaves higher-level style judgment to users. For example, the team will avoid using blue-purple gradients or high-saturation color schemes indiscriminately, but the key is not to ban a certain style, but to judge whether it matches the brand, users and usage scenarios. In the future, the team plans to further open up the Agent Team and Skills, so that different design experiences can be accumulated, combined and reused.

OJO's current target users are not professional designers. Zhang Qizhi believes that "the people who have real design needs are not designers". Designers are usually the people that upstream roles such as product managers, marketing staff and entrepreneurs turn to for problem solving. If the product starts with professional designers, it will easily become a pure efficiency optimization tool; OJO is more focused on serving people who have strong design needs but do not have a complete professional design team.

During the internal test, a content operation staff with no design experience built a personal website with complex motion effects in about an hour. Another user originally used Codex directly for front-end development, but the page became more and more deviated from expectations after multiple rounds of modification; he imported the existing results into OJO to adjust the visual effects, then returned to Codex to complete the code, and the project is now ready for launch.

These cases demonstrate what OJO aims to do: minimize the loss of ambiguous ideas between design and development.

Challenges still exist. Frequent users have reported operational bugs, and some people cannot quickly understand the main logic of the Agent Team. The team once put too many concepts into the interface, which caused the interface to lose focus. Later, they began to streamline the functions and strengthen the experience of "having a team working for you".

A product that solves the problem of design expression must first be easy for users to understand itself.

03. The competition of AI design tools is converging to the same end point

When OJO emerged, AI design tools were no longer a scarce category.

The market is moving towards the same end point along two paths: one starts from the design platform and extends to prototypes, coding and delivery; the other starts from coding agents, and adds capabilities for visual editing, design systems and collaboration.

Products including Figma, Google Stitch, Tencent Ardot, and Lovable are all expanding their boundaries. Figma Make and Stitch have supported interactive prototypes; Ardot uses MCP to connect design drafts with tools such as Claude Code, Cursor and Codex; Lovable continues to add capabilities for visual editing, design systems, Skills and multi-Agent support on top of runnable applications.

The end points of the two paths are getting closer and closer: one side turns design into code, and the other side endows code with design capabilities.

This means that the ability to "generate pages" can hardly become a long-term competitive moat. What is more worth comparing is whether a product can understand the existing brand, design system, code library and historical decisions; whether it can give judgments that are more aligned with the task among multiple seemingly reasonable solutions; and whether it can minimize the loss of previous decisions in the long pipeline from product definition to visual design, coding and launch.

This is also the difference between AI design and AI coding. The quality of code is more about "right or wrong", while the quality of design is more about "appropriate or not". The former is easier to be directly mastered by basic large models, while the latter relies more on continuous judgment in specific scenarios, brand context and collaboration.

However, Zhang Qizhi does not see this change as models "swallowing" applications. In her view, what is being reconstructed is not a certain product form, but the original industrial structure of the entire industry. Take Figma as an example, for more than a decade it has served the collaboration logic of large internet software companies: design is located between product, R&D and other links, and design drafts are not only creation tools, but also a common language for teams to transmit information and solidify decisions. After model capabilities enter the workflow, the first thing that changes are these upstream and downstream relationships — more roles can produce prototypes and participate in visual judgment earlier, and the old boundaries and organizational methods divided by functions will also loosen accordingly.

This does not mean that applications will disappear. Zhang Qizhi compares large models to railways: infrastructure determines the speed and reach, but it will not decide the destination, organize the route or complete the service for people. The more powerful the model is, the more obvious the gap between users and the upper limit of the model may become. It is like a "doctor" with more and more knowledge, but not every user knows how to put forward tasks, supplement context, judge results and keep it working continuously. The value of applications is to deliver this scheduling capability to more people in specific scenarios.

Back to design, Zhang Qizhi believes that drawing is only the most visible step in the entire design pipeline. What really affects the results are the product decisions, visual direction and aesthetic judgments before drawing, as well as the continuous modification, coordination and delivery that happen afterwards. Letting the model generate a page in one go does not mean completing all this work; handing over the entire complex pipeline to the basic large model is not necessarily the most effective division of labor.

This is exactly the position OJO aims to occupy: instead of competing with basic large models on single generation performance, it uses Agents, Skills and workflows to organize longer tasks, helping users who have design needs but no complete design team to turn their ideas into results that can be discussed, iterated and put into production. For OJO, design decisions, aesthetic judgments and control over models all need to be productized, rather than condensed into a single prompt.

She compares the large model to a "doctor" with growing knowledge: the improvement of model capabilities does not mean that ordinary people will automatically become better prompters. The value of applications is not to compete with basic large models for a short-term window, but to bridge the gap between users and the upper limit of model capabilities.

This judgment has practical basis. The number of people who can configure models, Skills, Tools and workflows on their own is still very small; a larger group of users needs products with lower learning costs and more stable results. But models will also continuously streamline some pipelines and redefine the boundaries of vertical applications.

The contradiction OJO faces has not yet been resolved: there is no public comparative data to prove that multi-Agent can truly improve design adoption rate and reduce rework; it emphasizes taste, but still needs to establish a more verifiable evaluation method than the aesthetic standard of the founding team; it hopes to build a Skills platform, but must first acquire enough users and creators to form network effects.

More direct competition comes from the professional users, design assets and collaborative relationships accumulated by platforms such as Figma, as well as the development and release closed loop formed by products such as Lovable. If it only provides "better-looking pages", OJO will easily become a temporary pre-step for coding agents; only by continuously saving design decisions, significantly improving the final product, and making these capabilities reusable through Skills, can it become an independent layer in the industry chain.

Zhang Qizhi has not given a definite answer as to whether future applications will still take the form we see today; it depends on model capabilities, organizational methods, and the new division of labor between users for aesthetics and collaboration.

Zhang Qizhi regards the end of this year as a verification node. By then, the team needs to obtain clearer demand signals from users, and judge whether Agent Team can truly keep design judgments in the workflow and deliver results that can be put into production.

Image source: X

OJO is currently available in overseas markets, and the team will focus more energy on overseas expansion. Domestic users and communication resources are easier to get started with; overseas markets require more investment in offline communities, word-of-mouth promotion and local networks. She believes that true Day One globalization means accepting that you need to put in twice as much effort in an unfamiliar market, and may only get half of the return.

Jianying was born in the rising period of short video content boom, and its opportunity came from the content changes that had already happened; what OJO is facing is a working method that has not yet taken final shape.