Season 4

|

Episode 7

Systems thinking for product designers

Ryo Lu

Product designer @ Notion

Feb 1, 2024

Feb 1, 2024

|

32 mins

32 mins

music by Dennis

About this Episode

In this episode we get to hear from Ryo Lu who was one of the very first designers at Notion. This conversation is an inside look at the Notion design process, how they think about product, and a lot more:

  • How Notion approached the user research process for AI

  • Strategies for improving your systems thinking

  • How design at Notion sources feedback on meaty problems

  • How Notion thinks about their design system

  • What Ryo is looking for in your portfolio

  • How to operate outside the traditional โ€œdesignโ€ role

Share on Twitter
Share on Twitter
Share on LinkedIn
Share on LinkedIn

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers ๐Ÿ‘‡

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Free lessons from ๐Ÿ‘‡

Lauren LoPrete

Lead designer @ Netflix

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers ๐Ÿ‘‡

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Transcript chapters

[00:00:00] Experimenting with AI in Notion

Ryo: What actually really kicked this off was, Simon, Ivan, and a bunch of people were just kind of prototyping AI stuff. It kind of clicked, like, this thing can help us solve so many different problems that our users already have. And then you're thinking about how do we package up all of these technologies and concepts in a way that's familiar to people, that's useful. That also fits with the rest of Notion's building blocks. How we think about AI is almost like we're designing, like, AI is almost like a building block of Notion, but also is like a horizontal system primitive., it needs to know, you know, how to interact with all the things we have. But also, like any other Notion primitive, we allow you to customize the shit out of it.

[00:00:00] Experimenting with AI in Notion

Ryo: What actually really kicked this off was, Simon, Ivan, and a bunch of people were just kind of prototyping AI stuff. It kind of clicked, like, this thing can help us solve so many different problems that our users already have. And then you're thinking about how do we package up all of these technologies and concepts in a way that's familiar to people, that's useful. That also fits with the rest of Notion's building blocks. How we think about AI is almost like we're designing, like, AI is almost like a building block of Notion, but also is like a horizontal system primitive., it needs to know, you know, how to interact with all the things we have. But also, like any other Notion primitive, we allow you to customize the shit out of it.

[00:00:48] Why UX research for AI tools is unique

Ridd: Can you talk a little bit about the role of user research in this project did it differ from the way that you typically approach projects in Notion, given the fact that it isn't just like this new isolated feature, but you are introducing this primitive layer that touches kind of everything in the product.

Ryo: User research for AI is especially interesting because it's a new world almost that we're entering in. It breaks a lot of assumptions with existing, , ways of thinking about building products

and then people AI into their products. I think., you know, most people start with, I don't know, slap on a chatbot next to your thing. And then it doesn't really still interact with the stuff that you have already. It doesn't really fit with the concepts you have.

It doesn't really fit with, you know, all the problems your users already have., and then user research almost, can give us more clarity. And a lot of, like, problems. Say, like, what is useful, valuable, what's important how do we prioritize different, , ways we can utilize AI to help people?

What are the biggest pain points people really need help with that AI can help solve? User research help with a lot of, more like tactical problems, like, how do we price this thing? It can also help you, you know, build more of these feedback loops. , I think the more of these loops you have, the better. It also doesn't have to be, you know, pure, , interview based user research or, just plain surveys. You can build a lot of, like, feedback mechanisms in your product itself, and then they all kind of act as input.

Ridd: If you think about the different tactics that you might use for research, like maybe you're doing live calls or feature flagging or surveys or something like that, which tactics were the most impactful for this project? And maybe there's even some like specific learnings or takeaways that influence the way that you thought about the rollout strategy for AI.

Ryo: One example would be, I think there is a lot of nuance around how much you want to kind of, say, label , what is the AI output. Or, how much human approval is needed. Or, how do you want to, , show people that, say, AI might make mistakes sometimes. For different kinds of things people do in Notion, or in general when they work.

There's like different levels of acceptance in terms of How much freedom you want to give the AI? How much disclosure do you want to give to people that something is generated by AI? , and then it's almost like for every single segment of users, there's different answers.

So we ran a lot of, , like multiple surveys to kind of collect all of these different patterns of people's usage, and then you can kind of design different solutions for those people in different points in the spectrum.

Some people are, they're more Early adoptery, more accepting technology type of people. But then there are also people who are really scared of AI. They don't really know what it is.

Why would they even want to buy this? What's the point? You kind of want to figure out what these different people need. And then you design a mechanism to , build more trust, give people more transparency in what the AI does. Make people feel like they know what's happening, and they're not really, scared or threatened by this technology.

Because the thing is so new and everything is kind of evolving, there's new things popping up every time. It's really important to keep building and prototyping and trying things. Because it's so new, I don't think , we need, really strong conviction from this group of people that okay, great, they like it, and then we ship it.

It's more like, we want to kind of discover , where people land in the spectrum, what do they need. Different kinds of people, different kinds of level of acceptance, and then we design the system that covers most of those

[00:00:48] Why UX research for AI tools is unique

Ridd: Can you talk a little bit about the role of user research in this project did it differ from the way that you typically approach projects in Notion, given the fact that it isn't just like this new isolated feature, but you are introducing this primitive layer that touches kind of everything in the product.

