 Good morning. Check. Hello. Okay. It's working. Welcome everybody to, okay, let me recall when did we launch Meta Refresh, 2012, 13, 14, 15, 16, 17, 18. This is the sixth edition of Meta Refresh. It's Meta Refresh has been the most interesting brand at Hasgeek. Those of you who are familiar, J.S.Poo, Meta Refresh, Swift Elephant, a lot of these other conferences are run by the parent company Hasgeek. For us when we launched Meta Refresh in 2012, the idea was that the web was developing so fast and how do you kind of help individuals do a complete paradigm shift because if you come from a print paradigm that doesn't work for the web. And I think over the years Meta Refresh has evolved in fairly interesting ways but also very challenging ways. One of them essentially being that there is a gap between designers and developers and I'm sure that those of you sitting in the room will have a lot of points of contention to this and I think over the years what we've tried to do with Meta Refresh is to understand how to bridge the gap. I think by the fifth or sixth edition we realize that we can't play Jesus Christ in this situation because the gap is there. It's fairly entrenched and this requires a completely different approach to think about how to now talk to designers and how to talk to developers. Whether this is done individually, whether this is done collectively, that's still open for debate. Having said that we decided to bring the brand back in 2018, primarily because we recognize that there's a real need in terms of learning and in terms of experience sharing among people doing design and doing design from the programming perspective, doing design from the design perspective and doing design from the product perspective. And with this recognition one of the commitments that we made internally is that we want to now turn this into a learning program which is available around the year to people and that there are various kinds of things happening under Meta Refresh which also then means that Meta Refresh as a name itself needs to kind of change. And so this conference is a nice way to get suggestions from the community in terms of what we should call this going forward. So if you have suggestions we'll keep a suggestion box outside and you can drop your suggestions in terms of how we can rename the brand and hopefully the next two or three months as the brand undergoes re-daming this community will be responsible for the rebranding altogether. On that note, I have two special word of thanks to give. I think one is to my colleague Abhishek and to Tejas who's speaking here for insisting that we rethink of bringing Meta Refresh back and we approach this from building the community which is really what we are going to now invest ourselves into doing. So I'm very glad for both these people to be very pushy and to make sure that this happens for the good or for the worst. So in that case they'll be my partners in crime. The other word of thanks is to Hasgees founder Kiran Doral Gadda and to people like Nakhul Shinoi who have been pushing us to think in the direction of how to serve the community better and better. So many thanks to all of you for helping us to always think outside of the box and to constantly be very aware and to keep our ear to the ground with respect to what the community's needs are. On that note, I think I will stop talking and I'm going to let the speakers take over. As usual, we have feedback forms here. Please do turn in your feedback and suggestions. And like we said, we want to rethink about renaming this brand so if you have good ideas and if you have not so good ideas every idea is welcome. We'll put a suggestion box outside so please do turn in your suggestions. On that note, I hope you have a very good conference and thank you to all the speakers for making this happen today. So good morning one and all. We have Nakhul here who will be sharing his viewpoints on UX and UI with all of us. So Nakhul, good morning. Am I audible? Awesome. Just wait for people to settle in. As they do that, just for me to get a quick feel how many of you think of yourselves as coders? Awesomeness. How many of you think yourself as designers? And how many of you think yourself as both? Awesome. Thank you. It's my pleasure and honor to be presenting the opening keynote at what I think is a fabulous event. And so I am taking the unconventional approach. I'm sort of sharing what I think or my perspective on what I believe user experience to be. So I might go into areas that are not normal but at the end of it I think we will all find a cunning. So welcome to my world. A world which is filled with words. I mean I got into this world in 99 and it felt like half the business was in the business of making these words. Those days the fight was am I an information designer or should I call myself an information architect? Today the fight is more about should I call myself a UX guy or a UI guy or am I UX slash UI? I think it doesn't really matter. What really matters is user experience. And everybody has their own meaning to user experience. Most of all our clients, right? And somehow their understanding of user experience is quite different from how we see it because we look at it many a times with this whole fight of what is UX and what is UI. We go on about no UX is more than UI because UX involves research. UX involves meeting people, doing a lot of things but as UI is basically about the screen, right? Interestingly that's how the clients are only interested in because the only thing they keep coming back to us is can you put this color here? Can you move this button? Can you make the button larger? The orange company where I am consulting or rather serving as the head of their UX team the recent fight is what should be the color of the button? It should be orange because people click orange and if it's blue they will not click it. Why? Because somewhere there are a couple of articles about why Amazon works and I said perhaps it's linked to the brand. The brand color is orange? So we all have our own meanings and why we go around it but I think the primary thing with UX creating a user experience is to keep in mind this that we should actively, always, continuously keep learning from mistakes from our mistakes from past mistakes. We can go back to Nielsen and say frames are bad which is a joke in the community and so we have deals and other things or we can basically say here's a collection of topics on which there have been others who have studied written design what can I learn from this? What is it that I can use to make my design better and my user's life easier? And which comes to this is not user experience, right? This is a meme. I was just looking around for UX. How many of you have done a search for UX memes? Do that. I mean if that's the one thing you take out of my session today do that. It's fantastic. It'll take you down a rabbit hole. So that's how I found Rowan Atkinson, the bean character. That's how I found this. Think about this. Today when we make a call, we are put on hold and we get to hear jazz, we get to hear flute, we get to hear oh the latest one. The latest one? Marketing messages. Have you tried calling ICICI one of these brands? All you get is like half the time you're thinking okay perhaps they do not want to answer my call because somebody in marketing says hey you know make them listen to this new jingle I have made. Spend a couple of minutes on this. Why do you think this came up? How many of you drive through Maratholi? Okay. That was my life. I was at SAP for a few years. I remember when the Maratholi bridge was out of Maine you would go under the bridge. Actually first you would climb the bridge when you're going from this side, it's a japa side and you would take a right. That caused a block. So they just said let's redesign this. They asked us to go under the bridge and take the first right. People who have done this? Okay that dates you. And then they said oh this is causing a block. So now we will push you slightly further, 200 meters take a U turn, come back and go. Yes? How many of you has done that? Okay that times you see. That tells you when you started traveling to Maratholi. And then it's now almost all the way to Isro and then a U turn and back. Right? Why do you think this is happening? Because we are not going back to the crux of the matter. We are looking at every problem, every design problem with a fresh eye but not looking at the history. We are not looking at what originally caused the problem which is where we have now got to very recently that you again climb the fly over take left take a U turn and go. Design is like this. This was people called a call center and you were put on hold and you heard that same train, train, train and you said this is boring. So what can I do? What can I do to solve my user's problem? Let us play some music. Music is good. And then the problem originally was the wait time. The real problem of wait time was never solved. Wait time only kept increasing with more number of calls coming and now with marketing coming you are even wondering do they want to solve the wait time. So perhaps the one message that you can take back is every time you are trying to look at a UI an interface and in today's world interfaces can be anything. They don't even need to be a screen. They don't need to be a button. They can be what we are doing right now which is voice. It can be just gestures and soon I hope just mind control because I delve in that side of the world too. So if you think something, you know, that should happen and some of these advances in research in MIT and others are sort of delving into that area. We are not there yet. But can we each time look at something with a real fresh mind and do our own bit of research. I am not saying user research. I am not saying get people in a lab, I mean if you can do that great but how many of us actually get that opportunity? I mean for me with nearly two decades in the business I have done actual in lab research perhaps 20% of the time and for most of the time my job was as a user researcher. And so that sort of is, I mean, even as much as last week there was something and I was like, yeah, we need to do research on this and it was like, yeah, yeah, you can do research but for now can I have the screen? Right, so yeah, you can do your research. That's okay, that's a pick on the Excel. You can do that. So that's where we are today and most of what UI slash UX is is not our problem. It's the problem of the industry. It's the hiring problem. I was speaking to a group of HR professionals yesterday and that's exactly what I was speaking to some of them and companies don't know what kind of a role to hire and that is where the word UI slash UX comes in. If you really look at it as a practitioner, all of us, if we create any kind of interfaces and I don't, not just saying design, I mean coding, I mean anything, right? If you are involved with one small chunk of creating an interface, you are a user experience guy because if there's a very brilliant design and it comes and the product decides, no, this is very, very, very difficult, right? And so we will just, you know, put a button here or a checkbox. That's it because that is the interface the user is finally going to interact with. So we are in this together, yeah? Every single one of us, which is why UX as such is a team and what kind of a team? I forgot about this. These are the tools, right? Most of the times we are so caught up in the kind of tools that we are using and we are creating the interfaces in that sense. It's like planning a dinner, giving only attention to the cutlery. And so, yeah, so we are trying to create this but none of us can create this because that is literally every single element to it. We can actually come up with a most wonderful experience for a user or plan and design, a wonderful experience for our user but let's imagine this to be a shop where some, you know, this wonderful shop that is inside, once they walk in they have the most out of the world experience and a great time but in entering the shop all that they are going through, including the traffic, which you have no control over is going to impact their user experience and yet we claim, some of us, me included, that no, I own this small corner in this multiverse. Even when it's a dinner, even if it's a very, very well planned dinner and you've got the right ingredients and you've got everything in there it's the company that matters, the kind of conversations you're having that matter so clearly there are a lot of things that even a restaurant cannot own cannot control. It completely depends on what happened halfway through your session so that sort of brings me to what I'm talking about, creating magic because alongside my UX side I have been a magician, I have been performing magic almost all my life and I try to find what is a parallel, if at all, between magic and user experience and I mean magic I mean magic like Copperfield flying in the air because when he did this or Dynamo walking on water this was bringing dreams live and of course beating death with Blaine. Blaine basically took one of the oldest effects in magic which was catching a bullet more than 20 magicians around the world have died performing this effect because something that can go wrong will go wrong and being Blaine he wanted to still perform it in such a way that it has never ever been performed before and yeah, he almost killed himself but he did not because before he actually did the televised final recording he had gone through a process in magic known as the Holy Grail magic has always existed magic goes back 6000 years the first of magic performances was in the Egyptian you know, Kramid times in the court of Faro sorry, Faro Cheops and performer magician was Didi and Didi performed one of the most phenomenal effects he took a hen chopped the head off and there was a headless hen walking around and then he put the head back and then it was live and walking around still Blaine by the way had recreated this recently on one of his televised episodes but what is the Holy Grail? the Holy Grail is that you take anything and you look at it and go in the field of magic and I find a more purer way of doing this and this is mostly the method what's making it for the people, for the users it's the same experience but internally you are going okay, but I am using this technology for this I am using this method for this can I improve on this? can I make it real magic? because as magicians we know we don't have any powers sorry, somebody here actually thought we had but you are essentially trying to create a character that seemingly has powers and every time you look at something that you do you are going but this is not perfect can I reinvent this? and this is what you do you sort of learn something you develop on it you try it out you practice it you rehearse it you perform it in front of the people and then you observe yourself having done it and the cycle starts again and the cycle keeps going and going not just within one person but through centuries and the classic for that is this do you know what this is? it's written down there sawing a woman in half this was the first time the sawing in woman was performed back in 1921 Selbert, what a lady in a big trunk sawed through it in a park and separated no sorry, didn't separate it just sawed through it and it was all over the world and then some people and more importantly Selbert started thinking yeah but how do they actually know that a lady is inside it? if you just see the picture I have to tell you there's a lady inside it and so came the next version where you could see the lady's head on one side and her legs on the other and then they did the same thing they cut through user experience roughly the same methods getting improved but actually user experience also is improving because now it's more clearer what's happening now people looked at this and said yeah that's fine I can see the head I know the head is sort of moving but the legs sort of looks stiff and it's sort of you know wooden-ish and so they said okay let's remove the box let's just completely remove the box and this is our own PCSoCast senior who performed this on the BBC in London and a very interesting thing happened at that time at the end of the show as he had just cut his assistant the show ran out of time and the curtains closed and this was live at those times right 56 and people thought he had just killed a person on live TV and so that's how half his fame came from because this went viral not viral in the way things go now but the phone lines you know the phone lines just went berserk people started calling in and saying oh the heck is happening and they had to say no no no everything is fine this is all an act but to see the whole act you need to come to the theatres and so it was a sold out month but really here in this act you are seeing the lady you're seeing no coverings etc and you thought okay I think this is perfect cannot be improved think again because somebody said all that is fine but how do I know that she's actually cut in half so somebody came up with the idea okay I will just have this and you can see her hands are moving you can see the legs the legs are moving but now you can separate it and I can walk through it really look back if I can use the word interface or effect or UI whatever that is it's the exact same thing it's sawing a lady in half and this was what we thought was phenomenal until this happened this was Copperfield where an act seemingly goes completely wrong and he gets cut and the two things sort of separate his legs are up and this is also the first time the magician cut himself right not the assistant and they separate out and Copperfield is sort of looking at the audience the legs are still and somebody from the audience screams out move the legs Copperfield looks smiles turns back and then the legs start to move that's such a theatrical moment but again that is user experience the element of doing the unexpected and doing it slightly more at the point when the users are expecting right the element of service magic in that sense that Disney keeps talking about even if it's about giving the child that walks into a restaurant one small 2 rupee car it's not the 2 rupee or the 5 rupee or the 10 rupee that went into that small bubbly ball that they hand out to the kids or the chocolate that they hand out it's that element of unexpected gift right and that's what makes user experience such a challenging field because like it or not every single day we are trying to make magic to make magic for our users and you thought that couldn't go forward could do because then Kevin James did this Kevin James basically got a person on stage cut him in half and the torso walked off you must have seen the Chris Angel version of the same torso sort of running around a park and freaking out people so I don't know what the next version is going to be but it's wonderful that cutting in half something as unimagined because it's nothing that existed somebody just thought of this idea hey, resurrection why don't I make a theatrical version of it and it's come till here so yeah personally as a performer I'm really keen on where that is headed but as a UX person or a design person I'm really excited about the magic that's happening in our living rooms in our lives the next session and others through the day are talking about some of these aspects about how we can just talk to something or we can just say what we want and like I said I hope pretty soon just think what we want and that will happen because most of IoT is exactly that it's about thinking what happens in magic what happens on a magic stage what happens in a magic book the buttons that Amazon created for Bolt I think they called it you sort of stick them on your refrigerator and things so if you run out of a particular thing like washing powder you have a button called washing powder you just touch it so they called it magic buttons where does that come from the idea that you have the Aladdin's lamp that we had at the start Aladdin's lamp is itself an inspiration for so many different things in Internet of Things the element of how we interact with magical objects they make magic happen and that is the element of that is when the interface sort of morphs into the experience itself because the interface starts getting invisible like you saw in the magic acts initially there was this large bulky interface which was seemingly there the time it reached Kevin James it was just the person being cut in half and the interface sort of became invisible to me the process I just sort of shared with you which has been followed by magicians for over 6000 years of trying to imagine the what does not exist and try to create it and try to create a wonderful version of it is very well documented in the design thinking slides because design thinking again was not something that was dreamt up the element of how does logically how do you come up with design how do you create a design how do you go about imagining and developing something was captured back into a model and said okay this probably is one of the good models to work it is not a holy grail we can use it to create our own holy grails and I think we absolutely need to because as I keep saying whatever it is that we do we are in the business of creating magic magic for our users so let's all create magic thank you we can take a couple of questions for him so any questions anyone for the staff we have any questions okay so thank you very much we have one so during the talk you mentioned like you asked your consultant can I do user research and you get the answer like yeah you can do it but you get me the screen first so how often you said no to them kind of like you did your user research and gave the prominent user experience so how to how to handle that that's a very good question I think it's completely dependent on the kind of project you are doing and the kind of screen you are building it's not to say that every single screen we build needs user research but if you are doing incremental or if you are doing a completely reimagining of a screen or an interface or a product user research would be very very important and in this particular instance I have not delivered the screens because it requires user research so the element of I mean as a designer you would need to know when is a formal user research required for this right again when we say user research it's a wide terminology what are we referring to are we talking formative research are we talking in lab research are we doing post validations right we have screens and we just want to test it on users that's validations so in that element it completely depends on you knowing very clearly what kind of inputs are required and if you are convinced these inputs are required for me it's I mean you've taken that call and so you have to stick with it I have been lucky I have played and perhaps also because of the kind of companies I have been associated with research has been respected and it's always I mean even in this particular one it was like okay you have demanded to do the research but how long is that going to take that's going to take at least two weeks even to sort of set up and get people and get a report even if we are doing everything ourselves so is that something we can do in the interim now that's a call we have to take project to project company to company because many a time the interim becomes permanent that's been my fight with dev all my life you give a design and look at it and say this is all fine this is wonderful but right now we don't have the bandwidth so we are just going to do this and we will come back to doing this screen come back to that is an open-ended question so whenever it is out of scope I come back and ask so out of scope never in scope what is it and if it's out of scope when is it going to be in scope so you put a timeline right there when you are agreeing to sign off on that screen that you know the dev has given you and is going live and saying okay I say okay to the screen go live and at that point you need to know when the redesign is going to come in one of my most recent examples was I needed the screen to change from black to white very very very very difficult right it took me a month to finally get them to make that in scope because the screen would just go because also I mean a couple of buttons would change color and css would need to be changed for whatever reason the earlier design went live and then the screen is live what do you care so that's the sort of a long answer to that question because there's no bullet on it so UX as we spoke tonight is kind of a subjective skill as opposed to really being objective so how do I hire a good UX guy I don't want to go behind a person who claims that I am a React guy or I am a Node guy because that is essentially like saying I know how to drive a car what they mean is I know what are clutches I know what are breakers but I really don't know how to drive so a very very good question and point isn't that how we hire everybody nowadays so I just said I want a React guy that is actually the problem right so I am just your follow up or do I take it take it follow up then alright go ahead so earlier to the industry things were easy hiring like I said I just had an evening with HRFox yesterday it was do you know Photoshop come today they hope do you know XD come it's not that simple is it so how do we go about hiring even as design folks it's extremely difficult for us to find a right mix which is where that whole dichotomy of a meaningless word as UI slash UX appears I mean go up and do a search why there is no such thing as UI UX because you can't have UI without it contributing to UX and you can't have UX without UI right so it's basically that it's a surgeon saying I need somebody else to just you know use the scalpel and then I'll do what needs to be done afterwards right so the problem there is I think there is no easy answer it has to be an element of trying out people more importantly giving people the space to learn my of personal speaking again I would not generalize this has been to try finding people who are interested in the area interested in learning and doesn't matter what their background I am not a designer I've turned into a designer and my personal feeling is if I could do this anybody can right because otherwise I would have been a writer because that's what my academic background is not a technical writer so it's essentially that I mean that's a good example that's how specialized we are today we want a technical writer or we want a creative writer we want a content writer and we want a brochure writer whatever that is no I just want a writer so in this concept I need a problem solver right I need a designer now whether I cannot to save my life understand colors so I am clearly not a visual designer that's easy like I said can you do Photoshop or can you put colors on a screen you are a visual designer that part is clear but the rest of it has to be an experiential thing you have to give those people tests or just share experiences to understand can they solve a problem can they solve a design problem first of all can they try a problem and then solve it because most of our problems today why do half our products bomb because the products we design are based on the latest technology that comes out it's like magic magicians for a very long time created magic around the latest technology that came out hey bluetooth is out so let me create something where you write something and I get it here and I know I can read your mind right it's technology based it will only work to the point where everybody in the audience does not know bluetooth exists that catches up with you on the tech side it's different blockchain yes so my product is blockchain what does it do in blockchain I am working on blockchain what I am in my earlier assignment so I said okay blockchain so this is what you need to do oh that's complicated that went out of the window so when can we stop I mean technology is important but when can we say technology is magic technology is this little bullet it's not what is the real user problem you're trying to solve and how are you going to solve it based on that see what technology maps do and that same thinking it's difficult but is the only way I can answer a real world answer to how you can hire designers thank you very much have a great day thank you Nicole thanks for it we have been a perfume announcement I think it's very useful that these questions are coming up because I think these are questions that will help us build a program like I think just now just like you know prompting ourselves while Nicole is answering questions that maybe we need to have like a special session on how to hire UX designers so please keep these suggestions coming the suggestion box that we put outside because this will really help us to understand how to structure smaller group sessions and more interactive meaningful sessions where you really have more concrete takeaways on that note so two quick things we actually are closing keynote by Rahul Gonzalez this afternoon is really about hiring for design so don't miss it the other is that we since Nicole was talking about why technology is not always a silver bullet remind me that we have a birds of feather session at 2.40 pm which is going to be on ethics and design and ethics and technology it's going to be a discussion from an anthropological point of view to understand what the challenges are to get inputs and feedback please feel free to join the discussion this afternoon Sunny over to you so here we have Tejas Bhatt and he will be sharing his view on how design systems can actually improve communication between the teams so over to you Tejas Mike hello can you all hear me okay awesome morning everyone I'm going to do this very curiously titled it's called the doctor design system or how I learned to stop worrying and remove the chaos after a lot of talk about an explanation about magic this talk is going to be a little bit short in the arm of reality okay so I'm going to repeat the question how many designers do we have here can you just raise your hand okay a few and how many devs do we have a lot I'll have to deem that okay designers have you ever been in a situation where you design something you give it to the devs you saw the coded version or production version it was very different from what you had done just say yes so awesome and devs have you ever been in a situation where you received everything like this does not make sense why are there three different buttons with this shade of same blue does that happen and you can also say yes just give me a yes okay so this is not a unique problem I'm glad it's not just my company where this happens but yeah in products and service companies when you're working together on multiple functions it also often happens that people are at war with each other on the ownership of the actual derivatives to the clients or users it's like everyone is pulling things in that direction without a clear communication between the teams so design systems the talk is going to be about my learning some of my learning and how building a system has kind of helped solve these type of problems but the experience has been that so far in teams everyone is fighting for the control of the overall processes it's like we are in our own game of thrones they're just fighting about something so the title of the talk is reviewed to a film called doctor strange love for how I learned to stop worrying and love the bomb the reason for this tribute is we had a backdrop of cold war between US and Russia and I think similar cold war exist in companies between devs, testers and designers so this title made a lot of sense to kind of refer to that cold war like I was saying it's as if we are in our own game of thrones some are house of planister house of stock and our managers or white walkers so to give you a brief intro my name is Pajas I've been designing for in various roles for about 10 years now and I do a lot of things some of you might recognize the company called uncommon based out of Bangalore and a lot of other cities I was one of the co-founders there I also worked I also teach or mentor you experience two things that I am interested in so let me jump right then how many of you have used design systems or a variation of it in your work have you helped few people so I would assume lot of you are interested in design systems but have not used it right so what are design systems when we talk about design systems and you see you Google for design systems and you will see like lots and lots of products which are like ready made design systems you can just buy them, download them start using those systems to create your products but what are design systems when we talk about design systems what is it design systems is documentation or laying down of foundations or principles that you can use to build your products it's not just something it's not your only component library it's not your react if you build something in react or java, petri, css it's not those libraries at all the foundation of a design system is the principles that you create in order to kind of build the entire product it involves a lot of other things than just component sheets because you have to think of the product in terms of a whole then screen by screen and component by component atom so it is very important because as we see further the principles will be very important rather than the actual deliverables and content of your design system so if you think of components and different ingredients as Lego blocks design system is the guidebook that tells you how to make super or castle out of those Lego blocks so just to see some of the some of the ingredients of design system first and foremost like I mentioned the core principles of your product what problem you are trying to solve with the product and more importantly what is your user experience take on it right so it's not just okay we need to use 12 column grid or something it's how actually we are approaching the problem solving in the in the product for example so this is it might not be very legible but this is something that I am recently working on and for the products design these are some of the foundational rules that we are coming up with in the user journey so for example how we come up with very logical defaults for all the options all the drop downs or all the configurations in the product so these type of things in part of the user journey in building the product is those principles become part of the design system because everyone else all the other team members not only other designers other developers can also think from this perspective how we are making for the user and at the more component or more craft level or some of you might have seen this this is from material design and how they define some of their core principles like they are using they are using material as a metaphor or their aim is to make their app very bold graphic and intentional and they use a lot of motions to provide feedback and different states communicate a lot of differences so content is one of the key part of design system which includes language that we use in our product images, illustrations and could use a lot of other media like videos first voice and tone so even if a product is mostly media something like instagram or youtube there are still a lot of messages a lot of text and labels in textual format so products are still a lot of textual communication in your design system you can define how you what is the tone of all those messages what tone are you taking to talk to your user whether your messages need to be very concise or you want to make them a little bit elaborate whether you want to use humor as a way to talk to the user or if it's an enterprise app you might say ok you want everything very straightforward the last point is very important in today's time it is inclusiveness how your messages and your text make everyone feel included in your product so to take an example use a pronoun normally we use the historically we only use E for any third person but how you actually move from there to include other genders and non fluid genders also so those are the things that are very important when you are defining your product content strategy this is an example from MailChimp who did very early work in voice and tone of their product I would really recommend reading their take on it next is images so how many of you started using internet very early like late 90s early 2000s have you seen images like this on website so like if a service company was based out of Bangalore or Hyderabad or Ahmedabad anywhere they would still put up an image like this to say that ok we are very professional it was because there was a lack of awareness people didn't know that you could put pictures of people of other colors or the activities or the genders or there was lack of resources there were no resources online to find pictures which represented people like us everything was very white at that time not to be offensive to anyone so you can define in your design system how you again can be included in this manner what your image strategy should be you want to be inclusive you want to be very diverse in your photos and some more technical stuff like what image size or resolutions you need to support so why are we talking about content I mean if you are designers and developers it's not really our job to talk and define content right it's someone sitting in the HR or marketing or legal who does that why are we to talk about it so A first answer is the cliched one which is content is the king of content but more important thing to me is that when you work on content with other team members people in other departments it gives a shared ownership of the product and the strategy not only that it helps you break down an eco chamber we all work with people who are like us designers work with designers devs work with devs you don't even know who those people if we work on this together let's break down that eco chamber and have a more diverse have more diverse opinions on the product and its building typography a lot of interfaces are still text which means typography plays a huge role into not only being legible and communicating the text but also to communicate the tone, the mood, the values of your product the typefaces you select so typefaces first selection is the typefaces which again falls back to how legible they are how accessible they are at different sizes what mood they want to come in you want a playful typeface you want something serious that's a little bit of work on and scale we actually scale choose the type sizes to fulfill this goal so I work with a company called webengage they based out of Mumbai I worked on the design system and when we started to explore the choices of typefaces there is an enterprise app so we started to look at a few workhorse typefaces Ariel and Helvetica they have always been there we also looked at San Francisco Roboto the two main native typefaces we compared them and kind of decided on Roboto was a good choice but when we saw that using Roboto at multiple weight it kind of flowed down the website completely we went with a font stack which looks like this some of you might have used this but all this does is some fonts have become much better so we went with this and established the typographic hierarchy to do this colors again colors you go back to your brand what your brand wants to convey so a lot of times color palette would already be decided by the brand how you take that and then test them for different things different combinations like you come up with color palettes from that this is a primary color palette that we use for web and gait but not only that as designers you also have to decide how to combine different colors so that they fulfill the requirement for accessibility people who don't have a strong vision as most of the people but lot of people do fall on the on the spectrum of visibility where they have some problem with detecting colors so we established a secondary color palette using nature colors because this app uses a lot of data visualization so we used picked a few natural photos of nature and have derived a color palette out of that and also associated this theme with emotion emotional state in the web so this was our secondary palette and how it went on a spectrum grid and structure so you can define if you want to use a strict grid something like a 12 or 16 column or if your app demand it or your product demand it you can simply do away with the grid there are ways to design without grid or go with a hybrid grid you can also define how your product responds to screen sizes and for your typography and all your elements you can define something called vertical rhythm for example those of you who have used materials to use a baseline of 4 pixels so every component is kind of multiple of 4 so you can that helps in creating a very easy to follow rhythm on screen so this is an example from IBM's carbon design system and how the grid system responds to screen size changes and another example is for how typography sits on a vertical baseline component sheet I am guessing that a lot of you have used component sheets you have like a huge component library with different components drop downs, input fields navigation component sheets are the most popular form of design systems and a lot of times component libraries are sold as design systems people just say hey here is a HTML series of everything this is a design system but they are just part of the whole not really whole itself it involves defining all the elements and components and how they are related with each other which is more spec like padding margin borders, colors etc and their behavior how they behave under different browser or step states when they are active, hovered etc and states like how when a user is interacting with a composite component or a component for the first time what sort of information they should get what they should get when they are using it there is no data to different states like that this example is from Shopify's Polaris by the way and they have a really good design system so to summarize the design system is made of the core principles of your product the content and content strategy, grid typography, colors the component library if your app uses a product uses a lot of data visualizations those in the system icons you can define your iconography if you have motion design you can define principles for those as well so why we need design system let's say you have very cordial relations between all the teams your work just flows smoothly you still need design system what will it solve, what problem will it solve I would say yes because what we have noticed from a couple of examples is that there are other benefits of using the design system which we will just jump into first communication using design system makes the communication very easy between teams so you can establish rules at the outset kind of share it with the entire team and then communicate using the same terms and same language so it becomes very easy for people to refer to different things also when you are designing when you are developing a developer you know when you receive screens or new clothes or something that there are not going to be any surprises there won't be the appreciates of the same button anymore because it will be hopefully picked by from the same repository that you have already established similarly for testers you don't have to repeatedly test the same thing because it's tested and certified once now you are just combining it into a different configuration so it eliminates all the surprises and these type of constraints when you already have an established system and the repository it makes life easy for everyone so this is an example from a product called intercom and if you see you can't see it very well but on the left is the definition of a component called conversation how they are using the same in a sketch file or in their design deliverable then they have a code component called conversation not only that the same phrases or the same terminology is used on the help docs as well for the end user so starting from product definition to your end user you are talking in the same language which means you have very happy designers, devs and testers to translate into happy users when you have this type of synergy in your teams it goes very well to your transfers to your users as well scalability having an already established design system makes it very easy to scale your product at web engage specially they saw that they didn't have to create new components or anything for almost a year and which meant they could wireframe something and start working on the design of visual, putting together the visual design and production immediately from there it created a very lower turnaround time from coming up with a low fidelity concept to production and which means money when you can scale things fast between concept to production it saves a lot of money for the company it makes sharing the knowledge very easy not only between designers but in the entire team and your outputs are consistent because two designers are now not coming up with their own version of the same design earlier if you have worked in team with multiple designers one designer will give you something but the other one will have something slightly different you don't know which one to trust which source to trust that kind of inconsistency is taken care of cross functional teams can see the rationale behind the design decisions from your documents because design is often seen as something where you only see the mock-ups you don't know why and how those mock-ups were made so when you rationalize your design process in terms of principles and a system then it makes design less of a black box everyone can see what is happening how certain decisions were made it makes it very easy for the new team members to start becoming productive you already have something the new designers on team members can look at the existing patterns start working on it immediately they have a very quicker ramp up you don't have to learn everything from scratch on their own so you have happy news in the office response to external changes information architects is a firm based out of Japan and several other places and they are very huge in product design and dev they did a research for one of their apps and they came up with this number 14,290 android devices in the market which means a huge spectrum of screen sizes and that's not it because now you have different device types as well you have everything from watches to VR glasses to TV sets where you can use different product it is very hard to design and test across this entire spectrum of screen sizes what you can do in the design system is you can define how your content response and your product response to this type of screen size changes and then test at certain break down points so this example is from material design and how something that shows up in one way on larger screens kind of shape into smaller screen so you can solve for the whole range of devices concurrent design because now you have one source of truth you have one repository multiple team members can start working together not only that you can have multiple teams working on the multiple modules different modules with certainty that their output will be consistent and in accordance with what's already been established so you have five new features or modules to design you can still like happily feel that okay it will add up to the coherent design of the product so people working together is one of the huge benefits a cure for imposter wellness how many of you here know what imposter syndrome is so imposter syndrome is when you feel like you are just a hack you are just putting together things without any skills or anything and you are not competent at all when you start rationalizing your design decisions in form of a document and principle you start feeling better about yourself as a designer, as a developer whatever your role is you start to feel that you are actually competent because now you can see the rationalization behind all of your decisions some of the stuff you have internalized you just immediately make decisions but when you actually write those down you see that there was some logic behind it which is I think very important quality for any work to have so here are some of the I am just summarizing all the benefits again improved communication scalability makes it easy to share knowledge between people you can define your responsiveness of the product multiple teams can design together and it cures imposter syndrome design system and its implementation is not without its challenges it's again like in earlier talk we saw it's not a silver bullet it won't solve problems that are because of the products culture or team culture or team dynamics that's for sure but what are some other challenges first one is you need time and resources to create a design system and then to maintain it because every time you come up with a new pattern of solving something and a new way of solving something you have to go back and document it in your existing system and also creating a system upfront takes up its own time there is some additional overhead work that's required to create and maintain them top level bind it's very hard if you don't start with a design system it's very hard to convince your top level to agree to move into this direction for them it means additional time and resources which no one really wants to put in because again design systems promise you future benefits and long term gains but you can easily trade it for some immediate you can just easily design and develop a couple of new features then why go for a design system until very recently the tools were not sophisticated enough to create a design system this is getting slightly better now because there are tools like Sketch has libraries Figma has a big built in library as we will see today and there are other tools also like UX pin there is also version controlling available for designers now called abstract so this is becoming better although the products are not there yet it's still better than what it was say a year ago here's an example of one of the design systems I have made for a company called webengage just to show you the kind of depending on different context how you can what you can actually make part of your system and deliverables because this was going to be used by other designers I kind of this is a little more verbose in how different components are stacked how they are actually made what are their actual specifications and different states and different variations of them I hope this will be better if you see the on a laptop and then I just have one variation of application of design system to show for a company called wallet buddy they are based out of the parent company is based out of Bangalore we made a vanilla design system which then they can adapt to create multiple very different products so here's the vanilla design vanilla here's a screen using vanilla design system which is very plain and very straightforward now changing some of the variables of the same system like typography a little bit of grid and moving to brand colors for a particular client we could come up with this which is not entirely different but there is a discernible difference to sell it to a different client who is aware that this is what we are getting so it's not as if we are cheating them selling the same product to five people but we can make discernible differences into multiple products and this is something a company called walks who runs those two like I think many many I can't even count but they are the company behind verge or polygon box.com right they have a similar design system where they just change certain variables to contextualize it for a particular website of publication but everything is at the core born out of the same system so this is a very primary application of similar concept side by side on the right is the vanilla version on the left is the improved version which for some reason is the reverse order of how I should have shown it anyway so here are a few examples in the wide of design system I am not going to read all of them because you will see the presentation you will get a link to the presentation at the end but salesforce mail jim atlation google who started the whole documentation thing design systems have become so popular now that they have their own libraries they have their own galleries so when anything in design has a gallery you know that the thing has arrived so I want to leave you all with a question of if you are not using design systems in what format in what scope you can start using it when you go back and then you will have your own stories to tell about how they helped you whether they helped you or not whether it was an overhead which didn't really lead to any place you can maybe start very small and then take it from there but I would really be interested in seeing how you actually start implementing it that's my talk I have time for questions now thank you so do we have any questions here we have a question yes it was a nice session thank you I recently had a chance to work on a product where there was not any design system in place and the UX designer has a hard time to convince you know stakeholders and to come up with each screen so who owns the ownership of creating this design system in place before starting development it exactly it resets on also Leon UX designer or any stakeholders involved in that including product manager yes so it depends from one product to another I would say the bare minimum people who should be involved in the discussion of design system a. your designers b. your devs the product manager or rather manager because they need to know what's happening and how their resources are working on just to be in that no I would ideally want other people like other departments to also be involved it depends on your product but if you have a product that goes out to like really huge audience and at a level where legal and marketing and HR and even you might have a content team all of those are involved in your product they all should become part of the design system at one level or another one deliverable or another probably they won't a content person won't be as necessary to be part of the component design right but they are definitely part of how the content what the content should be your content strategy and the I personally feel the goal of the design system is to make it transparent for everyone in the company not only designers and dev they are the immediate beneficiaries but in the end the way you implemented it goes everywhere like we saw in the case of intercom right they help documents use the same phrases same conversation same all the same terms and phrases right so they are also at some point involved or touched by the design system so it's very easy to contextualize this which is the beauty of this I mean you don't have to follow one specific rule of how to create and who the audience should be and who should be the stakeholders designers and devs should definitely be involved but you can involve other parties in the beginning you had like four or five type faces right and then you said that you pick robot can you just talk about what sort of parameters or how do you go about evaluating different typefaces and why you pick robot sure sure sure yeah so we ended up not ended up not really picking robot and but so for this particular product it's a B product and used by enterprise so it's not really a consumer product where and we didn't have a lot of mood to add to the product the product we didn't want to make the product with a personality right for example and I'll give you an example you use something like say mail gym it has its own mascot and it's targeted at really individuals so someone running a small shop they would use mail gym to send out e-mailers and newsletters web engage was not targeted for that their target audience is larger companies so they wanted to take as neutral a tone as possible which meant our typefaces from the outside needed to be very simple with no additional personality or flair of its own right we started so we thought okay what are if we didn't want to use a paid typeface because the product goes out to like a huge audience right what are our options that's where we started okay Ariel and Helvetica because they have always been there what is the next freely available but really popular and really workhorse type of typeface which was Roboto and San Francisco because we started to see that it is possible to use native fonts now in Mac like every Mac comes and San Francisco pre installed it is easy to refer to it from CSS that was our starting point to narrow down to four from that Ariel and Helvetica we didn't want to use because we wanted a slightly modern field to the app Roboto we ended up not using because including it kind of slowed down the app I'll just show you the that's screen again if you can so you can see like when we saw it some of the weight variations we needed right the load time became very slow which meant that for a product which is already built with a lot of JavaScript adding this one more which even in the beginning tells you that it's going to slow things down we didn't want to go with it and then the benefit to between I mean the variation between Roboto and San Francisco the Apple font was not very much so the what we ended up using this what this does is if you are an on an Apple laptop it will use San Francisco if not it will move to the next one so any Google phone or Chromebook or anything will get Roboto if you are on Windows machine you'll get the Windows native font which this additionally did was it gives a very native feel to the web application also you feel like you are using something that's built into it so that was our goal that was the process how we decided on like picked the few first runners and then narrow down to our final choices that is not it so I was I don't know if I mentioned but design system is always a living document right you go back and you make changes after testing for some time now web engagement has realized that the visually there are some inconsistencies they want to fix right so we might have to pick a typeface and we are looking at something called inter which is a variation of Roboto but it has a few additional features right which we can just enable in the CSS so we are now looking at that so it's always a iterative process the decisions here are also not final okay so thank you so much thank you so much Tejas we have a few more questions these questions yeah big round of applause for them thank you we have a few more questions which we can take offline because it's time for morning beverage and before we go for beverages we have a small announcements to be made a birth of feather session for sensitive data leakage yeah it has been shifted by one hour and the next talk is from 12 so let's see you guys again here and the questions we can take follow okay offline we can take it off sure hello this is good hello can I hear myself hello there is no monitor right it's straight off speaker audio monitor it's not okay right that's alright wait I need to extend my monitor is it better quickly put this up here and see I want to check the contrast it's dark can it be made brighter is that a thing that's a possibility no I'm fine with this I do have a timer of my own I don't need an external one no sorry no that's not required that's not required okay that sounds good sorry I can't is it hi can people hear me can I have the back shall we get started sure go ahead I'm ready welcome back again for the meta refresh post leverage session now we have Sri Hari here we'll be talking about how we can structure a way to conduct an experiment with our products that helps us to make mistakes faster and fix them faster so over to you Sri Hari thanks hi everyone I am Sri Hari I work at this place called Nilinso it's a software cooperative based here in Bangalore this talk is about embracing change I know that's a bit of an overused set of terms put together it's a call out to the XP or extreme programming embracing change as opposed to resisting it and this has been around for like 10-15 years and we're all familiar with the notion of embracing change but when it comes to writing software embracing change is hard and I want to talk a little bit about how to make that a bit easier and how to structure our team and our processes to make that in a nicer way so what I'm going to be talking about stems from a couple of experiences of mine both in the last year and a half or so and both were with some early stage products so it's primarily about what I've learned from experimenting with early stage products I'll get to what experimenting means soon so the talk itself I've divided into these three parts first we'll talk about what is this experimenting thing that I'm talking about next I'll talk about how to do these experiments and what are the different ways in which we can think about experiments and I'll try and think about like try and tell you about a new way in which I've been doing it we've been doing it in our teams a few times now and it's been quite helpful and it's using real software and that's supposed to be in quotes and I'll explain that also when I get there and I'll have a small section in the talk about the consistency of the team that does the set of experiments before all of this though I'll set some context so the context is that we're working on the product called simple go to simple.org so this is a non-profit initiative by the WHO, the ICMR Indian Council of Medical Research and together we've formed a body called the IHMI and this is to help eradicate or improve control of hypertension in India and throughout the world there are a few organizations that are running this they are resolved to save life and vital strategies and there's also a couple of firms in Bangalore Uncommon and Millen so that are building this so what it is is a simple app for nurses to use to record blood pressures of patients so if you're unfamiliar with the problem let me take a step back IBP is hypertension and it's very prevalent in India population that is 300 or 400 million people in India have hypertension and it is a leading cause of death and so that's what we're looking to help prevent so a little bit more about this is that it's all open source so it's all on github.com simple.org and all the work is out there even the design process for this is open source so there is Daniel Burka that works on this and he created issues that talk about the design coming up with the right design system and design languages for the app and have a look at that and it can contribute as well so a bit about what the users are or who the users are so these are nurses like I said and they work in public health care centers so these are PFCs, CFCs and sub centers and district hospitals that are government owned and an important part of this is that they are in rural villages in India so think Bhatinda, Punjab or Foshyapool, Punjab those kinds of places and interestingly the first thing that we've done on the product is to go with a paper mechanism so nurses have been recording DPs on paper and so design challenge is interesting because you're moving from a paper based system to an app and so there is a certain information structure and a certain workflow that are embedded in nurses and we have to move slightly away from that and also think of moving to a larger portion of thousands and tens of thousands of clinics throughout the country so the place like I said just so that you can also get a visual idea of this this is the place it's a rural rural Punjab so no internet connectivity if any there's going to be lots of drastic weather conditions potentially so people might or might not come to clinics on a day to day basis and even if you have phone network connectivity that might also be choppy at times the users are nurses in these clinics so they work there from 3 to 4 hours and have a pretty hectic time of patients coming in every day and this is the team there's a part of the team that works out of you know all these facilities and this is the software part of the team so this is based out of Bangalore that's uncommonly limited and that's an uncommon so to give you an idea of what the app does I'll take you through the basic flows the basic idea is when a patient comes in the nurse asks their name and then finds out if they are hypertensive they measure their BP and enter their BP maybe prescribe the medicine and tell them that hey you know what come back next month and that's about it so this is what that would look like so they enter their first name or their full name enter the blood pressure and maybe update their medicines if that means changing and schedule their next to it ideally usually it's in one month time and then what you do is you also follow up with them if they have not come in a month you call them up and say hey you know what you're a bit late why don't you come back to the clinic and get your BP taken again for some patients if their BP's are 200 and above they are in serious risk of death really so that's yet following up with patients gets really important so with a problem like this where you're faced with some extreme condition that you are unfamiliar with how do you know that you're on the right track how do you know that from a product perspective you're doing the right thing and going towards the right thing how do you know that you're building what users want every time you build the app getting to your user, getting feedback from them and then improving on that is an expensive process and you want to reduce that as much as possible because there's not so many times you can go back to a government hospital and say hey you know what try this new thing, try this new thing right and is the interface intuitive so someone who's not familiar with android as a paradigm how do you introduce something that's intuitive to them so the solution is usually a scientific process of experimenting where we build get to users, fail and then rinse into people however this process is expensive this is the fundamental problem a statement that I want to address in this talk so the first time we did this we built a production quality app of some narrow set of features went to Bhatindan in Punjab and tried to deploy the app and get users to use them to use them for that day that we were there and then not after that so this was about two months of effort that pretty much went to waste because the search interface was not intuitive people did not know if they were supposed to find new patients or add new patients differently they were too acclimatized to the paper system so the need then is to build faster get to users faster and fail faster and how do you do this so exploring the existing methodologies for experiments generally there's a notion of all these are like ones that you see used in agile projects and XP projects and so on despite you can think of a small experiment that's done once in a while and just find out if something is feasible or not and then you throw it away and then there's a traceable app which is production quality narrow scope put into production so that you can get your functionality to the user and then find out what the user wants and then there's of course the long term R and D type like Xerox labs type R and D where you have a huge cost a huge part of your organization dedicated towards making research long term and growing products creating new technologies altogether and so all of these have their pros and cons and the methodology that I was hinting at is this the notion of an experiment plane so this you can think of it as a combination of all the three things that we saw before it's an R and D for exploring ideas and you throw away your prototypes once in a while but you make simple versions of all the functionalities I'll make it more grounded in a bit but primarily with all this what I'm getting at is making the feedback cycle faster and in order to make that a little more explicit I want to say that the biggest part of this is conducting a user study so that's one big half of it the other half is us coming back analyzing results and improving design and getting back to users because the most important thing here is doing this we narrowed it down from a period of like two months to two weeks and we did this by getting users into the office every week or so establishing a set of users that can come in and help you with your user study is quite difficult but if you do that you can do this at your own pace and time that you want to do it analyzing results and improving design takes about a week after that you can't straight away after coming back from a user study you can't take the results and go engineer them takes a lot of time to synthesize your results and understand what really you've learned from that and then what you need to do is plan your next user study and then build backwards from that so user study is still very primary learning more about your users and getting your product out there so the fundamental difference here from what you would have noticed in other such cycles is that you first plan the user study and then engineer backwards from there and you build exactly what's necessary for that my proposition is this that we create a simpler version of the app focused on happy parts of experimental teachers and close I'll let that sink in because that's all I could try and compress that down to that and I'll get to the specifics right away I guess how we do it is by prototyping and in order to put this get an understanding of what's already out there and put it on a spectrum so on this side of the spectrum is of course pen and paper and the other side you have real software and the spectrum is non-linear so you have days, weeks and months so real software can take months to develop pen and paper is kind of immediate pen and paper is really fast so on time get you can do 5-6 prototypes on pen and paper really quick with the user sitting beside you maybe with an engineer sitting beside you in terms of flexibility you can throw away your paper prototypes or wireframes or even high-five mockups really quickly and then build new ones with real software really hard to throw it away once in a while and to varying extent based on the amount of involvement of real users you get various amounts of feedback along the spectrum right but on one note on one axis there is no spectrum which is usage software is only used when it's fully built out you can't take real patients and put them into a fake app that's just not done so how do you solve that another interesting part of the spectrum is that this part of the spectrum the latter part of the spectrum involves engineering as well right so that's where it gets really complex because there's more people there's more coordination there's more communication so before that it can be a single loan designer you know kind of spearheading that but that's where it kind of gets difficult and I'll try to answer some questions about coordination communication between engineers and designers so on this part of the spectrum though I'm sure you love you all are quite familiar with all of these things I'm not going to talk about good things about these things I'm only going to talk about bad things about all of these things so first thing is that they are always online you can think of them more like browsers sitting as an app right so at the moment you go offline like we have to do in Bhatinda and Punjab you don't have internet you can't load the next page on a click of a button you're doomed so that's not really an option for us it's also really really slow that's not what you want your app to feel like from a real user so you don't get that feedback there's no storage right so you can't record a patient go back and then see that patient again for best today's BPI just recorded it sometime back none of these things give you any storage the programmability is sub part in that they all give you some kind of an IDE or interface where you can throw in some code or some plugins where you can modify a few things but not really they also need constant guidance like sometimes you need to sit beside your user and say hey you know what don't click here click there and that really is the very point of user studies you know observe users do what they do and there's no custom components so a few things that we wanted to do was building a QR scan for scanning some interesting IDs and we wanted to build a custom keyboard that will make it really fast to enter blood pressures and find out if that made a difference for the user none of this is possible using any of these any of these tools and there's a bunch of pitfalls that I would sum up as you have to like you know quit it and start it from the beginning that happens all the time it's unlike real software where you know there is some notion of error recovery and you can start from where you left off so my experience and my recommendation would be this go just script react needed and I'm just going to leave that there because this talk is not about that I've spoken about it before I'm happy to talk about it later I'm going to quickly move on for the more design aspects of this so let me tell you with this what I can achieve so this is a demonstration of the experiments lane and the experiments app that we built so first thing is that you can build alternate flows so in addition to registering patients the nurse has to register herself also and this is important for setting context it's not something that she does over and over again it's a one time thing but this is what I can do with the experiments app there is a settings page I can go to settings screen I can change it from home to registration and then if I go back it takes me to the registration flow where I can do that and give it back to the nurse and say why don't you register yourself and the interesting thing is all these security pins and what not are actually validated so you know when if entering pin is usable and another thing is she has to be approved and ideally that happens over time and then she says you know she's been approved so that's a certain context and we wanted to try out the usability or understand the usability of access does the nurse inherently understand access we were using papers before this for that part of the flow and there's an in between that we could have built where we just use single screens and move over the registration just tap to click just so that we can get to the access part and then at that point where we want to change the access from requested to granted we just borrow the phone take it back change it to granted and give it back to them and say hey you know what assume that half an hour has passed what will you do now and then they read the screen and they figure out what to do from there so an interesting thing that you can do there is you can visit or was it but it's all a card which is that you can take all the registration screens and not build the flow at all just be a set of screens very much like a frame up prototype or an envision thing where you just click click click click you don't enter your name or phone number or whatever but that's not very important to the flow but for engineering that makes it really quick there's also the notion of time and us modeling it which becomes super interesting it's usually a thing that we all miss to do in software so here's an example we have a notion of an overdue list that a nurse has to call back so what I can do is go to the overdue mode and say empty and then I can switch to the overdue and say what do you think this means this is an empty state and I can switch and say okay assume it's been one month from now what does this look like for you and then the nurse calls up the patient actually opens up a dialer they actually call a patient I can do this using a real user study right and then what I can do is change it to six months later borrow the phone say six months now and then understand what they do when they are faced with like you know a potential of 50 overdue patients do they feel overwhelmed do they call each one of them they respond differently because it is a list to write paradigm here you know these are things that you can observe and these are not things that you can see in an individual model as much right and these are hard to build out in real software as well there's only so much you can do with all future flags and what not and then of course there's AB tests except these are observed in real time so here's an example so what I can change is there's an age versus age or DOB and then you see that the age a filter is a single thing right I just say I want Madhu Mehta age 20 and then two results show up and alternating I can do is say age or date of birth and then both the fields show up there I can either enter their date of birth or name but the date of birth field is a bit tricky because you have to get the format right and that takes a bit of getting used to the slashes get filled automatically and they have to know the right DDMM YY format and they can get it wrong right and we want to know what happens how the user responds when something goes wrong right so that's the interesting part like build in the validation so there are so many alternative things you can do there so we tried them all out we did year of birth we did date of birth we did age we like thought of doing in you know date pickers and there are trade-offs there usability versus accuracy and we also tried separate fields like DD is a separate field month is a separate field and year is a separate field they all make for different amounts of validation and accuracy in entering data and also usability so it's important for us to test these out in real time you know observe users doing this and we can do that with such an app and then this I think is one of the things that people tend to skip on very easily and try to force their way through it but here's a better approach so usually when you do user study there are a few cases that you want to try out expose the user to and find out how the user reacts my take on this is that you model it and treat it as first class like you would do in you know modeling your real domain so here's an example right there's Madhu Mehra and you see the addresses are like something in Bangalore I can go change it to Bhat Hinda and then go back and then search for the same Madhu Mehra again and suddenly she's in Bhat Hinda all the addresses are NFL Colony Jhandu K Road so I can take my user study and either base it out of Bangalore where I do my user studies or I can go to Bhat Hinda and then with a single change or a single click of a button make all the patients seem like as they are from your local area and that matters to user that's context and that's modeled in Cdata here's another example so there's Shreyas for example and there's Shreyas Garewal and Shreyas Malhotra so we find out if patients are able to users are able to differentiate their last name and Neha Gupta there are 3 Neha Guptas all aged 40 and we want to find out if they are able to differentiate the incoming patient based on their phone number right so these are all things that you have to model except in something like Cramer or something you would just end up hard coding all of these things not subject to change what you can do is something like this where you model a certain user architect and say that these are the common factors and these are the variants so for example Shreyas Malhotra is 35 male and he has a hypertension profile of the fact that he's been hypotensive for weeks except their names are different similarly for Mahalakshmi Puri the variants are that the first one is in the late colony 1, 2 and 3 so that's like she's from the 3 different Mahalakshmi Puri all around 70 that's another thing because people are not exactly sure how old they are they might be 70 even if they're 75 they'll say I'm 80 or I'm 70 so you have to account for that so this helps model that and the interesting thing is when you notice the call list there's like 10 or 50 of them so what I've actually done is I've taken this as a model and I have a tool that helps me generate data based on such a model right so it's not just what I put in but also in addition to what I design my seed data to be there's a notion of random data that fills in as well right so what you saw there was a separate app from the production app that we use to use a test that was built with closed script reactive but there are a few things that you can take away at a generic level first thing I would say is that if you want to explore and move things move fast types do slow you down so I would suggest a dynamic programming language a database also has a certain notion of either on file on storage it has a certain storage mechanism or it has a certain type system embedded into it as well so avoid that entirely either write to a schema storage or just write your application data structures to file which is what I did use an in-app in-memory database because your experiments app is not going to have a lot of data it's not going to have a million patients it's going to have a hundred maybe you don't need performance out of it you need usability you need the ability to move quickly ideally have library loads of your code so the validation mechanism is actually when it comes to entering a patient for example a phone number you can say I don't have a phone number you can type a phone number but you might enter alphabets that's wrong you might enter characters but it's not you might enter digits but it's not enough digits et cetera and the error states change a lot and it was difficult to get this right so what we did was we ended up by a program with a designer really and then changed code life and that's what they want and that we were able to achieve within 15 minutes of pair programming that would have taken days to achieve without a library loading a Drapel is something that I guess JavaScript also kind of has but Clojo gets it right so if you can have that that's great and like I said before the ability to generate data is done a certain schema it's fantastic if you're doing experiments and then apart from technology there are certain engineering practices that are good for this kind of an endeavor keep your environment entirely independent don't couple it with anything in production staging nothing remove all interfaces do not talk over the internet do not talk over device interfaces you can mock all of that locally for your experiment because that's not really important what's important is the user interface and the feedback that you get from your user and any other interface is only going to add more instability to the product if you don't want focus on happy parts and I said this before in that summary this is crucial which is that you don't design for error cases from a user study plan and build exactly for the cases that you've thought of test it out extensively manually and ensure that all those cases work out well and don't engineer for anything more than that it seems a bit clumsy but also is pragmatic it makes sense think about modeling external domain this is not something that is obvious so for example the notion of profiles of hypertensive patients have been in control for 12 months you know, kinds of patients that have been hypertensive high hypertensive low hypertensive these are not things that matter to the actual app in production these things are not modeled there but they're important here because you want to model users and that's not something that comes to you often in first class seed data like and then there is how we work with designers engineers work with designers and this is really it, it's just extreme programming the part that says with designers is really too far what that really means is that what I want to say is extreme programming can just be done normally with designers, it's not any different so here are some examples I just walked through some of the three fundamental XP values on that so you talk about system requirements you communicate a lot talk about pen, paper, prototype talk about whiteboard, the simpler prototype sit together and pair program this might seem ineffective but if done rightly it can be super effective so for example pair program on ideas work until you have a certain structure that makes sense and then break off to execute the idea that worked really well for us so one example is that GIF you saw of scanning a QR code we discussed things like can it be programmed, should it be a GIF should we not do it that would save us a lot of time for example that animation takes a lot of effort to get right in different phone sizes you have to place it correctly and very often designers have thought of other solutions from an engineer's point of view there's a lot to be gained by just asking a designer can I do something else, what do you think so the date of birth for example is a great example building a lot of validations into the date of birth field was expensive it would take a couple of days except when I went to the designer and we spoke for a while we just kept 3 separate fields because it makes this version easier and I got that done in 2 hours focus on simplicity Yagni applies to design as well very much so so there's screenshots like I said before just walk through the notion of a fancy VP keyboard is very interesting to experiment with but we don't really need it because that's only a proof of speed not usability there's a notion of login and that exists in the actual app and you might be tempted to build a simple version of login into the experiment app potentially don't do it, you don't really need it unless you're getting valuable user feedback from it design incrementally so again have a user study plan and design only for that and build only for that and if you remember what I said earlier about spikes and the experimentally even as a spike if it's taken you 2 weeks to build something you can throw it away and build from scratch and it's only going to take you 2 more weeks that's not a lot of time you can afford that so if something gets really complex or your requirements change drastically just throw away the whole thing and start over and feedback of course you need to get it from the customer from the system and from the team so design user studies feedback from the user directly from the system you need to if you're using the app on a daily basis and you fix bugs on a daily basis there's a lot to gain there because you want your app to be in production at the end of the day and from the team of course which is even for an experiment app or an experimentally in you have a PM board even if you're riffing designs right include engineers into that so that they know what you're thinking and that helps them plan ahead and quickly because I'm running out of time I'd like to touch on the size of the team there's been a lot of studies on this the whole 2pz team idea of Jeff Bezos so there's this thing by QSM which has some real data spanning across tens of thousands of companies about how the amount of investment that goes into a team to build a certain piece of software increases a lot with larger teams and with the same amount of investment in smaller teams you get much higher quality software so even in our small team size of 10 people or so that we're building the entire thing the experiment slain was 3 people and that makes sense and that makes even more sense for small teams because you don't want to waste time of 10 people in building the wrong team so you'd rather spend 3 people get your users fail fast, know what you need to build and then use the time of the other 7 people to build the right thing and of course like defect rates reduced with size the difference app in many ways had lesser bugs because it was built to serve lesser things, it had lesser code lesser people and lesser bugs and of course you'll also have to look into all this I'm speaking about technology but it really matters who you stop on your experiments slain so I go back to what I said earlier which is get your users faster be wrong faster and a way to do it is to create a simpler version of the app focused on happy parts of experiment features and clues that's what I have so thank you do we have any questions for them yes we have a question here so you talked about building the app for the experimental name now if you do the user testing and finally figure out this is the final workshop this has to go into the actual app how much of the code that you have built during the prototype phase can be moved over to that or is there any reusability that can be done you have to build again from scratch for the actual app so the question is how much of the code gets reused from the experiments slain into the production 0 that's usually the answer so be prepared to throw it away there are ideas that you can take away though and that's far more important leave the actual code aside but you now know that there are certain edge cases that you need to design for sometimes you're not sure what the edge cases are until you build them in the experiments slain you end up building at least one cut or the first cut of your feature and you learn a lot from that so just like the way a spike helps you estimate a certain story or you know flesh a feature out fully this will do that but in a much nicer way I hope that answers do we have any other questions okay so thank you Surya thanks for the wonderful talk before we move on for the next talk we have a few announcements to be made the BOF on sensitive data leakage and privacy has already started in the BOF session at 340 we have another we have another BOF sessions one is on ethics and design run by anthropologist Aparna Ashok and the other one is freelancing in web design and that's by Nick Hill so these are two announcements which were to be made and now I welcome the next speaker so we have Abhinav here from an Academy and he'll be describing how they build design systems for an Academy so I think we are ready so over to him hey everyone what's up my name is Abhinav I'm the head of design at an Academy an Academy is a ethics startup we're a test prep platform we have learner apps and educator apps we're a platform for educators to come and find an audience that they can see and we're a platform for learners to come I also run a bunch of other things I run this website called UI Sources which is a design inspiration site I recently wrote a book called Pajama Profit about freelancing previously I did a music app called Listen I was at housing.com as well so at an Academy we're a team, we're a pretty small design team so we're three product designers one illustrator tech product and design overall is about 40 people we're going to be talking about what are our goals with the design system what are the considerations that we had at our site and hopefully some takeaways that you can apply to your own organization so for me to get a read of the room how many people in here are developers and how many here are designers any other folks who are in between not pure development, not design this is uisources.com Profit alright let you sort of zoom back to how we got here the current state of design the years around 2010 before 2010 and somewhere around that most designers and I'm talking about 99 or 95% of designers used Photoshop and Photoshop is an extremely powerful tool but when it comes to screen design like you're designing screens websites and apps it can be overkill like it's got a lot of bloat that can make working harder and so somewhere around 2010 a new entrant came in the field which was Sketch and within the next few years so Sketch came out in 2010 but by 2012 most designers, most design teams all over the world had switched to Sketch and the reason they had done this was because Sketch just took one slice out of Photoshop and made it really efficient two design screens websites screen-based design basically and if you're in a tech company right now designer or developer there's about a 95% chance that this is your design stack or some variation of this so for design you use something like Sketch storage, version control you use Dropbox maybe you use GitHub maybe you use something like abstract but you use maybe more specialized tools like InVision handoff typically happens in Zeppelin or you use something like Marvel or maybe even InVision to prototype maybe complex prototypes happen in principle or framework so this was our design stack as well at Unacademy about six months back and as part of designing our coming up with the new design system we made a few changes to this design stack looks like right so most tools like we didn't know it at the time when we were trying out Figma but Figma started with replacing Sketch for us and then slowly it moved into everything else and by slowly I mean within three days Figma made it really simple for us to completely migrate from all these tools that we were using to just one single tool and this happened at the same time that we were figuring out what the design needs to be so some of the goals that we had with this so of course the first goal with designing any design system wherever you are is consistency at Unacademy we have four apps we have the learner app is on iOS and Android the educator app which is also on iOS and Android and one of the things we wanted to do was be able to move really fast so we were switching to react native we were starting with one of the apps and the goal was to switch all four apps to react native event so this was the perfect time for the design team as well to come up with a new system that ensured consistency moving forward the second goal that we had was we wanted it to be real time and what I mean by that is if we are pushing out an update every single week to our apps we want everybody to be on the same page no matter what part of the process it is so let's say I am designing a new feature I don't want the developer to know about it five days later when I am done with it I want everybody to know that we are working on this so that when I am ready to sort of pass the baton the other people can take it and run forward so we wanted real time to be one of the four goals of the system the third was collaboration so often with tools like sketch what happens is the sketch is only installed on the laptop of designers macbook it's a macbook only tool what would happen is I start designing something I am sort of halfway there my p.m. maybe knows about it the developer finds out only when it is time to find out which is not right when you are building new features it needs to be a collaborative process so everything can run efficiently the fourth was communication now communication has the tendency to become an overhead because there are always questions like have you started with this or is this on zeppelin yet or the version on zeppelin is that the right one you showed me something else yesterday send me the link to that design send me the dropbox link it's looking different on my computer do I not have the function just things like that can add up every single day every month so with these as our goals let me talk about how we sort of transition into picture one of the main things about it is sigma is a multiplayer tool this is probably the first design tool ever to be multiplayer what this means is it's a web based tool with mac, windows, apps and in a single design file a single source of truth you can see everybody who is on it you can see whether it's a PM whether it's a designer, whether it's a developer they're all in the same file and they're watching updates happen real time literally as I'm drawing rectangles putting text they can see this happening on their screen and I can just click one of the names here to observe what they're looking at and sigma is completely online so all you need to do is share view access or edit access this is just the same as google docs share edit access it's for designers they can edit your file share view access they can get the values out of it the same values that they would get out of that and since it's all in one place you everybody is on the same page so if you have a screen the designers and developers both know that this is the final thing that I need to be working with communication happens within sigma as well so while a design is going on let's say I'm on day 2 of my design developer can ask me hey have you accounted for that flow when you don't have this one thing and then this needs to happen right there and I'm like yeah I'm working on it this is where it is right now I can just mark it as resolved so all these communications happen within the design this makes it very very efficient and avoid unwanted surprises in the future and of course there's transparency so anybody who's added to the team on the left side you have all projects and you can see everything that's going on right now the first file was edited 5 minutes ago that file was edited 2 hours ago and you see the colored circle it means there's activity there so like 4 people are currently on that file right now one person is currently on this file right now so there's never a question of asking for something if you need to know you can just go here and you immediately get what you need so this cuts off a lot of overhead around communication of course it's multi-platform so it works well now let me give you an overview of our design system how we've structured it, what are the parts to it so the design system as well it's one of the projects everybody has access to it not everybody can edit it only one or two designers on the team can we have colors so we have a fixed set of colors the colors have names these names are consistent in the design files as well as in the react native code base and anytime a designer draws something in Figma they can just choose these are the on-academy colors these are other colors it's never a case where there's multiple shades of green just because over time something like that the same thing with typography so the styles are very clearly defined anytime you write something you can say okay this is an H1 this is an H2, these are titles the rules around this the designers typically know that P2 is to be used in cases like the icons as well so we have a custom icon set about 150 icons some of these are category icons some of them are actions in the app and we made this a component as well so anytime you're working on something you can just search for components and drag and drop into your files so the way we sort of structured our component so typically in the design system you think about atoms and then you think about molecules atoms are like the smallest elements that need that probably repeat across the screen things like buttons, dropdowns, dividers now buttons I still call them atoms although there's text and then there's a rectangle but this text is not a component it's just a style that applies molecules could be something like list items there's full sections in your app or maybe the app bar common android and iOS engine so our main component file it has all the base components here the composite components are all you know sort of arranged like this as well so at any point of time if a developer for example needs to know what primary buttons look like primary buttons with press state or the loading state they can come here because the development team also has their own set of documentation once they develop this so both of these always take into account components now one of the things with design system is that when you have new designers that join your team it can be hard to sort of onboard them and get them to start designing at 100% efficiency in the same way that the rest of the designers have been doing for few months or few years and the way the component system helps with this is that every single file every single design file in Figma if you say new file you can start along with your layers you have a list of every component that exists in the main library you can search you can see visual indications of these and when you have a screen you can just drag out edo, status bar, button and within 30 seconds you have a full screen ready so this also makes it really fast to prototype let's say you have a concept in mind you sketch it out but you show it and they're like you just go to this within a minute you have actual screen ready and this might not be what actually goes out in the end this can at least help you communicate what the concept is and now another hard part about design system so if you've tried building a design system in sketch one of the hard parts about that is sketch is a native mac app so you have sketch files that you store in Dropbox and Dropbox syncs this to every single one let's say I make the change to my team library there is sometimes a chance where the changes are not reflected when they need to be and this can creep in the form of an old version of a component versus a new version of a component so in fact by the way we handle this anytime I go to the main component file I make a change if you want to publish this I type a message very similar to GitHub anybody who's used a component that I just changed will get a notification in every file that they have opened right now that uses those components it says component updates available this is what was changed you want to update it and updates throughout the entire file so that's about it that's it for how we did this at Unacademy any other questions is there any possibility of versioning designs for example you have a top down and the next version is the disable button disable the drop option may have one hour so is it possible I'm just curious to version it because in Sketch or something which is just the component file I don't know if you can see the previous differences like that is it possible for versioning with who did it so let's say you have a component like a button we're going to talk about two cases here the first is when the button itself changes what we typically do in those cases is we take the old component and we put it into an archive file so that if ever in case we need to bring it back we can always do that talk about multiple states of a component so based on how you name your component so let's say I do button slash primary button slash primary with loader these are all states of the same yeah yeah I get it but they're all different but I'm talking about one specific version like one so and then the design team or the management team wants another version and who wants I don't know like in the code when you change it you can see it because it's text you can see who changes why they change it but typically in the design you're talking about binary files so there and then you cannot see who changes why they change it the way we do that is we also restrict access to the main component file so the big organizations like they have dedicated design managers whose job is just to maintain the design system in our case we design access to edit the components given to just one designer never changes somebody overwriting that but in the case of new features let's say we need a new component the process usually goes like designer comes up with a new version of the component or let's say the PM wants something after the parent implementation this is then discussed with the person who manages the design system then we figure out whether there's a need for a new component or we can use the old one or add a state to an existing component then in design as well as in the reactive component set all of these are I have three questions performance online only and prototyping you mentioned you're still using framework and principle in some situations firstly sigma is web based so the tools the apps that you have on windows and mac they do load web but it's possible for example just something as simple as something as simple as spanning between your design file it's much faster so and the way I say this is that when you use sigma and use it for about 10 minutes going back to sketch is like going back to Photoshop and I've seen this with a lot of designs which is why it's something that you just get through second is about online by default all files are online and you do need an internet connection to work so when you're working near offices usually it's typically fine but in case you do need to work offline let's say your flight you want to go into the field you can download these sigma files as dot things which means you can work on them offline when you do work on offline certain features are out so like you might not be able to access the live you might not get to but this is like a temporary measure when you do you have a question somebody yeah I know you I have worked with you in the past so I have a question that when I was there in your company you used to work with different tools now you have moved to sigma so what is your take on like is there any story when you shifted your team from this particular tool to now this tool and can you just share the thing is really fast the reason for that is sigma is actually important sketch file so even if you have your entire system in sketch you can directly import that within let's say 10 minutes all your files and sigma are ready to go and it comes to other tools so developers were apprehensive because they were used to zeppelin for example they were like what is this new sigma why do I need to use it but the sort of communication overhead that it cut out like every time I would add something to zeppelin I would message saying you know new version on zeppelin somebody tells me to change it and I send the message again like this was totally fine and developers were missing the thing where they get to see the design as it's being made they would only see it in the end to just benefit like that of being able to see it anytime switching happened for us like within the game I am a developer and I mean this is the first time that I am here for sigma so my question is is there an extension like we create components in sigma and is there any extension that it can be exported to a direct maybe a react component so the best it does is it gives you the same value that you would get on zeppelin so SCSS those parts yeah you have actually got prototyping as well sorry I missed on that sigma lets you do basic prototyping the same way that gets there the type same as marvel but we don't really work with framer we haven't found the need to work with real data but principle so far did work only with get so they recently now added a frame sigma import as well so workflow wise it stayed pretty much one thing that we do mess in sigma is the use of plugins if you are plugin heavy this thing you need to figure out alternatives a lot of these alternatives and build it into sigma as native functionality hi so I am a developer as well but I was in the conference room and I just came so I do not know whether you've heard this or not but I recently started using sigma and I usually used to do stuff on illustrator and it was a pain to just transfer I mean transfer the files from illustrator to sigma because whenever I used to copy and paste it there was no documentation on the website and when I used to copy and paste it it just used to transfer into images so do you have any idea how do I do that because there were a lot of files I have to individually select individual groups and then copy it as SVG and then paste it if you have for icon set was made in illustrator and then for us SVG import was the way that we did it you guys also did it but in fact one of the illustrator on RTU he was exclusively using illustrator now a lot of illustrator directly happened in sigma sigma has a really advanced pen tool that is way better than illustrator it is really fast I mean I started using it and I was in love with it I was surprised if you switched from Photoshop and illustrator also for marketing so have we compared sigma with prema like ask this question before so with prema prema initially started as a prototyping tool but they are trying to become an all in one design tool so now they have something which is prema X so we did compare but I think two things about it why we didn't switch one is that prema X can be really useful if you are doing stuff in react because it lets you get react components very easily it doesn't for react usage secondly prema X doesn't yet support design switch screen so you can do screen you can design this but if there is multiple people working on it you can't really create a switch screen you would just have to have one sketch file it has no concept of updating those things do we have any more questions ok so thank you Abhinav thank you so much ok so before we head on for the lunch break there are two announcements to be made sensitive data leakages and privacy is already going on at 140 bof first of further session on functional programming will start and at 240 ethics in design this bof session will also start and at 420 we will also have a bof on PWAs so and that's all for as of now and we have we have a building a technical documentation at the product that scale at sharp 210 so let's meet up again after the lunch thank you good afternoon everyone welcome back after the lunch and before we start let me inform that at 240pm we have a bof on ethics and design and as of now as of now we have Ravi Vidas Ravi Suha from Gojack and he'll talk about about how to documentation whenever we have something which has whenever we are making product which has like really a lot of tech intensive work how to make sure that documentation covers everything so over to him and let's see what he has for us so over to you hello everyone my name is Ravi Suha today I'll be talking about once you build like complicated products complicated data products or could be anything else and then how do you communicate that entire thing to your users so how do you build their documentation as a product all around okay a brief about Gojack so Gojack is a full platform for ride healing since 2010 we started as a phone based service to so anyone can hill ride but in last over like couple of years we have evolved as a like you know a full platform which post kind of more than 18 products starting from the ride healing to financial products to even you know food delivery and different different markets so the business has grown and the complexity of the technology has grown like very very rapidly a little about me I started my career as a designer turned into a developer and then was in some time as a data journalist and went into a visualization and these then I'm doing like a lot of data engineering so okay agenda so today we'll talk mostly about I'll give you a little landscape around data engineering at Gojack what we do what kind of products we build then I'll talk about Chronicle which is actually one product which we which is our technical documentation and which we treat as a pure product in itself then we I'll talk about why exactly you need an internal product website and you are just your customers are your internal customers and still you still you need a product website why do you need a micro website we'll talk about that and then we'll talk about the entire process we went through on terms like having nothing to having this like no proper product website we'll talk about the process and then at the end we'll cover like what exactly was the impact of this whole whole exercise so let's start so this is this is how the entire like you know landscape at the data engineering looks like at Gojack we have different different OMS apps which produce data from different different streams and that goes to a fronting stream fronting architecture that goes to main streams which are like a lot of clusters then we have consumers people who consume this data and then on one side we have aggregation where a lot of like you know all this raw data gets aggregated and that then under our teams which consumes that data as well then we have certain parts where data visualization happens where we take this aggregated data and we visualize and give it to like you know users then there is warehousing then there is infrastructure orchestration then there is a monitoring piece component then there is a load testing component and then there are like you know auto healing components so this all is how the data engineering landscape looks like and out of this whole landscape we have like you know more than 18, 19 teams internal teams working on different different things and all these teams data engineering is cross cutting and all these teams utilizes products we built for them so for data engineering the approach we follow is that we are a small team somewhere around 10 people team and we build products for all these teams and then the approach we follow is like one thing we definitely focus on is scale so the scale at which we grow is not linear because even the number of products and even the business itself has grown to like you know from one product to 18 in the last 3-4 years and so is the scale of the data and so is the complexity and so is the number of the users within the organization and second is automation so as soon as the product grows we also grow into international markets and when you grow into international markets you need to set up the whole infrastructure for a different country and when you want to set up the whole infrastructure for a different country you want to communicate the same thing for all these different teams as well so now as a team of engineers if you want to focus on different products as well as their scaling as well as scaling to international markets you want to make sure that the entire process is automated and no manual intervention is required so lot of what we do we heavily focus on that whatever we do whatever products we build whatever the process of setting up the infrastructure is entire thing is automated and third is product mindset so data engineering itself right now is like not there is no data engineering product outside gojek which we offer to the end customer right data engineering is an internal team which get us to different different teams within the gojek but we still like operate with a proper product mindset where we consider ourselves as a complete B2B product company within gojek and we operate in the same fashion we operate in the same fashion is that we do not ask for let's say for example access or in terms of how do you provide documentation or how do you provide what particular products you are building so we treat ourselves like a pure B2B company and we follow the entire cycle even starting from building products in requirements sales even going to talk to people showcasing our products like the whole process which you see for any enterprise company happens within the company so all these 10 engineers they are just like not just developers but they focus entirely on the full product cycle so let's talk about like the problems we were facing when we were at the point where we did not have this documentation as a product the biggest thing was that since we were operating as a B2B and we are operating as a complete separate team communication becomes hard like what exactly we are working on lot of people, most of the people at the floor do not understand what exactly the engine team is working on and what will be the next next in line of what next product they are going to release then you deploy infrastructure and products for different teams then support request starts to come and that starts to consume our core development time and given the size of the team then if you are spending a lot of time making sure that you have the support request get us to then that consumes a lot of our development time and we are not progressing fast on the features track so a lot of support requests are coming at that time and the last thing is that it becomes okay when we are building a product team right it's very important that we communicate like whatever you guys are problems you guys are solving you are solving certain problems and whatever you need in terms of data in terms of consumption whatever you need our product is this final solution you are looking for and you need to communicate that very clearly and this without any proper channel to do that this was getting really hard and I think this is this was one of the worst so we have I think in data engineering there are more than like internal products which data engineering offers to different teams it's somewhere around 15-20 like smaller big products but like some teams are using certain products like let's say BI is using certain products and the developers are using separate products or data producers using separate data consumers using separate products for these particular channels what happens is that data engineering became equivalent to one particular product so let's say FIROCE is one particular product right for consumption so for certain people data engineering is all about oh that the team that built FIROCE or let's say there is another product daggers which is mostly caters to BI folks so for them oh the data engineering team oh the the dagger team so the landscape was like that so the entire team became actually equivalent of one particular product team and that was the problem we wanted to solve because if that happens then these these teams are not looking at the other products we are offering and they are not they are not able to like you know get the full capability out of it or whatever whatever they can use so this was this was I think the biggest problem then this is the word the end product looks like in our terms the fonts is not available but this is the product website look like which we call Chronicle and this is a microsite we have built and if you have looked at the like you know the different different products outside for example hashicops like no products and you look at the documentation these are large scale open product projects which they offer to the entire like the entire ecosystem and they build very clearly build very you know very good documentation how do you go about using it why do you use it and everything but then we will talk about like that makes sense for them because the product is global and ecosystem is global and people don't know anything and they need to communicate that understanding but how exactly does that fit into an internal organization so so we followed the actually kind of the same same cycle in that in that and this is how then the end product look like where we talk about what data engineering team is doing what different scenarios we cater to what different particular products we offer and the whole cycle these these like then we talk about like you know from product point of view from developers point of view as well like what all features developers can use there are like you know complete knowledge resource websites and everything was there videos content documentation like everything even code samples like starting from just pure why to use it to how to use it okay let's move on to process so the whole cycle for us was I think two weeks when we had internal wiki which was more like web pages or things like that but that's that's where we started at something was there with like small small pieces but then then we started the process and the first thing that that that's there is that how do you go about research and planning like this was a product us and we were treating it as a complete complete product nothing more than that it's not a not just a documentation it's not just a read me file it was a full product for us product which will communicate what exactly we are doing there so in planning what we did is that as I mentioned there are different different categories of the teams right there's bi folks there are there are leadership there are people who are in the market section there are people who are into like pure development who are the consumers of this data so first we walked on like designing personas around it who are these different kind of people and what kind of products they are using to start by mapping different products into different types of personas and we heavily use narratives to do that within the within the team which I'll talk about in a while but then we then we went about this whole process taking like different different set of users taking different different set of our products we are opening and then doing a mapping of which all particular these users are using which products and then we sat down to exercise of if if we ideally we want them to use these products as well what is that particular method so categorizing everything and then going about that and talking to people so communication was the biggest into when we started about researching the planning in this space just just ideally in a nutshell figuring out what exactly users want and what is the next thing they can utilize the next was preparing content so what we did is that we for two days we stopped the entire entire development you're not doing any development at all the entire team actually sat down because since it was an entire back we did not have anything concrete at that particular point so we sat down and we like you know listed down everything we have every product we offer and everything and then went about like you know designing the entire content of that so in the screenshot what you look like is that where we are mapping of the entire entire list of the things and in the entire list there are streams so streams are our top clusters and these top clusters hold data and in the data there are main stream there is downstream there is downstream there are different different kind of clusters which hold different different kind of data now anyone wants to look as soon as I told you this right there are streams and which hold data next question will be okay what kind of data who is publishing who is producing who is consuming what use cases are there what case studies are there who has solved what problems what kind of problems I can solve all these things came into your mind right so these are the questions which we all gathered into the into the content design strategy and we put down we put together all these answers for all these streams all these aggregation products and everything for example there is a dedicated page for the for the mainstream a few let's say if you visit products and we talk about like all these streams are listed here mainstream upstream aggregation products are listed experienced products are listed products around warehousing products around data infrastructure we go to one of the stream this list down like all the overview application topics that's listing publishing consumption entire architecture of it where exactly you can monitor that particular stream what are the case studies of it the whole all this entire thing is listed here what is the scale of the data here seven days of retention you get in the mirror you get three months of data retention how many events are publishing there who are consuming how many topics how much data is there in that particular stream and this is for just one thing we prepared this entire content for everything every data every piece of data we were offering even after doing that entire cycle since this landscape is so huge that there are still a lot of sections which are not like documented but we tried our best to make sure that the entire thing is open then that's after research is done we have the content ready and the content content is actually pretty extensive then how do we go about designing it how do you want to communicate it so if you look at the as a term like data engineering team itself you will hardly co-relate design with the data engineering team if you talk about data engineering team what comes to your mind is that there are people who are like pure nerds or pure developers and they focus more purely on the code design will be the last thing that you will look into but it's not the case for us we actually focus a lot on the design and since like even for me my background has been into design so design everything we build we make sure that it's well designed not from the development point of view even from the representation point of view so even for this particular product we wanted to make sure that it looks good and whoever is looking into it actually feels good and looks good and the production has to be experience has to be good but yeah we care about the look and feel as well we care about if you look at like you know a lot of architecture diagrams usually what people do is let's say you pick mono draw or you pick any other tool out there and you just pin down boxes and you just make the entire diagram but we wanted to get away from that as well and we wanted to make that experience also pretty well so when I explain the you know landscape which architecture design like components we designed on our own so what we have in the design language is that we have a complete UI kit which specifically focus on the data engineering and what it has is certain components which you can utilize to even design the architecture diagram so let's say for example we have a copper cluster piece right so there is a component which represents one particular cluster one particular stream we have automation tool let's say we have a fire host as a product it is a full component which lists down as fire host as a product if you want to represent fire host itself then there is a smaller components which you can utilize for this whole thing in terms of tooling we just simply built it with the sketch and we exported these components as a symbols in sketch so all these UI kits are actually symbol symbol in sketch which the entire team uses essentially so not like a pure design team or something but we still follow the same guidelines which a pure design system design team will follow now that's to design architecture diagram and everything right and as I talked about we follow we believe a lot into narrative design so whenever we come up with a product what we do is actually go out and build a narrative around it the narrative I mean is that if we have to communicate that particular product and that particular communicate has to communicate with the user how you will go about it some user will ask some certain questions I'll tell certain answers so even for our CLI tools let's say for example we built right even for a simple CLI tool we build product narratives and not like okay this is the CLI this has to be but there is a complete product narrative around it and then even to distribute our products to different different people we have a complete design set of brochures and the kits and the print materials as well which we use whenever we go for for sure so yeah so in given in cells we have this entire library of the UI kit even the narrative design and then entire design language is there which we utilize to communicate our product to build architecture diagrams and even to build narratives around it and all of this is actually like you know maintained and self-utilized by like these are like some of the components utilized to build architecture diagrams and this is one example of the of the product narrative so this is this is one of our tool Odin which is infrastructure orchestration tool so any user will just so Odin here is saying I'm Odin Almighty God user last what all you can do and it tells okay I can safely create infrastructure for you I can create data clusters I can create viruses I can create consumers I can replicate your entire infrastructure to a different country as well then people can just simply say okay I want to create new infrastructure and I want to create it for this particular city and then you can just ask okay how many data clusters you want do you want different different streams of the data for this new particular region you just want certain streams so this is the narrative we designed before even starting to design the design the service itself how exactly people particularly the best narrative user can have with this particular service to make sure the experience is good and what we are talking about is a backend service which is REST service API calls so even to design that API call we make sure that there is a net narrative around it way before we go into the development or way before we go into the product that comes when exactly we are envisioning that particular product okay in terms of developing Chronicle so we wanted it to be so since like a lot of this is data intensive right and this data is growing every day there are new streams coming so we wanted to make sure that this website whatever cloud micro website we build can pull data from different services our meta data services and we can always stay updated and we wanted to make sure since we are developers we don't want to spend a lot of time after once we have finished like core development we did not want to spend a lot of time writing external CSS doing all this so we wanted to make sure that whatever bare bone structure we set up and we spend time into it later we can make sure that you can always fill custom design layouts into it without much effort and indexing and product categorization happens so fast that you just provide certain tags to it and the entire things falls into the place on itself so even our product manager doesn't have to write any code after we finish the bootstrap and then they can just specify certain tags write certain markdown and it automatically falls into where exactly on the entire micro site it has to be okay so if you look at that this is the boilerplate so if someone has to add one particular section all they have to define is this meta data what is this title about tagline description which path it belongs to which category it belongs to which position it belongs to what are the tags and when it's written and as soon as you define that it automatically knows on the entire website where it has to fall does it belong to developer documentation does it belong to product which is more focused on the end user in terms of security and people who are like non-developers and what I have to do with it and then someone just write the simple markdown around it and automatically what exactly it helps us in is into just making sure that we can continuously do it so that it becomes as soon as as you add comments in your code simply you just write simple markdown here and it automatically goes to the micro site so after that particular process happened and we were ready with the entire micro site what we wanted to do is deliver it to our users and our users are like internal teams so what the process we follow and this is not just for this particular micro website this we follow for any product we build so we do show cases so we follow the same process for us because for us it was no less than a product so we went about doing show cases in show cases we invite certain teams and we tell them that this is a product this is what we can do for you you can look through all the use cases you don't have to come to data engineering for all your needs to understand what exactly we offer what exactly like nobody is the landscape of the data inside the project and then we printed brushes and we did all those cycles we had personal interactions with the users talking to product managers how do you feel about the entire experience micro website does it help you in reaching from point A to point B where you don't know anything about data engineering what we offer and you still have at the end of the day you still have good understanding of how you can go about it in terms of adoption so there are like in Bangalore office for Gojek we are around 300 developers and this is how the active users and weekly active users looks like so users were like pretty good people were extensively looking at it I can't say that we still have reached that entire stage where everyone is using it and this is the single source of the truth and they don't have to come to the data engineering but I think still we are still at a really good position from where exactly we were in terms of a lot of people using it and a lot of the requests which were coming earlier are not coming to us and once you ship something right and then you give it to your users and you feel the same things then they give you feedback about so these are like some feedback and they talk about this is one of the best documentation within the org we have built or within the different company if the people have experience working with different companies they have seen we will see a lot of good documentation as I gave example of Hashi Cochai or any large open-scale project they built but you will hardly it's not very often that you see this kind of efforts put into building a technical documentation for an internal product for a team of 300 engineers internally they just show that how much the team itself is care about the product and how much value it can bring in totally few lessons as I talked a little about it supported destination is a myth I won't say we are in that perfect situation I still won't say that we are close to it I think we are still very far and it's an ongoing process and there are a lot of sections where people still feel like they don't have the entire understanding of where exactly the data is and but I think we are very we are a good situation from where exactly we were like before doing this and I think with continuous progress this is the way to go and I think we can solve most of our problems by giving the entire landscape knowledge to people with this microsoft and I would say like your documentation whatever you are building even if you buy a single product from a market it always comes with a handy guy it does not matter how simple that particular product is if that documentation is not there the only thing you will do is you will do a trial and error we will try to figure out what this particular button does for example even for the washing machine since we use it it's fine but if it's a new product you would need that particular documentation to start with this documentation can come in form of a video it can come in form in terms of picture it can come in terms of text right but that has to be there and it's not just a product it's a part of the entire product experience so if you are building a product it's even an internal product even if it's a REST API it's a product to someone someone is going to be the user of it so I would say focus as much as you want if you focus on the product focus as much as on the documentation itself because from my point of view documentation is extension of your product it's extension of your entire product experience next lesson we learned is that communication matter does not matter even if you build the entire product website and you communicate with the people still always make sure that you have an internal interaction with the people to figure out what exact problems you are solving this this applies to even if you have a very genuine experience delivery but always make sure that the communication is there and communication matters in whatever form you do it you make sure that you do it and then fourth is that if you look at like you know as different I talked about these open source projects so what they have is a dedicated team they will have a dedicated team of p4 developers working on it people who are good at writing pure technical documentation, there are p4 designers who are involved into it so there is largely a pretty huge team focused on just making sure that it is communicated to the users what I want to bring out is that it's good they need it maybe for serving such a large ecosystem but it's not necessary we were a team of 10 developers still the same thing and still maintaining it, no designer role involved, no extra frontend developers were involved, no one else was involved and then entire cycle actually just took us close to 2 weeks starting from planning to finishing the entire work and even doing sure because even 2 weeks entire thing is done and after that it has been a continuous exercise that as you write comments in your code you just write mark down lines in the code and then entire thing just keeps on rolling so you can still deliver you don't have to specifically focus or put your mind into that you need a dedicated team it cannot be done without that, I would say you can be even a team of 2 developers can deliver the same experience which a dedicated team can do so developers are good enough for this particular yeah I think that's pretty much it from my side but if you have certain questions around any of this you will be changing to the file sure let me put together this microsite I'm talking about then the chronicle I showed this is not actually your code documentation what it is is your product documentation yes if your product features are changing then you just go and change the markdown files a little bit as soon as you are documenting something say if your API contract is changing for example you would document it somewhere so it goes to exactly the same as that if your API contract is changing let's say you have a postman collection you will go change the request features there as well if you are not doing that you do it but for us it's the same as maintaining that as soon as one contract changes you change certain markdown things whatever it's happening with if there are new features coming we update that it's part of our agile iteration cycle from verification story goes to the production and this is done thank you everyone the joint Q&A session will start at 250 so the joint Q&A session will shortly start so it's like two or three minutes left hello guys I'm Jagdish and we have a panel of earlier and also she's a speaker I believe we have somewhere here to talk we will do a quick Q&A with them so what I feel is like people over here are interested in having different systems in their organizations but maybe you might be having questions around how to set up or how to get started so if you have any questions right now you can ask I have a couple of questions that I can ask do you have anyone with any questions hello so I think you've heard my question already but what's the first thing that you do how do you go about it which is first steps usually the first step is auditing what you already have it starts with take a screenshot of every single screen in your app let's talk about app for example every single flow, every single part of your app that's used very frequently document all of it together then once you have visibility of what your entire app looks like in your design tool, just screenshots you can start auditing now so you can say that this type of button is used in multiple places or let's say now that you have this you want to come up with a new design system a new visual design system you want to change a lot of things about your app this gives you the baseline to figure out what are the elements that repeat and now once you've seen this once you've identified the elements of the list of what you need to do primary buttons, secondary buttons these are different types of text styles, these are different colors we use these are the different types of components lists, cards, things like that and then now that you have a list of everything, you can now start designing all of this once you've designed it, then you can put some processes around that create your systems, figure out how the other designers on your team are going to work with it how developers are going to work with it and that's the start so as we know mentioned, if you have already something like that, that's how you go about it but in case you don't have anything let's say you are starting from the plain site then I think where you can go about is just talking to the people for you are building the product and trying to figure out which particular components you will have for example let's say you might need a card if you want to show some listing and that way you can just figure out what kind of different unique components you might need and then maybe drill down to the smaller one within a card what kind of call of actions you might need maybe you need a button you can go about what different kind of call of actions can be there in the entire application we are building whether it's an app or it's a web platform or it could be anything so you can go either from the top down approach or bottom up, it's up to you but like start figuring out like I think the most of the thing you need to focus on reusability what you can reuse and just categorize that particular entire thing and to add a point not everybody needs a design system if you are just about three designers for example that maybe when you start feeling like you need it under that you don't need it at all if you are just starting out your app doesn't exist yet and you are still making it you don't need a design system that's something you can do later to have more efficient processes in place for future development so like Abhinav mentioned we did a redesign so we redesigned an existing app and we added a lot of features to it so because we are redoing the whole thing we had a lot of wireframes we started with took existing things so how we could optimize the user experience in a lot of features from this wireframes we figured out like the more holistic view of the product we took several screens which looked like the most complex ones in terms of functionality and what user could do there and kind of visual elements also it contained we designed all four, we used design of those four screens as a way to establish the new visual language and kind of start building the first steps of the design system itself so then these components from the four file screens they went into the first layer of design system and then we started as we added more things we could either take something from the existing repository or we could add to it so and a slight change to what Abhinav said about whether you need a design system or not yes you may not need a full space design system so the beauty of design system is you can contextualize it for your product, for your audience is going to be how many people use it and who is going to enroll in all these things they are configurable I mean there is no hard set rules that if you do only this much it's called a design system I mean it is possible that within your organization a simple component sheet and kind of set rules about typography colors and everything is enough it may not be a system at the scale of your material design or something but within the context of your product that's still a documentation you can still write down the principles of how actually came to certain decisions and everything so that is your design system it doesn't have to be as big as a material design or a Shopify Polaris or anything in the context of what you are doing that is your system so one thing that I feel is like so like Abhinav said with the small team you don't really need a design system but then there should be something in place for doing it see a lot of people over here might be working for mid-size start-up for mid-size organizations so for these organizations how do they justify the time and effort that is spent in establishing a design system because end of the day the business is going to come back and say that what is my ROI on this so how do you justify that as well because one of the first things that when you want to set up a design system within your org is like you want to convince developers as well as convince your business stakeholders that yes there is value in doing this so how do we do that if you are answering something I was actually going to answer the previous question I can still answer a part of this question after that I am an engineer mostly I call myself a mostly engineer I actually don't have a lot to say about how to make design systems happen or where to start but in addition to what was already said I would say that talk to an engineer auditing your design is or your existing design system is very easy because code is unforgiving unlike a design tool code is reflective of what your design system is today components are captured and they have names in code they must that's how we write code flows components that or things that you haven't even thought of as a designer but are apparent in the product are captured in code reflect on that and jot it down that's a good way to go and again from an engineer standpoint you don't have to justify that to an engineer because reducing the number of components in code or even making them more clear is only going to make an engineer more happy so at least that one part you don't have to worry about but in terms of business when you need to convince let's say the CEO you need to convince product managers business units whoever design systems improve efficiency the reason they do this is they give more visibility to everybody it helps onboard new engineers and new designers much faster and new features can easily be built out if you have a good documentation so when you talk about very big organizations they have dedicated people who manage design systems just that's their only job mid-size organizations usually you will put a designer and a developer in charge of it maybe they take a few weeks two weeks maybe and then that's a one-time investment and then you revisit it maybe a few months later when significant changes have been made yeah just to actually clarify one question so in though I think all the things we are answering when we actually mentioned the design system what we're actually taking into account is that even the design components are there and you have their respective developed component in whatever thing you are coding into right if it's a web app then you have a let's say HTML, CSS or maybe React component ready for it or if you are building into you know app then you have your like you know your Android app or iOS component built into it so I think most of the questions we have answered we are considering we are thinking that you have this whole thing in place and you are not stopping at your design component just being a design piece if your team is design team is small and that's the point you are like stopping at you just use the reusable module for small small designs and buttons then it's not going to bring that much ROI value and if it's your team size is small but you have built corresponding development component for it then for developers and interfacing between designers and developers that saves a lot of time and efficiency as I mean so I think yeah I think when we talk about we are considering into account that you are actually building it to the level where even the development you know component of that corresponding component is there in the place again I slightly differ because although that helps in a lot of things like you don't have to test everything again if you have your developed components and so it does help there that I mean don't let that be a strong definition of what design system can or cannot be I mean because to me as a designer I see it more as a documentation of principle also and I was recently like I saw at other top Airbnb was talking about their design system where they have covered everything that they have like already passed the point that we all are kind of aspiring to get to right so now they are looking at how to apply a design system thinking or rather a design system to the user journeys of their flows and everything so they are taking it one level to the user experience part of it and kind of setting up rules for that how to approach that and then next ambition is to apply to kind of human values of what their product could be so I would say that the definition is constantly evolving and think that it should can only be this and not anything else would kind of become limiting in its own nature so define again it's completely in the context of what you are doing within your product that's where you can start and that definition changes with scale as well so like at my company we have four designers something like Flipkart you might have 30 closer to 50 Airbnb has about 400 designers, Facebook has about 800 designers questions that you're asking is you know it's probably different at every scale importance is different at every scale and probably the goals are also very very different at those scales hello so my question is regarding how do you deal with visual regression so two things which I so I personally try to implement design system in my own team and one thing is there is the design system is kind of keep on evolving like initially things are not very clear and you as you keep on dealing with a lot of things and implementing you let's finalize or materialize second thing is design and development both go hands on hand you have like certain components in design you need to have exact similar development or engineered component also present if the button is something which you have defined a button same thing you have not written a code about it and let's say using bootstrap or whatever whatever is there it's kind of pointless so what happens usually is you have this one design system and let's say since your design system is evolving you make one change the developers go on and implement the same change and somewhere in the corner of the web the things get broken so that keeps on happening so when you mention that design system improves efficiency I agree with it but it also increases a lot of visual regression so how do you deal with it I think a lot of this happens I think it's not the problem with the design system itself I would say I think it's the problem not sure in your case but I think most probably the problem lies in the way you write code about it and I think sometimes problem also lies into like what kind of choices are made so for example if I made choices like when I started designing my components there was some button I wanted of let's say 4 pixel or 5 pixel the margin I wanted 4 pixel and then in some places I wanted margin 5 pixel or something like that I know there are variations of the one button let's say for example like that like in some cases I think what we do is we end up making these hard choices where we want to have let's have a custom component for 4 as well as 5 and if something into places we need 6 it looks better than just have a 6 I think a lot of it comes by bringing this complexity that somewhere because of that small customization something broke out so from my point of view is that try to get rid of that if there is a 4 pixel 5 pixel I don't think it's going to change the world in that way and try to become as minimal as possible so that's I think from the larger approach but I think if you get mind it to it is then I think a lot of it is becomes to the way you are writing code if you are writing the code in a like very coupled fashion it might happen but if your code structure is good I think it should not happen and that is the whole that is the whole goal should be changed that component one place it should actually flow at every every place with speed comes churn and with churn comes regression that's the way I think about it so if you can go really slowly and do this waterfall come up with a design system build all the components design all the components then build them you have need everything but this is never the reality like you have to start with like your first go at it and then like build up from there slowly and as and when things change you have regression that will happen except it but what can you do to make things better is two fold one is bottom up one is top down the bottom up approach is that you do it slowly over time right which is what in engineering you call refactoring but I believe that in principle it applies to design as well and there's nothing different really about the process take your design and you want to change it slightly do that and look at its effects on other components and once in a while when you feel that a new feature has necessitated this thing go make that change however if you make many of these changes there is enough fluidity in the system that you're unsure what things should be and that's where a top down approach might really help like for example writing down an architecture decision record on software side might really help similarly writing a design system might really help so it has to be both at all times and it depends on the cost at the time like for example the amount of investment that you need in order to make a design system is high but you can make improvement incremental improvements to that at all times I don't know if I'm being clear here but what I'm saying is when you have the time try to do top down when you don't have the time try to do bottom up as much as possible catch up so having a design system in place does make it easier for people to like build newer applications get all applications into the similar visual language right but do you think that this also brings in a design fatigue where like let's say I'm going to build a completely new application and let's say I'm a product manager I want to build a new application I have some ideas in mind so I go and let's take Gojek's case so like Gojek has the microsite where I can go in I have a look at what all available components I have and then I feel that okay I have these things I want this thing but maybe the current components are not going to address my need so maybe I'm changing my needs to attune myself to what my design library is providing so how do you deal with cases like this where you want to still have people innovating on your applications but then and then still face a turn of getting new components into place which will actually address your requirements so how do you handle that I think in for the specific particular use case I talked about it's the scale in itself is not that huge that we kind of face that particular situation but I think largely it comes down to how often it is coming if that new particular feature request or component is coming like so often usually it should fit into a lot of use cases you already have ideally right because let's say for example if take a very small example which I was mentioning in the earlier example as well like how many of these variations are coming and can you actually make sure that it fits into one of the existing one as well I think from the mindset point of view I would the way I like on the personal what I would start to do is like saying no to any new any new feature or component that is coming and I think in 80% of the chance you will be you will find yourself exactly this thing is fitting into it and then there is no answer to it then I think that that particular component needs space in the space in the design system but I think as the time goes on to it if you keep your answer as strict know that okay it's not coming how it's coming and just try to find a place to make it and fit into the system I think most of the cases you will find if not I think then you need it there usually when designers let's say they're working on a new feature they might feel creatively limited if all I can do is pick up these components and put it together just like sticker sheets like what is my job am I just arranging components that can creep in and the answer is just that at least what we do is whenever there's something new the designers for very basic stuff like buttons regular components they use whatever is available but usually for composite components this is where the need for custom comes in so you might have a new type of list item on a different page this might need a new component so they'll just they design the best solution keeping in mind that okay if I can eventually convince them to add this new component and then it's about who is enforcing this so whenever we have a design review it's about okay what were your reasons behind coming up with this new component compared to this and this this kind of reasoning having designers go through that really makes them think about their work that's how they improve as designers and this is usually the way we have a new component or version of an existing component so actually after my talk someone did come up and ask me about this thing because there was coffee right after the people had time again the way I see design system is more than the component sheets and the little efficiency part that's absolutely important I see it more as a way to lay down the principle and rationalize your choices as a designer so that when you are discussing debating any component or anything any solution let's not even call them components we are designing new solutions which are completely new and not part of the existing patterns in your thinking on in your repository you can discuss them rationally and not just because you feel like it I mean it's not not because you saw something new one dribble a new button style on dribble and you want to use it here you kind of rationalize the use of this thing and after that if the new idea stands the test of that rationalization by all means it can become part of the design system also other thing is how frequent it's going to be reused because that's also one of the purposes I mean if it's something you are only doing for one time you have one new landing page come up where you want to try something different maybe first option is always to go through what you already have but if the push is strong enough that you want to try something new do it in new places test it obviously how that works out if it's performing better than or in many ways if it performs better than what you already have probably it has a place in your design system as well so this design system should actually encourage all the designers more to rationalize why they are coming to the conclusion they are coming I was also asked why I picked the type faces I picked so the entire thing like how we went from four type faces to the final one we already one we had is part of that documentation so a new designer it's also about not about the size one designer will move away and take all the knowledge with her right so how is the new person going to adjust to that that if that knowledge stays in form of design system then the new person can immediately start thinking about it and then they can debate okay why is this using Roboto I think I have a better option right so it's more about that also not only like efficiency and everything yes that's fine that's also a little more and the other thing is take out all the busy work of we doing the same thing over and over again because the history of design system or similar framework already exist in print and newspaper design and they design something new well pretty much new every day right we design on weekly basis they design a new product every day so if they didn't have a set of rules and visual language and everything in place they probably wouldn't be able to do that at all so what they do is they do the editorials in a very any slightly different way reusing the visual style of existing the existing visual style but for all the busy work they just reuse the stuff that's already done hello okay I was thinking of asking this when Tejas was speaking as a designer when you have to do a new product do you what's your core deliverable what do you think is the core deliverable the design system or the product itself or in other words would you what derives itself which so is the design system a bright product or is the product a bright product so because I work as a consultant for me whatever client pays for but ideally I would depending on the scope of the product itself and what the product tries to do I at least try to make it a point to deliver some sort of system or documentation on what I've done so even if it's a small e-commerce website in that case it could simply be like all the design decisions in terms of a component sheet and typography colors and everything and why we chose those things the design system is comparably very small but there is a documentation so the devs can start from there they don't have to go through the entire product to figure out the number of components they have to build they have a because as a designer I should have done that job already for them it makes their work easy so yeah I mean very much contextual for me it's very much contextual because I don't work on one thing by the nature of my work I don't work on one thing for very long time and through many iterations that is my take on it but on the same thing we now might be working very differently because he works on a product for longer period. The design system is the byproduct product is the thing that matters and we update it since we don't have a dedicated person to managing the design system we update the design system once every couple of months when enough has changed but at bigger organization we have a lot more designers. You have one person whose job is just design systems so in that case both happen together. And I think as an innovation it's a byproduct so your key matrix should not be actually just the delivery of building these components and giving it to someone but I think consistency and the time saved for the developers to add new thing or bringing in new things I think those are the things you look at finally when you have this entire thing rolled out so I think from my point of view these are the two things I look for like is my entire product consistent and does the like you know having the design system in place brought that and second is that I'm adding something in time it's saved for me so I think that for me that is what I'm I can take other questions just one thing to add so just to like simplify you cannot deliver a design system on its own without designing the product also you I mean I don't think one can get hired to say okay we have a product but can you just give us a design system I mean I wouldn't be able to do that I think we can take other questions later on for the next round so now we have Sohan here yesterday he delivered an amazing workshop on how to make Alexa skills and today we have here for giving a talk on voice UI and how designing for the year differs from designing from the screen so over to you Sohan. Thank you so much. Good afternoon I see a couple of familiar faces over there for the workshop yesterday so let me introduce myself again my name is Sohan I work in Amazon as an Alexa evangelist my job involves helping developers build skills for Alexa and part of that involves talking about voice design now a lot of people ask me what you know give me some tips about I mean building skills or what are the key components of building a skill and what I usually say is the tech part is easy we just did that in the workshop yesterday but the tricky part is actually designing for voice because it's very different from what we have been used to which is essentially designing for screen we are used to designing for web mobile and I'm sure you guys have done that so let's talk a little bit about voice user interfaces and how it differs when you're designing for the year as opposed to designing for the I. I'll give you a small I'll set some context first and look at how we have interacted with tech so far and we've started in the 70s with character mode which was when the era of the person computing really started and we went from character mode which is essentially small black and white monitors with keyboards attached where you enter text commands we went from there to the era of GUI graphical user interfaces which still exists of course but it first started in the mid 80s where you essentially had operating systems that were visual in nature so you could see a file on the desktop or you could move this piece of hardware around that would translate onto the screen and remnants of that still exist today of course with your macOS and your windows and your Linux and stuff like but that was for the first time in the mid 80s in the mid 90s things changed to the era of the web and to access websites for the first time you could get information on your fingertips and to really access that information you had to use this thing called a browser and when we first started using browsers we were introduced to so many new elements and new ways to actually get information in the mid 2000s I think something we're all familiar with the era of mobile where essentially we went from really basic phones with small screens and keep us fairly funky to the advanced smartphones that we have today and think of the sort of interactions that you have on your phone like the swipe right or pull to refresh or how you zoom a page by or by pinching in those are some of the interactions that didn't exist before but thanks to the advancements in tech and thanks to how tech has really evolved how we interact with tech has also evolved so if you see every 10 years or so there's a change in how we've really interacted in tech and as if on time sometime in the present in the 2010s, mid 2010s we finally moved to the era of voice user interface now you might think voice is something that comes naturally to all of us we communicate via voice and language why did it take so long if you've seen a lot of science fiction in the early 1900s if you've read a lot of science fiction in the early 1900s having like these robots that talk was like the sort of fever dream that was that and flying cars and I think we're working on both right now so why now you think the reason is it wasn't so simple but only now we finally have the speech to tech capabilities we have the data we have the data processing power we have the network power so all of this has finally sort of come along for us to be able to talk to machines and hear an intelligent response so at Amazon we sort of believe that voice represents the next major disruption which means that we will be talking with machines we will be interacting with machines via voice a lot more at home at your workplace at your university in your car and so on so I promise this is the only marketing side on the echo essentially it's a device that lets you voice control your world and yeah it's a great device if you want one you probably use it already on the echo there are a lot of things you can do built in you can ask the weather control your smart home lights do like household reminders, set alarms all these typical sort of things but you can really enhance the capabilities of an echo device by using something called a skill a skill on an Alexa enabled device or an echo device is like an app on your phone how on your phone you can do a few things but you download apps to do so that is just to set some context about what a skill is what an echo device is, what Alexa is and so on so let's get into the meat of things we all have been designing for different platforms for a while now of course few of you might have started with desktop most of us probably started on the web or on mobile we sort of got an idea of what designing really means but like I said so far we have been designing for tech which include its screen and one thing we can take away is that when you focus on the user and when you focus on the platform you sort of get like a good user experience but it takes a lot of effort when the web first came around it wasn't always pretty like it is now I don't know it seems like a fairly young crowd the days of the internet websites really sucked it was terrible basically people had no idea of what to do so they just put in as much as many logos and flashing gifs and mark we text on it as they could and honestly I know there is a government thing happening next to it but a lot of our government sites look like that in the early days which is a little embarrassing but of course now it is a lot better because we finally had like templates and block templates and we finally understood the web we went through the same thing when we moved from web to mobile when I don't know if you guys remember surfing a website on your mobile when smartphones just became a thing but you had to like zoom in like 300 times to read like one line of text because responsive design wasn't the thing back then it took a lot of people to think about design and to really think about the sort of paradigms that would work not just on mobile but also on your laptop and desktop and then people thought you know have a uniform sort of experience and then they came out with responsive design so now reading a website on your phone assuming you know it is mobile responsive is a fairly easy task it's the same with voice though when voice was launched like few years ago people just sort of either assumed like it could do everything there are of course limitations in tech in natural language understanding and so on but they also still sort of thought hey let's sort of experiences that we have had on mobile just take the same thing I want to be the first in this space you know like first prime mover advantage in that sort of thing and they sort of ported those real experiences without thinking about the fact that it's a different platform altogether you're designing for the year and not for the eye so things change so we're still at this phase I think where similarly how people used to zoom in on mobile where we're still at that phase with voice design and it's going to take from people such as us to really sort of nail the voice experience on voice user interfaces but that's what we're here to do so let's talk about some differences when you're actually designing for voice versus designing for the eye I think the biggest sort of difference is this where with your eye you expect uniformity but your ear really expects variety how we really look at graphical user interfaces is we sort of teach ourselves what something does so if you go to a website or you go to an app you sort of want a uniform experience there if for instance like an Amazon or like a Google decides to change how their website looks and you go to that website you've been using Google search for the last 20 years suddenly that search bar isn't there anymore they've added like another button that leads to a search bar we're all going to be very disoriented for a while because we're so used to it being there we sort of teach ourselves that just as an experiment if you want to sort of if you don't believe me take out your phones and look at the location of the app that you use the most and change it around change the location of, I'm guessing it's either WhatsApp or Snapchat or Instagram or whatever change the location of the app you will see that the next time you want to use the app you will go to where it previously was because we sort of trained ourselves for that app to be there that's how we learn user interfaces to screens with voice though it's not quite the same the year for some reason it's designed that way but doesn't like reputation as much you want a lot of variety so you really sort of need to keep that in mind while designing your voice user interface with GUI like I said again there is a defined happy part if I go to an Amazon or Flipkart I know that clicking on these four buttons will take me to a page that says buy and clicking on the buy button is done so there is a defined happy part to do something if I go to a travel website I know that first I have to enter the details of where I want to go then I enter my personal details and then I pay and it's done I can't do much outside of what the website really provides me there are buttons, there are menus there's a search bar but that's pretty much it so there's a defined happy part to do something again with voice there is no such guidance you can hint at the user to do something but at the end of the day the user can say whatever they want so it's really up to you to sort of figure out what to do also again all the words that you see on a graphical user interface are designed for writing or reading and on voice though you're designing it for speaking a good example I think outside of tech is the Harry Potter movies has anyone read the books and seen the movies I'm guessing most of them so you'll actually notice that the dialogues in the books are a lot different from what you hear on the movies because how we read a dialogue versus what is said in a movie or a cinematic visual experience is a lot different so there is a slight difference there as well and finally and this might not be in every case but largely when you interact with a screen based device especially a mobile phone it's a very individual interaction largely talking or you know interacting with that mobile phone just by yourself so even at a social gathering if there's a question about say hey does Virat Kohli have like the most ODI hundreds now let's find out people pull out their phones but that interaction you're checking it's still an individual sort of interaction whereas voice is a far more communal sort of interaction the way at least Alexa and all the other smart sneakers are designed it's meant to be like either in your home or at your workplace where around and they can also hear what's happening so it's a fairly communal sort of experience so these are the fundamental like differences that say between a UI and a GUI so keeping that in mind we've come up with four voice design patterns that you'll that that you probably need to think of if you're building for voice so let's just get right to it before that though this is the sort of core interaction of any voice you know any like voice user interface where first the user says something and that's called an utterance an utterance is what a user says so if I say something like Alexa what's the weather what's the weather is the utterance right so the user says something like what's the weather and that's the utterance all voice interactions are very very situation specific right which why you see in the core interaction there's this huge thing that says situation because the response that you need to hear from Alexa is based on that situation and I'll go into that a little later on and that's the response you hear and sometimes you have like a prompt from Alexa as well you know if a user hasn't said something as a reminder so we'll get straight into it and talk about the four voice design pattern alright so the first one is called being adaptable which is letting users speak in their own words now again as designers in the crowd when you're designing for GUI right when you're designing for a screen it's really you guys who decide what the user sees so you guys say hey if we change the color of this button to orange and instead of ok we type the word buy there's like a 30% chance the user is going to click on it so let's do that that's typically what we do as a designer and y'all are really deciding saying hey let's put all this information here and then the next button make this button this color and then this what the user sees so you're really deciding what the user sees and the user has to sort of learn that interface to get something done yeah that's what we do as a designer with voice though it's the opposite because the user sort of is going to say whatever they want yeah and it's really up to you as the designer or the developer of the skill to be adaptable to what the user said yeah and for that there is a lot of tech of course but a lot of design as well goes into it so for instance before that though let's talk a little bit about something called an affordance I'm not familiar with the concept of an affordance an affordance is essentially something that lets you know how to use something by design for instance a sign that says push the door an extra door handle is an affordance because it's letting you know how to use that door handle yeah so there are roughly three types of affordances one is explicit like I said the push sign is an affordance something like a pattern is something that you see everywhere worldwide maybe a convention like the save icon on your system like the floppy disk is a pattern that you see everywhere it's the universal symbol for a save icon or the Wi-Fi symbol so even if you go to a foreign country where you don't know the language and you can't read anything you see that Wi-Fi symbol you know okay that's what Wi-Fi means so it's an affordance and there are also negative affordances which is essentially when like in a form when you disable a button and then the user automatically knows that something is either wrong or incomplete it's a negative affordance because that way by design you're telling the user that hey there's something wrong with what you're doing so it's something that lets you know what to do so that's an affordance on screen based devices we had to sort of evolve from going from you know modeling how things looked in real life to you know flat design so in the early days of the internet and in the early days of mobile your morphism was a huge thing where we sort of took real life objects so this was how a volume control looked on both web and you know mobile essentially because this is how a volume knob looks in real life so you'll see like a drop shadow it looks little 3D it looks like I can actually feel it and I have to move it but you're actually moving a mouse or using touch screen to move the volume up and down then when people actually got a little used to something like this we went to like flat design I'm sure you guys remember the whole flat design shift in IOS the whole thing where designers basically said okay I think users know what to do we can move to flat design so the users know that if I move my finger across this bar the volume will increase or decrease so that is the affordance basically in voice again there is no screen so you'll have to say something out loud to increase or decrease the volume right so you can say something like turn up the volume so the intention or the meaning or what we call an intent behind what the user said is the affordance in voice right so when you say something like turn up the volume that becomes your intent you want volume to increase so that's the affordance the problem with voice is this right you can get your users to say something like turn up the volume it's a fairly standard way of saying this but most users will say things differently again remember it's a voice user interface so people can say something like volume up louder make it louder turn it down set the volume to 6 and so on yeah so these are different utterances that you can have that need to match to your intent which is the affordance so having just turn up the volume work won't really work I mean you're really limiting your user to say just that you want your users to speak actually at the end of the day so you should write your design or your skill such that it can take any of these and actually do that action this is another example so these are different utterances to basically get the name of a college right it's a skill that gets you a college so I can say something like you know let's assume the name of the skill is college finder so ask college finder for the best colleges for the best colleges in Bangalore for the colleges with the computer science program or for colleges with the computer science program in Bangalore right these are different ways of saying the same thing which is to find a college right we're trying to be adaptable to what the user can say all these will match to an intent that you as a designer or a developer will define which is called like let's call it refined search you can call it whatever so it's really up to you to define these different types of utterances to match to that intent yeah also you'll notice that there are some words in blue right and those are essentially what is called an entity or a slot which are variables within an utterance right anything in an utterance that can change so in the second one here this name of the city can change because I can easily another user can say something like ask college finder for the best colleges in Chennai or Delhi or Mumbai also in this example the type of degree is can change right because I can easily say for colleges with the electronics program for an economics program and so on yeah so things that can change within an utterance is called a slot right and essentially this is what it is you have like a degree or a location your utterances should match to an intent that's defined and also have slot value so you have like a degree and a location what the use of all of this is is essentially this is how you'd be developing your skill right where you give training data like different utterances matching to an intent and then there are natural language understanding algorithms right and I'm going a little technical but what the NLU algorithms do is sort of take what the user said and it matches it you know with an intent and that's how you know the intention or the meaning or the affordance behind what the user actually said there are sometimes though why you might want to use synonyms as well right sometimes your slot values can have synonyms because assuming you have a skill which has four different slot values which is size right like tiny small medium large again not all of your users will use the words tiny small medium large and the reason is someone might not know how tiny is tiny or they might just use a different word who knows right so instead of tiny they might say like minuscule or little instead of medium they might say average middle or in between instead of small they might say little again yeah so it's really up to you to sort of design your skill in such a way that it takes all of these synonyms as well and you know sort of you are adaptable to what the users really say yeah so that's why you really need to be adaptable while building a skill okay we'll talk about the second voice design pattern which is to be personal right and which is essentially talks about interactions in context I think the great thing about conversation interface in general you know chatbots and Alexa skills and so on is and I like to use this line a lot right so far we've been forcing humans to think like computers humans shouldn't be thinking in terms of radio button drop down menu swipe right etc those are not natural interactions but now we're actually forcing computers to think like humans right so with conversation interfaces you can actually have like personalization and contextualization in your skill and that means a bunch of things one is you can really tailor and change your skill and evolve your skill over time yeah the first time a user logs into a skill you can say something like hey welcome to the skill here's how I can help you this is what I do and so on right maybe the second time you say the same thing the third time you say the same thing but you don't want to say that exact same message the 20th time the user is logging into your skill they already know how to use your skill right but on the other hand on on phones you're going to see the exact same UI every time you go there which is a good thing you don't want your UI to change you want it to be uniform and you want to have that consistent experience right so with the screen-based device you like it to have that uniform consistent experience but with voice design you know you sort of need to tailor your experience and change things around quickly right so really have your skill evolve you also need to think of the sort of roles that your skill plays with the user right so there are we roughly look at it as three different type of roles the first one you know is like the dog sort of fetching it's it's about giving information immediately like a good example is a weather skill where I say something like Alexa what's the weather and Alexa says the weather in Bangalore so and so you really want to be quick and precise and concise and I say something like what's the weather I don't want to hear hey welcome I'm your weather skill I can help you with this like my facebook page to know more etc right because it's a very informational very transaction sort of skill so giving a quick response back with like a concise amount of information is what you really want another type of skill is a concierge like like like the guy helping out the lady there it's a type of concierge so think of like a travel planning skill and I'll show an example later where you'd call off your travel agent and then there's a lot of back and forth between the two right there's a lot of back and forth between the two and you're really sort of guiding the user and helping the user by asking questions and you're not getting something done for the user you really like like a support like a concierge so based on that the responses will be very different right you'd really personize and contextualize your skill based on that particular role and the last one is a sort of entertainment type of skill you know it could be a game it could be a choose your own adventure that's very popular on voice interfaces where you say something like when the skill says hey you've entered this dark room and there are two doors which one do you enter the left or right a different adventure happens on each maybe it's just like a you know like a fun podcast type thing so it's an entertainment skill so you have to tailor your response a lot more maybe add more jingles add more sound effects you know add there are these things called speech con which are local lingo words that Alexa can say so you can get her to say things like ballet ballet and macha and stuff so really think of how you can keep your users engaged with using things like that so that was two on how you can be contextual the third one is be relatable right where you're talking with your users and not at them again on web and mobile it wasn't really a cooperative experience right again website would offer you something and it's fairly individual sort of experience with voice it's a very cooperative experience there's a lot of back and forth between the skill it's almost it's almost human like it that's why it's called a conversation interface so you really want to talk with your users and not at them yeah don't expect your users to remember a whole bunch of things they are cognitive load shouldn't be on trying to remember how to interact with your skill it should just be able to speak with your skill naturally right so this is a bad idea right where you say something like Alexa open holiday planner and tell me the cheapest return flight from Bangalore to Goa on the 10th of December returning on the 16th of December with offers available on HDFC with cash back blah blah blah no one actually talks like this in real life so you shouldn't expect your users to do this and invariably if you expect your users to do this you're the one who'll end up with a whole bunch of errors right because your code has to actually parse all of this pick out the right things and then you know and then provide the user an answer you'd rather have something called a multi turn dialogue where like I said it's like calling your travel agent and there's a lot of back and forth right so for instance this is how the conversation would go I know there's a lot of text but so in the beginning the user says something like Alexa let's call the skill outdoor guru so Alexa start outdoor guru and then the skill says you know welcome to outdoor guru I can help you blah blah blah where would you like to go the user says Goa Alexa says are you sure Goa user says yes Alexa says when do you want to leave next Friday until when the following Tuesday what would you like to do I'll be fishing did I get all of this right yes and now you know I have two ideas for you and you hit like your API and get some information and present it to the user so it's a lot like how you would actually call up like a travel agent or you know like a holiday planner and it's a very interactive cooperative sort of experience so you should try and build your skill like this where essentially you're helping the user out with two things right if you really think about it things like source and sorry destination dates of going and coming back what activity you'd like to do are all what I said is a slot value right it's a variable at the end of the day and instead of having this where you have like different slot values in one huge utterance you're sort of eliciting the slots from the user yeah so the user is engaged is conversational and you're getting the right answers there are a few things happening here one is you're eliciting slots at couple of places so you're helping the user out with the slots in this step here you're actually confirming with the user a slot value especially when you have a lot of proper nouns that's a good practice because like for instance Bangalore and your sound barrier like so maybe you just want to make sure Alexa pick up the right thing right so you're confirming the slot and after so much information you might want to confirm with your user saying hey this is the information you gave me is this right or can I make any changes and if the user makes any changes please go ahead and actually write your voice design and your code to be able to accommodate those changes as well so this was about how you could actually be relatable and not have things like this but actually have like multi-term dialogue to get information done from the user and the last voice design pattern is to be available right and by that we mean basically rethink your menus and your top level UI what this essentially means is again so far with voice and with mobile sorry with mobile and with web we've been sort of designing our data in a slightly different way than what you should provide right it works in the sort of same principle that there's a front end and a back end in the front end with voice user interfaces things you say whereas in front end on web and mobile it's your screen that stuff remains the same but how your data stored is going to be slightly different right so I'll tell you an example right here if and this happens a lot of times so if a user or rather if Alexa says where do you want to go a user can say something like go out tomorrow right yeah just give me two amounts go out tomorrow that happens often and then it will be a really bad experience to ask the question when you want to leave again because the user has already answered it so in effect the user has over answered that happens often so yeah it might leave a bad experience but you'll still get your API call at the end of the day so that's fine but when the opposite happens it's even worse so Alexa ask where do you want to go and the user says I want to leave from Bangalore right so the user actually hasn't answered the question so you don't have this piece of information and then you continue this way and you don't have one piece of information one slot value and your API goes for a toss basically right because your information isn't complete so typically users will over answer and under answer and essentially the how you would handle that is not by using a typical flowchart type UI right this is how you would look at screen based devices where you say okay a user logs in a user does this a user clicks on this button and there's this entire flow or the user clicks on the other button there's another flow so you have lot of nested level you know iteration you'd rather look at what we call a frame based UI where there is a frame in which you need certain piece of information and until that frame is over you keep asking questions in that same frame yeah so in this case until you get these four pieces of information these four slots until you elicit these four slots that frame keeps continuing on and on right so that frame keeps going on until all those piece of information are complete and then you make the API call it's a slightly different way of actually looking at how the data is stored also try and have a wide top level UI as opposed to you know like nested menus and the reason is this I'm going to take a very specific example if you want to find the IFSC code of your bank what do you do you go to your bank's website you log in and you sort of click on your profile then you go to bank account details then you scroll all the way down then click on another button and then go to IFSC code and the reason and it's completely fine to do that and the reason is on screen based devices you have a limited number of pixels so you as designers say hey this is the most important stuff we need this is a hierarchy of important things so let's take all of that accordingly right if you translate that to mobile web you have fewer pixels so you might show just the five most important things and the user has to probably make more clicks to get to IFSC code it doesn't work that way with voice though right a user is not going to say okay open my profile okay go to bank account okay do this etc they'll directly say hey Alexa what's my IFSC code or open HDFC and tell me what my IFSC code is and that wouldn't work if you had like a huge nested sort of menu which is why you need to have like a wide top level UI where these piece of information are accessible immediately right so that's the slight difference again and it's about all about being available so just to recap we spoke about being adaptable which is let users speak in their own voice which means utterances, intents and slots be personal which is interactions within context you want to be relatable as well which is talk with your users and not at them you know we don't want like IVR type responses and we also want to be available which means to rethink the way your data stored and you know how your menus are stored just want to end with this quote from Gartner Gartner does a lot of research on cutting edge data and you know innovation so in 2018 they said something like this they said conversational platforms will drive the next big paradigm shift in how humans interact with the digital world I think it's a great quote because you know conversation interfaces are really here to stay and I'm sure it's going to disrupt how we engage with basically right and if I were to tell you ten years ago that keyboard and mouse won't be the primary user interface you already laughed at me so I'm here now telling you that touchscreen probably won't be the primary user interface ten years from now and it will be conversation interfaces so as designers you all are the ones really at the forefront in defining that experience so yeah do check it out anyway thank you so much these are my details thanks a lot I think I'm out of time so I'll have questions off stage one question if anybody has or else do we have any questions we have one question we can take one question there hi for a designer how much of interface design is involved in DUI so I'm not sure what you mean by interface design in the traditional sense but I can tell you this for any skill or any voice experience I think the designer plays the most important role right because I still think I'd still say the tech is the easy part and this is something that users are still not used to or it's new so designers actually play the most important part and it's all about interaction design at the end of the day like my colleague often says like always start with people and not computers when it comes to conversational interfaces and this has actually opened up like this entire new job market so now you have like dialogue designers or voice VUX people and stuff which are completely new job description in itself right where you're really sort of studying the interaction between a user and a voice user interface which is completely different from like HCI and like a traditional screen based so I'd say it's very important and it still falls under interaction design just that with the voice I'm confused because it involves a lot of machine learning data science and a lot of other stuff but you know the traditional way of design is no more involved right so in that way I'm like for a traditional designer it is a complete shift if you go to see so that's a question I wouldn't quite agree with it being a complete shift because as a traditional designer you look at like say a website and you say okay how to make this website the most user friendly website for my user and you're doing pretty much the same thing just via voice the good thing is lot of the tech stuff is taken care of by either the Alexa cloud or you know by like the tech team so you don't as a designer you really don't have to worry about the machine learning about the data science about any of that stuff right your core focus is on providing that voice user interface for your user right at no point as a designer I'm like okay how do I do the machine learning algorithms for this because all of that is taken care of by the Alexa cloud and not just with Alexa with any other system as well so you're really focusing on okay how are my users going to tell Alexa and how is my Alexa still going to help the user complete the task but that is again the job of data scientist or job of machine learning again that is the tech right so like okay let's take the trip planner they define all of those things right they define what the user should speak and all of that which is the wrong thing right it's basically like getting your engineering team to do the user interface in your app you know what happens and that happens right so it's the same thing that skills or you know building for voice needs designers to actually get that experience right you don't have your engineering team do that that is how even you know the coding happens you know we write high level coding and all that that's because we have defined or C or C++ there are definitions like you know what should be written and all of that so that is what even coders do that is not given by the designers but now if we say that you know we have the designers have to say what should be done and all of that then again the tech team will have a tough time no not quite so again let's look at front end and back end right on a traditional screen based device your front end is what the user sees so if I go to like the Hasgeek website for instance you see like an eyesight the menus etc and all that is sort of designed by the design team right so the design like okay I want these colors I want this menu I want this interaction to book a ticket it's the same way with the voice user interface there's a front end and a back end the front end is anything a user says to the skill so in my previous example that conversation is the front end part the back end is like that that pure back end making a call to some API that you have which is taken care of by the tech team that is not related really to the design I mean it is obviously that it works in conjunction with each other but that's not something you really need to worry about you really need to worry about the front end which is okay this is how my user is talking to the skill this is what my skill is going to respond to help the user etc so I'd say it's designers still play very important part thank you alright do we have time or we can take one more question if we have do we have more questions okay so I'll be your stage if anyone's interested so thank you thank you so much okay there's a few announcements to be made Manjunath winner of the coding challenge conducted by noon academy are Karthik M.A.M. and Himadri goes if you are here please go and meet noon academy and congratulations to all those who actually raised pool request who raised pool request it'll be great if you go and collect your goodies and gifts from noon academy after the session in the lunch in the beverages time okay so yes now we have we have Ranjeet here and he's from Swetha and he also represents Mozilla community here his talk is on how immersive technology is shaping user experience it's actually a talk where you get to know the difference between designing which is done for the flat screens versus the designing which is done for the 3D speed so that's what the whole talk is about let's shift to him like Ranjeet so hi today we are going to discuss about how immersive technology is going to shape user experience this is quite very different between designing for 2D screens and designing for 3D spaces but whatever change it might take one thing remains same the design should be user centered let's see how things should be done so with emerging technology and rapid growth of the technology UX is central of this growth because if people are supposed to adopt these technologies they should be comfortable of using them in their daily lives before understanding how XR is shaping the user experience let's try to understand what XR is and other similar terms like AR VR, mixed reality and many other terms you are listening but there is a problem that there is a great confusion around these terms let's try to have clarity among this so like for any field of science you have a scale for virtual reality we have a thing called virtual continuum in the virtual continuum you have two vents one is virtual reality where you win 100% CGI computer generated graphics on the other end you have 100% reality this is 100% reality in between you have a combination of AR virtual reality and reality the most popular one is augmented reality what makes something to call augmented reality if environment is real and the objects are virtual you call it augmented reality there is one more unpopular case that is augmented virtuality where environment is virtual and objects are real you call it augmented virtuality so what makes something immersive reality something with mixed reality where you have 3D effects of audio simulated noise effects all this adds to immersive technology let's try to see how a generic thing like copypaste works in 3D spaces how do you do copypaste in 2D screens with mouse clicks keyboard let's try to see how things work in 3D let's do a 3D scanning of an object just move it the virtual simulated object looks similar to the real one with 3D spaces you can also copypaste real life objects like we can do the text in 2D screens so it's very simple let's try to understand how things work different from 2D screens so looking at the evolution of the screens we look at earlier it was theaters we have distant screens then it reduced to the TVs which are comparatively near then we have computers which are little more closer then we have mobile screens which almost came to us you know with centimeters of difference now we have head mounted devices for virtual reality almost attached to your body it's like virtual organs of your body let's try to understand how things work with virtual reality so let's try to understand how interactions will look in 3D spaces with Skype call you do in 2D screens Mozilla has a product called Mozilla hubs where you have 3D characters you feel immersive into the conversation where you can see the depth of the characters nearby you you can walk, you can touch you can interact with your friends let's try to understand how XR will change UX of devices we interact with let's try to this is the example can anyone say the differences between how to designing XR experience for 2D screens and virtual reality spaces did you notice any differences there are some differences when you design for VR scenes it should almost feel as you are dealing with real life objects for example if I am in a real life I want to switch off a light or turn off the speed of the fan the design is different in virtual reality you have to design almost closer to your real life experience there are some good practices of virtual reality the best US practices of virtual reality are the 4 main important points you have to remember are the virtual reality experiences you design should be believable if you create a virtual reality experiences it almost looks like a cartoon network show it doesn't make any sense that to create a VR experience the VR experience you create should be believable as close as to a real life scene the second thing should be the VR experience should be interactive if you create a VR scene which has only plain walls or nothing much to interact still it doesn't make any sense to have a VR experience the third point should be the VR scenes you create should be explorable because that's how things work in real life and one more thing we have to be careful about when creating XR experiences likewise we take care about each and every detail in 2D screens about the color palette of the font sizes everything when you design for 3D experiences you should be careful about everything if you have the light we are seeing now have a different effect of the color of the shade now if you switch off the lights can you see the difference between red or blue what is the color of my t-shirt almost white ok but the color of our clothes would differ with the quality of light so when you dip a cloth in the water it changes the color it doesn't actually change the physical nature of the color but it just it's optical illusion because the direction of light quality of light, luminosity of light all these parameters affect how we think in real life the same principles would apply for creating XR experiences so when you create XR experiences you should be very careful about where do you put the light element and you should also be very careful about how many lumens you are setting for it and one more experience is you feel immersed because likewise at light you should also have a 3D sound in 2D you just have sound from only one direction but in real life if you are in a jungle in a safari you can figure out where the sound came from and also you can also figure out what the nature of sound is if it's from a predator, if it's from a lion tiger or if it's from your fellow human being you can figure out from the nature of the sound so also with immersive technology you have to figure out that where to put the sound so likewise you select Cartesian coordinate system for the visual elements you should also be particular about the Cartesian coordinate system of audio files so in immersive tech you have 3D audio so the difference between 2D audio and 3D audio is if you want to make someone feel like a sound coming from a different place you have to place the audio file way far away from the center of point if you want to make someone feel like an object is approaching them very faster or closer you have to be very particular about the audio file being closer to them and moving fast to them so immersive technology is not just about the visual elements it's also about how you care about the audio elements and other sensor elements so the general utilities like how we do web browsing in 2D and let's also look at how we do web browsing in 3D so if you look at it it's not no more rectangular or flat screen for 3D you have to design everything as pure also if you look at the controls it's not just mouse devices that enable VR if you have seen Oculus Go you have controllers so in the place of mouse you have controller now in 2D you have only 2 devices one is mouse and second one is keyboard but when you design with 3D spaces you have more devices it also let's also try to understand what are the different types of devices we have when you are dealing with 3D spaces you have factor called degrees of freedom let's try to understand what is degrees of freedom by looking at 3DOF 3 degrees of freedom consider the center of your head as the center of Cartesian coordinate system so think of the XYZ axis if you put your head mount device on your head you can rotate your head horizontally vertically also on third axis this is 3DOF so by using these devices the general VR devices we have is 3DOF we also have advanced VR devices with 6DOF 6 degrees of freedom you'll have another Cartesian coordinate system at the center of your body so you can also sync that with the sensors in your mobile or any other device so attached to 3DOF at the head the other 3DOF will make you feel like you are also immersed in the real scene if you move your virtual reality character it also moves in the scene if you jump the virtual reality character also jumps so all the moves you make in XYZ axis your virtual reality character simulates the same thing so one more thing we have to understand is virtual reality also has real life consequences for example if you are designing for a 2D if you have all your pages in the sidebar menu or if you have everything in your navbar menu it's pretty much fine to have a 2D experience but if you do the same thing with a 3D experience you are forcing your user to move your neck all the time if you force your user to move his neck for more than 5 minutes he'll die with body pains ok because when you are designing for 3D spaces you shouldn't make your user uncomfortable and one more thing we also have to understand is the wide angle for virtual reality is 90 degrees for the real life we have 180 degrees but the general devices for VR we have only 90 degrees so you have to also be conscious about when you are designing a VR scene try to limit the angle to 90 degrees and one more thing if you are not careful about the real life consequences if you are making your user if you put elements that move very fastly with high velocity if you make your user jump fastly that's not similar to the real life they'll fall to motion sickness so if you don't design your VR properly you'll make your user run to a nearest bucket they will attempt to be vomiting nausea body aches everything so to make sure your VR scene is motion sickness proof you should also be very conscious about the velocity of all the elements in your VR scene so if any UX designer here is planning to start designing for 3D spaces it's very simple thing everyone can start it just try to understand how XR works what are the new input formats we have all these we only have keyboards and mouses now we have user input now we have look controls we have additional controls hand controls and try to understand the new vocabulary in the XR domain like we were listening to the second slide and let's try to understand the difference between head tracking and motion tracking so ultimately XR is a very new domain it opens a lot much of scope for UX designers but with a test which here is you have limited options when you are designing for 2D flat screens all you have is hardly pointing and clicking but when you are designing for 3D spaces you have many parameters to take care of it could be face recognition voice recognition head tracking, motion tracking and near possibly brain waves so this is where we end the talk we can move for Q&A so my question is like whenever I am designing for a 2D elements are limited my audience are big now when I am designing for this 3D world the XR system the adaptability is still very low the count of user is very low why does the point of putting that much effort now in the system is there a reason I should go and invest this much time and design something for VR when my VR user is very limited this is a very nice user's base I have never seen someone actually trying to explore and buying something on a regular basis so let's say I am just taking an example let's say I am an Amazon guy I am trying to design an interface for VR whereas my people who come and have fun on a VR will not actually convert into a user is that still a valid time to put into this space very good question, thanks for asking so all these days VR is limited to R&D and this is the time is 2018 last few months it's in the market so as it was said all these days it was referred as a niche technology or you know with limited user base limited geeks but it's into the mainstream now how many of you played Pokemon Go so pretty much everyone right Pokemon Go it's a very viral game it's one of the AR game to become so viral so the lax of people who started walking out of the rooms who never walked around with XR technology that's one thing and there are many new apps and you know many across the business with Oculus and other things so the XR users now in 2019 are you know are less but by 2020 it's expected not very far in two years we expected that around 20% of web users will start using XR experiences as a regular use that's the reason Amazon have started Sumerian Google have started their own air platform Mozilla have started Mixed Reality so all the big B's and all those small startups started jumping into it predicting the new future so everyone is trying to be the primers to capture the market thank you so much Panjith let's give him a big round of applause for this one and thank you so much now we can move now we can move for the next and we'll assemble here again at 4.45 for the closing keynote so see you again okay hi I'm gonna start the talk and I know we're slightly late so I'm just gonna get going so I'm talking about building and scaling design organizations design teams design organizations whatever you want to call them and this is a bit of a change from the previous talks that have happened right the previous talks that have happened today have all been about crap they've been about becoming better at the kinds of things that we do just design whether it's collaboration whether it's technology all of these things have been about how do you do design better it's been about design systems which allow teams to collaborate what I want to do with this talk is I want to talk about how do you create the space for doing better design at an organizational wide level how do you create enough space enough you know it's either literal space so you have space for the design team to be available you have space for the design team to get better at their craft you have the budgets to bring in things that you need to get better you have the mind space to start thinking about things like professional growth and development of your designers so who is this talk gonna be interesting for and I think that's you know reasonable question you either are a part of a design team or an organization or you run one or you want to run or be part of a design team or an organization so and quick note on the last one if you decide that you want to run a design team or an organization quick word of advice is don't so why am I talking about this at this conference right the first reason is because there's very little information out there about building effective design organizations right there's lots of information about how to I don't know vertically center text there's lots of information on how to make better design systems right there's lots of information about how to use different and better design tools we had pages speaking about design systems we had other people talking about you know different products like Figma which allow for better collaboration but there's very little information out there about how do you grow from being a small design organization with maybe one person two people two how do you make that larger how do you make that better how do you scale it up and still do good work right I think that's the key part of it yeah it's not just about adding numbers right you don't want to say okay now I have a 50 person design team that doesn't work you need to have the right kinds of people you need to have support structures in place you need to have other people who do nothing except ensure that the team has the software licenses and computers that they need the other reason that I'm doing this talk is that most design teams most design studios are run poorly most design teams are run poorly most independent studios shut down very quickly after they've been started most you know lots of design studios that I know in India most of them shut down within three to five years that's pretty bad and I think like if you talk to if you are part of a design team if you're a designer yourself or if you have friends who are designers you've probably heard stories about how designers make terrible managers and how their manager is really really terrible right so I've organized this talk into two or three parts the first part is yeah what are the conditions that you need or what is the environment that you need to run and build an effective design team the second part which is a large part is a pathway to show scale right how do you actually grow from not having any designers right I'm sure if you've been in smaller startups or even larger ones you've probably been in a situation where there's been barely anybody maybe an engineer is working on design or sometimes the CEO or a product person how do you move from that point in time to a place where you have I don't know 50 60 designers all working together and doing good effective work so who am I I run a small design studio called uncommon we are a design and development studio we primarily build and design mobile apps for our clients we work with lots of people over the years lots of I think we work with I just checked we work with most Indian unicorns even though I dislike that term I'm going to be using it at the price during the talk in different contexts and one thing that I do a lot these days is that I help our clients it's kind of funny because they outsource their design to us but I help a lot of our clients in source design so that's building in house teams helping those teams build the capabilities that we need to do effective work so self help book time 12 qualities of effective design organizations I stole this from another popular book okay going to jump into things there's three things that well not enough contrast first lesson but there are three things I'm going to be talking about the way I've structured these 12 items the first part that I'm going to talk about are the foundations of what's required the thing the second thing that you can't see is output and the third thing that you can see is management and I think there are components under each of these that are required to build effective design teams right so the first thing that I think is necessary to build an effective design team or an organization is what I call a shared sense of purpose right now you've all heard and some of you may have had the misfortune to have actually needed to come up with one of these mission and vision statements at some point in time in your career or maybe you've interacted with your companies and they're awful right they're trite they're cliched they just should not exist in most cases but where can they be useful how can they be useful right there's very little articulation on a lot of the time about what is why does our design team exist and that reason will be different for each design team right so a shared sense of purpose helps ask helps act as a first pass filter right it helps externally articulate how how the design team operates right do you for instance say that quality is going to be the thing that you focus on or is it going to be speed right are you a team that believes in iteration which is what I think is the right answer or do you think that one should build things right the first time right visual delight versus it works well or are you going to be like apple and say I want to do all of these things right so it's also a useful reference for the team internally to look back on and say hey are we actually doing what we said that we're doing are we actually working in an iterative manner right are we actually doing the best possible work today or are we just shipping stuff out of the door because that's what we need to so that's often a useful checkpoint for internally it also externally helps as a first pass filter so that people can say do I want to actually work here is this the kind of work that I want to do is this a philosophy that I can identify with and believe in the second part of the foundation right is at a leadership level right you do need to have leadership which is and I think these terms are key right you need to have them being focused and you need them to be empowered right I'll go into those two words in a little bit more detail but the first thing that leadership does is that it provides cover for a team right it ensures that the team can do the work that they need to leadership also provides guidance it provides direction so you essentially are the north stars to say that okay yes this is how we're going to do things we're going to say no to this particular request we're going to ensure that you have enough time to do X they negotiate between different parts of the organizations as well right they're the seat at the table we've heard this term a lot design needs to have a seat at the table so they are the representative of the design team at the table when they're talking to the executive right then they do boring things but essential ones which are like fighting for budgets priorities and you know whenever there's a conflict between teams between say an engineering team between the design team between legal between finance HR they are often the representative or they need to be the representative of design at that point in time so the first part right focused with focused what I mean is that often what happens is that design reports into a different division I've had clients who had design teams which are reporting into say the engineering team often they will report into product what that means is that the energy of the leadership is at that point diffused into these two different areas and they often don't have a strong sense of what how design can contribute positively towards this so design needs to be owned by design leadership right you need to have the ability to think about how to mentor the design team you need to build that team actively right and if you're doing multiple things if your design leadership is also your engineering leadership it's unlikely that they'll be able to do those two things well and so usually what will happen is that he or she will or you know your leadership will end up prioritizing or focusing on the team that they know well or they know better the other part is yeah about empowerment they need to be able to say no they need to be able to say that hey we need four more people we are understaffed and there are too many things on our plate right now they need to say that hey we don't we can't use the existing recruitment pipelines the people you're bringing in are you know the recruitment agency that we're working with are terrible so yeah that's a second foundational value that we need to build effective design organizations right focused and empowered leadership the third thing and this is authentic user empathy right what does that mean design is a discipline which lives under the larger ambit of human computer interaction right but I think that we focus on those last two initials and not enough on the first one right we think about computers we think about screens we think about how performance right we don't think enough about the humans within that equation and it's critical for the design team to be able to empathize with users and be able to understand what their lives look like and how these interventions these design or engineering interventions that we're doing how those fit in in their lives do your users look like you in most cases if you're doing work for if you're doing work your users may not look like you they may not have the same backgrounds as you they may not have the same lives as you and it's really important to be able to understand who they are and and make decisions that support their lives rather than things that you think are right so for instance a good a good mark of this within a good or an effective design organization is is there sufficient time spent with going into users context and seeing them live their daily lives looking at how the design interventions that you make are being received by them right the other part about this which is really useful is also that this is a easy way to make the subjective area of design really objective if for instance you're having disagreements about color about you know I think that this is the way to go or actually this but I see this button all the time or this screen is really simple actually being able to show people around you or in other teams that actual users had a problem at this stage or they resonated really with this particular visual choice will actually lead to that discussion being far less subjective in nature right a quick example on this we worked with a ride a ride sharing a bike taxi company where the driver app actually just had buttons and what happened is that the app was being used by these drivers who were you know on motorbikes in you know similar to an Indian environment dusty loud busy etc and so there was a lot of accidentally key presses which would happen which would do things like move to the next step which was like end the ride or you know I've reached this place even though the person hadn't actually got there so a small intervention might be to move that to ensure that you don't have accidentally key presses so a button to a slider rather which requires a much more deliberate action which is unlikely to be triggered by you know your phone touching part of your body through your pocket etc so being able to understand how users are you know exist is really key to being an effective design organization the last part of the foundational aspects are about how do you communicate that design which is you know often looked at as a really creative discipline which doesn't really have a relationship with business how do you communicate that it actually has value within the business context in which we live other functions typically don't understand that design is important and therefore don't give it the space that it requires designers also I think equally guilty of not being sufficiently articulate or not taking the time to understand the other areas and how design can play a role in actually driving business value right we can't if there are other designers in this room we can't say that we are creatives and we don't think about business at all so you know don't talk to me about whether you know the last 20 years that I've spent really polishing this animation actually was meaningful or not that's a really broken conversation which should not happen we see this a lot today especially with you know platforms like dribble etc which just emphasize the visual aspects of design lead to design which is produced for dribble and not actually solving business problems so it's really important to be able to understand where design drives business value and then constantly be able to articulate that both within your organization as well as externally so that's the first part so that's the foundation of what I believe are the of what are needed to build an effective design on we'll now jump to the part that is most visibly designed the output aspects so the first part within the output or the fifth quality of an effective design on is that it supports the entire journey and what I mean by that is that design needs to have an impact across an entire organization I think you've probably seen this in your own organizations there's perhaps a product organization and then there's a marketing division and those don't necessarily talk to each other or maybe you have other parts of your organization which are completely disconnected customer support is not something where design plays a role but it should because all of these different parts of your company are places which have an impact ultimately in terms of your customers quick example of that is for instance if your product say you're running a mobile app and you have a bunch of notifications which the product team is pushing for because that drives user engagement but at the same time maybe your marketing team who isn't talking to your product team also wants to push their own notifications to users now end of the day what happens is that your customer or your user gets spammed with 15 notifications and then just chooses to disable notifications on your particular app so you're essentially losing that channel because you're not looking at design holistically across your organization the perfect example and perhaps the cliched example of an integrated design organization is is Apple I believe Johnny I've spent a year and a half working on the design of their campus because ultimately they believe that design played such a fundamental role that they needed that physical space to also have design thinking applied to it so that all the things that you know collaboration and I think if I remember correctly he talks about how the most important thing was to be able to see the trees so I guess when you have a trillion dollars in value you can prioritize the trees versus polishing your mockups so yeah supporting the entire journey right the other thing is that and as designers I think we're really responsible for this right is that we don't always look at all aspects of scale right we spend a lot of time on what I call surface of design so we spend a lot of time thinking about colors about typography about this layout versus that layout and we don't think enough about how does this how does design clear role across my entire organization right how does this impact the way that my brand is perceived right so the rough demarcations you know the big picture where looking at everything and how does design impact this but going into things like structure right how do I frame my design briefs are my design job of job descriptions being written appropriately am I getting the right people in to things then and then moving down to strategy so flows between your app information architecture service design so looking at how does the you know if you're large enough to split your offering into multiple pieces there's your login experience have similar characteristics to your checkout flows for instance right and then finally of course you do need to do really really good surface work as well you need to spend a lot of time thinking about the craft and art of what your offering finally looks like so design needs to effectively deliver at all of these levels to be effective the other problem with design is that we don't have clear cut standards for saying that this is good design and this is bad design there's many different ways to measure it it's often subjective it's like I like this it's often about who has the loudest voice in the room at least technology has some metrics right you can talk about okay board has 20% more bugs than it used to you can talk about this pages 40% quicker than it used to be last week and that's a clear improvement but whereas with design it's very difficult to have clear hard metrics and to be unless you often have post factor metrics so you see that okay this page performed better in conversion than the previous iteration of it but you don't necessarily have a metric at the time of delivery you can't necessarily say okay this is objectively better than this screen right so it's really important for the design organization to create meaningful standards to measure themselves by and then to stick to those standards right and not dilute them overtime we need to externally articulate them constantly so that people know what to expect other teams know that okay until things are at this particular level of quality it will not be shipped and I think this is universal but in design all other the other parts of the organizational perhaps unintentionally discouraged this level of quality right raise your hands if you've heard any of this I need this yesterday can you just put this quick fix in can you make the logo bigger why do you need so many people right these are not unusual things to hear and it's not even poorly intentioned it's just the way that organizations are structured and so you need design to be able to uphold and stick to their standards of quality right the other part is that you need to value delivery over perfection and the only time I've taken some animation liberties but yeah you heard about real artists ship right as designers I do think we have a tendency to get bogged down into getting things perfect right and we need to move towards getting stuff out on a far more regular basis right the idea of continuous delivery which exists in software programming needs to also be present in design we need to have continuous design through this thing and I think if you were there earlier for Abhinav stock where he's talking about Figma that's a good example of continuous design there's no this is ready but you can jump in and look at it at any point in time regardless of who where within the organization chart you fall right the other aspect of this is that it reduces the stress of the launch which is often a scary thing if you have continuous design delivery then you're not worried about this large launch which goes out which is you know looming on the horizon probably you know late and where you have to get things exactly perfect the concept of something being ready to ship rather than something being done is a typical concept right if it's ready let it go out there and the good thing about the medium in which we all work is that there's room for improvement room for iteration which can always happen even after something is done so coming to the last bit about the foundations which require which which effective design orgs will require and this is something that designers naturally chief at right managing having managers having management it's often seen as process which hinders me but this is something I believe very very strongly that for the long-term help of an organization or for of a team you need not just design management but you need good design management right you need management to think about what is professional growth look like for all members of my team you need people to look at what makes my team happy and effective how do you ensure that you don't get disillusioned while being a designer so the four points that I think make sense here are you know again the H in HR right where all humans treat people like they are and not as resources right the sort of linking back to the earlier point design doesn't have as much definition as other disciplines right what's the difference I don't know what the difference between a UX UI service creative technologist product designer any other titles that you can think of right user experience programmer I don't know I've heard like 30 titles for people who fundamentally do similar things right and that often corresponds to salaries to compensation etc so we need to be flexible around things like titles and ladders and be willing for different parts to for people to kind of grow through right the other part is design is often an understaffed or overstaffed right so if you're understaffed then design team is just stressed out a lot and not delivering effectively if you're probably overstaffed then people don't have much to do and I think that designers especially want to see their work go out into the world that impacts that a lot is there a budget for education because design like technology is an extremely fast moving field you know the kinds of design tools that I know about and I've used are rapidly becoming obsolete I believe that today if I want to be really effective I have to learn JavaScript and be you know making prototypes in framework now so the other thing that's also hard is to allow team members to also move to other positions or other disciplines right that's also a reasonable growth path to expect and that's something that you know say as somebody who started as say somebody who's working on content now wants to move into design an effect or rather a healthy design org would be one that allows that transition and growth the other thing that I think that design teams do poorly and which we could do a lot better is to have far more diversity in terms of people's perspectives and backgrounds right the thing I see all around me is that design teams often look very very similar and it's really simple build a team that looks like yourself that's easy, that's safe, that's comfortable you know how this person works you know what motivates them, what drives them you know you can make the same kinds of jokes everybody gets along but unfortunately design requires divergent thinking right design is one of those few not few areas but I believe divergent thinking is fundamental to coming up with really really strong design right especially in India where you have so many degrees of diversity that aren't being fulfilled right gender is one large area which design does a little bit better than engineering but not much the others are even harder right there's caste in India, there's class there's people's orientations there's religious diversity there's also language diversity right most of the design teams I work with all speak or design teams have seen English is the lingua franca but the intended audiences especially in a country like India are far far different from that and that has a huge influence if you create a diverse team that also helps ensure that your assumptions and biases are at least questioned and that ensures that for instance you know if you have a design team which is all male all between the ages of say 20 and 30 you're going to get a particular set of design solutions and those design solutions may make certain assumptions about say how comfortable people are with technology or what's important in people's lives etc and this is hard right you have to ensure that you have to remove bias which is present you have to remove bias in recruitment you have to remove bias when you're hiring when you're promoting people even when people are growing within the organization but it's key the other aspect is how much collaboration happens and how do you create that space for collaboration and by collaboration I mean that feedback is encouraged feedback is both encouraged to be made as well as to be taken mistakes are encouraged mistakes are really really important as somebody who's been doing design for a while now I will tell you that it's very rare that you know that a design is right when you put it out there there is a lot of experimentation a lot of mistakes which you need to have that space to make that with collaboration you need to ensure that there's sort of a critical piece of ensuring a collaborative environment is that there's respect there's respect for each other that feedback happens in a way which is frank because that's really really key but you're not compromising your quality standards for this there's this whole idea of creative abrasion where you have divergent perspectives and you fight them out to ensure that the best solution comes forward again you know going back a little bit to the previous slide how do you ensure that how do you create structures that ensure that all the voices are heard and not just the voice or you know the person who leads the organization finally says let's do it this way jumping into the last bit how do you ensure that operations happens effectively and because design typically emerges from a very sort of creative loose space operations is often something that's overlooked but it's really important to ensure that you constantly remove what I call the sand from the gears so that things move smoothly people can do the best work that they can that's that's really important basic things like coordination file management access to hardware software whether people are you know have reasonable working hours these are all key parts of operations which need to be taken care of so essentially this is you know sort of if we sort of look back at these three things we need to move away from you know sort of very crude productivity metrics like how many designs have I made this week right almost as meaningful as asking how many lines of board did you write this week right treat people like humans and it's especially important here because in some sense as designers we exploit our own humanity because the way that we work is that we take that empathy that we feel for people or we build systems to create empathy for other people and then we convert it into our design products so since we're doing this so often it's really important that the organization ensures that designers are treated like people so I'm going to pause here for a sec because I think there's a good time to if there are questions and if not I'll jump into the evolution of design orgs and a bunch of ways to get from zero to many some of the other so two questions one is how do you ensure or how have you ensured the baseline of objective quality in the design work and secondly what checks and processes one needs to put in place in order to make sure that the highest paid person's opinion or hippo does not take precedence over everything else cool great questions I think this I'll start with the second one so often when we are asked to approach a design problem we jump into like one of the first processes that people jump into is this one called brainstorming and I think brainstorming is awful it's fundamentally broken it doesn't allow for great solutions to come out and it prioritizes the loudest voice in the room or the person at the top of the pecking order is or her solution to be prioritized there are lots of ways in which you can change that for instance if you are familiar with the design sprint I don't know if some of you have run them or even part of them there's this whole concept of there's a really nice phrase that we use which is escaping me at the moment but essentially brainstorming quietly together so there's an actual exercise where everybody comes up with solutions to a particular problem on their own and after that the solutions are maybe put up on a wall for instance and then you can go and look at which aspects of which solutions you like and then there's a bit of a voting process which happens that's a small way to ensure that the loudest voice doesn't always sort of win the other way is also ensuring that the small things like ensuring that everybody is heard we do really silly ritualistic almost things like giving somebody a particular object and only when they are holding the object can they actually speak it's a shortcut to ensure that everybody gets heard but it actually works it works much better than just allowing anybody to sort of say something I think the other thing is also in terms of how you structure and ask for critique and feedback and that's a whole other topic we could go into 30 minutes just talking about structuring critique like I said one of the underpinnings has to be respect the others have because only when you have respect can you have really frank feedback and only if you have really frank feedback can you ensure that you're not diluting your quality standards that sort of a stab at your second question the first one is harder and the way that I don't know if there's as many different ways as there are organizations the way that we particularly have solved this is by saying has your design been looked at by somebody else have you worked on this with another designer for instance so we've borrowed the concept of pair programming from you know extreme programming and mentors like nil and so etc and we've applied that to design so we do pair design we also then ensure that we build in user testing into all our cycles before saying that this is ready so everything goes through around where it's exposed to actual people we look at their reactions and then we iterate on that so it's not as subjective hopefully then it is yeah does that answer cool any more questions otherwise I'm going to jump into this part of the so this is stage one right you oh okay run stage one is the initial pair right and this is really really important that you always that when you start you have two people working together you have somebody who leads the team and you have somebody like a product designer this will be a little bit more relevant towards digital design because that's what we do it's really important to have these roles as distinct separate ones so that if you remember we talked about delivering at all levels of scale so that people can both people can think at the levels of scale that they are suited to right you have enough time for the head of design to start thinking about prioritization about planning how do these requirements match what needs to be done in the future and you have a product designer who can actually go really really deeply into the craft of how does this look and work and so on right yeah so there's these are kind of the characteristics right they need to be creative they have managerial roles they have operational roles but there's still a maker at this size right your two people you still have to be a maker from two you slowly go towards stage two which is a full team and this is roughly what that looks right you still have that head of design you have now say three to four product designers right this is still sort of a manageable number we found that teams of roughly six to seven are roughly how many roughly as large as a design team can take without needing further management input right we introducing two new roles at this point as well you have a communication designer so that's somebody who sorry works on collateral it could be somebody who works on illustrations it could be marketing materials it could be you know graphic design broadly the other important role at this size that we've noted is a content strategist right our interfaces are full of words right that's 50% of the available screen real estate it's really important to think about how those words are crafted for us and as the previous talk also talked about as voice is becoming an increasingly important part of design you do need to have somebody who is thinking about how tonality how how do you basically communicate different states of a machine to people using language then we jump through you know from a team to an organization so this is where we were at and basically what we do is we double this right so one of these product designers actually it could be anybody right one of the people within the team typically grows into a team lead kind of role and we establish a second team which somebody the person was you know heading design then overseas in more detail yeah there has to be some people skills but they do have domain expertise so they're still respected as a maker themselves the other role that we introduce at this stage is also the one of a user researcher or a UX researcher right and the job of a UX researcher is to take the you know sort of output of the team to eventual users and look at how they respond to it right so there's generative aspects there's evaluative aspects right so evaluative is looking at how things work generative is actually going in and saying hey these are potential areas to solve problems so this is the part at which things start getting tricky I call this stage coordination and complexity this is where we sort of left the team now we're going to grow it by saying okay we're going to introduce a new role which is a design manager who is now completely responsible for that team right the head of design does not play a role at all in managing that team and we kind of scale it up right so roughly you can sort of roughly build a team of this size without needing too much more management right so you have about two or three management level people you double the size of your user research team and then you add two more roles right there's what I call a service designer and then there's a program manager because at this size you've probably got unwieldy enough that you need somebody to do all those operational tasks full-time and you also have a service designer who ties the work that all these three teams are doing together so if there's one team which is let's go back to our e-commerce example there's one team which is looking at login there's another team which is looking at the product page and the last team which is looking at checkout you need to have one person who sort of says hey how do these three things work together and are the flows between them seamless enough yeah strategy and structure yeah and finally we move to a larger design org where essentially the leadership becomes far more distributed right so we sort of left people here and oops we get to this right which looks really colorful but is really interesting and actually I'm just going to jump back one sorry didn't realize I left my animations in essentially what we're doing now is we're going to double this right and we introduce a new role which is the design director who plays the same role as the head of design in the last stage right they're managing one team and then there's another design director who manages another team the research team now has you know gone to four people so it probably needs somebody who's head of research who looks at how does that team actually grow much further look at their professional development right the only new role yeah we have a bunch of other things right we have another service designer to tie even more things tie everything even more strongly together you probably need two or three program managers at this point in time so the two new roles at this stage of a organization evolution that you're talking about right one is a creative technologist and this is a really fun and interesting role where essentially this is somebody who's perhaps doing prototyping full time now if any of you over there for Shri Hari talk we talked about how we're building you know simple this product called simple with a sort of a subset of the features of the main app and it could be completely throw away right a person who's doing creative technologist could be somebody who's looking at prototyping could be you know building these experiments lanes out etc and we're also introducing a new role which is the creative director now what happens at this scale of an organization is that the head of design is unlikely to be actually able to look at craft and how best to enforce quality standards you now do need to have somebody who can actually look at is this work the most are we you know really going deep into the craft of all our distinct areas there's couple of distinct areas right this product design there's content, strategy there's communication, there's research and there's creative technology the creative director will sort of look at and chart out a growth or set quality standards for all of these different things yeah so creative leadership and then this person the head of research leads the research team is this basically hub for a bunch of insights so anytime you want the leadership wants to know answers to a particular problem this is possibly who they would approach and yeah there's a creative technology so these are quickly the design roles that exist divided between leadership and an individual contributor right so that's that's essentially sort of a roadmap to scale and depending on your needs and your organization it will look different for you right if you're an organization say which has a lot of physical events maybe you have a lot more communication designers right you have people who are working on say physical space design like the design of this event and banners and standees and so on if you're somebody who does a lot more digital stuff maybe you have more product designers maybe you have teams of six rather than five or four right so there's plenty of variance variation that this model actually allows for I think the key thing that I'm trying to talk about here is the support that you need at different levels as you grow your team along this path so any questions so far on this where running out of time so I'm jumping through a bunch of things I'm not going to talk about professional growth and design hiring but if you do want to talk to me about either of these things we can chat outside there's lots of stuff here right to unpack if you're interested in any of these areas there's a whole bunch of books and journals and things that you can jump into I'd suggest all of them at different points in time can be interesting there's quick reads like design is a job there's sort of manuals like org design for design orgs and then there are the classics like the mythical man month and cathedral and the bazaar all of these elements of all of these influence the thinking here and in building orgs right so I'm going to stop there one quick thing if you and ask for questions and we can even open it out to be more discussion oriented if you like cool if you do want to connect with me I'm on Twitter and you have my email address as well thanks we are done for the Audi 3 thing and we are wrapping it up we have the closing keynote in Audi 1 by Arnav writing the Haas geek app with native script it will start in oh yeah it's started it's already started so till then bye bye