Menu
brain.dex
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
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.
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 for the experiment. A second, built in-house, tracked how the helmet electrodes and reference sensors wear out. The operator opened it separately to see what needed replacing and to order parts from our development centre. A third told him which devices were configured for his station and which weren't. Three logins before a session starts.
Management's theory was that the software is where you win a customer. Show it to a lab, the lab understands what the company does. So my brief was to make the collection system worth showing, and my first assumption was that the seams were the problem. Four months merging the three into one. Along the way I built a vocabulary for how the software describes the hardware: what a station is, what a device is, when a sensor is worn out and how you know that before a session rather than after one fails. The collection centres felt it immediately. They live in that part of the system every day. The research labs didn't care. Nothing about their work changed.
Experiment building didn't match how researchers work
My second assumption was that the language was wrong. The system talked like a database; the customer thought like a neuroscientist. I could see the mismatch, not the shape of the fix, so I proposed research, and had to fight for a $2,500 grant to do it. The pushback was "we know our users." Semi-structured interviews, two hours each. The question I asked was: walk me through how you design and plan an experiment. They answered it precisely.
From those interviews I built a first schema of the flow labs wanted. Then Amir Shapira, the product manager, pushed it one level deeper: Projects contain Flows (protocols), Flows contain Runs (one participant, one execution), and Runs contain Sessions. Nobody in a lab says "a run." We invented it, because participants don't come in once: they skip a week, come back a month later, and something has to hold those visits together. I argued against it. I thought it was over-engineering. Amir wouldn't let it go, and without Run none of the cross-referencing that follows is possible. The most important object in this product is one I tried to talk us out of. We built the 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
It shipped. It was coherent. Every entity had a name a researcher would use. And when I asked Gil, a PI and one of our main customers, what he made of it, he said: "It's certainly more organised than my Excel." That was the whole review. A spreadsheet is free. Two assumptions, both reasonable, both executed properly, and the verdict hadn't moved.
The model was also exactly right for labs in a way that 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, which put us at a fork: two systems that behave differently depending on who signs up, or one system where 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.
He already knew how to do this. Just not with his own data.
Going back through my own interview notes, I found something I'd walked straight past. Gil had mentioned that before a study he goes into the public repositories. Not to download. He plays around in there, tries combinations, waits for something interesting to fall out. The behaviour already existed. He does it regularly. He just does it on other people's data, and it had never occurred to him to do it with the two thousand sessions his own lab had produced. In his head, having that would mean building a platform, and a lab doesn't build platforms.
So I built the thing nobody had asked for. Two weeks, not on the roadmap, a working prototype with real data rather than a mockup. Static screens tell you what people think they'll do. Then I took it to researchers outside the company alongside the system we'd shipped, and asked a different question this time. Not which they preferred: take a problem you have in the lab today and try to solve it with one of these.
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. So they could cut across it and find things in their own data they hadn't found before. 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.
Gil took control of my screen, typed three characters, and in four seconds cut straight across the hierarchy I'd spent months building. Two users, two axes, one movement. That repeated.
I didn't have to invent a behaviour. I had to move one, from somebody else's data to his own.
A question about a process gets you a process
Same people, same room, months apart. The first time I asked how they design an experiment. They told me accurately, generously, in detail, and I built a tool for exactly that, and it changed nothing. The second time I didn't ask about process at all. I handed them a problem they already had and two things to solve it with, and then I shut up. A question about a process gets you a process. I had to ask for a problem before anyone showed me one.
And what came back was an action, not a persona. 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. 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. He was querying the entity model we'd spent three days on, not browsing it.
Six sketches. Three became screens.
The next sprint came in as "search — a field at the top, like every other system, two weeks." By the rules of the backlog that was right. So 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 colour 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. Amir's answer was to give her a simple corner of her own: patients only, one day of work, nothing to learn. Yoni, our VP Product, looked at the two of us and said: you decide. I argued against the simple corner, and the reason wasn't kindness. A corner can only look inside one project — which is the hierarchy we'd just proven was worthless. And if only PIs can cross-reference, then cross-referencing is a feature. If the person who never designed the study can do it, the value isn't a feature; it's the data. The cost is real and I won't soften it: on day one she sees more than she needs. 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.
The solution was partial. Here is the rest of the thinking.
Two rooms and three lenses got the structure right: one atom, two grammars, no compromise on a single screen. What it got wrong is subtler, and I only saw it later. I gave the researcher a filter. Filtering narrows toward something you already know. Exploration widens toward something you don't.
Gil isn't searching. He's cross-referencing: men, dyslexia, after coffee, under five hours of sleep — and then the same without coffee. The combination is the hypothesis. Every change of a condition is a new experiment. What he needs isn't results; it's feedback on the hypothesis, and a way to put two of them side by side.
The idea underneath all four: the conditions a researcher must define to run a valid experiment are the same conditions someone else will later use to find what the researcher wasn't looking for. Nobody curated a taxonomy. Rigor is the index.
The direction of the cut became the direction of the layout. Cross-referencing is wide — facets, comparison, a grid. Extraction is narrow — one field, one column, one timeline.
The room — one question, one answer, one vocabulary
A lab tech who didn't design the experiment opens Explore. No conditions yet. On the left, every dimension a PI ever defined — grouped by where it came from: the protocol, intake, the PI's own conditions, the sensors — each with a live count. The counts tell her what exists before she knows what to ask.
Cross — the count is the feedback
Two conditions. 2,140 sessions became 38. Every facet count updated with it — N-Back is now zero, not because it doesn't exist but because it wasn't recorded under these conditions. And a strip shows how the 38 split on a third dimension: the next hypothesis, offered before she asks.
One field, or two — and why a participant is a filter
Every comparable product separates "search conditions" from "find a patient." I didn't, because in this model a participant is a filter: an ID takes 2,140 sessions to 6, and it combines with a condition to give 4. Two fields make that combination impossible — and they force the clinician to answer "person or condition?" before she knows a cohort is possible. The cost is that one field can't announce what it's capable of, so the empty state has to: every group it can find, including Participant, listed before you type anything. The same logic runs through the rest of the room. Cross-referencing is comparison, not retrieval — two condition sets, two panels, a difference row. N is always shown; p never is. And the detail a senior designer would ask about: grey, dashed cells for “not measured.” A condition exists only where a PI defined it. Not zero — undefined.
Extract — the clinician's door
The opposite geometry. One field: a Measurement ID — the masked identifier that maps to a name only inside the clinic's own records. Nothing is shown until it's entered. Then a vertical timeline: one participant, visit after visit. And at the bottom, the bridge: “patients like this one” opens Cohort. The same masked ID that protects the patient is what makes her a thing you can cut by.
None of this shipped, and I'm not embarrassed that it was still in the thinking stage. This is the thinking. The part I'd defend hardest is the grey cell.
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. Hadani used exactly that. He trained neural networks to identify neurological disease from EEG alone — something the literature had only put forward as a hypothesis. He could do it because the sessions arrived already tagged by paradigm and population, and because he could slice across them instead of having someone label thousands of raw recordings by hand. That labelling would have taken months. His research, not mine — what I'd claim is that the architecture removed the step.
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.
Three things I got wrong. Run wasn't my idea — I called it over-engineering and argued against the most important object in the product. My research was goal-oriented: I asked how an experiment works, got a perfect answer, and never asked what they wanted from the data afterwards. And I never usability tested Explore. What I ran was a heuristic walkthrough, which is not the same thing, and I can tell you the three findings it produced. The best design decisions I've made all came after I was wrong about something. The worst came when I was sure.