Ryo: User research for AI is especially interesting because it's a new world almost that we're entering in. It breaks a lot of assumptions with existing, , ways of thinking about building products

and then people AI into their products. I think., you know, most people start with, I don't know, slap on a chatbot next to your thing. And then it doesn't really still interact with the stuff that you have already. It doesn't really fit with the concepts you have.

It doesn't really fit with, you know, all the problems your users already have., and then user research almost, can give us more clarity. And a lot of, like, problems. Say, like, what is useful, valuable, what's important how do we prioritize different, , ways we can utilize AI to help people?

What are the biggest pain points people really need help with that AI can help solve? User research help with a lot of, more like tactical problems, like, how do we price this thing? It can also help you, you know, build more of these feedback loops. , I think the more of these loops you have, the better. It also doesn't have to be, you know, pure, , interview based user research or, just plain surveys. You can build a lot of, like, feedback mechanisms in your product itself, and then they all kind of act as input.

Ridd: If you think about the different tactics that you might use for research, like maybe you're doing live calls or feature flagging or surveys or something like that, which tactics were the most impactful for this project? And maybe there's even some like specific learnings or takeaways that influence the way that you thought about the rollout strategy for AI.

Ryo: One example would be, I think there is a lot of nuance around how much you want to kind of, say, label , what is the AI output. Or, how much human approval is needed. Or, how do you want to, , show people that, say, AI might make mistakes sometimes. For different kinds of things people do in Notion, or in general when they work.

There's like different levels of acceptance in terms of How much freedom you want to give the AI? How much disclosure do you want to give to people that something is generated by AI? , and then it's almost like for every single segment of users, there's different answers.

So we ran a lot of, , like multiple surveys to kind of collect all of these different patterns of people's usage, and then you can kind of design different solutions for those people in different points in the spectrum.

Some people are, they're more Early adoptery, more accepting technology type of people. But then there are also people who are really scared of AI. They don't really know what it is.

Why would they even want to buy this? What's the point? You kind of want to figure out what these different people need. And then you design a mechanism to , build more trust, give people more transparency in what the AI does. Make people feel like they know what's happening, and they're not really, scared or threatened by this technology.

Because the thing is so new and everything is kind of evolving, there's new things popping up every time. It's really important to keep building and prototyping and trying things. Because it's so new, I don't think , we need, really strong conviction from this group of people that okay, great, they like it, and then we ship it.

It's more like, we want to kind of discover , where people land in the spectrum, what do they need. Different kinds of people, different kinds of level of acceptance, and then we design the system that covers most of those

[00:05:01] Why systems thinking is so important for designers

Ridd: My assumption is like, you're designing for such a wide spectrum of like, you know, power users on one hand, all the way to people who are basically just using notion as like a glorified word document and AI just really increases the ceiling for those power users in a way that probably significantly broadened the spectrum of personas that you are designing for. How do you even approach something like that as a designer thinking about these different types of users and the different capabilities that they would be looking for, while also, you know, like preserving that simplicity for the people who maybe are just kind of using a

Ryo: Yeah.

Ridd: rudimentary way, almost.

Ryo: We started mostly from the systems side. It's like, we build the building blocks bit by bit in a way that everything is, you know, fits together pretty well. There's very few number of concepts, but then it almost does a lot of things. It's almost like there's two ways of designing, .

One way is you design the system. Ideally, the system has the fewest parts that does the most things you want. , the other way is , you design more, typical SAS companies. Or, where it's like, they have this group of users, this set of problems. You design specific solutions for those problems.

It's like the default mode for a lot of designers when they work on problems is they want to kind of okay, let's focus on this one problem and then make a really really good solution for that. And then we add all the delight and all the crazy craft on top of it. They focus on this thing, they come up with like a, Ideal single model that does everything within that bubble. But I do think for a , more general purpose tool like Notion. One single model doesn't really fit with everyone. It's almost like the only way to do it is with a generalizable system that ideally most people can understand. And then we need to kind of make every level that simple. Both, like, on the conceptual level, and all the things that Tie things around, like how you navigate, how you file things, how you create things, how you search for things. We want the thing to feel as good as a single purpose tool, like all the craft, all the speed, all the delight, whatever you call it, can still exist.

But also the power, the flexibility. The building blocks can also exist and then you need to kind of figure out a way to fit everything together.

When Notion started, it was mostly, , system thinking, building the blocks, but then when people kind of click and figure out how to use these building blocks to do the things they want, they fall in love with the tool.

Because they, it gives them so much power, and then they can create the things they want without, you know, asking the, support team, please build this feature for me. When you're building a product that serves so many different groups of users, so many different use cases, you can't think in one way or the other way. You need to come up with good systems to tie up all this, different people's needs, people's mental models of how their tools work. Different variations of doing, say, project management. But then it's like still kind of built with the same ideas, primitives, building blocks.

You can't build single purpose features in Notion and try to slap it on top of it. Because it will make the systems more complex. How we're thinking about how to solve these problems is we build systems to kind of wrap these,, different use cases up.

So that you get the things you want without understanding how the blocks works. We want to kind of Give people what they want in the way that feels the most familiar and easy. But still, having everything built with the blocks that are flexible. And then AI can also be this middle layer.

