Jingyi Zhu
SynMateris / AI Research OS for materials R&D

From literature to molecule, in one conversation.

An AI co-scientist for semiconductor and materials R&D that carries a project from a target property to a recipe you can actually manufacture. I researched, designed, and prototyped it in code, end to end.

RoleProduct Designer, end to endClientSynMatAIScale100+ screens, one system
SynMateris turning a request into a molecular structure in one conversation
01Problem framing / Domain research

The gap between a prediction and a material you can make.

AI can now predict new materials by the million. Almost none of them can be made. The teams I designed for call it the gap from design to pilot production, and it is where a new material still loses the better part of a year: slow trial and error, expert knowledge that does not transfer, results scattered into data islands.

But the deeper problem is not that the tools do not connect. It is that a scientist will not stake their name on an output they cannot see into, question, or overrule. For an expert, an AI you cannot verify is not a tool, it is a liability. So the hard part was never raw intelligence. It was trust, control, and accountability. That made it a UX problem before a technical one.

Predictednew materials by the million
The gap from design to pilot production
Madealmost none reach a real material
A year, lostto slow trial and error
Knowledgethat does not transfer
Resultsscattered in data islands
How might we make an autonomous AI a scientist will trust with work their name goes on, and stay in command of the whole way?
02The approach / Prototyping in code

I designed it by building it.

The loop behind every decision
1Vibe-code a working versionNot a mockup, something that actually runs
2Use it like a skeptical expertHit the dead ends a scientist would hit
3Watch what breaksThe running product teaches what a spec cannot
4Reshape the designThen build the next version
Repeat until it earns trust
Every decision was built, used, and reshaped until it earned trust, never specced on paper.

Trust is a behavior, not a screen, and no static mockup can prove it. So every direction call and every design review ran on a vibe-coded, interactive build, something that actually behaved, not a picture of it.

I used AI as a design collaborator, not a shortcut, refining in running code instead of on paper. So every decision below was pressure-tested on something that actually behaved, long before it was ever a finished spec.

What emerged was not a chatbot but a lab the scientist steers, where the AI does the work and the human stays in command. Earning that from a trained skeptic came down to four moves. Each one answers a reason they would not switch it on.

03Interaction design / Information design

Watch it show its work.

Scientists will not stake their reputation on a result they cannot examine. So I designed every result to carry its sources, its reasoning, and how confident it is, and to flag for review anything uncertain instead of hiding it.

It makes the interface denser than a clean chat. I made that call on purpose: showing the work is what turns a skeptical expert's caution into trust.

An answer you cannot check is not a result. It is a very confident guess.

photoG2
Every answer cites its sources and shows a confidence value. Uncertain results are flagged, not hidden.
04Human-in-the-loop UX

AI proposes. The scientist decides.

photoG3
Generated structures open as editable objects. The scientist corrects and approves before anything is logged.

Next, the fear of an AI that acts before you can stop it. So I designed it to propose, never to commit: a generated result opens as something the scientist can edit by hand, and nothing is final until a person approves it.

Yes, that adds steps a fully automated flow would skip. But in high stakes work, a system experts cannot steer is one they will not adopt. I chose trust over speed.

I found the exact handoff points by building the prototype and using it. You cannot feel where a human needs to step in from a static mockup.

05Information architecture / Systems design

Six tools, one workspace.

Then the cost of making an expert relearn how they work. The job had lived across six separate tools, so I pulled it into one dual-panel workspace: the conversation on the left, the live lab on the right, files, tool outputs, the editor, and the knowledge base. Every result files itself, so the next person starts where the last one left off. The information design had one goal, make a dense expert domain feel like one calm place, not a cockpit.

photoG4
One workspace instead of six tools. The conversation drives it, and every result is captured as it happens.
Most scientific software equates power with density. I chose the opposite, and made an autonomous system legible.
06Interaction design / Command line

A command line for the lab.

And experts distrust a vague chat box for precise work. So I designed a command line: precise, fast, and scriptable. One instruction chains tools, the workspace and context stay one action away, and every step stays visible.

The only thing to learn is how to say what you want.

I built it to design it. I typed real commands, hit the dead ends an expert would, and reshaped it in the same loop. The tradeoff is a steeper start for a beginner, in exchange for real speed for the expert it is built for.

photoG5
A command line, not just a chat box. One instruction chains tools, and every step is logged.
07Design systems / Design ops

100+ screens, one system.

A product this dense drifts without discipline. Most research software equates power with clutter, so I went the other way, a quiet interface that stays readable across 100+ screens. I built one design system, tokens shared between Figma and code, a 4 pixel grid, and a fixed set of radii. The audit came back with zero ad hoc values.

photoG6
One design system across 100+ screens. The same tokens live in Figma and in the code.
08Outcomes

From a black box to a system you trust.

The platform I designed the experience for reports about 90% prediction accuracy and 70% faster R&D at ¥1,000 a month, deployed with national energy, chemical, and semiconductor enterprises. Those are SynMatAI's figures, not mine. What my design changed is different: an autonomous engine a skeptic would never switch on became a system they will, because they can see into it, question it, and overrule it.

Design system
100+
screens on one system
Consolidated
6 → 1
six tools into one workspace
Consistency
0
ad-hoc values, end to end
09How I worked / Figma handoff

End to end, one designer.

01 / Discover
Prototype in code, not slidesI vibe coded clickable prototypes and ran them in client sessions, so we settled the real interaction early instead of arguing over static wireframes.
Research
02 / Design
One conversation over a complex labI designed the agent experience, the human-in-the-loop editor, the command line, and the approval and knowledge flows, threading six tools into one surface.
Product
03 / System
A system that holds at scaleI built the design system on tokens shared across Figma and code, so 100+ screens stayed consistent with zero ad hoc values.
Design system
The interface reviewed as a running build, then delivered in Figma
Every direction call ran on a live, vibe-coded build. Figma carried the final specs and the design system.
View the live prototype
10Reflection

Three things that apply anywhere.

/ 01
To design trustworthy AI, build it. Feel the model's behavior first, then design around it. A handoff loses the one thing you need to get right.
/ 02
You earn a skeptic by being checkable, not by being convincing.
/ 03
In high stakes AI, trust is the product. Every answer has to earn it.
One lab, one conversation

The best research tools do not replace the scientist. They hand one person the reach of a whole lab.