Stride

The temptation with any ambitious website is the same - open Figma, pick a style, start building. Skip that instinct for a second.

That is usually the wrong place to start. The more useful question is: what experience is worth building in the first place?

This project began with that question. The technology came later. The process moved from personal research and concept development into references, visual experiments, AI-generated imagery, video, relighting, design systems, AI-assisted development, testing and launch.

The interesting part is not the final website. It is how the idea was broken down into smaller problems that could actually be solved.

Concept first. Technology second.

A portfolio becomes more memorable when its experience comes from something genuinely personal instead of starting from a familiar template.

Before opening Figma, make a list of things that are genuinely connected to you. Interests. Habits. Places. Objects. Skills. Things you repeatedly return to. Things you could talk about without preparing a presentation.

A keyword cloud can be useful at this stage. The purpose is not to create a perfect list. It is to surface possibilities.

Don't make the site unique with decoration. Start with something that is already unique to you.

An unusual visual idea becomes stronger when there is a reason behind it.

A motorcycle could simply be a visual theme. It becomes more meaningful when it represents movement, exploration and a way of seeing the world.

The useful question is: what does this idea allow the user to experience?

Don't stop at "this looks cool." Ask what the concept lets the user do or feel.

The first visual direction is rarely the final one.

The early exploration moved through game-like 3D environments, vector illustration, different illustration styles, different visual treatments and realistic imagery.

Illustration was deliberately questioned because it is already widely used. The experience was meant to communicate real-world scenarios, not just represent them with a decorative style. That led to a more important question: if the user is experiencing things that have actually been experienced in real life, what would happen if the user saw the world from the rider's point of view?

Exploration is not wasted work. It helps reveal what the final direction should not be.

The POV was born from a simple question: when I'm riding the bike, what am I seeing?

That changed the role of the visitor. Instead of watching a designer's story from the outside, the visitor could see the world from the rider's position.

This is where realism became useful. The goal was not photorealism as a look. The goal was to make the experience feel like a real-world point of view. The rider's face did not need to be shown. The viewer could experience the ride through the rider's eyes.

When the story is about experience, consider showing the experience instead of explaining it.

AI becomes much more useful when it has a consistent visual source of truth.

Instead of repeatedly describing a person, vehicle and helmet from scratch, build references first. Here the reference set was rider, motorcycle, helmet - personally photographed and turned into character sheets.

The important idea is to separate what must stay fixed from what can change.

When AI needs consistency, give it a visual source of truth before asking it to generate variations.

The goal of the first image experiment was not to create the final scene. It was to find the right POV.

Different AI tools were used to explore different interpretations of the rider's perspective. One generated image finally matched the visual direction that was already forming in the mind. That became the base.

The important decision was knowing when to stop exploring completely different directions. Once the visual language felt right, further exploration could happen inside that language instead of restarting from zero.

Reference sheets → POV experiments → Compare outputs → Choose the strongest direction → Use it as the base

Exploration should eventually converge. Once the right visual language appears, build a system around it.

Generating one good image is very different from generating many consistent images.

The next challenge was creating different places without losing the established rider, motorcycle, helmet and POV. A dedicated Image Prompt Engine was created in Claude. Its job was to translate the visual reference into words and keep the important characteristics consistent.

The engine understood rider, motorcycle, helmet, POV, camera angle, framing and visual characteristics. It also accepted new location imagery as reference, then generated structured prompts for new scenes.

The useful AI workflow is not "generate again." It is "build a repeatable instruction system."

Detailed image prompts work best when they describe the parts of the image that must remain controlled.

A useful prompt can be structured around reference inputs, camera, foreground, environment, lighting, composition, palette, style and negative constraints. The prompt below is a real example from the project.

Not every generated image needs to become a video.

Video generation takes more time and costs more, so the possible scenes were filtered down to five main scenarios before production moved forward.

The lesson is simple. Explore broadly with lower-cost assets first. Spend the expensive production effort only on the scenes that matter most to the experience.

Image exploration → Review possible scenes → Select the key five → Move only those into video production

Filter before you animate.

A still image can tolerate ambiguity. A video cannot.

Before generating video, define exactly what should move, what should remain stable and how the movement should behave at the end.

Important constraints in this project:

• Motorcycle never stops
• Motorcycle never slows down
• Constant cruising speed
• Smooth left/right sway
• Continuous forward motion
• Loopable ending
• First and last composition match
• Foreground motion continues through the final second
• Distant elements remain comparatively stable
• Environmental motion stays consistent

The video prompt went through multiple iterations before reaching the final version.

For AI video, describe motion as carefully as you describe the image.

The final prompt that worked. Not the failed ones.

Tools Claude for prompt development. Magnific for generation workflow. Seedance 2.0 for video generation.

Once the design supported light and dark themes, the visual system suggested a natural extension. Light = day. Dark = night.

Instead of creating a completely different night scene, preserve the same scene and change only the treatment. This makes the day/night switch feel like one continuous composition rather than two unrelated pieces of content.