Because once we, say, teach AI how to think about the notion structures and the stuff you have, it can help you figure out, how to set and set them up better, what are the different features you might need, so you don't have to really think about it.

[00:05:01] Why systems thinking is so important for designers

Ridd: My assumption is like, you're designing for such a wide spectrum of like, you know, power users on one hand, all the way to people who are basically just using notion as like a glorified word document and AI just really increases the ceiling for those power users in a way that probably significantly broadened the spectrum of personas that you are designing for. How do you even approach something like that as a designer thinking about these different types of users and the different capabilities that they would be looking for, while also, you know, like preserving that simplicity for the people who maybe are just kind of using a

Ryo: Yeah.

Ridd: rudimentary way, almost.

Ryo: We started mostly from the systems side. It's like, we build the building blocks bit by bit in a way that everything is, you know, fits together pretty well. There's very few number of concepts, but then it almost does a lot of things. It's almost like there's two ways of designing, .

One way is you design the system. Ideally, the system has the fewest parts that does the most things you want. , the other way is , you design more, typical SAS companies. Or, where it's like, they have this group of users, this set of problems. You design specific solutions for those problems.

It's like the default mode for a lot of designers when they work on problems is they want to kind of okay, let's focus on this one problem and then make a really really good solution for that. And then we add all the delight and all the crazy craft on top of it. They focus on this thing, they come up with like a, Ideal single model that does everything within that bubble. But I do think for a , more general purpose tool like Notion. One single model doesn't really fit with everyone. It's almost like the only way to do it is with a generalizable system that ideally most people can understand. And then we need to kind of make every level that simple. Both, like, on the conceptual level, and all the things that Tie things around, like how you navigate, how you file things, how you create things, how you search for things. We want the thing to feel as good as a single purpose tool, like all the craft, all the speed, all the delight, whatever you call it, can still exist.

But also the power, the flexibility. The building blocks can also exist and then you need to kind of figure out a way to fit everything together.

When Notion started, it was mostly, , system thinking, building the blocks, but then when people kind of click and figure out how to use these building blocks to do the things they want, they fall in love with the tool.

Because they, it gives them so much power, and then they can create the things they want without, you know, asking the, support team, please build this feature for me. When you're building a product that serves so many different groups of users, so many different use cases, you can't think in one way or the other way. You need to come up with good systems to tie up all this, different people's needs, people's mental models of how their tools work. Different variations of doing, say, project management. But then it's like still kind of built with the same ideas, primitives, building blocks.

You can't build single purpose features in Notion and try to slap it on top of it. Because it will make the systems more complex. How we're thinking about how to solve these problems is we build systems to kind of wrap these,, different use cases up.

So that you get the things you want without understanding how the blocks works. We want to kind of Give people what they want in the way that feels the most familiar and easy. But still, having everything built with the blocks that are flexible. And then AI can also be this middle layer.

Because once we, say, teach AI how to think about the notion structures and the stuff you have, it can help you figure out, how to set and set them up better, what are the different features you might need, so you don't have to really think about it.

[00:09:16] How Ryo sources feedback from the Notion team

Ridd: I want to talk a little bit more about how you defined that middle layer of AI in design. And. Ideally, even like kind of put listeners in the room with you, like kind of let us be like a fly on the wall because my assumption is that, you know, at some point you're going off, you're exploring things and then you are giving some kind of crit environment or presentation or sharing some of your thoughts and maybe it's like that first or second big milestone in the AI project. Can you tell us that story and maybe even specifically talk about , what are you bringing to the table for that meeting? Like, what are you actually showing as a designer? What are you hoping to achieve in that meeting? And , ultimately, , what are some of the strategies that you're using to drive alignment and provide more clarity for what that middle layer can actually become

Ryo: I feel like for certain kinds of problems, like an in person crit of like 30 minutes just won't do it. When things get into like this system's conceptual land almost, because it touches so many different things, you need to kind of put all your thoughts down in a really clear way for people. And then how we usually do it is we just write docs in Notion. And then usually those docs kind of show people how you reason about the problems. What is maybe like the high level system you are trying to design. How do different concepts connect with each other. Maybe you list out different options for the solutions. And then you kind of think about each of the options, pros and cons, try to compare them. You kind of, , supplement that thinking with pictures. That could be like, Figma artboards, link previews in Notion. It could be, random drawings that you've done in a whiteboard.

And then, you need to get a lot of people in there. Not just designers. Maybe European partners, but also like maybe Engineers, people are thinking about how to architect the technical designs. And then people come in and people leave comments, and people start conversations and discussions on specifics of that doc.

And then, We just try to kind of mix all these things back in, do more loops, get more feedback from more people, do more loops, and then try to kind of share all these ideas out.

In a way that is, not just, the designers talking about this. Tiny little visual details, but how do we, wrangle Notion up so that things get clearer and simpler, but also more flexible in some sense.

Ridd: I I've worked in similar environments where a lot of things are happening in a notion document, and I'm kind of trying to break down this project into like different initiatives with maybe sub directions within that initiative. And like very clear using like the call out block is one of my favorite ones for these types of, of documents.

I think a struggle that I've encountered a lot of times with doing things entirely async is the pace. And getting people to actually weigh in on the things that matter. And if I'm doing a loop, my God, sometimes those loops take too long. And like, then you have some upper level person that swoops in like four days later after you think you already have alignment.

