Larissa Oh

The whitespace wasn't the real problem

Twos had a lot of unused space on web, but filling it for the sake of filling it wasn't much of a product problem.

The more useful clue came from users, Twosers. Some were already opening multiple browser tabs just to keep two lists visible at once. They had made their own version of split view before Twos had one.

That shifted the question for me from “what should go in this empty space?” to “what are people trying to do on desktop that Twos currently makes harder?”

First reactions from Twosers from Discord community and release video

"Wowzer! This is terrific...already lovin' it"
"This is another game-changing update…"
"One of the best new features released recently"
"I use it every day. It's easy to understand and navigate"

Desktop users were doing a different kind of work

Twos was great for quick capture on mobile. On desktop, people were settling in to do longer, more involved work: planning, comparing, and moving between lists. The single-list view made them keep bouncing back and forth.

That gave split view a clearer purpose. It wasn't a layout upgrade. It was a way to support a desktop workflow users were already trying to create for themselves, while keeping the rest of Twos familiar.

Why the obvious split-view pattern didn't fit

I looked at how Notion, Gmail, and Superlist handle split view. Most use the same basic model: select something in the main panel and show its details in a second panel.

That relationship makes sense in those products, but not in Twos. Twos treats things and lists as independent rather than forcing them into a parent-child hierarchy. If I copied the familiar pattern, one pane would always feel subordinate to the other.

Instead, both panes work independently. Each has its own navigation and search, so a user can pair any two lists. It was a little less conventional, but it fit the way Twos was already structured and gave users more flexibility.

Adding split view without making Twos feel unfamiliar

I worked directly with the founder-developer to keep the build practical. Rather than introduce a new navigation system, I kept the existing sidebar and used a floating action pattern that Twosers already knew.

That let us add a substantial desktop feature without asking users to relearn the product, and it kept the implementation relatively contained.

I tested the prototype with 5 users. Split view scored 5/5 for ease of use, usefulness, and expected frequency of use. The interaction itself was working well, but the sessions surfaced another issue: people still needed a clearer way to discover that the feature existed.

Split view, shipped

The shipped version gave each pane its own navigation and search. Users could keep any two lists open side by side and move between them without changing the way they already navigated Twos.

Within 3 months of launch, Twos saw +30% DAU, +40% WAU, and +20% MAU.

The next problem was getting people to find it

The post-launch engagement numbers were encouraging, but testing had already shown where the next round of work should go: discoverability.

My recommendation was to introduce feature education inside the product, at moments when split view would actually be useful, instead of expecting people to stumble across it on their own.

At that point, I wouldn't have prioritized adding more to split view. I would have focused on getting more users to the value we had already shipped.