A networking tool for Google's global startup campuses

Overview

Google for Startups runs co-working campuses for founders across seven cities, where members sat two desks from the person they needed and never knew it. We built a searchable community directory that turned proximity into real connections — a Madrid pilot that grew into an official Google product across all seven campuses.

My role

Design strategy, UX and UI design, research design & facilitation, partial front-end implementation, and joint stakeholder management with Carlos.

Team

Me (design & research, co-founder) · Carlos (co-founder, engineering) · Edu (PM, Google) · Chris (Special Projects, Google)

Timeline

2019–2022

Why we started

Carlos and I had been members of the Madrid campus for over five years — long enough to know almost everyone, and to have become the informal connectors: the people who’d say “you should meet Andrea, she’s the best React developer in this building.” The Campus team noticed and asked us a direct question: how do you do that, and can we build it?

The core insight from early conversations was simple but easy to miss: the problem wasn’t that people didn’t want to connect. It was that they couldn’t discover who to connect with. A founder looking to hire a growth marketer had no way of knowing one sat three floors up. The human proxy — someone like Carlos — worked, but it didn’t scale. We needed to replace it with a product.

How I tackled it

Step #1 — Dogfooding: we were the human proxy

Before any wireframe, we had five years of lived experience in the space — playing the connector role the product would eventually replace. That was the research base. The Campus team’s question (“can we build it?”) is what turned an informal habit into a brief.

Step #2 — Research, phase 1: Madrid

I designed the research script and led the interviews; Carlos took notes and helped with analysis. We structured the script around five areas: how members first found the campus, their role in the ecosystem, what communities they already belonged to, what they were actively looking for, and what tools they used to communicate.

GFS Madrid research — four user types identified — Four distinct user types emerged from on-the-ground research at Madrid's campus.

We mapped four primary user types — the well-connected founder (hiring and raising), the less-connected founder (seeking peers), the unhappy employee (scanning for new roles), and the happy employee (just meeting interesting people). The throughline across all of them: people know what they need, but they can’t see who can provide it. The product’s job was to make that visible.

Step #3 — Data and research, phase 2: going global

Madrid’s engagement metrics convinced the GFS team to expand — first to London, São Paulo and Tel Aviv, then Warsaw, Seoul and Tokyo. Before touching the product I made the case for on-site research at each campus: the assumption that one community’s patterns would generalise across cultures was exactly the kind of unknown unknown that breaks products at scale.

GFS Tel Aviv on-site research — Tel Aviv campus research — different culture, different needs, same research cadence.

Tel Aviv changed our thinking. Madrid’s community was vertical — people clustered by industry, so founders had to build new networks from scratch. Tel Aviv was horizontal — most founders had served in the military together, so cross-functional relationships already existed. The same product meant something different in each place: discovery in Madrid, ambient visibility in Tel Aviv. We also learned Tel Aviv members used Facebook the way Spaniards use LinkedIn, and that Facebook’s notification volume buried time-sensitive info — which led directly to the Home menu.

The challenges

Mobile-first was the wrong bet

We inherited the “mobile first” mantra and assumed members would browse the directory on their phones. Then the analytics arrived: over 80% of traffic was desktop. Of course it was — people come to a co-working space and sit at their laptops, opening the directory in a tab. The phone was for after the meeting, not during discovery. We’d built a mobile-first UI for a desktop-primary use case. Recoverable, but instructive: assumptions about device context have to be validated, not inherited from a design principle.

GFS mobile-first UI — built for phones, 80% of traffic from desktop — Built mobile-first for a crowd that overwhelmingly visited on desktop — the data caught up two days later.

Google took away the one thing a networking tool needs

Google’s legal team wouldn’t allow vendors to implement “Sign in with Google” or any login feature — a reasonable data-leakage concern at Google’s scale. But it made personalised recommendations essentially impossible. Networking tools live or die on their ability to say “here are people you should meet.” Without knowing who you are, you can’t do that. This wasn’t a minor inconvenience; it was an existential constraint.

GFS directory — no login required for searches — Challenge: usefulness without login — every interaction had to be valuable without a barrier.

The Slack bot: high awareness, low adoption

The campus communities ran on Slack, and every member had a Slack ID — a soft identity layer that didn’t trigger the login constraint. Sol Chea helped us build the integration, and we launched it with a proper campaign: screens in London and Madrid, an announcement at the all-hands TGIF. Awareness was high. Adoption was low. The problem was the interaction model: to get a recommendation you had to message the bot directly — intent and manual input, exactly the friction networking shouldn’t have. People discover connections passively; asking them to cold-query a bot broke the pattern. Architecture right, interaction design wrong.

GFS Slack bot — directory search from within Slack — Where the community actually lived — discovered in Slack, not a separate app.

The solutions

From “find” to “discover”: the quick filter bar

The original search bar was prominent — partly for utility, partly to collect data on what people actually typed. Some searched names, some skills (“UX”, “WordPress”), and a surprising number searched “free beer”. The beer queries told us something real: people were using search to discover, not to find. That reframe led directly to the quick filter bar, which operationalised an interview quote that stuck with us: “the ability to see who has a similar skillset is a great icebreaker.”

GFS directory search — quick filter bar — A single search bar with smart filters — what 80% of users needed, in one interaction.

Skill-based searches rose after launch — the filter bar turned “find someone” into “discover who else is here.”

Mobile-first was wrong: rebuilding for the desk

We iterated fast — keeping the decisions that worked from mobile, but rebuilding the information hierarchy around desktop. Around the same time the Campus was updating its brand identity, so we absorbed the new brand book and updated the colour scheme and components to match.

GFS directory — desktop-first redesign — Desktop-first redesign: when the data tells you where your users actually are, redesign for that surface.

Engagement skewed habitual rather than one-off — people came back, not just poked once and left.

Configurable by design: seven campuses, one codebase

Every campus wanted something different — Tel Aviv wanted quick filters on the Startups menu, Madrid didn’t; Tokyo needed surname before name. Rather than hardcoding each variation, we made the product configurable from the backoffice: community builders could toggle features, adjust display logic and customise text without a code deployment. Then we fixed the architecture that couldn’t hold new features: a constrained content width, a persistent left navigation panel and a right profile viewer (full-screen on mobile, a bottom bar). Finally, “one source of truth” — a shared component library keeping the Figma library and production components in sync.

GFS backoffice — CMS for campus managers — Backoffice CMS — letting campus managers curate their own directory without engineering.

GFS directory — three-panel layout — Three-panel layout: directory, detail, and actions — all visible at once for power users.

One codebase, seven campuses — the configurable architecture that made scale possible without seven forks.

Feedback & impact

Week 1 (Madrid pilot): one Slack message → more than half of Campus visited — early proof the problem was real before Google made it official.
80%+ desktop usage — the desk-first rebuild earned the engagement the original mobile-first design didn’t.
On-site research in London, Tel Aviv and São Paulo before scaling — each community used the product differently, and the configurable architecture absorbed it.
The Slack bot saw high awareness but low adoption — the architecture was sound, the interaction model required too much intent. Documented, not glossed over.

And the emotional proof:

“The ability to see who has a similar skillset is a great icebreaker.” — a Madrid campus member, research interview.

Questions or want to discuss this kind of work? Email me.