So can you talk a little bit about how you steward this async feedback process as a designer and ensure that you're getting the answers you need and preserving the inertia of the project?

Ryo: I also think it's like just doing async is not enough, but it is good to kind of capture your ideas down and all people's thoughts in a more open environment. Anyone can come in and, , jot their ideas down, give feedback, but when When you want to, say, make more decisions, where you want to start refining different parts of the problems, you want to get into more details, , that's when, , we want to do more of, , in person type collaboration, people jamming, is what we call it.

Like, maybe it's like one designer with another designer. Maybe it's like a group of, say, four to five people. whiteboarding, working on the same problem together versus giving specific feedback, you know, more like, oh, this person knows this thing and makes all the decisions it's more like , everyone shares the same. Problem and space. Everyone tries to throw out everything . out. we essentially need to look at stuff holistically, and then try to figure out which hills to climb, or which set of steps to do. On the little pieces that you need to start doing, maybe each of them are owned by different group of people in different teams. It's more like a how do we plan? How do we sequence? How do we get each of the teams to do the right things problem?

[00:09:16] How Ryo sources feedback from the Notion team

Ridd: I want to talk a little bit more about how you defined that middle layer of AI in design. And. Ideally, even like kind of put listeners in the room with you, like kind of let us be like a fly on the wall because my assumption is that, you know, at some point you're going off, you're exploring things and then you are giving some kind of crit environment or presentation or sharing some of your thoughts and maybe it's like that first or second big milestone in the AI project. Can you tell us that story and maybe even specifically talk about , what are you bringing to the table for that meeting? Like, what are you actually showing as a designer? What are you hoping to achieve in that meeting? And , ultimately, , what are some of the strategies that you're using to drive alignment and provide more clarity for what that middle layer can actually become

Ryo: I feel like for certain kinds of problems, like an in person crit of like 30 minutes just won't do it. When things get into like this system's conceptual land almost, because it touches so many different things, you need to kind of put all your thoughts down in a really clear way for people. And then how we usually do it is we just write docs in Notion. And then usually those docs kind of show people how you reason about the problems. What is maybe like the high level system you are trying to design. How do different concepts connect with each other. Maybe you list out different options for the solutions. And then you kind of think about each of the options, pros and cons, try to compare them. You kind of, , supplement that thinking with pictures. That could be like, Figma artboards, link previews in Notion. It could be, random drawings that you've done in a whiteboard.

And then, you need to get a lot of people in there. Not just designers. Maybe European partners, but also like maybe Engineers, people are thinking about how to architect the technical designs. And then people come in and people leave comments, and people start conversations and discussions on specifics of that doc.

And then, We just try to kind of mix all these things back in, do more loops, get more feedback from more people, do more loops, and then try to kind of share all these ideas out.

In a way that is, not just, the designers talking about this. Tiny little visual details, but how do we, wrangle Notion up so that things get clearer and simpler, but also more flexible in some sense.

Ridd: I I've worked in similar environments where a lot of things are happening in a notion document, and I'm kind of trying to break down this project into like different initiatives with maybe sub directions within that initiative. And like very clear using like the call out block is one of my favorite ones for these types of, of documents.

I think a struggle that I've encountered a lot of times with doing things entirely async is the pace. And getting people to actually weigh in on the things that matter. And if I'm doing a loop, my God, sometimes those loops take too long. And like, then you have some upper level person that swoops in like four days later after you think you already have alignment.

So can you talk a little bit about how you steward this async feedback process as a designer and ensure that you're getting the answers you need and preserving the inertia of the project?

Ryo: I also think it's like just doing async is not enough, but it is good to kind of capture your ideas down and all people's thoughts in a more open environment. Anyone can come in and, , jot their ideas down, give feedback, but when When you want to, say, make more decisions, where you want to start refining different parts of the problems, you want to get into more details, , that's when, , we want to do more of, , in person type collaboration, people jamming, is what we call it.

Like, maybe it's like one designer with another designer. Maybe it's like a group of, say, four to five people. whiteboarding, working on the same problem together versus giving specific feedback, you know, more like, oh, this person knows this thing and makes all the decisions it's more like , everyone shares the same. Problem and space. Everyone tries to throw out everything . out. we essentially need to look at stuff holistically, and then try to figure out which hills to climb, or which set of steps to do. On the little pieces that you need to start doing, maybe each of them are owned by different group of people in different teams. It's more like a how do we plan? How do we sequence? How do we get each of the teams to do the right things problem?

[00:14:06] More details about the Notion design process

Ridd: You talked about like the little pieces. Can you talk about how you like steward the feedback process for that more like isolated area of the product? Are you still doing it more like async docs? Are you sharing more prototypes?

Like, how do you get the feedback that you need once you realize like, okay, I'm working on this specific set of features or this specific area of the product.

Ryo: If we zoom into something we're actively building that will be shipped soon Or at some point that is really clear

We do, try to collect feedback from as many channels and sources as possible. We try to build and prototype live as much as possible. So you can think of like, say when we're Doing earlier phases of speccing and stuff. Maybe it's more about all those async feedback on docs or crits or You know little reviews here and there but once things get a little more more momentum Once engineers start prototyping stuff, we try to release them in our, dev Notion workspace, which is like the internal thing we use, , so that people can play with it.

