Good design hasn’t changed with AI

Talk transcript

1. 0:00

   [upbeat music] Okay.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 2:13

    This includes all of your UIs, your APIs, your API

13. 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.

14. 2:26

    And it basically boils down to like how does a user feel as they interact with all these, uh, surfaces.

15. 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?

16. 2:46

    Design decisions influence basically everything a user feels as they're interacting with all of your products.

17. 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.

18. 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.

19. 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.

20. 3:28

    What, what makes up speed is perceived time, feedback, and jank.

21. 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.

22. 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.

23. 3:54

    A good, a good way to think of trust is your products never tell lie. It cares and forgives user mistakes.

24. 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.

25. 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.

26. 4:23

    Ideally, this use- this usefulness is enjoyed by everyone.

27. 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.

28. 4:42

    Uh, yeah. Experience-- Like delight basically contributes to like how a person will remember and also share your product's experiences.

29. 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.

30. 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.

31. 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.

32. 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.

33. 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?

34. 5:57

    Why do they need my address? These are weird things to provide to like a cloud provider."

35. 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.

36. 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.

37. 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.

38. 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.

39. 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.

40. 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."

41. 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.

42. 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.

43. 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.

44. 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?

45. 8:05

    How do we make it accessible for everyone?

46. 8:08

    One key part or one tricky part about this is the fog density is, is, is event-driven.

47. 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.

48. 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.

49. 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?

50. 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.

51. 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.

52. 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.

53. 9:20

    Uh, that kind of looks like fog now.

54. 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.

55. 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.

56. 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]

57. 9:55

    Okay. Let's talk about trust now. Expectat- expectation setting is p- pretty important.

58. 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.

59. 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."

60. 10:25

    Uh, this reassures the user that this won't be a time drain, and it will be super fast.

61. 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."

62. 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."

63. 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.

64. 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.

65. 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.

66. 11:31

    They are a way better fit for you."

67. 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.

68. 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.

69. 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.

70. 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.

71. 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]

72. 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."

73. 12:44

    We should respect this preference. So whenever we see this preference, we basically just pause all animations.

74. 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.

75. 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.

76. 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.

77. 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?

78. 13:36

    We don't want that, so no layout shifts.

79. 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.

80. 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.

81. 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.

82. 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.

83. 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.

84. 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.

85. 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]

86. 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.

87. 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.

88. 15:23

    Uh, this is where all of our GPUs live, and this is a live camera feed into, like, the GPUs.

89. 15:31

    Our GPUs are kept inside of this environment. They get access to fresh air, sunlight, and running water twenty-four seven. [laughing]

90. 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.

91. 15:51

    Okay, how would you make this? Any ideas? Here's a hint.

92. 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.

93. 16:13

    So, uh, the video is like a looping video. It's very small, and it's v-very fast to stream.

94. 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.

95. 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.

96. 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.

97. 16:56

    Okay, let's first draw the, um, let's first draw the camera viewport.

98. 17:01

    Let's move the video around in the background. This is basically how, how the GPU, uh, live camera feed works.

99. 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.

100. 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.

101. 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.

102. 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.

103. 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.

104. 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.

105. 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.

106. 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."

107. 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.

108. 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.

109. 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.

110. 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

111. 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.

112. 19:40

     How do you, how do you fix this? There's this fancy thing called a prediction cone. Where is it?

113. 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.

114. 19:58

     So like instead of a user having to do that janky like super precise

115. 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.

116. 20:14

     Thank you so much. [clapping] [upbeat music]