e 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