Maybe it starts with the team that builds that feature, and then it expands to everyone within Notion itself. So people can give feedback back to the team that built it. , and then, once we feel good enough internally, we try to give more access to people outside of Notion.

We have like a group of ambassadors and they know every bit of it. They can help us cover feedback around, say, the more power user use cases. then there are also like, we cover so many different group of users. In big companies, enterprise, they have more , admin needs. Maybe it's like small companies or startups. Maybe it's individuals and students. And then we want to get their perspective on things too. And then we get all of these feedback, we triage them, we do loops of these.

Until we feel like it's good enough. And it's really close to ship. And then we just polish everything up.

[00:14:06] More details about the Notion design process

Ridd: You talked about like the little pieces. Can you talk about how you like steward the feedback process for that more like isolated area of the product? Are you still doing it more like async docs? Are you sharing more prototypes?

Like, how do you get the feedback that you need once you realize like, okay, I'm working on this specific set of features or this specific area of the product.

Ryo: If we zoom into something we're actively building that will be shipped soon Or at some point that is really clear

We do, try to collect feedback from as many channels and sources as possible. We try to build and prototype live as much as possible. So you can think of like, say when we're Doing earlier phases of speccing and stuff. Maybe it's more about all those async feedback on docs or crits or You know little reviews here and there but once things get a little more more momentum Once engineers start prototyping stuff, we try to release them in our, dev Notion workspace, which is like the internal thing we use, , so that people can play with it.

Maybe it starts with the team that builds that feature, and then it expands to everyone within Notion itself. So people can give feedback back to the team that built it. , and then, once we feel good enough internally, we try to give more access to people outside of Notion.

We have like a group of ambassadors and they know every bit of it. They can help us cover feedback around, say, the more power user use cases. then there are also like, we cover so many different group of users. In big companies, enterprise, they have more , admin needs. Maybe it's like small companies or startups. Maybe it's individuals and students. And then we want to get their perspective on things too. And then we get all of these feedback, we triage them, we do loops of these.

Until we feel like it's good enough. And it's really close to ship. And then we just polish everything up.

[00:16:20] How Ryo thinks about parity betwee design <> code

Ridd: Can you talk about I hate using the word handoff, but like this transfer of knowledge between design and engineering within those loops, because what you're getting feedback on does exist in code. So how much are you prioritizing? Parity between what's in Figma and what's ultimately in code.

And like, what do those deliverables within that loops cycle look like from your end?

Ryo: For the longest time, like most of the Notion designers code too. So we actually don't really have this distinction. , it's usually like people who are working on this thing and then they're just thinking and making things together and iterating on it. And then it's more like a pretty fluid experience.

At some point we didn't even have, , PMs. Like the engineers sometimes lead the project and do some planning. Designers help filling, details in. As the team grew bigger, a lot of these things don't really scale as much. And also it's like people start to have different levels of skill sets and there's more variability. , there are people who are onboarding, joining in, trying to help, but then maybe they don't really know all the rules of like how the system works. Then we started building like a Figma side component system.

, like one of our designers, Ricky, he's been starting doing this like on the side. And then the engineers have the same problems. Because they might not know which components to use, which, text. property, text icon color sizing and stuff to use. So we're trying to work on, making sure that the Figma system maps to the code and everything ideally converges at one point. But, for the meantime, it's all about eye checking on everything that we ship and then trying to polish it up. So that things feel consistent. Cause ultimately everything that we do ends up shipping as pixels on the screen. And I think it's like, the first order is you make sure that pixels on the screen works in a cohesive way. All the concepts you have work in a cohesive way. And then it's about, how we structure and reason about all the components, all the different tokens all your different Variables in your designs, they match, , and have better tooling for designers and engineers to, make things faster in a more efficient way.

Having more flexibility when things are changing so much helps. It makes you more adaptive to change, , and then it makes evolving the system a little easier.

[00:16:20] How Ryo thinks about parity betwee design <> code

Ridd: Can you talk about I hate using the word handoff, but like this transfer of knowledge between design and engineering within those loops, because what you're getting feedback on does exist in code. So how much are you prioritizing? Parity between what's in Figma and what's ultimately in code.

And like, what do those deliverables within that loops cycle look like from your end?

Ryo: For the longest time, like most of the Notion designers code too. So we actually don't really have this distinction. , it's usually like people who are working on this thing and then they're just thinking and making things together and iterating on it. And then it's more like a pretty fluid experience.

At some point we didn't even have, , PMs. Like the engineers sometimes lead the project and do some planning. Designers help filling, details in. As the team grew bigger, a lot of these things don't really scale as much. And also it's like people start to have different levels of skill sets and there's more variability. , there are people who are onboarding, joining in, trying to help, but then maybe they don't really know all the rules of like how the system works. Then we started building like a Figma side component system.

