 Hi, hi everybody. My name is Anand. I am a UX designer at Kukumbatown. We are a recipe blogging platform where you could post awesome recipes so those of you who are into cooking and those sort of stuff should definitely check it out. So designing at breakneck speed, as a designer when I read it, you know, it sounds very oxymoronic, right? So we as a group of professionals are institutionalized to think the top-down view, a holistic view of design where you are advised to spend ample time understanding the needs of the user, create the perfect wireframe and information architecture before you actually dwell down into detailing and designing your product. But unfortunately in a fast-paced startup culture or a small product setup where time and the money is kind of like burning every second, you probably don't have the luxury to spend a lot of time understanding your users and building the information architecture up front. You probably have a rough picture of what you are going to build but immediately you need to start showing results to the people concerned and stakeholders. So typically designers who come from fresh, I mean design institutes, young designers who have worked with find this kind of situation very difficult to comprehend and adjust to. So what is it like dealing with such a situation, right? So I mean in short it might sound initially something like this, right? So this is your ideology of design, a good design how it should be but there is a reality that startups and small product cultures thrives on the push culture. So you have to push something out to the market, see the traction, see the reaction from your audience and then improvise and build on top of it. So this is about the speed of delivery and then how quickly you are reacting to the situation. So we try on making prototypes, right? So everybody wants to make the 100% perfect prototype beforehand and then go into detailing of each component which is never going to happen in a startup because requirements keep changing. You will have a finite set of requirement when you start up with and then suddenly it's investor meet will have a new suggestion and new direction that the product might want to take into. So your core idea might take some twists and turns and you might probably have to revisit the prototype that you have made and so the idea here is to like kind of have an idea of what you are going to build, a rough idea of what you are going to make and don't try to make it 100% perfect, always leave room for improvement out there. So again there is a question of what is an ideal prototype? What can I actually build which is the perfect solution for everyone to understand? The short answer to that is there is no perfect solution. Early on when you start on a product in its very early stage, you typically will have this request from your product manager or the term master, right? I have an investor meeting coming up, you know, why do we have buildings in this feature? Why don't you just come up with a mock or prototype that I can show it to him. Now unfortunately not all solutions can be considered in a prototype at that stage because as a designer you yourself have no idea of what you are going to build. So how are you going to, you know, kind of visualize that in a prototype and then show it to somebody in a high-fidelity sense, right? So that will lead into unnecessary discussions, right? I didn't like the color. I mean, I don't think the labeling is not the right one. So you know, this is an example of how, you know, I don't know the picture is right but this was at Yahoo when I was working there, you know, early stage in a project, we didn't even have a proper architecture diagram in front of us. Since we were working in Yahoo, there were lots of components that were pre-built and the initial stage of the project was about, you know, connecting those pieces together and kind of, you know, build and work around and improvise those features and add more features into it. So we actually, we devised a nice way of, you know, kind of printing out or illustrating paper diagrams and then kind of connecting them into, you know, different modules with paper connections. So the idea with this was, you know, since we're all working in one team, you know, everybody, this is extremely visual. So it's not constrained into, you know, actual like wireframe, which has to have, it has to be referenced every day on a computer, right? So whatever you do, the prototype, the idea has to be communicated upfront and whatever method that you choose, make sure it is effective. So again, the early case of, you know, the wireframe or mock-up syndrome, you don't really have to make every design into a mock-up initially. The key here is to communicate the idea again. So in this case, you know, there was a constant interface difference between a mobile interface and the, I mean, online and offline experience, right? How are you going to show that in your five-minute investor meeting through mock-ups, right? So you could always relay upon making storyboards where the experience is captured and in five minutes, you, everybody in the room kind of gets the idea of, okay, hey, this is what these guys are going to build and, you know, kind of get the buy-in or make constructive criticisms and discussions happening around it. Now, once you start moving into making wireframes, quality time spent on a good wireframing. I've seen people making, hey, this is just a wireframe. My final design is going to be like, you know, my visual design is going to change things. Often people understand, underestimate the effort that takes to make pixel-perfect, you know, visual designs and, you know, coding for that matter. So any time that you spend on making your initial designs, you know, kind of in proper layouts, proper structure is actually an add-on bonus in your incremental product development lifecycle. So make sure the prototypes are dealt with equal seriousness. You may not get the time to do the actual visual design in the end. Documentation. So, you know, people who have worked with large organizations often complains that, you know, in startups, we don't have documentation. True, we don't have time to document. So, but even if I document, nobody will have the time to read it. So, we improvise. What do we do? We improvise. So this is a case where we were building a mobile app at Cucumber Town and the entire design was done probably in half an hour, the initial designs. So, as I was working on Illustrator and we started taking screen captures of each screen as I was building and then started posting them into HipChat to my team. So the interesting case is I work out of Chennai from my home and the team sits here in Bangalore. So we use HipChat a lot to communicate. So, since they could really see the rendering over there on HipChat's preview, we started debating and discussing over it. And then once it was, you know, kind of approved, a certain flow was approved, we kind of moved it into Evernote. And then once we voted up and then discuss it further and then moved into a Trello card. And see these kind of collaborative tools are your documentation tool when you're actually working in a very fast-paced environment. So, I think the next point, I think Chris might talk to you about a little bit more detail, I hope, when you're actually discussing it. This is one of the feedback that I got from him when he was reviewing one of our designs. That, you know, you have to make sure you document your components really well. Don't get into atomic details of, you know, how my H1 tag is going to be, how the spacing between the H1 and the next PETA paragraph is going to be. That's a pointless exercise because that's the kind of documentation which people will never going to read. So try to make sure, so why is it that Bootstrap is so popular among developers, right? Because it's, I just need to give a developer a doodle of this is how the components are going to be. They can just pick it up from Bootstrap and create a decent enough design with that. So think of your design documentation in that sense. Develop your components first. Make sure that things doesn't move around or change quite a lot, you know, once you finalize on those elements. So again, often in this script, in this kind of, you know, agile environment where, you know, you are like really close and work in a very pressurized situation. Getting feedback from real feedback from people and getting constructive criticism is quite tough. So, but it is really important to have your ideas bounced off against a neutral audience and to get it validated. So we use different techniques. Being in the consumer segment, we post a lot into Reddit groups where, you know, our core idea, some of these snippets of what we are building will be exposed to them. And then we track the feedbacks through that and then kind of improvise and build. This has helped us a lot in terms of getting feedback. Now Raj Gopal talked about data-driven design. It is really important, but there are cases where data can only exist when you have a design or a certain pattern. But when you don't have a pattern, you probably have to improvise and you have to go with your intuitions and, you know, see where it goes, where it leads you. So always go and approach UX communities and kind of get their feedback on certain things before you go with your intuitions because everybody in the design community might have validated your intuitions at some point or the other. When you get feedbacks, create a parking lot of all your ideas and if not today, you probably will have to go and revisit them at a later stage. Now, again, this is a question of, you know, how focused you are and when you are working in that kind of a focus, churning screens and, you know, developing at a very day-to-day basis, you often tend to look into your designs in a very page-based or even a component-based manner. So you don't have to look, to understand this point, you don't have to look any further. This is Facebook's, you know, New Street versus Facebook's, you know, profile page. You could see the stark difference in style there, but, you know, I don't think people really complains about it, but as designers, this is probably something that could catch our eye, because this was developed probably as two different kind of ideas. Each, we all know how the timeline has changed to this, so probably elements of the timeline might be still remaining there in that design. So taking a look back and see if your design patterns and minute details of your designs are followed through the entire site is also very important. So as a designer, personally, I would also advise everybody to be hands-on when you are doing design, not this interaction design, because especially in startup environments, you have to be a visual designer, you have to be an interaction designer, you have to be a, you know, front-end engineer to some sense, because that's what gives you a lot of control over your design, right? If there is a feedback on a small font size or an alignment or something that you get from somebody, it is not something that should take you a day to fix. You should be able to have your own git check-in and should be able to make that correction quickly and, you know, get it out of your system. So to summarize, these are the things that we need to remember. It's a participatory game. Everybody can design. So small startups, everybody has to do some, has to pay some sort of designer role. So being a designer in a team, you should actually be the enabler of those things. Your component should enable a normal developer to take up your Doodle and build a component or an admin system with that. So that's, you shouldn't be a bottleneck at that stage. Establish the idea of the storyboard example that I've given, prototyping early and often and being hands-on at the last point. So, yeah, this is to summarize the points in slightly philosophical way. So that's it. Questions, please. Hi. Yeah, that was a nice talk. What about a no-chrome flat design? Sorry. What about flat designs? Yeah, so that is something that I had in my notes, but then it was extremely subjective way of looking at things. So then I thought I would remove it. So the idea was that, you know, when you go into documentation and detailing, a small line or a drop shadow or a color that you are actually add on a design is actually going to make a two, you know, a small change to that is not a small change eventually in the end because it gets added up the different components that might get affected to that. So that's kind of goes back to the perfect wireframe idea where, you know, you make that wireframe perfect with the minimal elements and then that would eventually adding very minimal styling element to that would eventually build up your final visual look and feel. So that's where I think the flat design scheme that is a kind of a trend these days can come to a lot of, you know, importance these days. You talked about building a visual design dictionary or kind of an encyclopedia and you showed the example of peer. Any more comments on that? Any ways you recommend would be the right way to do it or any things that you've had good success with in doing that? So honestly, I discovered peer very recently and so the small example is that, you know, when you start building components, you know, the components eventually improvise, right? So take the case of Facebook's like box, right? It was not the like box when it started, but now it has reached to a maturity where Facebook has to use the same like box everywhere across wherever that similar module appears. So over the time, you evolve a component and at that stage, you have to realize that this component, this is a potential component that you're building and then probably try to sit with your, you know, lead front-end engineer to make it an independent piece and have it documented like the way bootstrap does, right? All you need is a master bootstrap file and you just call the component and anybody can build that component in no time. So that's what I meant by looking at. So peer is probably something which you as a designer can start off, right? You don't need the developers assistant there. You have your HTML file, you try to make it and then probably give it to a developer to do add the necessary component structure to it and take it home. Just a quick follow-up. Nobody else's. What about things like style tiles and any feedback on that? Have you ever used those things? Style tiles. It's where you take just a small piece of the UI and kind of put your style in there just as a visual reference while showing off your design. You mean say sort of before you actually start of the design. You used to do mood boards if that's what you meant. So to basically show people that this is how eventually the site would be built up to. But if that's the case, mood boards are often not a meaningful exercise in my opinion because very good chance that you drift away a lot from the initial mood board pattern that you conceive. And if you're looking at having the basic theme structure you could use maybe if you're desired on the base framework that you're building upon. In Cocombaton we have a customized bootstrap framework where we created our own theme on top of the basic bootstrap framework and that is being used as a reference. So just wanted to check your designer. Do you actually spend a lot of time holding CSS and plus you'd also mentioned the bootstrap theme just now. Is that completely enough? Can you just make the bootstrap theme and leave it at that and can the developers just use that? To a lot of extent, I mean once the design reaches certain maturity in terms of the correct layouts and stuff like that, for doing a small improvisation to a, let's say a pop-up component, right? All I need to tell the user, my developer is to like refer to those components and kind of build it. What a little polish it might need afterwards. It is because I have worked on those codes easy for me to just clean up and push it. So yeah, as a designer, I work extensively on coding.