Building a Starship

It started as an experiment in recreating the interfaces from my favorite science fiction films. Five days later, I had a working starship bridge in the browser. I learned a few things along the way about using inspiration, giving feedback, and designing by building.

I’ve spent most of my career designing interfaces for real products. Then I decided to build a starship.

The initial question was simple: could I make a browser interface feel like the displays in Interstellar, The Martian, and Prometheus? Five days later, I had Kestrel: the bridge display of a research frigate sitting at Barnard’s Star in July 2166.

I didn’t design every screen in advance. I gathered references, pointed at things I liked, described what I wanted, and worked with Claude Code to build it. Then I looked at the result and decided what needed to change. That process turned out to be more interesting than I expected.

Lesson #1: Start with inspiration

On the first evening, I had almost no plan. I knew the kind of interface I wanted, but I hadn’t worked out what it would contain or how all the pieces would fit together. So I gathered references from the films I liked and started describing what caught my eye.

I wasn’t asking for a copy of any particular screen. I was looking at the visual language: line weights, density, color, geometry, and the way information was arranged.

Claude Code turned those references into a collection of interface components. The surprising part was how much could be built from a relatively simple set of instructions. The lines weren’t just decorative graphics. They were real geometry, generated as code and rendered into SVG. Change a parameter and every instance could change with it. Frames could resize without losing their detail, and the controls could have their own sounds.

My first art-direction note was essentially this:

Different line weights. Mostly thin. Make it feel sophisticated.

That was enough to get moving.

The lesson here isn’t that you need a perfect reference library or a detailed brief before you begin. You need something concrete to react to. Collect images, but pay attention to what you like about them. Is it the density? The contrast? The rhythm of the lines? The way a panel fits into its surroundings?

Being able to describe those qualities gives you a much better starting point than asking for something that simply looks futuristic.

Lesson #2: Design can suggest a story

I didn’t set out to write a story. I was building an interface. But as the interface developed, it started suggesting what belonged inside it.

A ship schematic suggested a captain. The captain suggested a log. The log suggested an anomaly. From there came a readiness board, camera feeds, crew profiles, a relay network, and science displays.

By the end of the second day, Kestrel had grown beyond a collection of science-fiction-inspired screens. It had a setting, a crew, and things happening aboard the ship. The interface was giving me ideas for the story, and the story was giving me ideas for the interface.

Sound helped connect everything. The main engine hum became a constant background layer. Music sat underneath it, dropping away when the captain read her log. Those details changed how the interface felt. A wall of instruments with sound and context is a different experience from a dashboard with the same information. It started to feel like somewhere you could spend time.

This is one of the interesting things about building interactively: the next idea doesn’t always come from your original plan. Sometimes you discover it by seeing what you’ve already made.

When you finish a feature, it’s worth asking what the experience suggests next. Not necessarily what belongs on a roadmap, but what would make the thing more complete, more believable, or more interesting to explore. You don’t have to know all of that at the beginning.

Lesson #3: Honest feedback is art direction

When iteration takes minutes instead of days, you can afford to be honest about what you’re seeing.

At one point, the orange accent had spread across too much of the interface. It looked muddy, so I pulled it back to smaller, more useful places: labels, level bars, and selected states. The first interface sounds were synthesizer chords. They were cheesy, so I replaced them with the clicks of relays, switches, and electrical components.

Then I found a bracket around one of the reference dials that I particularly liked. I turned it into a reusable piece of geometry, and it eventually appeared on three other instruments.

That’s how the visual language developed. I wasn’t working from a finished design system. I was finding things that worked, keeping them, and using them elsewhere.

The feedback itself was often pretty ordinary:

• That looks muddy.
• That sounds cheesy.
• I love that bracket.

Those aren’t sophisticated design specifications. They’re honest reactions to something you can see or hear. And they’re useful.

You don’t always need to explain the entire theory behind a design decision before acting on it. Sometimes you know something feels wrong before you can fully articulate why. The important part is being able to communicate that reaction clearly enough to make a useful change.