, like one of our designers, Ricky, he's been starting doing this like on the side. And then the engineers have the same problems. Because they might not know which components to use, which, text. property, text icon color sizing and stuff to use. So we're trying to work on, making sure that the Figma system maps to the code and everything ideally converges at one point. But, for the meantime, it's all about eye checking on everything that we ship and then trying to polish it up. So that things feel consistent. Cause ultimately everything that we do ends up shipping as pixels on the screen. And I think it's like, the first order is you make sure that pixels on the screen works in a cohesive way. All the concepts you have work in a cohesive way. And then it's about, how we structure and reason about all the components, all the different tokens all your different Variables in your designs, they match, , and have better tooling for designers and engineers to, make things faster in a more efficient way.

Having more flexibility when things are changing so much helps. It makes you more adaptive to change, , and then it makes evolving the system a little easier.

[00:18:50] How Ryo thinks about the Notion design system

Ridd: I want to talk a little bit more about that because you have this. Line that you use on your job descriptions, which I think is so cool. You talk about making software with the craftsmanship of German cameras, the playfulness of Japanese toys and mass appeal of Coca Cola, which is like a heck of a mandate for design.

And you're in this really interesting season of Notion where it's no longer this like small, really tight knit senior team of designers where you only had like three people and now you're scaling up to like 10 different designers. And maybe there's more variance in skill level even, but like, I'm really curious to, to hear more about how you think about the different systems that you need to put in place in order to empower the design team to reach this level of craft and kind of soft skills in there and there's also kind of hard skills.

Maybe we could even start with the Figma side, like actually how much of a system do you build? As a team, like, where do you think about that line between, okay, there are real efficiencies to gain here, but we don't want to go too far to like overarchitect things and invest too much in the systems level when we really just want to ship.

So how do you think about that sweet spot for notion?

Ryo: There are certain things that pretty much, you know, they don't really change, but they touch so many different parts of the tool, say like all the base components, all the rules that are foundational that needs to be clarified to both, designers and engineers that needs to be systematized so that things are, cohesive, say like you don't have a blue button that looks different, that have two shades of blues, but then for Notion, I think there's a lot of things that Figma design systems can't really cover, there's a lot of things around how we want to design features or reason about problems that are really not captured by the components themselves, or the UI itself. We need to both be crafts, you know, humans on the, say, visual UX UI side. But also, when we design, concepts. How they generalize, how much flexibility and power and possibilities does this thing open, while keeping the system itself still understandable to people

[00:18:50] How Ryo thinks about the Notion design system

Ridd: I want to talk a little bit more about that because you have this. Line that you use on your job descriptions, which I think is so cool. You talk about making software with the craftsmanship of German cameras, the playfulness of Japanese toys and mass appeal of Coca Cola, which is like a heck of a mandate for design.

And you're in this really interesting season of Notion where it's no longer this like small, really tight knit senior team of designers where you only had like three people and now you're scaling up to like 10 different designers. And maybe there's more variance in skill level even, but like, I'm really curious to, to hear more about how you think about the different systems that you need to put in place in order to empower the design team to reach this level of craft and kind of soft skills in there and there's also kind of hard skills.

Maybe we could even start with the Figma side, like actually how much of a system do you build? As a team, like, where do you think about that line between, okay, there are real efficiencies to gain here, but we don't want to go too far to like overarchitect things and invest too much in the systems level when we really just want to ship.

So how do you think about that sweet spot for notion?

Ryo: There are certain things that pretty much, you know, they don't really change, but they touch so many different parts of the tool, say like all the base components, all the rules that are foundational that needs to be clarified to both, designers and engineers that needs to be systematized so that things are, cohesive, say like you don't have a blue button that looks different, that have two shades of blues, but then for Notion, I think there's a lot of things that Figma design systems can't really cover, there's a lot of things around how we want to design features or reason about problems that are really not captured by the components themselves, or the UI itself. We need to both be crafts, you know, humans on the, say, visual UX UI side. But also, when we design, concepts. How they generalize, how much flexibility and power and possibilities does this thing open, while keeping the system itself still understandable to people

[00:21:16] Preserving simplicity in the new user experience

Ridd: You've mentioned this word power a couple of times. And I do want to talk a little bit more about that because I started using notion like six, seven years ago when it was much simpler and you've added so. Much to this product where it can do everything, like literally anything I want to build, I can build it in notion.

And for me, as someone who's been with the product for such a long time, I've learned each of these new additions in isolation where it's kind of preserved the simplicity because I'm not really ever having to experience the whole thing for the first time. So now that there is this level of functionality and it's such a robust product, can you talk a little bit about how. Thinking in terms of like the new user experience for notion has evolved over the last few years.

Ryo: If you look at Notion, the simplest state of Notion is just a blank page. And you can write whatever in there. But there is a lot of, pretty complex, , foreign concepts. For most people, especially people who don't build software, like databases, that are pretty hard to get at first. But then if you look at all the apps that people use every day, they're all powered by databases. They all have similar views, say like you have tables, you have lists, you have boards, , But all of these things are pre built for people for different purposes. For different problems people have, different workflows they have.

So what we're trying to fix is almost like, there is no one size fit all onboarding for Notion. Because every single person, every single team wants different things. All the tools, the configurations of them might be very different. But maybe they're all conceptually similar. How do you have a system that maps what the user needs with the things, the tools that they want? We want to figure out the fewest questions that we can ask to give you the closest set of tools that you need when you start. And then, it's almost like, ideally, when you use those tools, they are self evident, they're familiar. They maybe behave, even have similar concepts that you're used to in other tools. When you navigate around, it feels pretty natural. You can go from projects to a task to a subtask really nicely. Everything's presented in a way that's familiar, you don't have to configure anything. And then you kind of go down to the middle layer if you do want to customize it.

