Accelerating Design & Development Innovation with AI-driven Tools

Hello, everyone. Very excited to speak with you about this topic today. Innovation is something that really excites me. And when I see products out there that are innovating, or even people that have great ideas, this is something that really excites me. And this is definitely something that I am very excited to talk with all of you.

So let's start. And before starting, I want to give you a little bit of background about myself. My name is Cristobal Chao. I am from Spain originally, came to the United States 11 years ago in 2012. And when I arrived to San Francisco, I started working for an innovation lab called Hatchery Labs. And our goal was to build other startups. It was very exciting. I was the first engineer there, and I had a great time working with a lot of startups. Some of them didn't go very far, but some of them went to the next level. And one of them actually became a unicorn, which is very, very exciting. A year and a half later, I joined Google as part of the front end transformation. And I learned a lot, not only from an engineering perspective, also from a design UI and UX. And I work in great teams. I was part of material design version 1 and version 2, building the main component systems, as well as moving all these pieces across platforms like Google Maps and Search. It was very exciting and I had a great time there. And then a few years ago, actually at the end of 2019, so three and a half years ago, I started my own studio called Torii Studio and we work with startups and also small, medium sized companies to try to help them go to the next level by building great front-end applications. And what I mean by great is front-ends that can scale very well from an engineering perspective, as well as building products that look and feel great. This is very exciting to me and we have seen a few startups going to the next level using some of our systems, processes, and what is still learning. And we have a lot of things to learn every day that is something new. So I'm very excited to actually speak about innovation today, which is what we try to do with the companies that we work with at Torii Studio.

So what is innovation, right? A lot of people probably are innovating right now, the ones that you are hearing me today, maybe in the past or maybe you are thinking to do it in the future. But all of us have a different sense of what innovation is. In order for me to explain how I think about innovation, I ask you this question, are you solving the right problem? And your first reaction probably is for sure, I mean, that's the easy part understanding the problem. And I know it very well. However, my answer to you probably is you are not really aware about the whole perspective.

You are bringing your own reality, your own biases, and you think you know everything. So you start building the best solution for that problem. And that's the main reason why most products fail in the first iteration. I don't really know one product that was successful at the first try. And I challenge you to tell me if I'm wrong. I haven't seen one in my life.

And to illustrate you a little bit about this topic, I'm just going to share like a story that happened back in the 50s, 1959. So 70 years ago, the world was different than today. And Henry Cramer, he was a magnate and came with this question. Can an airplane fly powered only by the pilot's body power? So it's like ET, like flying a bike. Isn't that crazy? He offered over a hundred thousand pounds. Back then, it was a lot of money. Just think about that amount was around two and a half million dollars. So that was a lot of money.

And they were big companies because there was a huge sum there and a lot of reputation that they could build trying to solve the problem. He wanted for companies to actually cross a canal of two miles with this flying bike. So they had to build it. They had to do everything and then try to fly the canal. So big companies were there like NASA and also a bunch of individuals. So then years later, no one has figured that out yet. They were spending a lot of money, a lot of time into every single experiment. And it was very costly because any time that they had to put something, it will take them months and then it will break and they will need to rebuild and try again. So it was taking a lot of time, a lot of money.

18 years later, Paul McGrady as an individual challenged the perspective of things. So he came with this perspective, with a different one. How can you build a plane that you can rebuild in hours, not months? So with this perspective in mind where he was thinking about ways to create a system that allows him to learn more about the problem by making very quick iterations. So every quick iteration will help them, well, will help him understand more about the problem and try again from a learning that he got from the previous iteration and build on top of that. So in a few months, he was actually able to create a system that allowed him to rebuild the bike that he was building in a matter of hours. So in just one day, he was actually able to experiment twice or three times. And all the competitors were taking them months.

So if you think about that, right, he was ahead of everyone else by just being able to do that. And in a matter of months after he created the system, he was actually able to cross the canal and win the prize.

The story is called You Are Solving the Grown Problem. This is from the Stanford University of Innovation. I would really encourage you to take a look. It's way better explained than I am explaining to you. So it's very, very interesting, this story. And it tells you, right, how important are quick iterations.

Every iteration is very important. Don't think about building the best solution. Just try to find a way to get there fast, and you will actually understand a lot. And don't think that you're going to get it right away. It's probably going to take you a lot of iterations.

So probably you are asking, OK, this is great. This is 1959. So the story now is different. We're building digital products. We use React. So who cares about building flying bikes? Stanford University comes with as well with this design thinking process. Some of you know, but it's a very similar idea.

You empathize with the problem. You define what problem is. You ideate a solution. Then you prototype and you test. And you want to do it many different times. And every iteration is a very, very interesting learning problem. So you want to learn from every iteration as much as you can and try again and again and again.

As Albert Einstein said, no amount of experimentation can ever prove me right. A single experiment can prove me wrong. He was able to achieve a lot of things by just making experiments.

