Menu
brain.dex
I joined to unify three systems into one. Two years later, a working prototype showed me the structure I'd built wasn't the product. It was what made the real product possible.
Role — Information architecture · User research · Prototyping in code · Interaction design · Design system
With — Amir Shapira, Product Manager · Jonathan Hepner, VP Product (2024–25) · Yoni Abeshitz, VP Product (2026) · Guy Perera, Product Manager
Brain data had outgrown its tools
brain.space gives neuroscience labs a place to collect and manage neural data. EEG signals, cognitive task results, physiological measurements, captured through a sensor-covered helmet. Until then that data lived in spreadsheets, on local drives, and in lab software nobody had updated in a decade.
Three people touch it: the researcher who designs the study, the operator who runs the equipment, and later the clinician who tracks patients through treatment. They want completely different things from the same data. That's where this story ends up. It starts with three separate tools.
Three systems, one operator, no single place to look
When I joined, running an experiment meant three tools. One tracked the experiment itself. A second, built in-house, tracked the helmet electrodes and reference sensors wear out, and the operator had to open it separately to see what needed replacing and order parts from our development center. A third told him which devices were configured for his station and which weren't.
My first contribution was structural, not visual: bring experiment planning, the sensor lifecycle (wear, replacement, ordering) and per-station device tracking under one roof. One platform, one login, one place to look before a session starts.
Experiment building didn't match how researchers work
Unifying the tools exposed the second problem. The way the platform let you build an experiment didn't match how a neuroscience lab actually designs one. I could see the mismatch; I couldn't see the shape of the fix. So I proposed research and had to fight for a $2,500 grant to do it, because the pushback was "we know our users."
From the interviews I built a first schema of the flow labs wanted. Then the product manager, Amir Shapira, pushed it one level deeper: Projects contain Flows (protocols), Flows contain Runs (one participant, one execution), Runs contain Sessions. Inside a run, a participant moves through steps — each with its own paradigms and breaks, as the experiment defines them and each step has its own state. We built that entity model together over three consecutive days. The paradigm-level state was his call; how it reads on screen was mine.
Solving one problem created the next
The new model was exactly right for labs and it made the platform harder for everyone else. A clinic doesn't design experiments. It runs a fixed treatment protocol and wants one thing: each patient's history, visit after visit. For them, the flow we'd just built was jargon.
The obvious answer was a second, participant-oriented UX. But that put us at a fork: two systems that behave differently depending on who signs up, or one system in which one of the two users gets less than they need. I asked management to choose. They wouldn't, and they were right. Telling a small startup to drop half its market is telling it to die a little. So I stopped asking them to choose.
Knowing exactly what you're allowed to give up is half of working inside an organization.
Nobody had shown us what they actually do with a session
I had a hunch. Every interview had told us what people wanted. Nobody had shown us what they did once they had a session in hand — what problem the system really solved for them. You can't get that from a mockup; static screens tell you what people think they'll do. So I built a working prototype in Lovable — real data, real interactions, two weeks — and ran the research on it.
What I saw wasn't what anyone had said. Nobody cared about dashboards. Nobody checked the status of their experiment. What made people lean in was that the new structure had tagged everything — paradigm, population, demographics, experiment type — and they could cut across it and find things in their own data they hadn't found before. Give me my raw data, help me slice it by demographics and paradigm, and I'll turn it into an experimental field. That was Gil. Three characters, four seconds, straight across the hierarchy.
And it held for the clinic in Cyprus too. Dr. Mavridou didn't want a patient-oriented UX. She wanted the same cut, along a different axis — one person, down through time.
He took control of my screen, typed three characters, and in four seconds cut straight across the hierarchy I'd spent months building. Two users doing the same thing isn't an edge case — it's a signal.
The structure wasn't what the platform needed. It was what created a new need.
Personas lie. Intents don't.
I'd been asking which persona matters more when the question was what action are they actually doing. Personas describe people — Gil is 38, has a beard, bikes to work. What tells me something is the sequence of actions in his first thirty seconds. It's repeatable, measurable, and portable: "discover a pattern in unstructured data" applies to Gil and to any researcher doing that kind of work.
As personas, Gil and Mavridou are irreconcilable — pick one. As intents, they're almost the same. Both are slicing, along different axes.
And here is the thing I didn't expect. The four seconds didn't break the architecture. They revealed what it was for. Gil could cut across the hierarchy only because every session already knew its paradigm, its participant, its state. The entity model we'd spent three days on wasn't a filing system. It was a query surface waiting for someone to ask.
Six sketches. Three became screens.
I started where everyone starts — a command palette like Linear, a persistent search bar like GitHub, a sidebar panel like VS Code. Two days in I felt like I was being asked to pick the color of a wall when the real question was where to build the house. All three assumed search is a component inside a product. For Gil, search was the product.
Three placements of the same assumption. Each one answers "where does search go?" None of them asks "what is search for?"
Search as a place you go
It assumes search is an event: type, submit, arrive somewhere else. That's good at bulk operations on a known query. It fails because the results page has no context. No sidebar, no way back. And because Mavridou searches for a patient and gets a list of her paradigms. Rows, not a person.
Conditions are the shell
No hierarchy, no sidebar, no search field: the chips are the question, the table is the answer. This is the breakthrough. The first time Gil and Mavridou get exactly what they'd done in the prototype: cut, adjust, watch it move. It fails on the third user. The operator works in steps, not conditions, and has nowhere to go.
Both grammars, one screen
Conditions lead; the hierarchy stays as a dimmed sidebar. Everyone has a home. Nobody has a clear one. It doesn't fail loudly. It fails quietly, by refusing to decide what the product is.
The fifth sketch killed the results screen. The chips became the question, the table became the answer, and they lived on the same page.
The operator I almost broke
Right when I thought I had it, I remembered the student. The operator who actually runs the equipment. She opens a new run, picks a protocol, enters a participant ID. Linear. She doesn't want chips, she wants a wizard. The conditions-first design would have fixed Gil and Mavridou and completely broken her. She isn't the paying customer. But if she can't operate the equipment, nothing works. I had to hold all three.
Two modes, one schema
Iteration 3 taught me the answer wasn't a compromise on one screen. Sketch 05 stopped compromising. It separated. The idea came from Slack: the workspace switcher. Not between organizations, but between ways of working inside one.
Build mode is the existing system: the hierarchy, linear navigation, creation, execution. Nothing changes for the operator.
None of it touched the schema. The architecture from section 2 stayed exactly as we'd built it, which is the whole point. It was already the right architecture. It just needed a second door.
Explore mode is the conditions shell. The chips are the question, the table is the answer, and there's no results screen. A view toggle renders the same conditions three ways. Sessions for Gil's catalog, Patient for Mavridou's single person story, Cohort for a trend across all her patients. When results cross the hierarchy, they come back grouped by where they live: project, then flow, then runs. The hierarchy stopped being how you navigate and became how results are explained.
From running experiments to training models
The unified platform, the entity model and the hardware lifecycle shipped. That's the product labs use today.
The bigger change was what the company understood itself to be. brain.space stopped being a tool for running experiments and became a platform for collecting data in a form that models can be trained on. Every session now carries its paradigm, its population, its demographics, its signal quality which means the raw data is already sorted before anyone asks.
Prof. Amir Hadani used exactly that. He trained neural networks to recognize patterns of neurological disease from EEG alone something that was in real doubt until then. He could do it because the sessions arrived tagged by paradigm and population, and because he could slice across them instead of having someone label thousands of raw recordings by hand. That labeling would have taken months. The architecture had already done it.
Nobody had to tag ten thousand raw sessions by hand.
The architecture had already done it.
The product manager estimated that for data collection center customers, the redesigned search cut time-to-find by roughly 18%. That's his assessment, not an instrumented measurement, and I'd rather say so than dress it up.
Explore mode reached concept stage with Amir. The company restructured and I was let go before it was built. I'm not going to pretend that's a clean ending, but it's the right one for a case about architecture: the part I'm proudest of is the part that didn't need me to stay.
Two years of being usefully wrong
Designers love to say we listen to users. Mostly we don't. We listen to the loudest stakeholder, to the deadline, to our own assumptions. Real listening is watching someone use the thing you made and letting yourself be wrong about it. Gil went straight to search and showed me in four seconds that the map I'd been handed was the wrong map. The entire outcome hinged on the fact that I didn't defend it.
What I'd take from this and I hold it loosely is that the era of hierarchical software may be quietly ending. Users never navigated the way we designed them to. They always cut across. With AI agents that take an intent and return a result, the hierarchy is becoming invisible to the thing using it. The intent is everything.
The best design decisions I've made all came after I was wrong about something. The worst came when I was sure.