And the idea is we don't want to push you towards the low level concepts too much, too quickly, too early. Maybe there are a bunch of things that you can tweak without, touching harder concepts. And then it's almost like for people who are really interested, In building more tools with more power, I think they should still get the full set of powers they could get.

Or even with more flexibility. Not everyone have to become a toolmaker, in a sense. It's like, most people don't really care. Most people just want something that works, especially for people who are in a company, , using Notion. A lot of people are just, say, Creating docs, sharing them, getting some feedback, looking at stuff without, thinking about how things are structured.

So how we're thinking about onboarding is almost like we need to rethink how our concepts are presented. We need to tie it up better with what we know about the user. We need to make it so that you get things that are useful out of the box. We want to make it so that if you want to tweak it a little bit, it gets really easy without you, being the designer of the tool or under the need to understand how databases work, for example. So it's really about like, how do we close the gap between. What people tell us and what people get. And ideally is like when people are using that thing that they get, it's pretty easy.

[00:21:16] Preserving simplicity in the new user experience

Ridd: You've mentioned this word power a couple of times. And I do want to talk a little bit more about that because I started using notion like six, seven years ago when it was much simpler and you've added so. Much to this product where it can do everything, like literally anything I want to build, I can build it in notion.

And for me, as someone who's been with the product for such a long time, I've learned each of these new additions in isolation where it's kind of preserved the simplicity because I'm not really ever having to experience the whole thing for the first time. So now that there is this level of functionality and it's such a robust product, can you talk a little bit about how. Thinking in terms of like the new user experience for notion has evolved over the last few years.

Ryo: If you look at Notion, the simplest state of Notion is just a blank page. And you can write whatever in there. But there is a lot of, pretty complex, , foreign concepts. For most people, especially people who don't build software, like databases, that are pretty hard to get at first. But then if you look at all the apps that people use every day, they're all powered by databases. They all have similar views, say like you have tables, you have lists, you have boards, , But all of these things are pre built for people for different purposes. For different problems people have, different workflows they have.

So what we're trying to fix is almost like, there is no one size fit all onboarding for Notion. Because every single person, every single team wants different things. All the tools, the configurations of them might be very different. But maybe they're all conceptually similar. How do you have a system that maps what the user needs with the things, the tools that they want? We want to figure out the fewest questions that we can ask to give you the closest set of tools that you need when you start. And then, it's almost like, ideally, when you use those tools, they are self evident, they're familiar. They maybe behave, even have similar concepts that you're used to in other tools. When you navigate around, it feels pretty natural. You can go from projects to a task to a subtask really nicely. Everything's presented in a way that's familiar, you don't have to configure anything. And then you kind of go down to the middle layer if you do want to customize it.

And the idea is we don't want to push you towards the low level concepts too much, too quickly, too early. Maybe there are a bunch of things that you can tweak without, touching harder concepts. And then it's almost like for people who are really interested, In building more tools with more power, I think they should still get the full set of powers they could get.

Or even with more flexibility. Not everyone have to become a toolmaker, in a sense. It's like, most people don't really care. Most people just want something that works, especially for people who are in a company, , using Notion. A lot of people are just, say, Creating docs, sharing them, getting some feedback, looking at stuff without, thinking about how things are structured.

So how we're thinking about onboarding is almost like we need to rethink how our concepts are presented. We need to tie it up better with what we know about the user. We need to make it so that you get things that are useful out of the box. We want to make it so that if you want to tweak it a little bit, it gets really easy without you, being the designer of the tool or under the need to understand how databases work, for example. So it's really about like, how do we close the gap between. What people tell us and what people get. And ideally is like when people are using that thing that they get, it's pretty easy.

[00:25:20] How to think outside of your defined role as a designer

Ridd: I want to talk a little bit about you personally, but maybe first one more question about. Notion itself, because I think a lot of people do recognize the fact that notion has a special design culture. And at least for myself, I'm very interested in getting a little bit of like an inside look at, and actually how you operate.

So I'm going to toss a hypothetical question your way. Let's say that tomorrow you are forced to join a new startup. What is an aspect of. Design operates at notion that you would for sure want to make sure that you bring with you to that new company.

Ryo: I think designers at Notion do probably more than what typical designers do at other companies. I started personally building stuff and designing myself. I did not know the boundaries as much and then I started to build my own startups. With, say, like, two people, four people, ten people.

And then I went to, like,, more established tech companies with, say, hundreds of people or thousands of people. I've seen, like,, different kinds of configurations of all this, you know, engineer, product, designer type of thing. Sometimes the engineer gets more upstream, designer goes downstream, sometimes it's flipped.

Sometimes it's like, maybe the PM is upstream, and then they kind of delegate to the designers and the engineers more, you know.

What I find that work the best is you kind of throw away all these titles and stuff and you just work on the thing together and then you cover each other, you know, with anything. You might have a spike or, , You might own a certain piece of it, but then people blend their areas of ownership, their skills, their thinking.