For us, it's the same idea. We want to make experiments. Every experiment is an iteration. So that's a very important concept for you to understand. Because that's the main reason why most startups are successful, whereas others are not.

When you are trying to innovate in a life cycle of a product, you're going to start with a paper and draw your idea to it and put it in front of people. And you're going to start asking about how does it feel. However, if you start with paper, you're probably not going to get a lot of great feedback. You're going to get some level feedback that will be useful, but it's not the reality. You can go through other phases like trying to go wireframes, low fidelity, high fidelity, fully functional or building the product, right? But until there, until you don't get to the product, you're not going to get the highest level feedback.

When you build the product, you put it in front of people, that is when you understand what's going on, but it's very painful, especially the first situation because that's when you get punched in the face. That's when you fail. Especially the first time. You're building something that is new, right? That you think is going to solve everything and it's not, right? And that's fine. But until you are there, you're not going to get the highest level feedback. And the second question you want to ask yourself in the life cycle of any product is, how fast can you get there? Drawing something in paper, very, very fast. You can do it right now. It takes a few seconds, minutes of your time, but building the product takes the longest.

So if we put this into perspective, how fast and how accurate are our assumptions depending on the life cycle of any product? You know that product takes the longest, but we want to also get there. And if you think about the size of the company, the product takes the longest, especially if you're in a big company. And that's a very important concept to understand. That's why most companies, when they are big, they have a hard time to innovate something new. If you look at Google in the last 10 years, we barely have seen any innovative products. However, they spent billions into AI. And a small company like OpenAI comes to play and creates just GPT. Think about that. That's the main reason why small teams can innovate way better than bigger companies. However, they have a much more limited resources, much more limited budget. But there's a very interesting concept for you to understand because at the end of the day, that's how the world operates. So, now, we, as developers, usually, most of the time, we're just building the product.

We're in the latest phase of innovation. But innovation happens before than us, right? The designers usually go through paper, wireframes, low fidelity. Depending on the size of your team, you can go through all these different phases. But then, at the end, we're just building what the designers are handing to us. I want to question this perspective.

And I have a question for you. What if instead of doing that, we mix these two worlds together, we blend them in such a way that designers and developers are part of this innovation phase from the very beginning? The first question is how? And the first thing you need to understand is that the most important part, the most critical part, is the mindset. It's not the level of knowledge that you have, the experience that you have. It's the mindset. If you come with a very clear mindset, like a kid. When I mean a kid, is you want to go there without having any sort of ego. Nothing like tells you, oh, I know this way better than you. Keep your ego on the door. Just try to have the right mindset because that's very important. And you want to be learning from the very beginning. Even if you have been 20, 30 years in the space, you want to come with a very clear mindset and with no knowledge, no ego.

I mean, the knowledge is very important. Don't get me wrong. But you wanna come as very fresh person there trying to understand what's going on, try to learn. I think that every experiment is a learning for you. So as kids learn so fast because they don't care, they try a lot of things. That's why we want to also apply the same mentality. So how do we start? So we as developers and designers, we're actually blending ourselves into the same reality when we think about component systems. Designers usually use Figma, developers we use React. We can transform these design systems into systems that work very well and they are reusable in both sides. They are actually tools that allow you to go from Figma to React and the other way around, but this is a very interesting mindset that you want to have because you want to reuse as much as you can so you don't spend too much time into building the components. You are actually building the experience that you want to put in front of users. And with this idea of mine of iterations, you want to make a small iteration, try to get there, and as you go, you are polishing things. You kind of start when you have an idea with a very minimal way which is HTML5. You don't really need a library.

I mean, I really encourage you using React because that really implies reusability of components that can actually get you to the next level way faster. So that's why I also encourage you other libraries, but before I jump into that, just think about this, building something in HTML, I mean, it's very fast, but also it's something very ugly. People don't really have a great time, especially users these days. These days, users have raised the bar to the next level. They expect a user experience way better than before. So right now, and the reason why they do it is because they use digital tools all the time. They are in their phones constantly and that actually leads to great user experiences. So if you give them something that looks ugly, they're going to just reject it from the get go. So that's something to keep in mind, but for you to go from HTML5 components to bootstrap or material UI is not actually that hard. You just need to create, I mean, if you never did it before, it's maybe going to take you a little bit, but it's not that hard.

I want to also share this concept, some of you know already, I guess most of you should know that Figma has these dev mode capabilities, which allows you to actually get components already from Figma and have certain tools that get you to the next level way faster. However, I have to say this was released a few months ago. I am not the biggest fan. I think the idea is great, but I think we're still far from being the best or something that I'm very proud of using. So just keep that in mind. I would love to know what you think about it, but this is a very interesting area. And I hope Figma does a better job as we go. They are actually iterating, right? They're trying to create something innovative and I think they are in the way, but they haven't reached a great solution for everyone.