AI Engineer World's Fair 2025
Good design hasn’t changed with AI
Read the talk
Good design hasn’t changed with AI
From GPU onboarding to fog effects and forgiving menus, John Pham shows how simple browser techniques make products feel fast, trustworthy, accessible and memorable.
From a talk by John Pham
Before you start: Basic familiarity with web interfaces and CSS will help you follow the implementation examples.
What is design beyond pretty pixels?
What counts as design: the appearance of a page, its animations, or the experience of using it? John Pham opens with that question, then shows a video full of attractive visuals. The tempting answer is the surface polish. But pretty pixels and elaborate animation alone do not explain whether a product works well for the person using it.
Design is how people experience your product. Everyone who builds and ships it participates, regardless of job title. Trends change quickly, especially around AI, but the people using software still need understandable, dependable interactions. That responsibility extends beyond the main interface to APIs, API error messages, documentation, emails and tweets. Each touchpoint changes how someone experiences the product.
The practical question is how those interactions make a person feel. Do they feel slow and scared, or fast and powerful? As AI-assisted development makes it easier for competitors to ship similar features every day, Pham sees less differentiation in feature parity itself. The experience surrounding those features becomes more consequential.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Four dimensions of the experience
Pham organizes that experience around four dimensions:
| Principle | What to design for |
|---|---|
| Speed | Perceived time, immediate feedback and freedom from jank |
| Trust | Clear state, error prevention and forgiveness of mistakes |
| Accessibility | Screen-reader support, usable contrast and appropriate motion |
| Delight | Care, rewards and a story people remember |
Speed means the interface does not make someone feel held back. Trust means it communicates honestly and gives people the affordances they need to act safely. Accessibility makes the product’s usefulness available to more people. Delight shapes whether they remember and share the experience.
In Pham’s framing, speed earns the first click, trust keeps people around, accessibility expands the addressable market, and delight creates fans. His assignment is to examine an existing product through all four lenses—not merely to add a decorative finish after its features are complete.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make unavoidable onboarding feel lighter
The first concrete example is San Francisco Compute Company, where Pham worked at the time of the talk. Customers arrive expecting a cloud GPU provider. They may not expect questions about their Social Security number or address. Pham attributes the country restrictions and information collection to US export-law compliance. Those requests create friction before the customer has used the service; the design problem is to make necessary onboarding feel lighter without concealing what it requires.
The experience begins with a fast arrival from a search result. Pham reports first paint below 300 milliseconds for the onboarding page. He does not supply device, network, cache or measurement conditions. He also invokes roughly 400 milliseconds as a perception threshold, but responsiveness depends on the interaction; that figure should not be treated as a universal boundary for what humans can notice.
The implementation uses server-side rendering, caches as much as possible, and minimizes the bundle and external assets sent to the client. Pham reports 60 FPS or more while browsing the experience. The purpose is continuity: transitions should feel fluid rather than stuttering between states.
Page weight becomes a team concern rather than an occasional optimization project. Pham mentions e-commerce studies connecting smaller pages with revenue improvements, without supplying a specific study or uplift. His actionable suggestion is a scoreboard: record the current performance scores and make reducing them a team objective. The Web Vitals he names are LCP, INP and CLS—Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. First paint is distinct from LCP; loading, interaction responsiveness and visual stability each need attention.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build fog from one small image
The onboarding borrows its visual identity from San Francisco, especially the fog. This background is not simply a fixed animation: its density responds to events in the experience. The effect must also work across browsers, look sharp on retina displays, remain fast and accommodate accessibility needs. Those constraints make its construction more interesting than its appearance alone.
The reveal proceeds from a single transparent cloud image:
- Enlarge it. A close-up of the cloud starts to resemble fog, though it lacks depth and movement.
- Animate it. Movement helps, but one moving image still looks mechanical.
- Duplicate it. Stack copies, offset their transforms, and give them different opacities and movement speeds.
- Control density. Change layer opacity and the number of stacked copies in response to events.
The apparent complexity comes from independently moving layers, not from a complex source asset.
A CSS implementation can express that layering directly. Here, each .fog-layer uses the same image; a data-density change exposes the additional layer and increases opacity. The offsets and durations are illustrative values:
css
.fog {
position: relative;
overflow: hidden;
--density: 0.25;
}
.fog[data-density="dense"] {
--density: 0.55;
}
.fog-layer {
position: absolute;
inset: -25%;
pointer-events: none;
background: url("cloud.png") center / cover no-repeat;
opacity: calc(var(--density) * var(--alpha, 1));
animation: drift var(--duration, 30s) linear infinite alternate;
}
.fog-layer:nth-child(2) {
--alpha: 0.7;
--duration: 43s;
--offset: -8%;
animation-delay: -15s;
}
.fog-layer:nth-child(3) {
--alpha: 0.5;
--duration: 57s;
--offset: 10%;
display: none;
animation-delay: -29s;
}
.fog[data-density="dense"] .fog-layer:nth-child(3) {
display: block;
}
@keyframes drift {
from {
transform: translate(-5%, var(--offset, 0%)) scale(1.2);
}
to {
transform: translate(5%, var(--offset, 0%)) scale(1.2);
}
}
Pham reports that the fog reuses one 14-kilobyte image and requires no third-party JavaScript. Reusing that small asset lets the visual effect coexist with the page’s performance budget.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tell people what comes next
People often try to rush through onboarding. When required information prevents removing the work, the interface can still remove uncertainty. The initial onboarding message promises three steps taking under a minute. Selecting a business account adds another step, and the interface updates that expectation at the moment of selection. Progress also updates as the customer advances. Pham describes the motivation to finish after reaching the halfway point as an endowment effect: visible investment makes completion more appealing.
At the time of the talk, SF Compute also required an onboarding call for every user. Engineers may hear that requirement as an unwanted sales conversation. The interface addresses the concern explicitly: the call is with engineers to understand and qualify the customer’s needs, not to pitch them. If SF Compute is a poor fit, the team will recommend another provider. That promise gives the required conversation a purpose the customer can evaluate.
Scheduling follows the same principle of reducing unnecessary work. The product proposes a meeting time first. Only when that time does not work does the user need to open the more involved calendar selection. The time should be displayed in the customer’s local time zone and explicitly identified as such, so they do not have to wonder whether a displayed hour means UTC, Eastern time or their own clock.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Reduce motion, typing and cognitive load
The animated fog creates an accessibility obligation. Repeated motion can cause severe nausea, and Pham jokes that the number of users who vomit is not a KPI to increase. His implementation pauses animations when the user requests reduced motion. The platform preference does not stop animations automatically; the application must respond to it. For the fog layers above, that response can be expressed in CSS:
css
@media (prefers-reduced-motion: reduce) {
.fog-layer {
animation-play-state: paused;
}
}
This preserves the background while removing its continuous movement.
Forms introduce a different kind of effort. International addresses can involve many fields—Pham mentions countries with as many as 12—and retyping information is rarely the user’s goal. The HTML autocomplete attribute supplies field meaning to the browser so it can offer autofill. Apply it throughout the form, not only to the address: the desired experience is as close as possible to one action filling the information the browser already knows.
Visual stability matters during those interactions. If a button moves just before a click, the user may activate something else. Avoiding layout shift protects the intended action. Progressive disclosure addresses cognitive load: the onboarding could have been one large form, but dividing it into three steps makes the work easier to approach. Neither choice removes the required information; both make completing it less demanding.
The fundamentals still apply beneath the visual treatment: give every input a label, use semantic HTML, and test with screen readers. A polished animation does not compensate for a form whose controls cannot be understood or operated.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the flow a memorable ending
The onboarding’s blues and greens are intentional. Pham describes them as part of an attempt to slow the user’s perception of time and counter the impulse to rush, while openly questioning whether the color psychology behind that choice is proven. The colors, fog and visual metaphors establish a deliberate pace around otherwise administrative work.
The flow ends by revealing a beautiful San Francisco scene. Pham invokes the peak-end bias: a strong final moment can shape how someone remembers the preceding experience. His design intent is for the reveal to leave a positive memory after the effort of onboarding; he does not present a measurement showing that it erases the earlier friction.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A camera illusion made from browser primitives
The next demonstration is the GPU purchasing page. Buyers choose a GPU type, an environment, a GPU count and a rental duration. Alongside those controls is the GPU habitat, introduced as a live camera feed showing where the GPUs live. Pham extends the joke: the machines get fresh air, sunlight and running water around the clock. As buyers change specifications, the apparent camera points toward the GPUs they are about to purchase.
The implementation reveal is much simpler than the fiction. The habitat uses stacked div elements, a small video and browser-native animation without third-party JavaScript. Pham favors this approach for speed, contrasting it with shaders and canvas; that is his rationale for this effect, not a measured comparison of rendering technologies. He also says the video should not loop for motion accessibility, although the construction demonstration uses a looping clip. The precise playback condition is not specified.
To understand the camera, start with the video itself. Its loop becomes visible in the water, which briefly appears to flow upward—prompting Pham’s suggestion that the habitat might be on a planet with reversed gravity. Next, draw a camera viewport over the scene. Moving the video behind that fixed window creates the apparent pan. An Easter egg exposes the mechanics, and zooming simply enlarges the same video inside the viewport.
The essential CSS is a clipping container plus a transformed video. Changing --pan-x, --pan-y and --zoom changes the framing without changing the media source:
css
.habitat-viewport {
position: relative;
overflow: hidden;
aspect-ratio: 16 / 9;
--pan-x: 0%;
--pan-y: 0%;
--zoom: 1;
}
.habitat-video {
display: block;
width: 100%;
height: 100%;
object-fit: cover;
transform-origin: center;
transform:
translate(var(--pan-x), var(--pan-y))
scale(var(--zoom));
}
.habitat-viewport[data-view="close-up"] {
--pan-x: -12%;
--pan-y: 8%;
--zoom: 1.6;
}
These illustrative framing values expose the mechanism: the window stays fixed while the image behind it moves and scales.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Help the buyer finish—and get a better price
The purchasing form supports completion through small, practical decisions:
- Defaults and recovery: Start with sensible configurations for common needs, then guide users out of mistakes so they can continue the purchase.
- Familiar units: Accept duration in days, hours or weeks. Someone who thinks in weeks should not have to perform a conversion before entering a rental period.
- Relevant feedback: Avoid loading states where possible. When a wait is necessary, the demonstration uses a GPU tensor-core visual that its technical audience may recognize and enjoy.
These details reduce the work around the purchase while keeping feedback connected to what the customer is doing.
Care also affects the transaction itself. Pham argues that helping customers can be worth more over time than maximizing immediate revenue. In his example, a buyer requests eight GPUs for one day, and the product finds a better price. SF Compute earns less on that sell order, while the customer saves money. The immediate tradeoff is explicit; the long-term revenue benefit is Pham’s rationale, with no measured uplift supplied.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let the pointer follow a natural path
The closing lightning round returns first to visual stability: if an application needs a banner, displaying it should not shift the interface underneath the user. Pham then moves to a nested menu he built at Vercel.
A naive nested menu changes the active item whenever the pointer enters another row. That creates a familiar failure: the user moves diagonally toward an open submenu, crosses a neighboring row on the way, and accidentally switches the submenu before reaching it. The interface effectively demands a precise route—across first, then down—instead of the direct movement the person intended.
The fix is a prediction cone. On hover, the menu establishes a region corresponding to the likely path toward the open submenu. Pointer movement through that region is interpreted in the context of the destination, rather than immediately treated as a request to switch rows. The user can move naturally into the submenu without tracing an awkward, exact path. The final demonstration makes the design principle tangible: a small implementation detail can remove a motor task the interface should never have imposed.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Definitions, measurement tools and field thresholds for LCP, INP and CLS.
Further reading
A user-centered framework separating response, animation, idle work and loading performance.
CSS examples for adapting animation to device motion preferences.
- Design Engineering at VercelArticle
How Vercel organizes design engineering, collaboration and ownership of polished product experiences.
An interview with Evan Conrad covering GPU markets, San Francisco imagery and the company's purchasing experience.
Read the complete timestamped transcript
- 0:00
[upbeat music] Okay.
- 0:15
So the thing I wanna talk about is basically, like even with the advent of like very good AI tools today, like the principles of good design hasn't really changed.
- 0:24
Uh, I've been building on the web for a while now, and I've built some pretty memorable and viral, uh, experiences. So today, I'm just gonna be sharing with you like what are the thought process and techniques that we use to build all of these experiences.
- 0:39
The first question is, I will give you a couple seconds to think about this, is what is design for you? Everyone w- everyone here w- will have a different answer to this, and that's perfectly fine.
- 0:48
Like design is a very human thing. There's no strict definition of this. What I'm gonna be doing is I'll, I'll be showing you what m- my perspective on is-- I will be sharing what my perspective on what design is.
- 1:02
Here's, here's like a leading question. Uh, again, I want you to answer the question what is design for yourself. You might be looking at this video, and then this might be like leading you on to like a very specific answer.
- 1:18
Okay. So in that video, there were a lot of very pretty things, but that isn't what design is. It's not the pretty pixels or like all of these fancy animations.
- 1:28
Design is also owned by everyone. If, if your title is not designer, you still own design. If you're building and shipping a product for people to use, you are part of the design process.
- 1:39
And another key thing is like human trends change month over month, year over w- year, uh, especially in AI, it changes day to day. But like good design doesn't change.
- 1:49
Like we've been building on the web for humans for a very long time, and like a lot of the common principles still, still, still apply to software today. Basically, design is how people experience your product.
- 2:02
And you might think of your product as like a very singular thing or if your company has multiple products, like those multiple things. But actually, like this includes every single touch point for your users.
- 2:13
This includes all of your UIs, your APIs, your API
- 2:17
e- e- e- error messages, all of your docs, your emails, your tweets. Anything where like a prospect or like a user interacts with, like that's part of your product.
- 2:26
And it basically boils down to like how does a user feel as they interact with all these, uh, surfaces.
- 2:33
Does-- Design affects how, how a user feel, so like does a user feel slow and scared or do, or do you want them f- or do you want them to feel fast and powerful?
- 2:46
Design decisions influence basically everything a user feels as they're interacting with all of your products.
- 2:54
In the age of AI, where prompt and vibe coding is like a very big thing now, like feature parity is no longer like a product differentiator. Like if you're just, if you're just shipping pr- features every single day, your competitors are also shipping features every single day.
- 3:07
So like those-- that's no longer a differentiator anymore. The key differentiator is like the very human thing, which is the everything that is a part of design.
- 3:16
In this talk, we'll walk through what my mental model is design is, and hopefully you guys take s- some stuff away from it. The four things w- we're gonna be talking about is speed.
- 3:28
What, what makes up speed is perceived time, feedback, and jank.
- 3:33
You can basically think of speed as like you want your product experiences to feel so fast where like the user does not feel slowed down by it.
- 3:41
Next thing is trust. Trust is, um, all of your products, products should be conveying its state, preventing errors or p- preventing errors, and, uh, provide all of the affordances.
- 3:54
A good, a good way to think of trust is your products never tell lie. It cares and forgives user mistakes.
- 4:03
The third one is accessibility. Part of accessibility is like your product should work for screen readers. Not everyone is fully capable, but these non-capable people still wanna use your products.
- 4:14
And other things to think about are contrast and also motion. We should basically build all of our products where everyone can use them because we're building products to be useful.
- 4:23
Ideally, this use- this usefulness is enjoyed by everyone.
- 4:27
And the very last thing is delight. This is my favorite because this is what truly makes like unique experiences enjoyable. And you can think of what goes into this as care, um, user rewards, and like the general story.
- 4:42
Uh, yeah. Experience-- Like delight basically contributes to like how a person will remember and also share your product's experiences.
- 4:52
If you want a takeaway, this is basically a summary. Like speed wins their first click, trust keeps them around, accessibility grows your total addressable market, and delight turns users into super fans.
- 5:06
Okay. Now, as you're building your product, this is like a actionable thing for you to do. Uh, this is your homework now. So after this ta-- after everyone's talks, I want you to look at your current product and see how you, how you are able to apply these four principles to them.
- 5:23
Let's walk through some examples now. Here's an example from my day job. I work at a company called San Francisco Compute company, and think of SF Compute as a cloud provider for GPUs.
- 5:34
One thing with being a cloud provider for GPUs in the US is we need to comply with US export laws, which means we can't sell GPUs to certain countries.
- 5:44
Uh, but a tricky thing with this is many people just view SF, SF Compute as a simple cloud provider. So when we ask them for information whi- which is required by law for us, they're like, "Why does a cloud provider nee- need my Social Security number?
- 5:57
Why do they need my address? These are weird things to provide to like a cloud provider."
- 6:01
This is like, this adds tremendous friction, but with using a bunch of design techniques, we're able to make the experience feel a lot lighter than, than, than what it actually is.
- 6:14
Let's walk through how we built the onboarding experience. Loading the website should feel super fast and actually be fast. So as you can see from Google and navigating to our onboarding experience, the page loads in under, like, it loads p- pretty much v- very fast.
- 6:31
I will quantify fast in a bit. So let's dig deeper into speed. The first paint happens in under three hundred milliseconds. Most humans can only perceive stuff in under four hundred milliseconds.
- 6:41
So if you're faster than that, your experiences will seem very fast. How do we do this? We server-side render a bunch of stuff, we cache as much as possible, and we minimize the bundle size, and basically all, all external assets that we ship to the page or we ship to the client.
- 6:58
All of the experiences are sixty, sixty FPS plus. So as you're browsing through the entire thing, like there's no stutters, it doesn't feel jank, it feels fluid.
- 7:09
And the last key part is the page is very small. Uh, every additional like megabyte you ship to the client, like there's a bunch of studies out there saying, "Hey, like this e-commerce website increased revenue by X percent by dropping their page's bundle size."
- 7:22
We basically take that to the extreme. We also do this because we want to like maximize the user experience. So like there are a bunch of user experiencing metrics that you are able to gamify, uh, or gamify for yourself.
- 7:36
You basically put your current score onto your scoreboard, and then it's your team's objective function to reduce that score. So these scores are like LCP, INP, and CLS.
- 7:47
Let's take a look at the full onboarding flow now. Uh, we lean heavily into the beauty of San Francisco for all of our design, and a big part of San Francisco is the fog.
- 7:56
For people who don't know about the fog, the fog visits the city pretty often. Uh, yeah. So how do you think this is made? How can we make it super fast?
- 8:05
How do we make it accessible for everyone?
- 8:08
One key part or one tricky part about this is the fog density is, is, is event-driven.
- 8:15
Okay, I'll give y'all five seconds to f- try-- I'll give y'all five seconds to try and figure out how we made this.
- 8:27
Here are some hints maybe, or deception. Here are some other things we also need to consider. Needs to be supported on every browser, needs to be sharp on retina screens, and it also should be super fast.
- 8:41
I'll show you how we did it. For the fog, let's start off with a single, uh, transparent image of a cloud. It doesn't quite look like a fog yet, but what if we zoom in?
- 8:52
It kind of looks, it, it kind of looks like the fog, but like it's missing like depth and motion, right? Uh, let's try animating it, animating it a bit.
- 9:03
Cool. It's moving now. It kind of looks like fog, but it's missing like liveliness, right? Like, it looks p- pretty static so far. Let's duplicate the image a couple times.
- 9:13
Let's offset all, all of the transforms. Let's change the opacity of a bunch of them, and let's v- let's make the speed variable for all of them.
- 9:20
Uh, that kind of looks like fog now.
- 9:25
Oh, and then for the event-driven like fog density, you basically are able to control that by changing the opacity and also changing the number of layers of the stacked image.
- 9:35
So with that very complex effect, we were able to get all that done with one single image. This image is fourteen kilobytes, very small.
- 9:44
And all of this doesn't require any third par- third-party JavaScript. The additional JavaScript you add, it just makes your page a lot slower. [siren]
- 9:55
Okay. Let's talk about trust now. Expectat- expectation setting is p- pretty important.
- 10:03
Most people don't like onboarding experiences. Like I know for me personally, every onboarding experience, I try to speed run it. Like it's my mission to get through this as fast as possible.
- 10:11
For this one, we cannot make you go through this fast because we are legally required to collect some information. So, so the way we do this is we basically t- tell you saying, "Hey, this will take three steps, and this will take u- under a minute."
- 10:25
Uh, this reassures the user that this won't be a time drain, and it will be super fast.
- 10:30
Expectations are updated, so c- creating a business account requires one additional step. So if they choose that option, we tell them saying, "Hey, this is gonna take an extra step."
- 10:41
And as a user progresses through onboarding, progress is updated, and this is kind of like a gamification thing, where like if a user sees that, hey, I'm halfway through this, they are like, there's like an, a-- there's like a endowment effect where they're like, "I want to finish this now."
- 10:57
Here's another part of onboarding. Uh, for right now, we require onboarding cards with onboard, onboarding calls for all of our, uh, users. Most engineers who use our product hate onboarding calls.
- 11:07
They don't wanna talk to sales. One way to get around this is we set, uh, we set expectations. We say, "Hey, this is not a sales call. We will not try and sell you anything.
- 11:17
We-- You will be talking to all of our engineers f- for us to be able to qualify you." This is a moment where like we will listen to you, and if it turns out that SF Compute isn't the right partner for you, we will say, "Hey, here are other, here are our, our other friends.
- 11:31
They are a way better fit for you."
- 11:34
Uh, picking a time is also like, uh, like a high-friction thing. So like instead of requiring all of our users to like manually pick a calendar date and time, we pick one for them.
- 11:43
If it doesn't work for them, that's when the user has to opt into like a higher, uh, higher complexity of like actually picking, picking the time for themselves.
- 11:53
This one's a dicey thing. Like all times should be in local time zones, but sometimes it's in UTC, sometimes in, sometimes it's in, sometimes it's in EST. We should just be straightforward and say, "Hey, this is in your time zone," and also reaffirm that.
- 12:08
Okay, last one. Ex-- or no, third one, accessibility. We have this animated looping thing, uh, that represents the fog in the background. Uh, some people for, like, repeated motion on the web, it can make them feel very sick.
- 12:23
Very sick to the point where they vomit. I don't think vomiting or, like, the number of people who vomit during your product experience is a KPI that you want to increase. [laughing]
- 12:32
So, uh, for most platforms, there's this preference called reduced motion, and users are able to say, "Hey, when I'm browsing the web, I do not want a- any motion because if there is motion, I will vomit."
- 12:44
We should respect this preference. So whenever we see this preference, we basically just pause all animations.
- 12:53
Another thing, uh, filling out addresses is, like, kind of hard, especially if you're not in the US. Like, some countries have, like, 12 different fields. We make this super fast by, by being able to au-auto-complete stuff as much as possible.
- 13:06
Uh, this doesn't just apply to our address fields. This applies to pretty much every single form input. Uh, ideally, a user is able to click a single button, and it fills out the entire form.
- 13:16
Uh, we're able to do this, do this because on the web, there's an input attribute called auto-complete. If you set this, the browser will, will be able to fill out a lot of the form for you.
- 13:28
Another thing is layout shift. Have you ever gone to a website, and then you went to click a button, and right before you click the button, the button moves, and then you end up clicking something else?
- 13:36
We don't want that, so no layout shifts.
- 13:40
And, and the last thing is, like, uh, progressive disclosure. Uh, our onboarding form was like three steps. It could have been one giant step, but, like, this is actually a d- conscious design.
- 13:50
This is a conscious design decision. We want to reduce the cognitive load as a user g-goes through the onboarding. So by reducing the load, r-by reducing the cognitive load, it makes the form seem a lot easier than what it actually is.
- 14:05
And the last couple things for accessibility. Every input should have a form labe-label. You should be using semantic HTML, and you should also test with screen readers.
- 14:15
Now the fun part, delight. Okay. Uh, yeah. Um, all, all of the colors picked here are, like, intentionally. Like, there's some psychology, proven or not, who knows, uh, which basically, like, slows down a person's p-perception of time.
- 14:31
So, like, all of the blues and greens, they were purposely built. Most users want to speed through onboarding, so, like, we basically use a bunch of metaphors and devices to, like, slow them down.
- 14:41
And, and the last thing is the onboarding experience, uh, uses a human bias called, like, the peak-end psychological bias. So we end the onboarding experience by, like, revealing a beautiful scene of San Francisco.
- 14:52
So when they end, they only remember this. Like, all of the hardship that they just went through, like, it kind of disappears. [laughing]
- 15:02
Okay. Another thing I wanna show off today is our buying a GPU. Uh, let's walk through it. This is basically the page that lets you buy a supercomputer. You get to pick what type of GPU you want.
- 15:13
You get to pick what type of environment it is. You get to pick the number of GPUs, and you get to pick how long you want it. The cool thing I wanna focus on is our GPU habitat.
- 15:23
Uh, this is where all of our GPUs live, and this is a live camera feed into, like, the GPUs.
- 15:31
Our GPUs are kept inside of this environment. They get access to fresh air, sunlight, and running water twenty-four seven. [laughing]
- 15:38
We use this video feed as a way to show buyers the exact GPUs that they're about to buy. So as they're ch-changing all of their specs, um, the live camera feed points them to the exact GPUs that they're about to buy.
- 15:51
Okay, how would you make this? Any ideas? Here's a hint.
- 15:59
Any ideas yet? How about now? It's just a bunch of stacked divs because stacked divs are very fast on the web. Shaders, canvas, those things are very slow.
- 16:13
So, uh, the video is like a looping video. It's very small, and it's v-very fast to stream.
- 16:21
All of the animations are just using browser primitives, so there's no third-party JavaScript. Again, with looping motion, we do not want people to vomit, so we do not loop the video.
- 16:32
Okay, how does the panning work? How do you think it works? So like this as it z-zooms around the GPU habitat.
- 16:42
Okay, let's first start with a looping video. If you look closely at the water, you should be able to see when, when the video loops. Uh, water should flow downwards, not upwards, but maybe this-- maybe the habitat's on a different planet where gravity is inverse.
- 16:56
Okay, let's first draw the, um, let's first draw the camera viewport.
- 17:01
Let's move the video around in the background. This is basically how, how the GPU, uh, live camera feed works.
- 17:10
Uh, yeah. There's also an Easter egg. So this gives you, like, a good understanding of, like, how, how, like, the camera mechanics work.
- 17:20
So, like, a user is able to zoom in. This is just zooming in in that video, and then the panning is just, like, translating that video around, around inside of the viewport.
- 17:31
Uh, another one. Uh, we wanna make it super fast to fill out a form, so, like, y- most of our users have pretty sane defaults, and we also wanna guide them.
- 17:38
Uh, whenever a user makes a mistake, we want to nudge them outside that mistake easily, so then they're able to buy a GPU.
- 17:47
Uh, another one. Um, some people buy, um, some buyers of GPUs, they think in different units. We don't think it's, it's a good idea to, like, force them to convert their units.
- 17:57
Some people think in days, some people think in hours, some people think in weeks. We should be able to allow anyone to be, anyone to be able to buy this without having to do, like, a bunch of m-mental calculations inside their head.
- 18:09
Does anyone know what this is? Uh, we have loading states. Ideally, we have zero loading states, but for some parts of our application, we are required to have loading states.
- 18:17
Uh, this is a loading state for like a GPU to tensor core. So like for people who are buying like GPUs, they probably know what this is, and when they see it, they're like, "That's cool."
- 18:28
Uh, another thing, uh, we're not maximizing revenue because we think we should c- c- actually show care for our users, and by showing care, it-- by showing care, we actually increase revenue on, on the long-term horizon.
- 18:41
So here, a user is saying, "Hey, I want, I want eight GPUs for a day," but like we were actually able to find them a better price. Because we found them a better price, on the sell order, we actually make less money, but like it's saving the user money.
- 18:52
Like w- we highly value that. Okay, I have twenty-seven seconds, I think. Lightning round. So yeah. Uh, banners. Who hates banners? Banners also cause layout shift.
- 19:08
If your app needs a banner, do not render... Do not cause layout shift. Okay, I'll, I'll skip to the last one, which is the most fun one. Okay, so this one I built at, this one I built at, at a company called Vercel, and it's basically like a
- 19:24
n- nested menu. Uh, most nested menus are kind of hard to use. Like a user basically wants to do this, right? But in actuality, when, when they try to do this with like a, with a naive implementation, it doesn't work out because it like switches over.
- 19:40
How do you, how do you fix this? There's this fancy thing called a prediction cone. Where is it?
- 19:47
Oh, over here. Prediction cone. Play. So as you hover, we basically generate or like in-- we basically generate like a prediction cone, which basically maps to like a user's intent.
- 19:58
So like instead of a user having to do that janky like super precise
- 20:04
pointer flow, they're able to use this as if or as if it felt, felt super natural for them. Uh, but yeah, that's pretty much all for my talk. I hope you enjoyed.
- 20:14
Thank you so much. [clapping] [upbeat music]