The same applies to working with AI. You don’t have to translate every instinct into technical language before you start. You can describe what you’re experiencing, look at the next version, and get more specific as needed.

The bracket example is a good illustration. I didn’t begin by defining a system of decorative geometry. I found one detail I liked, recognized that it could become a pattern, and followed the idea. The system emerged from the work.

Lesson #4: Make the experience the thing itself

Most websites follow a familiar structure. There’s a header, a hero section, perhaps three columns, and a call to action. There’s nothing inherently wrong with that structure. It works for a lot of things. But it’s easy to keep using familiar patterns simply because they’re familiar.

Kestrel didn’t need to pretend to be a website. It was a ship.

That changed how I approached the layout. The frame surrounds the display. Panels fit into its geometry. Navigation becomes a column of icons, and on a phone it becomes a honeycomb. The instruments are interactive, and the readings themselves contain parts of the story.

The interface isn’t there to illustrate the subject. It is the subject. That distinction matters because the experience can communicate through more than text and images. The arrangement of the controls, the behavior of the instruments, the sound of the ship, and the information available to explore all contribute to the fiction.

I could have built a conventional website about a fictional research vessel and filled it with illustrations of the ship’s systems. Instead, I could let people interact with those systems. The difference is more than visual.

Once intricate interfaces become affordable to explore, you’re less constrained by the familiar structures of the web. You can start with the experience you want someone to have and work backward from there.

A useful question for any project is: What convention am I following simply because everyone else follows it? Maybe that convention is the right choice. Or maybe the subject suggests something more interesting. You don’t know until you try.

Lesson #5: Your stomach is the first reviewer

On the fifth day, I experimented with a 3D sequence that moved a camera between two rooms. The first version looked impressive. It also made me motion sick.

The camera banked into turns, wobbled during hover, and moved itself around in ways I didn’t want. It looked like the kind of camera movement you’d see in drone footage, which wasn’t the experience I was after.

My feedback was straightforward:

The drone footage gives me motion sickness. I’d rather look around with my mouse.

The next version kept the horizon level, moved at walking pace, and let the visitor control the view. Much better.

I couldn’t have fully specified the problem in advance. I needed to experience the interaction before I knew what was wrong with it.

This is an important part of design that can get lost when we treat a specification as the complete definition of an experience. A spec can describe the intended behavior, but it can’t tell you everything about how that behavior will feel. You have to use the thing.

That applies to motion, sound, interaction timing, and plenty of other details. Something can be technically correct and still feel uncomfortable, awkward, or simply wrong. When you can build a working version quickly, you can test those reactions while the design is still taking shape. You don’t have to wait for a separate implementation phase to discover that an interaction isn’t working.

Kestrel still isn’t finished, and I don’t expect it to be. There’s always another layer to explore or something that could be improved. That’s part of what makes the project enjoyable. I can follow an idea, build enough to understand it, and decide whether it’s worth pursuing.

What five days taught me

The biggest change wasn’t that I could build a complicated interface quickly. It was how I approached the design itself.

I could start with a vague visual idea, turn it into something tangible, and use the result to figure out what I actually wanted. I could follow an unexpected idea without having to justify a substantial investment of time before knowing whether it worked. That changed the role of the initial design. Instead of trying to resolve every decision before implementation, I could use implementation to help resolve the decisions.

The process also reinforced something I’ve learned throughout my career: good design depends on paying attention. You need to notice what works, recognize what doesn’t, and understand what to change. The tools can help you make those changes, but they can’t remove the need to make good decisions.

Kestrel is an experiment, but the lessons carry over to product work. Start with something you can react to. Be specific about what you like. Trust your response to what you’ve built. Let useful patterns emerge, and don’t assume the conventional solution is the only one. Most of all, don’t confuse the plan with the experience.

When the cost of making something drops, you can spend less time designing around what is easy to build and more time exploring what would be interesting to experience. That’s a much more exciting constraint.

Explore the ship at kestrel.wellcrafted.pro.

We keep iterating.