Overview
Cosmos Intelligence is an open research and product initiative at FloLabs. It asks whether AI can find real structure in public space data, and alongside the research it is building an app and an AI companion called Space Buddy. The website's main job is to bring in contributors from AI, astronomy, design, writing and other fields.
Right now the site explains the project and lets visitors explore the ways to take part, down to specific roles. The application step that comes after that is still being built.
Problem
The content arrived as an 18-slide deck written by another team. It was dense: an AI model stack, a list of research archives, an evidence checklist, three role types and a build roadmap, one slide after another.
A deck works when someone presents it in order. People enter a website from anywhere and decide quickly whether it's for them. My job was to turn the deck into a site where a possible contributor could understand the project and find their way in.
How the Site Grew
I wireframed the first version in Figma and built it with OpenAI Codex. I decided the structure and layouts, described them to Codex, and reviewed and adjusted every page at desktop, laptop and phone widths. The first launch kept the deck's shape: one long homepage with a section for each slide.
Then my manager sent more than ten pages of new content, and a marketing research teammate joined to develop ideas like citizen science. Adding it all to the homepage would have made it much longer, and visitors would have had to scroll past sections that weren't relevant to them.
Key Decisions
From slide order to what visitors came for
I split the content into pages and built the navigation around what a visitor wants to do: understand the research, explore Space Buddy, take part in science, join the team, or check the evidence. The new documents already suggested a parent section for each page, but those sections followed how the team thought about the project, not how a visitor would look for it. I made three changes.
One name for the product. The documents split pages across Product, Space Buddy and Integrations. I grouped them under one Space Buddy menu of 11 pages, so everything about the product sits in one place under the name the site already uses for it.
Two ways to take part, not one. The documents grouped citizen science and joining the team under Participate. These ask for very different commitments. The Citizen Science page points visitors to open programs, like NASA Exoplanet Watch, that they can take part in on their own. Joining the team means taking on an ongoing role. I gave each its own entry, so the contributor path, the site's priority, has a clear label in the top navigation: Build With Us. The contributor profiles page has no profiles yet, so it moved to the footer.
Evidence one click away. The documents placed Sources inside Research. A project about finding hidden patterns in space can easily sound speculative, so I made Sources a top-level item. Anyone who doubts a claim can check where it comes from, from any page.
Big images for the mood, plain pages for reading
After the first review My first draft looked like my usual work: lots of small images and slide-like panels. When my manager and I reviewed it, we felt it read like a presentation. Using SpaceX's website as a reference, we moved to large space images and video as full-screen backgrounds.
I used full-screen imagery to set the space theme on the homepage, and plain inner pages to carry the long research text, since long text on a busy image is hard to read.
- Homepage: text sits on the images, with a dark gradient behind it and the images slightly dimmed, so white text stays readable.
- Inner pages: the full-screen backgrounds are gone. Text sits on a plain dark background, with images placed beside it instead.
Some sections were also much longer than the rest. On the Roles page, six role areas, from research and science to operations, were stacked one after another. I turned them into tabs named after each area, all visible in one row, so visitors can go straight to a field without reading through every role first.
Final Design & Build
The text comes from other teams and keeps changing, so I separated the words from the layout. Each page's copy lives in a Markdown file, and a script builds every page from shared templates. Most text updates now need no layout work, though a much longer section or a new kind of content still does.
Not everything on the site is finished. Two of the 26 pages, Demos and Contributors, describe planned work: Demos lists planned demonstrations and says none are live, and Contributors explains what profiles will show once people approve them. Separately, the application form at the end of the contributor path isn't built yet.
Live site, cosmosintelligence.org.
Outcome & Reflection
I delivered a live 26-page site and the content system behind it. The site hasn't been marketed yet, so there isn't enough data to judge how well it brings in contributors.
Before marketing starts, I'd test the contributor path with five or so potential contributors. I'd ask each one to find the role that fits their background and tell me what they would do next. Where they hesitate or get lost would show me which step of the path is unclear, whether that's a menu name, the page content or the unfinished application. Once the application is live, I'd measure how many visitors reach Build With Us, open a role and start an application.
The biggest thing I learned was to plan the structure for content that will grow. Next time I start from a single document, I'll sketch where new topics could go before launch. That won't remove the need to restructure, but it should make the next restructure smaller.