 And it was a conscious decision that we took as a program committee to try and ensure some continuity between sessions. We wanted to have a theme that ran throughout, or if not a theme, then a logical flow at least, starting from why does one do design, how does one do design, how does one make a living doing something that you love or building something that you love. And I think that Ben's talk really got there. It's not something that one thinks of traditionally as design, because design is often perceived to be what something looks like. But that's only a very veneer, that's a very superficial veneer, in my opinion. Design is a complete process, right, from how do you start creating an environment for yourself to actually build amazing products, or to build amazing things. And then go into the details of how one actually does it, starting from what goes into it, why does something have to go into it, which in fact is what Navjoth is going to talk about. He's going to talk about not the intricacies of technologies that you use, what kind of programs you edit your images in, not going to talk about, you know, new techniques or new visual identities, but he's going to talk about why, a question which is essential when you're building something, why does X go into it, why does my product do this, why does my product exist in the first place. And I think that's an extremely important question. So Navjoth was a brief internet celebrity because of a t-shirt, and since then of course his life has been meaningless, he used to work for Opera, and he had this t-shirt which said, show me Opera on your phone and I'll buy you a beer, right. So he ended up buying a lot of people beers, and it was possibly the best marketing campaign that Opera ever ran. He's not a trained designer, he's not a trained graphic designer, but works as an interaction designer, building mobile products in Singapore. Hello. Hello. Yeah. That's actually interesting. There's two buttons here. One says power on off, and the other button says on mute. I was like, is that supposed to be like mute on, or how does that work? So yeah, thanks Rahul for the introduction, and thanks Ben for setting up the stage for this conference, you know. My first slide, it's wireframes. Like Rahul mentioned, I'm not a trained designer. I was always fascinated by design, and I always knew I wanted to create products or create things. But I really didn't know how, so like most people here, I just started doing things and kind of stumbled into things, and then eventually, right now, I'm doing design full-time, which so far has been great. So this is actually going back to when I was still in uni. I used to see these kind of pictures come up online, and this was amazing for me, because I would look at these pictures, and I'd be so fascinated by them. They would inspire me. I'd look at these wireframes, and they're so neat and clean, and I'd be like, wow. You know, just samples of pictures and people looking cool drawing wireframes as well. So I was like, you know, I look at these pictures all day, and the thought that would come to my mind would be, I want to draw wireframes. I want to make wireframes. And people go into so much detail with the wireframes, and it's amazing. It is inspiring. It's something that I think, you know, I'm not alone, but a lot of designers really love. You know, we'll go online. There's blogs about it, right? There's blogs about just wireframes and good-looking wireframes. You go to dribble people up loading wireframes. So I went back, and I said, you know, I would go back, and I would like, I want to draw wireframes. So I started drawing wireframes, and these are some of my own, and I try to make them look good and make them take pictures with Instagram, where they looked even better or looked good when they didn't. So, you know, just really, really try to, just, you know, and this is one of my wireframes where, you know, it's actually looking like an app. I would just be like, oh, I'm going to make this take a picture and upload it. It's going to be the best thing ever, right? It's going to go on my blog. And what I became is a self-confessed wireframe whole. That's what I like to call myself, where I was just so obsessed with wireframes. And these things really, really inspire me, and everyone who's in design looks at them. What I realized over time, though, is wireframes, you know, as I started off, actually, Ben had an interesting anecdote where, you know, he was sitting over here as an eight-year-old, and he was saying, I was drawing this man bouncing around in flash. That's where I started as well, Ben. When I started, I was actually, I moved to Bangalore in 2003 for my six months. I had a period of six months where I could do an internship. So I said, okay, I'm going to go to Bangalore. I grew up in Chandigarh in the north. So I was like, okay, I'm going to move to Bangalore because I can meet some interesting people there. And actually, one of the people who really inspired me at that time in the audience as well, Brajesh, were sitting back over there. He had this website, you know, and he was doing some flash stuff at that time as well, and I was really inspired. So when I started, you know, with all of this, I started as a flash developer, got into HTML front-end, and, you know, kind of stumbled into product management and product design and product creation. I've realized that, you know, wireframes are important, and, you know, that's something, that's a part of this process, like Rahul mentioned earlier, that design isn't slapping on, you know, a few pixels on something. It's a process. So what I've realized is design is a process, and wireframes are a part of the process, and wireframes need to look good, but that's not what they're meant for. Wireframes aren't meant to look good. That's not the purpose of the wireframes. Well, actually, I was going to call my talk, Confessions of a Wireframe Ho, but I realized I already had put up a topic on the website. But so, you know, looking at all these wireframes, I get inspired. I make these wireframes. What I've come to realize is wireframes are meant to explore something. There's a reason why we make wireframes. I got very obsessed, and I think a lot of designers do as well. I would, you know, buy my pencils, buy my sketchbooks, sit in a coffee shop. That's the rosy picture that everyone dreams of, right? You're a designer sitting in a coffee shop all day with a sketchbook, a few nice pencils, and you're drawing, sketching wireframes, which are going to change the world, or at least get popular on Flickr or Dribble or Instagram. And I've realized, I think, hopefully for the good, that there's a bigger reason behind that. The wireframe is called a wireframe because it is the most basic essence of your product. It's where you explore that why are you building this product? What's the purpose of this product? How can you build this product? And what are the things you should think about? What are the things you should not think about? It's the one place where, before you get into development, you're not bound by the constraints of the platform that you're building for. You know, if you're building a website or an iOS app or an Android app, it's the place where none of that matters. What matters is the idea. You have an idea, and this is where you're trying to figure out how or why am I building this product and how is this idea going to translate into a product? That's the purpose of the wireframes, right? So with this knowledge, I, you know, this is something I've raised over the last few years, as you can say, when I've kind of stepped into the shoes of a designer, I started looking at a lot of the processes that are going to, you know, designing something or creating a product with the same approach. Rather than looking and saying, hey, you know, why do I need, or how am I going to make this look at why am I doing this or why should I not be doing this, you know? And that's kind of what I'm going to, I want to talk about a little more in the talk today. So yeah, it's not called Confessions of a Wireframe, it's called Fishing the Why by Navjod Paveira. That's me. And if the people behind at the back can't see me clearly, I'll put up another picture of me online. That's me, sometimes how I look as a hippie designer, whatever. And that's somehow how I look like that. Sometimes as a politician, if you may, from Punjab. But I want to go back a little bit like I mentioned, you know, I was not a trained designer, I became a designer. And I, like I said, I started off as an Adobe flash developer. I wasn't trying to be a flash developer, I was just trying to do something that was interactive on the screen. I was trying to come up with something that I could interact with and it would, you know, respond back to me. Or I could make things move when I did something. So over the years, I, I mean, flash was a very short stint, to be honest. From flash, I very quickly switched to HTML, CSS. Because, you know, actually the truth is, when I would make my flash website or my flash app, it would be perfect and I'd put it up on the website and I didn't know how to put it into the website. So I started doing HTML. I was like, okay, I need to know how to put it into the website. That's how I started. Eventually got the best job in the world, I think, which Shwetank right now has, which is I was paid to go and go out and talk at conferences. That was my job. And I was just going out, talking at conferences, putting up funny pictures of me on the presentations as well, as well as the website. And eventually I got into product management. I did that. It was, you know, web evangelizing. I did that for a while. It was fun. And then I got into product management. And I started as a trial. I was at, I was working at Opera at that time and I got the chance to, to take care of a product, part-time initially. So I started doing that and I really loved it. And within three months, I, you know, told my, told my boss that, told my mentor that, I wanted to move into this full-time. I don't want to be traveling around anymore, going to conferences. I don't want to move full-time into actually managing product. So, so he was like, okay, well, you know, three months it's been a good trial. All right, why not? So I got into product management. And I used to question, you know, when I, when I got into product management, I used to question what does a product manager do? And the main reason I used to question that was every time I'd call my dad and I'd be like, he'd be like, how's it going? I was like, going fine. I've become a product manager now. What does a product manager do? I was like, okay, I didn't know. I didn't know what to tell him, right? So I was like, okay, I'm a manager. So I should be managing people. But I realized people weren't listening to me. So I was like, okay, I need to manage something else now. Oh, I'm a product manager. Maybe I should be managing the product. The product wasn't listening to me either. It was just going in all the directions. So I actually went back to my mentor and I had this discussion. I was like, what does a product manager do? You know, I know I'm kind of in charge of this product, but what does a product manager do? And he gave me this analogy. He said, think of a football game. You know, it's a football team, football game. Lots of players on the field, usually two teams. Well, most of the time, two teams are football. And there's a referee. So as a product manager, you're a referee. You know, you're not very important on the field. People are doing their stuff. You're not the celebrity on the field, but you're needed there to make the game go on. I was like, okay, yeah, that makes sense, right? So I was like, okay, great. Had a hard time explaining that to my dad, but I was convinced. I was like, okay, that makes sense. I'm the person who's kind of, you know, making sure the games played the way it should be played. A couple of months down the line, you know, every product has its ups and downs. And we were, a couple of months, we were in the down, you know, where the product wasn't going well. And I was sitting and having a beer with my mentor. And I was like, you know, you said we're like the referee. He's like, yeah, yeah, yeah. I was like, it's not. I was like, I'll tell you what a product manager is. You go on a field, right? It's a football field. There's two teams, and you know, those are the celebrities. There's a referee. You're not the referee. You're the football. You're the person who's been kicked around by the engineers or the developers or the designers. And you have no control, but you're important because you needed for the game to be played. You know, you just kicked around. That's what a product manager is. Anyways, you know, over time, I had a great time learning how to manage products or people or what. You know, you learn how to get products out of the door. And I kind of changed my definition over time. And I think I went through a confused state where I was quite confused. I was like, product manager is not really a product manager. I went through quite a few phases. So one of my phases was being disillusioned, right? I was like, product manager is a CEO. A product manager is a mini CEO. You need to think of your product as the CEO. And actually, that's quite a bit of truth in it, right? If you're in charge of something, you need to be committed to it, you know, with all you have. You need to be committed to that product because you have to be true to what you're doing because if you're not, there's all these other people who are dependent on you, right? It could be a design team, it could be a development team, it could be the sales team, the marketing team. You're the person who everyone comes to and says, hey, what are we doing? What's going on with the product? So I was like, okay, you know, you're like the mini CEO in a way. You need to be really, really focusing on the product. And over time, I realized that was true, but the other second very important role of a product manager was actually to ask questions. I'm not a very big fan of managing people. You know, I like working in environments where people are just moving. People are committed to the project, the goal, and they're just moving. You know, you don't need to manage people. So I was like, as a product manager, you're the person who needs to be asking the right questions. You're the person who should be saying why, why not, how, for who, when, you know, all these things. You're the person who needs to have these answers with you. And that made a lot of sense to me. The other thing I realized when I was thinking as a product manager was different products are created, you know, and you read online about how, you read stories about how people create products, how when there's a product or a startup that becomes successful, there's all these stories, right? This is how they started. This is what they did, and this is where they ended. And I said, all these products are created, but they're not created the same. You can have five startups who are doing the same thing. Like, for example, in India right now, right, in the startup scene. What I've seen is there's a lot of cab companies. You know, there's a lot of startups around transportation. They're all in a way doing the same thing, right? The goal is the same where you want to have, you know, easy availability of cabs. But all the products are different, right? The experience is different. You use one, you use the second one, the product. The experiences are different. What I realized was every product has a DNA. You know, it's what makes the product what it is. You know, in some of the products you go and you see, okay, you know, this product was started by designers because it looked fantastic. Or in some places you can say, oh, this product was definitely started by technology people because it's got all this great technology, maybe it doesn't look that great, but it's got all this great technology behind it. And, you know, so different people, different backgrounds. And that's where I realized that what I really wanted to do at the beginning of, you know, of my thought process as a kid was I wanted to create products that, you know, like I wanted to create products that had a good experience around them. So I was like, okay, I am maybe not the CEO, you know, or maybe I am, but I'm more towards the design. I'm maybe more of a product designer. And, you know, I kind of realized that even as a product designer the best place to sit at was actually in a product manager's shoes. Because then there was no one to say no to you, right? If I would come up with a design there was no one who could say no to me because I was, I'd come up with a design and look at it and I'd be like, yeah, okay, all right, keep moving on. But that's what I realized I really, really enjoyed. And so I moved into product design and for the last four or five years now, almost, I've been focused, I've been focusing on design. And all this while, you know, I educated as a computer engineer and I did all these things, but I never was a designer. So I'd heard about wireframes, you know, I'd sketch wireframes, not for any products. I would just, you know, just to make something cool. But I didn't know what was the purpose of, you know, I'd heard about wireframes and prototypes and, you know, interaction design techniques, card sorting and all these, you know, interviewing people and usability testing. A few of these I'd played around with, but I really didn't know what they were for. I didn't know, you know, I was used to going to having a design team and they would come up with something and they would give it to you and you'd be like, oh, I like it or I don't like it or you'd have a debate. And then you'd convince them they were wrong and they go back and do something again. So I realized there were a lot of these things that I don't know about. And to be honest, I didn't ever feel that I need to know everything, you know. I didn't feel that I need to know what's prototyping or usability testing or what's paper prototyping or rapid prototyping and all these things, or wireframing and this and that. So I was like, I don't know any of this. I don't need to know any of this. What I need to know is what do I need to make my products, right? So I looked at the wireframes again. And this wasn't, you know, I sat down one day and I said, okay, what are wireframes for? It was just a process over time. I started questioning. I was like, why am I drawing these wireframes? What's the point of these wireframes? Why am I doing this? And it took a while, but I realized, there was a purpose behind it, right? There was a very specific reason why you spend that time doing that exercise. If you look at a product development life cycle, not in the software development life cycle, but yeah, you come up with an idea. You're convinced that this is the idea that you want to take forward. Then you sit down and try to figure out what can you make out of this idea? How can you turn this idea into a product? And that's where I think something like wireframing and prototyping fits in. You know, you have your idea. You make your wireframes. You explore all the other options, all the options that are around there. Like I said, you're not bound by anything. You're saying, okay, I'm making, for example, let's say I want to make a website for dances, right? You define who that product is for. You know, you're like, okay, this product is for dances. Okay, so what do dancers need? So this is for dancers who want to learn dancing. Okay, great. What do you want to put on the website? My goal is to have tons of videos. My goal is to tease these dances, and I've realized videos are great because they've got video where it shows how they move and it's got audio as well. So okay, I'm going to have video on the websites. And then you're like, okay, how is this going to look? So you start sketching things and you're like, okay, that kind of looks great. And you're convinced that this is correct. This is what's going to work. The sensible thing to do here is probably show it to a few people who've never seen this product before, who've never heard you talk about this product, because as soon as you do that, they'll point out a few things that they don't understand, right? So it's kind of an exercise to kind of figure out how this process works, how your website's going to work, or how your app's going to work. So you ask these questions on the way, you try to find answers to the questions. You say, who is this for? Why am I doing this? What's my goal? Then you get to the point where you're like, okay, now I need to develop it. How do I develop it? And you get someone intelligent who's an engineer, hopefully, or who knows technologies, video and websites if you're developing on the web, and they'll help you create the product and then you keep moving on. So in all of this process, if I have to simplify it a lot, like to the lowest level, there's kind of two sets of people involved, right? There's the development team, or there's the developers who are concerned about their... I mean, for them, as a developer, your biggest goal is to be on top of your skills, right? On top of the technologies. And that's a valid goal. You want to make sure when someone comes to you and says, hey, we want to build this, or when you want to build something, right? You want to build something. You don't have to go searching for how do I do this, how do I do this. You need to be on top of your technologies, your skills, and you develop it and you build your prototypes and you build your products. And there's also this other set, which I might be biased here, but I think of as designers or the product managers or the other people who kind of questioning, or should be questioning, why are we building this? There are the people who are constantly doing, maybe not as designers but product managers, you're questioning why am I building this product. So there's a set of people, or there's someone sitting there and constantly questioning why am I building this, right? Why? What's the goal of this product? What's the purpose of this product? And then you've got your set of people who are like, how do we do this? How are we going to build this? And if you get a good combination of those two, I think you've got a solid team. Now, on the same analogy, I read this book, which I mentioned in my intro video as well, which is where I actually got the idea for this talk. I read it last year. I actually really recommend people read it. It's called Shape of Design. Developers, designers are very short read, but it's, to me, it was like, I spent more time thinking about what I was reading than actually reading. It was that kind of a book. It was fantastic. And in that book, the author, Frank Jimero, he talks about how and why. He really spelled it out. He's like, okay, these are the two things, and this is how these come together. And he gives an analogy, which I think is really, really good. If you've ever painted, you know, this example is from the book, so you'll find it there as well. This painting is called The Art of Painting. And in this image, what you see is a painter sitting there with a subject in front of him, and he's drawing strokes to paint this picture. Now, in this scenario, in this scene, what you see is the painter's focused on his canvas. The painter's looking at his canvas and figuring out how he's going to draw every stroke. And maybe he's drawing the dress she's wearing. So he's concerned about, okay, how am I going to make this dress look like? How am I going to make my painting look like the dress? How does every fold? How am I going to draw every stroke so that... So he's concerned about his skill, right? Now, if you've ever painted, this isn't the whole picture. Because if you've ever painted, you'd be sitting like this, going, how am I doing this? How am I doing this? And every now and then, you'll step back. You'll maybe just lift up a bit and say, is this kind of fitting in together? I drew this stroke. I drew this stroke. Are they kind of getting together to make or create what I wanted to create? Are all these strokes getting together, coming together to make that dress? So these are kind of the two stages of creating a painting or anything, right? You're concerned about the house. You need to know how to do it. That's the skill. That's the form. And you also need to be aware of why you're doing this, right? That's the purpose. So there's how and why, form and purpose. And if you think about it now, if you don't have a purpose and you're just building stuff, you're just building stuff, where are you headed? What are you doing? I did that a lot when I was a developer, when I was creating products. We just get so engrossed into the technology that we were using or the new cool solutions that we found to some problems that we just keep on building, keep on building, keep on building. And we would forget to ask, why are we doing this? How is this going to come together into a product? So it's very important to keep in mind there's a purpose to every form that you're trying to create. There needs to be. Of course, your purpose can be, I'm trying to learn. I'm trying to learn this skill, this technology. Keep that in mind. It's just... Now, let me just kind of give you a disclaimer here. I'm not trying to say that this is how you should be approaching everything. All I'm trying to say is that I kind of realized that this was a smart and powerful tool for me to be able to think about the same things in different ways. It's just a tool. It's just when I'm stuck somewhere, I try to come at it from a different angle, a different perspective. And this is one of those perspectives, which is why am I doing this? I'm trying to come up with solutions, like design. I often say design is a solution. That's how I approach design. Design can be many things. For me, it's a solution to a problem. And that why is very important for me. So, yeah, you know, questioning is... This is... It has questions, questions so you can make room for answers. In... There's a book called The Innovative Dilemma, written by a professor from Harvard. And I read this, not... I didn't read the book. I haven't read the book. I read this on a blog where Jason Fried from 37 Signals is talking about it. And he mentions this. Like, one of the great things that I had... He had a conversation with this professor, and he's like, one of the great things the professor said was, questions are needed to make space for answers. You need to ask a question so that you can make space for answers. Now, think about it for a minute. What he's basically trying to say is, if you just keep going on the path that everyone else is going, and everyone else has been talking about, you're just gonna... You're not asking any questions and you're not gonna come up with anything new, right? You might come up with a remix, which might be new, but there's just another way of thinking about it. If you stop and ask why, or any kind of... You're like, why not equally important? As soon as you do that, you make space for an answer. You make that cavity where you need a solution, right? And that really struck with me. And I was like, yeah, that really makes a lot of sense. A few examples here we talk about a lot in the design community. One of the things is when you go to a website or you're using apps, you see all over the interface there's icons, right? There's different kinds of icons. And sometimes the icons are just there. There'll be an icon. We're actually looking at the metal refresh icons. This is a great example. We've got three different icons that we use to represent refresh. When you've got these icons, if you've seen these icons before, you might know what they mean, right? If you've not seen them before, you probably won't know what they mean, right? So a lot of times designers use icons with labels. So they say, this is the icon and this is the label. This explains what it means. The label explains what it means, but the icon is still needed because it's easier to go back to. Once you've used it, you can find it anywhere quickly and interface and say, okay, this is what I'm going to use, this is what I'm going to use. I want a refresh. So, yeah, you know the refresh icon. You can just go and tap it anywhere you want. And there's another school that says, well, why don't we just use labels then, right? And that's kind of the middle ground there. What I found interesting there was I was doing these in products in my projects where I would use icons because they look great. I wanted a minimal interface and I would just have icons, no labels. And the same questioning really helped me there because I was like, hold on, why do I need icons? Because I was really trying to get a minimal interface, right? I was like, why do I need icons at all? I was like, well, I need icons because I've got navigation, for instance. There are actions. There are actions on this interface that people need to be aware of. I was like, okay, but the icons might not communicate those actions or that navigation. So I was like, okay, although I do need, this is my design goal. I want a minimal interface, but I want it to be usable, right? I'm creating a product. I want it to be usable. I want to make something that people can use. So I was like, okay, maybe labels can work. This is just a small isolated example where I really went back and said, okay, why am I doing what I'm doing and how can I make it better based on what my goal is? So everything can be questioned. Another thing is, as soon as I said, okay, I'm going to be talking about questioning the why. The first thing that came to my mind was why did the chicken cross the road? So I went online and I was like, I'm going to look for why did the chicken cross the road? Because living in India, I've heard this in all the Hollywood movies everywhere. I don't know why the chicken crossed the road. So I went online and I found out, well, the chicken never crossed the road, actually. There was no chicken ever crossing the road. And if there was, no one knows why he did. So I was like, okay, well, there is a why. I'm going to try and answer it. And I came up with my own answer. There was a butter chicken shop on the other side, so I was trying to get away from it. But this just popped up. So I was like, yeah, it's too funny not to throw it on the screen. But the point was that you can question everything and anything, right? And it might not have an answer. It might have an answer. The point here is just use it as a tool. Just use it as a tool to approach your problems or approach your solutions even, evaluate your solutions from different angles. When we're talking about tools, like I said, I was never a designer, so I got into design. And one of the first things I did was I was like, okay, over time I realized Photoshop is where all the design happens. So I need to learn about Photoshop and Illustrator and Fireworks and Balsamic and all these tools. I was like, okay, great. I need to know about all these things. And then when I started just actually making my websites, I was like, oh, there are a few other things that people are talking about. People are talking about typography. People are talking about grids. People are talking about responsive websites, HTML5, all these things. And for the longest time, I would go online, read a blog or a website. If you're a web developer or a web designer, you've probably heard of a list apart, right? If you're a designer, if you're an app designer which has come up recently, you might know Dribble or, you know, everyone's got their idols, right? Everyone's got people. They want to follow and people they listen to and people they read. So that's what I would do. I had my RSS feed reader full of these RSS feeds where I would go and I'd look for answers, right? Or I'd look for explanations. I'd look for knowledge. I'd be like, okay, typography. What is typography? I'll go online and read a website about it. I'll read a blog about it. Okay, I know what typography is. Okay, I can use this, right? And typography says, okay, use different fonts. Don't use the normal fonts because they'll make your website look great. Use these, I mean, a lot of, you know, buzzwords start coming out, kerning and line height and gutters and all these things. So I would, you know, I would just read all this and never question it because these were the people online who I really looked up to. I would read what someone who I've been following for the last, you know, two years, I've been following that person's blog, I'd read about typography or skeuomorphism or anything and I'd be like, okay, that's our navigation, you know, floating navigation and this and that. And I'd take that as the holy grail. I'd be like, okay, that person said it, I don't need to spend any more time and I can keep moving on. To be honest, to be fair, I don't think there was anything wrong with it. You know, there's someone who's done all this research and I kind of respect it. So I'm kind of willing to say me, who doesn't know anything about typography, I don't know anything about the history of typography, but someone who really knows about this stuff is saying something, you know, I could have read a book. So I'm gonna trust that, I'm gonna move forward. There's nothing wrong with that, it's perfectly fine. The opportunity that I missed there was because I didn't question them, I didn't learn enough. You know, when I would, you know, use something in my designs, in my products and someone else would ask me, why did you do this, right? My question would be because that person said so or I read it on this blog. A few others like me would say, oh, fair enough, right? Yeah, yeah, that person said so. But you know, there's that opportunity, miss, where you completely skip over the fact that the reason this person said something, there has to be a reason behind someone said something. Right? They said, I'm gonna use this on my website. I'm going to use jQuery on my website because, you know, I need animations. Right? And I said, okay, anytime I need animations, I'm gonna use jQuery, right? I'm not a developer, I'm sure developers, front-end developers know much more about JavaScript than one hundred, but I'm just giving an example. I mean, okay, anytime I need this, I'm gonna use jQuery. What I would do is anytime I would need JavaScript on my website, the first thing I would do is script call jQuery. I mean, like, just because I need it, it's there, right? And jQuery is popular, everyone's using it. But I was like, for a while I was like, why am I doing this? Why do I need jQuery? What am I trying to accomplish? And it just gave me another kind of angle into it. I was like, hold on, I don't need jQuery. All I'm trying to do is make something load when the page loads. Okay, all I need is on load or on window load or whatever it's called, I can't remember anymore. But it kind of gave me that insight on where I started questioning this. And as soon as I did that, I kind of went into saying, now I know what I need, but let me go back and question why did that person go into this. And then I learned about why jQuery is actually important, right? So different things. Very, very related to this is this quote, creativity is the defeat of habit by originality. Does anyone recognize this? People in Bangalore should recognize this. Have you gone to Bentu Forum, the Forum Mall in Kormangala? Anyone? Forum Mall? Yeah? Have you been to the food court? I first moved to Bangalore in 2003. And at that time, Forum Mall was just opening. And I was living right down the road in front of Forum and I would go to Forum Mall and go to the food court to have my lunch and dinner and whatnot. I haven't been there today or yesterday. So I don't know if it's still there, but I'm pretty sure it should still be there because when I came back in 2006, it was still there. When I came back in 2010, it was still there. In the food court, they've got tables. They've got tables where you can sit and eat. And if you look at the smaller tables, where you can see four people, they all have these quotes on them in a weird design. You never look at it. But one of the quotes there is creativity is the defeat of habit by originality. That's where I got it from. And it's so true. This is exactly what I've been talking about, right? If you want to come up with new solutions, you have to question why you're doing something or why you should be doing something or why not. It really resonates with me with what I said. I've just been told I've got five minutes left, probably three now. So I'm going to just mention, these are some of the things that I actually already touched upon. This typography, we think of these things. I'll only talk about the line height piece here for the designers. It was an example that really stood out, so I thought it's worth mentioning that when I started looking at websites and design, and I was like, okay, line height is important. Line height is something that everyone uses. I went online and I said, okay, what kind of line height? I don't know anything about typography. What kind of line height do I need? And I found somewhere, I think it was Jason Santamaria, who said, well, usually 1.2 to 1.4 percentage or points or E and whatever you're using is recommended. I was like, great. And I started using that for the longest time. Very recently, I'd read an article by another guy, another internet celebrity, Olivier Riistan, from the information market. He was talking about responsive typography on the web, and he mentioned this. He's like, if you don't know what line height you should be using, pick up a book. Pick up a book that you find easy to read. So I've got this book. I don't know what the line height is, but I've got this book. I'm like, okay, the fonts are great. And I can easily read it. I love reading it. It's never given me any problems. So he's like, put it in front of you. Hold it where you would hold it. And you're looking at it. Now you've got some text in front of you. Now, if you're designing a website, put the computer, put this book down and sit in front of the computer, normally where it would be. Now pick up the book again and put it where you would hold the book. Now use that as a reference to make sure that when you're sitting here and looking at the website, the space between the lines should be approximately the same. He's like, that's what line height is. It's just a tool to make sure that reading experience is easy. And I thought that was great. I've been given Q&A. I'm just going to finish this point. And I thought that was great. And that can be applied to anything. You have a website. You have your iPhone. You hold the iPhone where you hold the book where you hold the book. And you're like, okay, I'm going to try to make it similar. So instead of just following what someone said, I tried to question why. I tried to question why are we doing anything that we're doing. That gives you interesting answers. As some of the lines, probably I can talk about it later. I actually, to be honestly, thought I'm going to be done in 20 minutes. But you underestimate yourself. There's similar things about grids and layouts. People say layouts are great. You need layouts. You need grids. 960 grid. 1136 grid. Why? Why do you need grids? The reason grids were started in the first place, even before there was any design thing to it, was just to make sure that the type designers and the printers had a standard. They knew that's my grid. That's what I have to say. The designer didn't have to go on to the developer and say, I make sure it's in this paragraph or it's falling into this grid. That was a tool. Skeumorphism is another thing that I'm going to skip over. So in the end, all I want to say is just question why you're designing anything. That's the main thing. Why do you even need something to be designed? And to be honest, the answer a lot of times is you don't. Your purpose is to build a product. Build a product. If you're not confident about something, don't use it because you're going to end up with something suboptimal. If you are, question. Question as much as you can. So that's it, actually. That's a great another. There's no foolish questions, only fools who don't question. And although I've run out of QA time, it still applies here. So if you guys have any questions, maybe we can take it. Okay. Yeah. I've just been told there's some time. So yeah. Any questions? Any personal anecdotes? Or any... This is one of the back. I'm going to put my Twitter, because I'm a Twitter slut now as well. Hi. My name is Sandil. I'm a content strategist. Where is this from? Hi. Sorry. Maybe I'll start up. So when you design a product, how important do you give to content? Sorry? How many? How much importance do you give to content? How much do I pay attention? Yeah, importance. It all depends on what product you're making, but content usually is very important. I mean, let me talk in this way, that when the purpose of your product is to serve the content, content becomes important, right? So content is very important, but I've heard a lot of people, everyone likes to say that, but in the reality, what I've seen is when we're building products, you get the idea and you're like, okay, this is what I'm going to do. Getting the content is also a process. So it takes time for the process for the content to start flowing in. So usually I still end up with lower MIPSIM on my mock-ups, because I don't have the content, right? Or I still will get, you know, gifs of cats dancing around for the images that I'm going to use. I don't have the content. But I think, yeah, I mean, it's very simple. Content is very important. The challenge is always to get the content on time. If you have the content in front of you and then you're designing around it, I'm pretty sure you're going to end up with a completely different kind of product. It might make even more sense, but the reality is you might not get the content on time. Hi, here. Yeah, hi. Actually, when we are talking about the wireframe, I'm from a product-based company, actually. But whenever the enhancements comes or whenever the new requirements comes from the client, what is the stage where we can start this wireframe? Is that, you know, during the development, before just before the development or while even talking to the, you know, clients we need to create the wireframes and explain? So wireframes, like I said, you know, for me, wireframes is a tool to figure out what you're building. And wireframes usually start on a whiteboard or on a glass window. We're discussing the idea. We just start putting things up there and like, okay, so this is what you're talking about. Yeah, yeah, yeah, that's what I have in mind because when you're explaining something to someone, you have something in your mind and you're using words to communicate with someone else and they'll make their own picture, right? And you might agree that, yeah, that's exactly what we want to build, but it might not be the perfect thing, the thing that each of you have in mind. So it's always good to just put it up in front of you. So that's what I say. You're having your ideas, discussions. Just put them up on the chalkboard, on the whiteboard. That's a wireframe. That's all you need. And then you start exploring all the different options. You might go into paper, sketching, or whatever tools you can use, you can afford to use. And you just take it from there. So it's, to me, it definitely belongs to when the idea is born. That's closer to where you should be experimenting with these things. Thanks. I just have a question. I'm just using my volunteer powers here. So one of the things that I always keep wondering about is how do you find the balance between data-driven design and going by your gut feelings? Because there's this whole new career about A.B. testing and all that stuff. And you want to use a lot of data from your customers and figure out which shade of blue works like Google did for instance. And going by your gut, which is, I think, the DNA of your design. So how do you find the balance between it? I think it's, again, I don't think there's any good answer there, right? Because it, I'm kind of talking from my experience now. What really happens is, right now, for the last two years, I worked at a product company. I was leading the product there, product design. Now, just about two months ago, I moved to a product design company where I'm actually, it's a services company where I'm in charge of product design, right? So it's different realities. Right now, a client will come and say, hey, we want to do this. And this is the amount of time we have. And if it's really not, you know, if you have the option of saying, no, this is not good, we need more time because, you know, we need to explore all the options. You can say that. But a lot of times you don't have that option, right? So I don't think the right approach might be to say what's the correct balance, right? The right approach, I think, is, depending on how much time you have and how much what your options are, that's the kind of product you're going to end up with, you know? And all this, again, is not a curriculum. It's not a discipline, right? It's exploration. So you, a lot of times, you just want to throw all the answers out and say, okay, I'm not going to question anything. I got my first idea. I'm just going to go with it. And then you can see if it goes around or not, right? I'm not sure I answered that question in the best way, but that's the best I could come up with. Yeah, so I quite like your idea about finding questions in your wireframes and product design on your wireframes. But there is a very colloquial line, parallelism by analysis. So I have been, till now, mostly been looking at product managers and product designers at work and trying to figure out now for myself how this thing works. So how do you basically balance between this whole idea of parallelism by analysis and keep questioning where you want to take a product to? It's very difficult. It's very difficult because the thing is all these usability testing and user experience testing and prototyping and wiring, all these teach you to explore as many options as you can, right? And that's the goal. That's the goal there as well. But it's very easy to get stuck into this and just keep not, you know, you get into the stage fright where you don't want to release anything because you're like, I don't have anything perfect. But one thing that helps there is you're never going to have anything perfect till you've actually put it out there because whatever you have in front of you is only true for yourself. You know, you can never be able... It's very rare that you'll be able to figure out the perfect solution just by yourself without putting it out there, right? Like, I mean, Ben gave a great example, right? He thought DocPad was going to end when Google came up with something, right? And if he was just thinking about in that close silo, he would have been like, oh, I'm dead. But people were still using it because people suddenly had another use for it, right? Or there was another scenario. So it's very difficult, but it's... I don't think I'm experienced enough to give you an answer. The only thing I can say is experience helps. You know, you release a few products, you get out with some stuff, and in the end what I can say is till I put it out to the customers, nothing's perfect. Nothing's perfect. And that's kind of why you make wireframes as well because you want to make sure by the time you get into the development stage, you're not already on a path that's completely different because you're going to spend three weeks developing something and then there is, oh, shit. So you do the exploration in the wireframe stage. Navjot, here. Hi, Navjot. Yeah, hi. Last question, sir, I've been told. Varun here. Hold on, there's two mics, sorry. Which one? Okay. So my name is Varun, I'm an engineer and designer, exactly like you. So what happens is, I've worked for a lot of startups, like four or five as I can remember, and whenever I'm sketching wireframes, they ask me why are you sketching? How does it help? And I've never had a definite answer to give them. So how do you convince your employer that sketching is an integral part of what you're doing? Well, I mean, the best way is actually to be able to show them why you're doing it, to show them the value of it. So when I do wireframes, I'm looking at all the different options. So I'll draw three kinds of signup screens. So I'll put them in front of them and I'll be like, which one do we go for? And they go like, okay, you could have done this directly, but how do you explain to them that... Why don't you come to me with the right solution? I know exactly. They start questioning you that okay, why are you sketching your wasting time? Because sometimes you spend like a couple of days, like three or four days on sketching. They don't quite get the importance of it. So how do you sit in and explain that it helps in your design process? I've experienced that as well. And I think over the time, I've become better at it. And one of the things, like I said, is just to kind of put it in front of them and say, okay, but the other thing is, I mean, sometimes I've seen, I just explained, I was like, the reason I'm doing wireframes is to explore all the options. Because if we don't, we'll go into the design phase and the development phase. For me to change my wireframes takes two minutes because it's a sketch, I can say no. Let's go on to the next one. I want to explore all the options, the UX flow, the interaction design, this often make a new one, right? So it's not going to take me much time, and that's the point of wireframes. If we go into development phase and we start doing this and we realize something like that, oh, this navigation doesn't work here, we're going to have to redo all that work again, right? So it's very cheap. That's the main, it's a very cheap way to figure out what your product's going to be. There's value in that. Thanks guys. And if there's more discussions, you know, I'm sure we'll catch up over the next two days. Thanks. We'll have five minutes break before the next talk. Guys, there's tea and coffee outside if you'd like to help yourselves. It's in the cafeteria upstairs.