They don't think in role boundaries, they think about the problems, the systems, the solutions. Anyone can propose any idea that will ultimately get mixed back into something better. The designers can code and polish things up. The engineers can think of the, system designs that eventually will, transpire through in the ui.

The product people can, think less about, specking out me MVPs, but think a little broader about how do we turn this into a bigger thing that's more impactful across, every user, every use case. People should just, work together and make stuff. Doesn't really care what your role or boundaries. Put all the ideas together. Find the best idea. Follow that through. Push that further. In every aspect.

[00:25:20] How to think outside of your defined role as a designer

Ridd: I want to talk a little bit about you personally, but maybe first one more question about. Notion itself, because I think a lot of people do recognize the fact that notion has a special design culture. And at least for myself, I'm very interested in getting a little bit of like an inside look at, and actually how you operate.

So I'm going to toss a hypothetical question your way. Let's say that tomorrow you are forced to join a new startup. What is an aspect of. Design operates at notion that you would for sure want to make sure that you bring with you to that new company.

Ryo: I think designers at Notion do probably more than what typical designers do at other companies. I started personally building stuff and designing myself. I did not know the boundaries as much and then I started to build my own startups. With, say, like, two people, four people, ten people.

And then I went to, like,, more established tech companies with, say, hundreds of people or thousands of people. I've seen, like,, different kinds of configurations of all this, you know, engineer, product, designer type of thing. Sometimes the engineer gets more upstream, designer goes downstream, sometimes it's flipped.

Sometimes it's like, maybe the PM is upstream, and then they kind of delegate to the designers and the engineers more, you know.

What I find that work the best is you kind of throw away all these titles and stuff and you just work on the thing together and then you cover each other, you know, with anything. You might have a spike or, , You might own a certain piece of it, but then people blend their areas of ownership, their skills, their thinking.

They don't think in role boundaries, they think about the problems, the systems, the solutions. Anyone can propose any idea that will ultimately get mixed back into something better. The designers can code and polish things up. The engineers can think of the, system designs that eventually will, transpire through in the ui.

The product people can, think less about, specking out me MVPs, but think a little broader about how do we turn this into a bigger thing that's more impactful across, every user, every use case. People should just, work together and make stuff. Doesn't really care what your role or boundaries. Put all the ideas together. Find the best idea. Follow that through. Push that further. In every aspect.

[00:27:55] The importance of communication for designers

Ridd: What about you personally, like when you reflect on your own skillset and all of the ways that this culture has grown you looking ahead, what is a. Skillset or area of growth that you hope to reach as a designer in 2024.

Ryo: I think communication is like super important.

I started doing design without communicating at all, because it's like you , build the stuff and it's out and it's done. But then when you start , working in a bigger organization with more people, it is really important to be really clear with your ideas. Where you want to take people to.

You want to have a way to articulate it in a really crisp way At different levels of detail in different languages when you talk to different people so that people feel motivated. They feel they want to do this. They get more clarity in their thinking. It's like they can unblock themselves and start moving.

And then kind of helping people. Tie things back together. I think it's super important, especially for Notion. Because every concept of Notion ties back together. And then this communication is not just about, how you talk or how you present yourself in credit, how you write docs. It's like everything.

How do you interact with different teams, different roles of people?

How do you help group of people work better together? That kind of stuff.

Ridd: It's very clear, just listening to you that the way that design works at Notion is, it's special. Like you have something very interesting there. And I love this idea of really kind of breaking outside of the traditional roles and responsibilities boxes in terms of what we think of as, joining a company as a product designer and the types of things that you'd be doing and working on and the ways that you'll be moving the needle. For anyone that is listening, who's like interested in this, and maybe is either in like the San Francisco or New York areas or somewhere like that

[00:27:55] The importance of communication for designers

Ridd: What about you personally, like when you reflect on your own skillset and all of the ways that this culture has grown you looking ahead, what is a. Skillset or area of growth that you hope to reach as a designer in 2024.

Ryo: I think communication is like super important.

I started doing design without communicating at all, because it's like you , build the stuff and it's out and it's done. But then when you start , working in a bigger organization with more people, it is really important to be really clear with your ideas. Where you want to take people to.

You want to have a way to articulate it in a really crisp way At different levels of detail in different languages when you talk to different people so that people feel motivated. They feel they want to do this. They get more clarity in their thinking. It's like they can unblock themselves and start moving.

And then kind of helping people. Tie things back together. I think it's super important, especially for Notion. Because every concept of Notion ties back together. And then this communication is not just about, how you talk or how you present yourself in credit, how you write docs. It's like everything.

How do you interact with different teams, different roles of people?

How do you help group of people work better together? That kind of stuff.

Ridd: It's very clear, just listening to you that the way that design works at Notion is, it's special. Like you have something very interesting there. And I love this idea of really kind of breaking outside of the traditional roles and responsibilities boxes in terms of what we think of as, joining a company as a product designer and the types of things that you'd be doing and working on and the ways that you'll be moving the needle. For anyone that is listening, who's like interested in this, and maybe is either in like the San Francisco or New York areas or somewhere like that

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers ๐Ÿ‘‡

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watchโ€

Eugene Fedorenko

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watchโ€

Eugene Fedorenko

hello@dive.club

โ’ธ Dive 2024