Have you ever dug for a link that a co-worker shared only to not find it? Teams today have so many links from so many different places -- a link to a design file, CRM, document, etc. -- and they store it in so many different places -- Slack message, Notion page, etc.

It's a huge inconvenience! So my friends and I built OneLink for ourselves and found out others wanted it too.


Co-Founder, Head of Product Design


Apr - May, 2023


User research, Product design, Interaction design

More than just a dashboard

OneLink is a shared dashboard for teams to store all their links in one place. But it was more than just a word-doc with sharing permissions. OneLink was built to be accessible from anywhere:


Save and auto-categorize links on your browser via a Chrome Extension


Auto-save links mid-conversation via a Slack/Discord bot


Generate onboarding briefs via a Slack/Discord bot

User Research
Finding the right customer segment

Our team interviewed over 40 people across various industries and company sizes. We learned about how they work, their frustrations, and their wishes (sometimes we got an inside look at how their teams operated). Here are some of the most notable insights:

Jake Rorrer,
Software Eng. Manager at Snackpass
Farza Majeed,
Founder of Buildspace
Michelle Wirantono,
Co-Founder of Typedream (YC W20)
The Problem
Too many links across too many places

User Problem

Finding important links across separate platforms is irritating and results in lost time and, sometimes, lost work.

User Research Takeaways


Problem is most consistently felt in teams with 10-50 people or teams of over 10 people, comprising of 2 or more roles.


On average, teams' links are scattered across 4 or more platforms


Problem is most consistently felt when a team has over 8 links with 3 unique types per project (e.g. Notion, Google Docs, Figma)


The more frequently a team member adds links, the heavier the problem is felt

The Process
Time constraints = Speed + Rapid iterations

* Doing user research in parallel with designs meant iterations could be implemented swiftly


As a side-project, my friends and I wanted to launch in 15 days. This meant that I had to serve 2 masters: the user and developers. The designs not only needed to be technically feasible, but also quick to develop, while catering to user behavior!

This meant that we needed an initial design direction fast (backed with quality user interviews) and I needed to update the designs as I had additional user interviews.

Scope & Initial Feature Sets

With our 15 day timeline, we had to be picky with our initial feature set, relying on user feedback to prioritize the next features to add:

* Yes, for our MVP, users didn't get an 'invite and accept' email when their teammate invited them to a OneLink dashboard. They just had to log in.

Iterating from our Beta-Tests

Beta-testing really helped when designing something so foreign and filled with assumptions like our "Sharing Permissions."

I gave 8 beta-testers a goal: "Share this dashboard." Observing them helped us find pain-points, helping me craft a new design. Below is the original design (A) and the iteration (B).


This was the original permissions design, inspired by Figma. But, our users didn't know how to send out invites nor did they understand how the link sharing permissions worked.


This is the new and updated permissions design. Using user feedback, we added an invite button. We also made a more intuitive way to set the link sharing permissions.

The Solution
Save, access, and share your links in one place

Feature #1 / Dashboard


This is your team's dashboard. Click the large "+" icon to add a link


Paste your link and continue


We'll autofill the details for you (site icon and title)


This is what a filled dashboard would look like

* To watch a demo for features 1 and 2, scroll to the top or bottom

Feature #2 / Sharing Permissions


Add your teammates' emails to give them view/edit access or send them a link to your dashboard!


If a user isn't logged in but they try to access a dashboard, this is what they see


If a user is logged in but doesn't have access to a dashboard they opened, a "request access" container appears

* To watch a demo for features 1 and 2, scroll to the top or bottom

Feature #3 / Alternate Points of Access

Creating a new way to store and share links would be a foreign workflow for a "small" pain-point that just adds undesirable friction. Hence, we built ways to access OneLink without going to the dashboard.


Click on the OneLink extension and we’ll automatically parse the link and title. We'll also auto-sort it into the right dashboard and section


Users can add optional tags before the bar reaches the end. Just like that, the link is saved


Some user interviews said they stored and shared links via Discord/Slack. This is a screenshot of our Discord bot, where users can request links or generate role-specific onboarding briefs!

Beta-Testers to Users to Nothing


It's obvious that talking to your users can open many doors. But listening without products can only take you so far. I was surprised at how much testing trumped assumptions. One shouldn't waste time on indecision: just launch and iterate quickly as it opens new, concrete directions.


OneLink started as a side-project to solve our own pains. But we thought it would be fun to actually launch it. We started strong with 8 beta testers, then got 20 users but retention quickly dwindled. Why is that?

The problem was frequent but it wasn't a strong pain. OneLink needed a hook where users feel a sense of relief after use, instead we had a nice-to-have tool. And even when we added features to reduce friction, new workflows were a larger friction so retention dwindled.


Case Study: Personal AI research assistant