Good design hasn’t changed with AI — John Pham, SF Compute

Channel: aiDotEngineer

Published at: 2025-07-21

YouTube video id: 7e7eVtcygCM

Source: https://www.youtube.com/watch?v=7e7eVtcygCM

[Music]
Okay. So, the thing I want to 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.
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 going to be sharing with
you like what are the thought process
and techniques that we use to build all
of these experiences.
The first question is I will give you a
couple seconds to think about this is
what is design for you? Everyone
everyone here will have a different
answer to this and that's perfectly
fine. Like design is a very human thing.
There's no strict definition of this.
What I'm going to be doing is I'll I'll
be sharing you what my perspective on is
I will be sharing what my perspective on
what design is.
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.
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.
Design is also owned by everyone. If if
your title is not a designer, you still
own design. If you're building and
shipping a product for people to use,
you are part of the design process.
And another key thing is like human
trends change month over month, year
over year. uh especially in AI changes
dayto day but like good design doesn't
change 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 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
this includes all of your UIs your AP
API, your API
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.
And it basically boils down to like how
does a user feel as they interact with
all these uh surfaces.
Does
design affects how how a user feel? So,
like, does a user feel slow and scared
or do or do you want them or do you want
them to feel fast and powerful?
Design decisions influence basically
everything a user feels as they're
interacting with all of your products.
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 features
every single day, your competitors are
also shipping features every single day.
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.
In this talk, we'll walk through what my
mental model is design is and hopefully
you guys take some stuff away from it.
The four things we're going to be
talking about is speed.
What what makes up speed is perceived
time, feedback and jank.
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.
Next thing is trust.
Trust is um all of your products
products should be conveying its state
preventing errors preventing errors and
uh provide all of the affordances.
A good a good way to think of trust is
your products never tell lie. It cares
and forgives user mistakes.
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 want to use
your products. 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. Ideally, this use this
usefulness is enjoyed by everyone.
And the very last thing is the light.
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, user rewards,
and like the general story.
Uh yeah, experience like delight
basically contributes to like how a
person will remember and also share your
product's experiences.
If you want a takeaway, this is
basically a summary. Like speed wins
their first click, trust keeps them
around, accessibly grows your total
addressable market, and delight turns
users into super fans.
Okay. Now, as you're building your
product, this is like an actual thing
for you to do. Uh this is your homework
now. So after this talk, after
everyone's talks, I want you to look at
your current product and see how how you
are able to apply these four principles
to them. 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
SFMP compute as a cloud provider for
GPUs.
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. Uh but a
tricky thing with this is many people
just view s of s of compute as a simple
cloud provider. So when we ask them for
information which is required by law for
us they're like why does a cloud
provider need need my social security
number? Why do they need my address?
These are weird things to provide to
like a cloud provider. 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.
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 pretty much very
fast. I will quantify fast in a bit. So
let's dig deeper into speed. The first
paint happens in under 300 milliseconds.
Most humans can only perceive stuff in
under 400 milliseconds. 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.
All of the experiences are 60 60 fps
plus. So as you're browsing through the
entire thing, like there's no stutters.
It doesn't feel jank. It feels fluid.
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 increase revenue by x% by
dropping their pages bundle site. 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 or
gamify for yourself. 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.
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. 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? How do we make it accessible
for everyone?
One key part or one tricky part about
this is the fog density is is is event
driven.
Okay, I'll give y'all five seconds to
try I'll give y'all five seconds to try
and figure out how we made this.
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 of the screens and it also should
be super fast. 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? It kind of looks
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.
Cool. It's moving now. It kind of looks
like fog, but it's missing like
liveless, right? Like looks pretty
static so far. Let's duplicate the image
a couple times. Let's offset all all of
the transforms. Let's change the opacity
of a bunch of them. And let's let's make
the speed variable for all of them. Uh
that kind of looks like fog now.
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. So with that very
complex effect, we were able to get all
of that done with one single image. This
image is 14 kilobytes. very small
and all of this doesn't require any
third part third party JavaScript. The
additional JavaScript you add it just
makes your page a lot slower.
Okay, let's talk about trust. Now
expectation setting is pretty important.
Most people don't like onboarding
experiences. Like I know for me
personally, every onboarding experience
I try to speedrun it. Like it's my
mission to get through this as fast as
possible. 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 tell you saying, hey,
this will take three steps and this will
take under a minute. Uh, this reassures
the user that this won't be a time drain
and it will be super fast.
Expectations are updated. So, creating a
business account requires one additional
step. So, if they choose that option, we
tell them saying, "Hey, this is going to
take an extra step."
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,
here's another part of onboarding. Uh
for right now, we require onboarding
cards for onboard onboarding calls for
all of our uh users. Most engineers who
use our product hate onboarding calls.
They don't want to talk to sales. One
way to get around this is we set we set
expectations. We say, "Hey, this is not
a sales call. We will not try and sell
you anything. We you will be talking to
all of our engineers 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 compute isn't the right
partner for you, we will say, "Hey, here
are other here are our other friends.
They are a way better fit for you."
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. 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.
This one's a dicey thing like all time
should be in local time zones, but
sometimes it's in UTC, sometimes in
sometimes in sometimes it's in EST. We
should just be straightforward and say,
"Hey, this is in your time zone." And
also reaffirm that
Okay, last one. Oh 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. 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.
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 any
motion because if there is motion I will
vomit. We should respect this
preference. So
whenever we see this preference we
basically just pause all animations.
Another thing uh filling out an address
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 autocomplete stuff as much as
possible.
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. Uh
we're able to do do this because on the
web there's an input attribute called
autocomplete. If you set this the
browser will will be able to fill out a
lot of the form for you. 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.
We don't want that. So no layout shifts.
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 conscious design a
conscious design decision. We want to
reduce the cognitive load as a user goes
through the onboarding. So by reducing
the load, by reducing the cognitive
load, it makes the form seem a lot
easier than what it actually is.
And a last couple things for
accessibility. Every input should have a
form label. You should be using semantic
HTML. And you should also test with
screen readers.
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 perception of
time. 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. 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. So
when they end, they only remember this
like all of the hardship that they just
went through like it kind of disappears.
Okay. Another thing I want to show off
today is our buying a GPU. Uh let's walk
through it. This is basically the page
that lets you buy a supercomput.
You get to pick what type of GPU you
want. 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 want
to focus on is our GPU habitat. Uh this
is where all of our GPUs live. And this
is a live camera feed into like the
GPUs.
Our GPUs are kept inside of this
environment. They get access to fresh
air, sunlight, and running water 247.
We use this video feed as a way to show
buyers the exact GPUs that they're about
to buy. So, as they're changing all
their specs and the live camera feed
points them to the exact GPUs that
they're about to buy.
Okay. How would you make this?
Any ideas? Here's a hint.
Any ideas yet?
How about now?
It's just a bunch of stack divs because
stack divs are very fast on the web.
Shaders, canvas, those things are very
slow.
So, uh, the video is like a looping
video. It's very small and it's very
fast to stream. 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.
Okay. How does the penning work? How do
you think it works? So like this as it
zooms around the GPU habitat.
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.
Okay, let's first draw the u let's first
draw the camera viewport.
Let's move the video around in the
background. This is basically how how
the GPU uh live camera feed works.
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.
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.
Uh, another one, uh, we want to make it
super fast to fill out a form. So, like
most of our users have pretty sane
defaults and we also want to guide them.
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.
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. 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 mental calculations
inside of their head.
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. 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.
Uh another thing uh we're not maximizing
revenue because we think we should
actually show care for our users and by
showing care it by showing care we
actually increase revenue on on the
long-term horizon. 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 sale
order. We actually make less money but
like it's saving the user money. like we
highly value that.
Okay, I have
27 seconds I think. Lightning round. So
yeah. Uh banners. Who hates banners?
Banners also cause layout shift. If your
app needs a banner, do not render. Do
not cause layout shift. Okay, I'll I'll
script 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
Versail and it's basically like a
nested menu. Uh most nest and 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. How do
you how do you fix this? There's this
fancy thing called a prediction cone.
Where is it?
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. So like instead of
a user having to do that janky like
super precise
pointer flow, they're able to use this
as if or as if it felt felt supernatural
for them. Uh but yeah, that's pretty
much all for my talk. I hope you
enjoyed. Thank you so much.
[Music]