The goal was to preserve composition, rider, motorcycle, camera, motion, scene structure and sequence. Only the lighting, colour and weather treatment should change.

When two visual modes need to feel connected, preserve structure and change treatment.

Relighting needed a different kind of prompt.

The prompt should not describe a new composition. It should tell the model what must remain untouched, what is allowed to change, how the new lighting should behave and how the weather should be introduced.

A dedicated Relighting Engine was created in Claude. Its responsibility: generate prompts that focus on lighting, colour and weather while explicitly protecting the original structure.

Day video → Relighting Engine → Relighting prompt → Magnific → Seedance 2.0 → Night video → After Effects → Final lighting adjustment

After Effects was used to adjust brightness, levels and overall lighting. The purpose was to make the final night treatment darker and more realistic.

When transforming an existing asset, explicitly define what is allowed to change and what must stay fixed.

Notice how much of this prompt is "don't touch." That is the whole point of a relighting engine.

When AI is going to build multiple pages, consistency has to be established before the implementation spreads.

The design system was built in Figma using typography, spacing, padding, variables, styles, reusable UI values, icons and responsive rules. Figma became the visual source of truth.

Figma Cloud MCP was used to make the design system available to AI. The UI kit was then translated into a development-ready system so the same values could be used across the project.

Give AI a system, not a collection of screenshots.

The entire website was not designed in one giant pass. Design and development happened page by page.

Homepage → Game → About → Chat → Tutorial

The homepage established the menu, footer, logo, background media, core layout, main interaction and mobile version. Then the next page was designed and converted. The same UI kit remained the shared foundation.

A strong system makes page-by-page development much easier because every new page does not require a new visual language.

Build the system once. Let the pages inherit it.

You do not need to become a developer before experimenting with AI-assisted development.

The important skill is understanding enough structure to communicate what needs to happen. The useful mental model:

• Understand HTML structure
• Understand nested containers
• Understand layout relationships
• Understand spacing
• Understand responsive behaviour
• Understand what the interface should do

Then let AI handle the coding implementation. In this project, JavaScript knowledge was very limited. AI handled the coding while the design decisions, testing and feedback remained human-led.

You can direct implementation without personally writing every line of code.

Once the base HTML existed, interactions were added progressively.

The homepage was used as the first implementation environment. The process included adding correct images and videos, building scene progression, defining menu behaviour, integrating audio, adding animations, defining interaction behaviour and refining the experience against the Figma design.

External references were also used when AI needed help understanding a particular interaction or visual behaviour.

The approach was not to build everything at once. One interaction was defined. It was tested. The problem was identified. The implementation was adjusted. Then the next interaction was handled.

Build one behaviour at a time. Complex experiences become manageable when each behaviour is isolated.

The website was run locally and repeatedly tested in Safari and Chrome.

Testing included comparing the browser output with Figma, replaying interactions, trying different scenarios, watching transitions repeatedly, finding one issue at a time and giving AI a precise description of the problem.

When something did not work, the problem was described directly to AI. Instead of asking AI to inspect its own implementation generally, the feedback was more specific: "This is the problem that is happening. It may be related to this particular area." That kept the debugging process focused.

AI can implement the fix, but the quality of the feedback determines how quickly you get there.

Some browser problems are not worth forcing into the main implementation.

Safari introduced specific problems: WebM files were not loading properly, video sizes differed between Safari desktop and mobile, some interactions took too long to load, the eyelid-close transition was too heavy, and blur in that transition had to be removed for Safari.

A dedicated Safari engine was created. Its rule was explicit: anything changed through this engine is dedicated to Safari and should not affect other browsers.

This is a useful pattern for AI-assisted development: keep browser-specific work isolated when it needs to be.

Don't let a browser-specific workaround contaminate the main experience.

Responsive design did not mean shrinking the desktop experience. The mobile context required different decisions.

The original videos were horizontal. Cropping them to fill a mobile screen would remove too much information from both sides. The solution was to create separate mobile videos.

• Separate video composition and orientation
• Different navigation and menu mechanism
• Scroll removed, hold/swipe interaction added
• Custom bottom logo and navigation area
• Arrows for moving between scenes
• Dedicated mobile menu toward the bottom
• Helmet shadow/edge to reinforce the POV

The helmet detail is subtle. It represents the small portion of the helmet naturally visible from the rider's perspective.

Responsive does not always mean rearranging the same design. Sometimes the interaction itself needs to change.

One large AI conversation eventually becomes difficult to manage.

After multiple rounds of edits, context becomes too large. Version tracking becomes difficult. Previous decisions are harder to retrieve. Different tasks start competing for context. A change in one area can affect another.

The solution was to split the work into specialised AI engines. Context files such as skill.md and cloud.md were used to hold the rules and context for those engines. The result is closer to a small AI team than one giant conversation.

When the project becomes too large for one conversation, split the context by responsibility.

The chatbot is not a generic "ask me anything" interface. It acts as a conversational guide through the website.

The Chat Engine decides what should be said, where it should appear, when it should appear, which version should appear and how the message relates to the user's current state.

