I was researching split keyboards recently, and something caught my attention.
At first, I was looking at the obvious things.
Why split the keyboard?
How far apart should the two sides be?
Why tent them?
What does that actually change for the person using it?
But then I started seeing other things around them.
Trackballs. Touchpads. Rotary controls. Modules you can move around or replace.
And at some point I started wondering:
Are we still designing a keyboard?
Or is the keyboard slowly becoming something larger?
Split keyboards started with a fairly clear problem
A normal keyboard gives everybody basically the same rectangle.
Your hands come toward the center. Your wrists rotate. Your shoulders and arms adapt to wherever the keyboard happens to be.
Split keyboards change that relationship.
Separate the two halves and the keyboard can start moving around the person. You can change the distance, angle and tenting, then position each side around the way your arms naturally sit.
This idea isn’t particularly new.
Split keyboard concepts go back much further than the current mechanical keyboard scene, and researchers have been systematically studying their ergonomics since the 1960s. Research has also shown that properly configured split keyboards can move the wrists closer to a neutral position compared with a conventional keyboard.
So the original problem was largely about:
Where should the keyboard be?
That makes sense.
But when I started looking at newer products, the question seemed to be changing.
From fixed keyboard to configurable input system
Three stages show a one-piece keyboard with fixed width and angle, a split keyboard with adjustable distance, angle and tenting, and a modular split keyboard with pointing and rotary controls around its halves.
Conventional keyboard
Fixed width / Fixed angle
Split keyboard
Distance · Angle · Tenting
Modular input system
Position + Controls
What else should your hands have access to?
ZSA has a system called Navigator.
It adds a compact trackball or trackpad next to its split keyboards, so a lot of the small pointing interactions can happen without moving your hand to a separate device.
The physical attachment is magnetic, while the pointing device still communicates through cables.
One of the clearest examples of taking the idea further was Naya Create.
Before Naya B.V. went bankrupt in August 2026, the company developed Create around a much deeper modular idea: a split keyboard designed as an ecosystem of interchangeable controls.
There was a trackball, a touch surface, a rotary control and a 3D navigation input, with software designed to control how the keyboard and those modules behaved together.
The company is no longer operating, but the product is still interesting to study because it pushed the keyboard much closer to being a configurable input platform.
Dygma has also publicly explored trackball and trackpad expansion concepts for its Raise 2.
These are different products and different approaches.
But they all made me think about the same thing.
We normally treat the keyboard and mouse as separate products because that’s how computers developed.
Keyboard here. Mouse next to it. Maybe another controller somewhere else.
Once the keyboard is already split into two independent objects sitting around your hands, there is suddenly useful space between and around them.
And that creates opportunities.
From separate devices to a modular input system
Diagram comparing separate desktop input devices with a modular keyboard system combining trackball, touchpad, dial and 3D controls.
Traditional workstation
Modular input system
Different controls solve different problems
Think about what your hands actually do while you’re working.
A key is really good when the action is clear.
Save. Delete. Undo. Switch tool. Mute.
A rotary control makes more sense when you’re adjusting something continuously.
Volume. Zoom. Brush size. Timeline position.
A trackball or touchpad handles spatial movement.
A 3D controller gives you another way to navigate an object or environment.
We already use all of these interactions. We’ve just spread them across separate products.
So once I started looking at modular keyboards, the interesting question became:
What if the keyboard becomes the place where some of these interactions come together?
I wouldn’t try to put every possible control onto one giant keyboard. That would probably create another problem.
What interests me more is keeping the core product relatively simple, then changing the controls around it depending on what you’re doing.
That’s where modularity starts becoming useful.
Then the idea gets complicated
A module sounds simple when you’re sketching it.
Maybe there is a dial here. A trackball there. A small control surface on the other side.
Then you start asking what actually has to happen for that module to work.
It needs power and data. The system needs to know what has been connected.
What happens if you remove it while everything is running?
Can the same module move from the left side to the right?
Does it remember its configuration?
Can two modules work at the same time?
And suddenly the little module isn’t really a little module anymore.
It affects the architecture of the whole product.
This is one of the things I find interesting about physical product development.
A small design decision can quickly reach electronics, firmware, mechanical engineering, manufacturing and user experience.
They are all connected.
One module affects the entire product
Diagram showing how an interchangeable hardware module affects industrial design, mechanics, electronics, firmware, software, manufacturing and future product architecture.
Software starts responding to the physical product
You can already see part of this happening in the custom keyboard world.
QMK supports pointing devices such as trackballs and trackpads, including configurations designed for split keyboards.
It can also activate a different keyboard layer when pointing-device activity is detected.
So imagine using the trackball and having the keys around your fingers temporarily behave as mouse controls. Stop using it and those keys return to their normal functions.
The hardware hasn’t physically changed.
But the interaction has.
That’s interesting because the physical configuration and software behavior are starting to work together.
A system designed around interchangeable modules could take that idea much further.
A module could bring its own controls. Another module could create a different workflow.
At that point, the physical product and software need to be considered together from the beginning.
Even the connector becomes important
Then there is the part that looks almost boring at first.
How do you attach the module?
Magnets? Rails? A latch?
Where does the power come from?
How does data move?
Can you connect it without looking?
Can you put it on incorrectly?
Can the same module attach to either side?
What happens after thousands of connections and removals?
These seem like small decisions.
Together they can determine whether the whole idea feels effortless or annoying.
What actually connects a module?
Exploded view of a module approaching the side of a keyboard. Six numbered leader lines connect the interface to alignment and retention mechanics, power and data connections, firmware detection and software configuration. These are design questions, not a specification for a particular product.
- Alignment
- magnets / guides
- Retention
- magnet / latch / rail
- Power
- contacts / cable
- Data
- contacts / USB / other interface
- Detection
- firmware knows what is attached
- Configuration
- software decides what it does
ZSA’s Navigator is a useful example because they separate parts of the problem. The shell attaches magnetically and positions the pointing device beside the keyboard, while cables handle the connection.
Naya approached it differently. Its modules were designed as part of the Create platform itself, with dedicated positions on the keyboard and software controlling their behavior.
Neither approach automatically gives you the answer.
The architecture depends on what you expect the product to become.
An accessory you might build once has very different requirements from a platform you want to keep expanding for several years.
Music production made this much more interesting to me
The research that originally sent me down this rabbit hole involved music production.
Once I started thinking about keyboards from that perspective, the idea of modular controls made much more sense.
Look at a producer’s desk.
There is the keyboard. The mouse. Maybe a MIDI controller. Knobs. Transport controls. Faders. Shortcuts everywhere. Possibly a macro pad.
Each device exists for a reason.
Music software asks you to switch between very different types of interaction constantly.
Typing. Pointing. Selecting. Adjusting continuous values. Starting and stopping playback. Navigating timelines.
So maybe the interesting opportunity is asking:
Which controls actually deserve to stay close to the hands?
That feels like a much more useful product question.
And the same question applies elsewhere.
Video editing. CAD. 3D modeling. Photo editing.
People who live inside complex software already build little hardware ecosystems around themselves.
The keyboard just happens to sit in the middle of most of them.
I wouldn’t assume one modular keyboard solves everything
It’s easy to look at this direction and decide that everything should become modular.
I’m not convinced.
Sometimes the separate mouse is better.
Sometimes you need a full-size MIDI controller.
A tiny dial next to the keyboard isn’t going to replace a proper control surface.
And a CAD user probably has completely different priorities from a music producer.
So before deciding which modules to build, I would want to understand the workflow.
How often does the hand leave the keyboard?
Where does it go?
What does the person do there?
Which controls need precision?
Which interactions happen hundreds of times a day?
Once you understand that, you can start deciding what belongs close to the hands and what should remain separate.
That’s a much stronger starting point than deciding upfront that a modular keyboard needs a trackball, three dials and a screen.
At some point, you’re designing a platform
This is probably the biggest shift.
If you’re developing a normal keyboard, there is a reasonably clear boundary around the product.
Once you start building interchangeable electronic modules, that boundary gets much wider.
Now you’re making decisions about the core device, mechanical connection, electrical interface, firmware, configuration software and future modules.
And the first product starts affecting products that haven’t been designed yet.
Choose the wrong connector and a future module might need more power than you can provide.
Make the physical interface too restrictive and maybe the next product doesn’t fit.
Build the firmware too tightly around the first accessory and every new module becomes another major engineering project.
There is another dependency too.
If the modules rely heavily on proprietary firmware and configuration software, the longevity of the hardware starts depending on the company behind it.
Naya is now an interesting real-world example of that problem. The physical keyboards can continue working, but the original company’s bankruptcy ended its warranty, future modules and official software development.
So product longevity isn’t only about whether the connector survives thousands of cycles.
It’s also about whether the system can keep functioning and evolving if the software, company or ecosystem around it changes.
This is the part of modular product development I find especially interesting.
You’re making decisions today for products you haven’t designed yet.
A connector decision becomes an electronics decision.
That affects firmware.
Firmware affects interaction.
The architecture affects manufacturing.
And eventually those choices can affect what products the business is able to build next.
So where does that leave the keyboard?
I started this research thinking about split keyboards.
Where the hands go. How the two halves sit on the desk. What feels comfortable.
I ended up thinking about something much bigger.
The first generation of split keyboards asked:
Where should the keyboard sit around the person?
The newer products are starting to ask:
What should the person be able to control from that position?
Maybe the answer is a trackball.
Maybe it’s a touchpad.
Maybe it’s a dial.
Maybe for music production it’s something completely different.
And maybe some of those ideas turn out to be worse than simply using the separate devices we already have.
That’s what exploration is for.
I don’t think I need to know the answer at the beginning.
What interests me is understanding the possibilities, the constraints and the tradeoffs well enough to make the next decision.
That’s usually where product development gets interesting.