The conversation was mapped using platform, location, sequence and trigger.

User state → Trigger → Chat Engine → Contextual response → Next user action

Triggers include site load, ready state, preloader dismissal, first scroll, arrow or touch signal, first press-and-hold, inactivity, game opening or closing, iframe loading, previous interaction state, time elapsed and scroll state. The chat can respond differently depending on what the user has already done.

A good conversational interface is not just copy. It is a state system.

The Chat Engine decides what the site says. The Behaviour Engine defines how the experience speaks and behaves.

Every headline, button, caption and chat bubble runs through this canon first.

Define the voice and behaviour before generating hundreds of interface messages.

The game was not added because every portfolio needs a game.

It was added because a motorcycle game connected naturally to a childhood memory. Road Rash was part of the experience of growing up with early computers. That memory became a useful source for an unexpected interaction.

The game gives the website a break from the main ride. For younger users, the retro game can feel unexpected. For millennials who grew up with similar games, it can trigger recognition and nostalgia.

The purpose is simple: an unexpected break, a personal childhood connection, nostalgia, a playful interaction, an AI experiment. There is no need to invent a deeper professional metaphor.

A personal reference can become a strong interaction when it is used with restraint.

The game started from an existing open-source JavaScript racer.

Repository: github.com/jakesgordon/javascript-racer. It was downloaded directly from GitHub and placed in the project folder.

Claude was asked to understand the existing game, create a separate local environment, keep the game files isolated and apply the website's design system. The game was maintained in a separate folder and separate local environment.

Then the visual and interaction layer was customised: characters, backgrounds, colours, visual assets, police appearance, rider standing posture, riding posture, collision, sound effects and other interactions.

The game became a useful example of AI-assisted modification. Start with an existing technical foundation. Understand it. Define what should change. Use AI to implement the changes. Test the result.

You don't always need to build the technical foundation from zero.

The game demonstrates another useful AI workflow.

The visual assets were generated with ChatGPT and edited in Photoshop. The existing game logic provided a foundation. Claude handled the coding and modification work.

The designer remained responsible for what should change, how it should look, how it should behave, and whether the result felt right.

This is a useful model for non-developers: use an existing technical base where possible. Use AI to understand and modify it. Use visual judgement to direct the result.

AI can help customise existing systems without requiring you to build every underlying system from scratch.

Sound was treated as part of the interaction rather than something that plays automatically.

Music and game sound effects were sourced from Envato. The website remains silent until the user enters the experience.

A dedicated Music Engine handled the implementation: music integration, play, pause, mute, playing animation, line/waveform-style visual feedback and music interaction behaviour.

Sound should respond to the experience. It should not fight for attention before the user is ready.

Generated assets become much easier to maintain when they are organised around the experience rather than scattered across one folder.

For each scene, the video system contains four variants: Desktop WebM, Desktop MP4, Mobile WebM, Mobile MP4. One scene = four files. Organised into separate folders.

This makes replacement simple. If a scene needs a new video later, the relevant file can be replaced without restructuring the entire project.

Good asset organisation is part of the design system too.

The project used many tools, but the useful way to understand them is by role.

The most useful way to show the AI workflow is not as a list of chatbots.

Show each engine as a specialist with responsibility, input, process, output and next step.

Specialised AI contexts make large projects easier to manage.

Before launch, the project went through a dedicated AI-assisted readiness check.

The Take Live Engine checks code quality, award-worthy site readiness, SEO in HTML, broken links, required functionality, database, chat, responsive behaviour, browser compatibility and anything that may have been missed.

Build → Check → Fix → Check again → Go live

The goal is not to ask AI to declare the site perfect. The goal is to create a repeatable checklist so important things are not forgotten.

A good launch process is a checklist, not a feeling.

The main website experience follows a simple path.

1. Invitation.

   The visitor lands on a preloader inviting them to come along for a ride.

2. Enter.

   The visitor chooses "I'm in."

3. The ride starts.

   A background video shows the rider moving. A black overlay appears. The conversational guide begins.

4. Explore.

   The visitor moves through different scenes. The motorcycle POV continues. Each video loops continuously.

5. Night.

   A long press reveals the night version. The same scene becomes a night version without rebuilding the composition.

6. Game.

   The visitor can enter the retro motorcycle game. An unexpected break and an AI experiment.

7. Return.

   The visitor can return from the game to the main ride.

Invitation → Ride → Explore → Day/Night → Game → Return

The most important lesson is not which AI tool was used. It is the order of the thinking.

A useful sequence:

1. Find something genuinely personal.
2. Explore the concept before designing it.
3. Give the concept a story.
4. Give the story a behaviour.
5. Identify what must stay consistent.
6. Build references.
7. Test the visual direction.
8. Turn successful experiments into systems.
9. Use AI for repeatable generation.
10. Filter before expensive production.
11. Build the design system.
12. Implement page by page.
13. Test locally.
14. Isolate browser-specific problems.
15. Split AI contexts as the project grows.
16. Run a launch checklist.

The tools can change. The thinking sequence remains useful.