 Hi, so my name is Radhavi Kintalbis and I run a small design studio based in Bangalore called Pixalore. I'm Ashash, and I'm a sleepholder engineering, that's a Ruby on the Edge services company, two years old based on a Bangalore. We are all the company behind Ruby on the Edge platform for learning Ruby on the Edge, and that's what we are going to talk about. Before actually getting into the design media, the talk is actually about the collaboration between developers and designers and how we kind of came to some consensus that this is the best way to work. We are still figuring out certain aspects, but whatever our learning has been in the past four weeks, we are going to share that. Let me just give you a quick introduction, so this is the application that we are going to talk about. The challenge is that we faced while designing it was primarily because of the interactivity. So this is the application that I have some content for learning Ruby, or we have some programming languages. I have some code, people can type code over here and actually execute it, it will get executed real time and show the results to you. That's pretty much the whole application. Leaving developers around is a bit dangerous, they don't really know how to control their emotions. So going back to sleepholder engineering, before we started RubyMunc, we have been an Agai company for almost two years. Agai by definition or by the philosophy is an iterative way of doing development. What I mean by iteration is I try to release a really small amount of functionality but a finished functionality to my audience, get the feedback, incorporate the feedback into the product, again get into another iteration and do it as frequently as possible. Now in these two years we have dealt with almost, like I have possibly worked with around four or five applications with my clients. When we started we didn't really have any design capability in-house. So we were forced to work with external designers and most of the time our clients will actually choose the designers that they want to work with. So we ended up working with designers in the US, UK or Australia which pretty much meant that there was no collaboration whatsoever happening, at least not face to face. One practical problem that external designers would face is if we want to work in iteration that means I just care about one big worth of work. But if I'm dealing with an external designer they certainly care about at least one month or two months of work because a client is going to give them the whole idea and you want to really just design one component on a page. You actually need to have an idea about the whole holistic application and then only you can decide what the theme is going to be, how layout is going to be or what kind of feel a user should get when designing that application. So what it meant is whenever we get the final design we have almost complete product with us. Now there is a fundamental problem with having a complete design on table and getting into a creative way of development because even if I gather feedback of the first release I can't really use that feedback to change the product unless I am asking the designer to go and rework on it which almost always didn't happen because of financial constraints on my client side. With RubyMonk we had just one month to come up with a prototype, really easy to beat our customers, get the feedback, again incorporate that feedback into the system and actually do a release. So the reason we had this one month deadline was when we started with RubyMonk we had RubyMonk in the US and it was happening exactly one month after that and we wanted to release the product on that day. Now with this design restraint we had to really break this designer and developer disconnect that was happening because otherwise it would have been impossible to release a good product in one month. When we started we had a lot of ideas, we had a lot of principles like we wanted to have a clean UI, we didn't really want any page scrolls happening, we had some very weird constraints like don't ask me reasons why we had those. Then we had a lot of functionalities as well where we wanted to create gamification, we really wanted social integration to the application, we wanted to cover everything under the sun when it comes to Ruby. We wanted an experience where people can actually type in code and actually run tests around those codes and tell them this is the aspect of your code which is wrong and this aspect you are going to get right. Now the more we thought about all this the more confused we get because we really didn't have any way of ideating. I have 10 concepts in mind how do I communicate with other developers let alone with my clients to get feedback. We started reading a lot about designing UX and we realized that there is something called wireframing. So we started doing wireframings which is this was the first homepage or really shitty one that I came up with. This was the other one that a friend of mine came up with. What we decided to do was we had two parallel tracks, two wireframes happening and we will keep on looking at each of those wireframes and based on that collaborate and take the best of those words. Sorry the batteries are off. Hello. So they wrote to me on the... So this Aakash's colleague wrote to me on the 3rd of September. Then we said we have basically 20 working days to release a product. You want to help us design it? And of course being a slight master-kist I said sure I'd love to do that with you. I came in and they were really at the idea stage. They said we want to be able to teach people how to learn this new... They want to teach people this new language Ruby. And they had some ideas. They said we want to clean and minimal UI. Who doesn't? And then of course despite not knowing anything about design they of course have very strong opinions. And they said oh we love World of Warcraft. Let's make it like World of Warcraft. And... Yeah. So eventually over the course of some drunken evenings we came up with a basic theme for the application. We said let's make it like an RPG set in a Buddhist temple. It was at this point in time that we actually called in and that we called the name of the place. We decided we... I thought that wasn't really ready for the market. The only reason I had that name I could create a video repository to check in my book. Sure. So we came up with the name Ruby Monk. And then we went through a couple of stages of actually picking out what would the visual sort of influences be. So we looked at... We looked at Avatar which is a series that a lot of people like. We looked at the genderless headaches that are involved with Monk's monastery. We were looking really at oriental monks not occidental. And eventually at this particular design I created. We started here. This is exactly where we started. Akash and his team had put together wireframes which really just expressed functionality. And they really liked that. But this was a really good way to communicate. I found this extremely helpful as I'm sure any of you who are designers also do. Because it was a complete feature listing or what they thought should be a complete feature listing. These are some more... These are other wireframes. This is the core of the application. This particular page for example showed that there was a problem. A space to enter code which would then be evaluated and the results outputted. Similar to the way in which it would work in a terminal or an IDE. This was one of the... This was the design at the end of the design process. Similarly, this was a problem page which talks about... Once you've learned a bunch of concepts, how do you put them together to solve a design problem? Similarly, we went from here to here. How did we actually go from A to B? That's really the interesting thing. Not because it was a terribly hard design challenge. The design challenge itself was minimal. But the biggest problem was making sure that we could do this in a short amount of time. Because there were financial constraints. There were constraints in terms of wanting to launch it at a particular event. So we came up with ProtoDrawing. So we started off here. We started off with a really basic homepage. And this is something that I can't stress. It has been a useful learning for me. How do you build something which as designers, we have a very strong impulse to not push your half-finished work to our clients? How do you actually get over that? How do you convey a concept which is half a completely half-baked to your clients and allow them to see your vision rather than what you have at a specific instance? So this was the end of the first day of our workshop. We put this very, very quickly together. We did some basic sketching. And you can already see that things are changing around. We moved particular blocks of content into different places with color schemes which we thought might reflect the original theme of monestries, monks, etc. And then we got an illustration in. And then put bits of it together. So at all these stages, we didn't quite have exactly what we wanted. But we were quickly able to iterate over less than a week. I think this whole process took the first seven days only. At which point we were here. And this is pretty close to what we released at the end of the initial configuration. The application has since been revived. It looks slightly better. But this is really where we were at at the end of the previous. I then changed it around a bit. I don't know if you can see the differences but toned down the colors, cleaned up certain things, changed around the fonts. And this is an important aspect as well because I was here and I wasn't terribly happy with this. But what I think is extremely important as designers is to go with what your visual instincts are. This definitely was according to the theme. But it didn't feel right. And as developers, they were more than happy to take whatever. But it's important to listen to your visual instincts or your design instincts and go with them. So we cleaned it up. So you can see the initial processes of another part of the application. This was the lessons page. We started off really simply. And this is another thing that's important. If there are existing design patterns which are good ones. If there are things which you can easily reuse, go for it. Essentially at this stage, all that I did was add in a basic grid to the application and perhaps rationalize the fonts to some degree. After that, we added in certain features. And the interesting way in which we came up with features or decided to act particular features that they planned was the fact that we were co-located. We were working out of the same office, which was extremely useful because there was constant conversation about where the application should actually be going. And this is extremely easy then for me to have a sense of the changing requirements because I was involved in the conversations which were happening. I could hear debates about whether features should be included or not right next to it. So that's another important thing to take away. So we moved from here, went along with the other visual theme that I showed you and then finally came out with the page that's online right now along with particular features that we thought of. So we moved from a wireframe to then a completed design. And this process as well took, this was the first two weeks essentially. So we were within, at this point in time we were on target more or less. Of course, the developers were holding me back. That's how it was, completely. So the collaboration was literally like this. There was the developer, we were working together, there was Akash right next door and we could see each other's screens, we could see the processes that we were taking. If there were features which were too expensive, either from a design perspective or from an engineering perspective, we asked them right there and then. There was no further reviews, there were no changes which occurred on everybody who is part of the project knowing about it. At the same time, if you've ever had a client staring over your shoulder while you're designing you know that there definitely going to be a huge amount of bike checking. There are people going to say, oh that logo, can we make it bigger? You know that font, do you really think it belongs there? Yes. You just have to say no. That's an important thing, when you're working with a product company or when you're working very closely with a collaborative, there has to be a point at which somebody says, okay the buck stops here, we're not changing anything further. It was nice to have this debate, let's all go home. So similarly, there were features which we designed initially because we thought that you know gamification, everybody is talking about it, let's do it. It seems to be the mentality of a lot of startups these days. So we put in the ability to track progress, to have badges, we actually did it over a couple of times and then we just decided this was going to be far too expensive from an engineering perspective so we cut it, we completely cut that right there. The scope management aspects of it are extremely important for an agile project. So I was kind of wearing two hats while developing this product. I was a developer as well as product owner to say so. Now as a product owner, one thing that I would like to say, what I would like to be is someone who knows exactly what I'm going to develop have perfect estimates as developers and actually meet the deadline. Obviously it was not possible. Every day morning, and that actually holds to till the last 30th day as well, we would meet in the morning, figure out what our things have been developed, what exactly is the stage design in, estimate the existing stories based on whatever work we have done so far and then based on that take a call assuming five days of buffer, how much work we can get done and remove the features, change certain features or even add more features. We are going to a stage where a particular feature we actually removed and added twice. And all this while, obviously he was taking the back. Now this was actually a very important point in the whole product life cycle, but for the MVP is one week before the actual release. We have to take a call that we have one week. We have certain really important features that are important to be developed. Either we can complete those features or we can just stop the development where it is and just make sure that the product that we are releasing is finished and it wasn't an easy decision to make. We had so the social aspect, social integration that he showed earlier. That is one thing that we removed on this day. The challenges or the badges that we saw is something that we used on this day. We actually wanted to integrate identification in terms of getting score and then sharing that score with your friends. We removed all that on this particular day and it was a really good decision. When we started, we wanted to pretty much something like this. We thought it's possible to do it. Somewhere in the middle, we thought this is what we are going to do. And in the end, we shut this. But trust me, it is still more than what we should have shut. We should have shut a lot more late. But all these changes that we saw made a huge impact on the design. At least it flows. So how exactly did we make those decisions? How did we actually decide whether we want certain features or not? Like this is, I'm not sure, this is not really a part of a developer design or collaboration, but you can't really take any calls unless and until you are becoming a product owner. You are completely involved into the process. And the best way to get involved into the process and understand the product is not to look at it from your perspective, but look at it from your user's perspective. And it gets really, really tricky to do that because once you start looking at an interface for seven days, eight days, ten days, you just become blind towards negative aspects. You just see that whatever you have in front of you is perfect. And that's where showing it to people who are not used to the interface becomes extremely important. Just to give you some example. If you can see that we have this really perfect error message over there. As a developer, my target audience is developer. I really like this particular message because it's told me what exactly is happening within a particular spec. But when we actually started showcasing this product to other people and actually we showcased just this screenshot. We didn't even actually showcase the actual product. A lot of people told us that they didn't really care about this. It's just too confusing. And that's when we removed this. The feedback cycle itself doesn't have to be after you have released the product. You can actually or you must do it even before you start writing the first form. We started getting feedback even on this. So when Rahul came in, he already had my wife or anyone else, even people who are coming in to my company for an interview will just sit over there and both do bar bar steps. And that actually worked very well. When Rahul joined in, we had these half-baked sketches. There is some sketch over there that we are not able to see there. We even showed these sketches to other people and tried to get feedback. When you just have 30 days to release, it's not really important to complete everything and get the feedback. Once we were done with the development, and that's the reason we actually stopped 7 days before the release, we started showcasing our product to certain private customers. Basically people who understand where we are coming from, what our limitation is and we actually explain to them what the idea is going to be and get the feedback. For me personally, this has been the best feedback I have ever received. The way we generally do it is I actually sit next to that person, ask him to go through it. You don't talk to him. If he can think about that, it's great. And you just jot down everything that he's doing. When he's clicking on this, you feel that he's confused. You actually jot that down as well. Once he's done with the product review, you actually talk to him and figure out what was his perspective when he was looking at certain features, what exactly he was thinking about. So it's not a private beta. It's a personal beta. Yeah. It's a new term. You heard it here first. Yeah, sir. We are a giant company, right, sir? They grow ice. One thing that you made a huge difference for every customer was a concept that they called a new feature that they introduced for example. So when we started writing content, we realized that rather than just explaining a concept through the text over here, a best way to show a programming concept is to actually show them an executing code. So over here, basically, these are exercise blocks and you will have incomplete code examples there. The user is supposed to fill in, complete the code example, and then submit the code. What we came up with was something called an example code where in the same box, I'll give you a completed code form. You just execute it and see the outcome. A very simple concept, right? Like, there's nothing rocket science to it. And we were very, very aware of people are going to get confused because of this, so we added this text example code over here. I showed it to three people, or three of them, my lovely clients, actually. And every one of them, right there, clicked something, executed a draft, and is looking at it, like, what do I do with this? When we start changing something, he removes that question mark, like changes some syntax over there, executes it, the test either fail or just giving some stupid outcome. He's like, what do I have to do with this? This is already solved. Nobody read the example code. Not a single one of them. That's where we came up with this idea of doing a distinction through color. This is really similar. So this is supposed to be of a yellow, sort of off-whiteish background. We came up with a really simple idea that the background for example code and the exercises are going to be different. And that was enough to tell people that case is something different. I need to have a different expectation. And these kinds of inputs we could get only after having these feedback sessions. This was another part which came out of this personal feedback. As we showed you, we came up with a design where a best way we thought to showcase our product on home page is to push the core functionality on the home page. That is, if I click on run, the code executes over there. And to our surprise, this was the most misunderstood part of the website. Nobody got exactly what we do after this. Even people who are experienced Ruby developers, they click on this. They look around the page for a while. Read, code run, learn, which were unfortunately links. What to do after that? So we finally removed everything. As I showed you earlier, we just changed that to a single link saying start learning Ruby now. That's all. It worked like a charm. I unfortunately don't have statistics for that, but I can show you something else. Another way to get direct feedback that actually started happening after 30 days, but otherwise that's a very important part. We were using this tool called the linkage and then people are pushing in their feedback. We were skeptical how many people are going to do that, but we actually received more than 100 feedback in a single link. This is something I wanted to show. Whenever you change design, there is a way to get direct feedback. When I'm moving from homepage to the get started button that you can see over here, we wanted to know how many people are actually clicking on that. We went through three iterations to reach a level where the conversion rate was earlier 21%, after a certain result, it was 33%. Unless you have access to insights like this, you can't really make a decision. Don't make decisions based on just feedback. So that is pretty much the crux of all our decisions making nowadays, where rather than getting into a subjective conversation for half an hour, we just decided to do something which is cheap to implement and go ahead. Show it to as many people as possible. Nothing beats getting user feedback. At the end of this whole process, we did have this methodology as a theory that we studied before and then implemented. It sort of fell together because of the circumstances. Because it was a short time that we had, we had to release a product and it had to be a working product on day 30. We sort of found these ways of getting around that by working together. It wasn't something that we'd done before, but it did fit into some theory or some assumptions that we'd had. So the most important thing for me was that we need to move from being a visually designer. Of course, all of us know that. We need to become an interface designer. That's the new buzzword. Of course, an experienced designer. But more importantly than interface, we need to become a product designer. That's an extremely important step because you need to move from saying what does a product look like to say how does it fit in with all the other constraints that exist. How will this product actually perform on the market? And the best thing is if you can then pick up a product on your own or yourself. We look at what's happening in terms of not just the interface, not just the product but the constraints of the company. We look at how much engineering resources do we have today? Are they free to want to work on something? You look at what are the long-term goals of this product? And I feel like this step is extremely important to move from becoming mere visually designers to becoming product owners ourselves. It also works backwards. So for a product owner and we started, we were very skeptical about getting into the design. At the end of this whole 30-day period, or even after that as well, what we realized is there is a massive distinction between a visual designer and a product designer. As a product owner, maybe you are not great at visual designing but that doesn't really stop you. But nothing stops you from actually becoming a product designer because you actually understand the product best. You are going to assume that you are talking to customers. If you are not talking to customers, you can't be a product designer. But if you are doing the right things, you can certainly come up with a pretty good design in collaboration with people who understand duets, who have done studies around user behavior or obviously, as a visual designer or a professional designer, you have a lot of insights that you can give to me. But as a developer or as a product owner, don't shy away from designing. You can add a lot more value to the designer himself. This is something that we used to say, design is too important for a YouTube designer. The crux is for developers as well as product owners to say that I understand something about it. I can take ownership out of my opinions and obviously a lot of responsibilities come with it. So we spent a lot of time reading about case studies as well as how people approach this in the first place. You can't just go and say that as he was saying, we can't just go and say that I have an opinion about this logo. You need to justify it. This is more for developers that don't be afraid to get your time dirty either using pyrogorps or doing HTML CSS. Just get into it. It's not really that difficult to do it. Even with the first 30 days of development, one mistake that we did is we outsourced our HTML CSS. Even though the company that did it was great, thank you. Yeah. What we have started realizing now is what I was saying earlier about the iterative development, anytime you have any difference, which is not deeply coupled with the universe cycle, it's going to be a hit. So it's very, very important for people to get into this. This is a very important part. I can't say that this is going to work for every team, for every designer and every developer. Because from a developer's perspective, you really need to appreciate and respect designer's knowledge. So from a designer's perspective, you need to appreciate where the product comes from. One more thing to do now is we can actually check this interface at staging.beamong.com. We are kind of going for new features as well as designs. And more important than that, there's a side to experiencing. So now that we are doing experiments with continuous design and other things, maybe next year we'll share that experience. It would have changed, but not for the good. Sorry. The question is, if we had more than a month to develop this product, would we choose the same methodology? If we say yes, if I know how this process worked out, I will choose or rather we are doing the same thing now as well with Beamong. In that, at that time, probably we wouldn't have. That is the way to go about it for even a longer period. So the process is a slightly scary process. We are talking about essentially an agile philosophy. And this is a philosophy I have been introduced to by our passion. I don't think that it can work even for designers. We need to move away from thinking of design as a process with fixed deliverables and outcomes and move into a phase of continuous design. Not just having that continuous development, but you also iterate on your future design. You see what needs to happen to you. You're not afraid of cutting the stuff that you've done. And you can actually work it into cycles and release something. So even if it's a six month process, iterate on features, re-actuate, keep going over them, redo certain things, see how it's actually working. I think it's an extremely important thing for any product. So the question is, what is the team composition? So we started with one developer. I kind of joined into the process. So we had two developers. Around four days down the line we found Rahul as well. So these are the only three people who are involved from this company. We were working with Swabic for HTML, CSS. He was directly working on the board-based, which is one of the reasons why we could actually deliver it on time. But yeah, that's it for me. We have the quickest question of all. How much data is required for decision making? So there are certain decisions which we made based on feedbacks. Feedback from just three users. Things like the home page resigning, all that happened with more than 20,000 users. I don't have a good answer to your question. I would just say go on a good feeling where I have this data, do you feel it's enough for a given product statement? I really don't have a good answer. So at this stage, most of our data is coming from the panels or the analytics, and that's a very large thing. So we generally think nowadays when we are taking decision, we have about for any decision making, at least 10,000 users going through the board. That's what the AP testing. Yeah, so we did conduct AP testing as well. But I personally found AP testing working for a certain set of problems, not for everything. As I said, my best, my most favourite way of getting feedback is sitting next to the person. Obviously you can't do that with a person. Anyone wants to criticise the design? Yeah, so the question is what was the budget or actual cost of doing this one month of development? It's pretty tricky because being a services company, we were always looking at opportunity cost. That means if these two people are not working on the product, they are working on some background. Yeah, on some clients. And the earning is certainly a lot more than the salary that I'm actually paying for this. But I guess in this one month, we spend probably two and a half to three lakh rupees in terms of salaries, in terms of infrastructure. Because when we release this within, after three hours, we had to increase, basically we had to push our infrastructure from one server to around five servers. So considering all told, yeah, it was around three lakh rupees. So we have two questions. One is what's our view on eye tracking software? Switch, basically you can get statistics based on either cursor movement or scroll movement. You can include some JavaScript and it will tell you that these many people were focusing their attention on this part of the application. That's eye tracking software. And the second question was, if we had any visual disagreements in normal process, I'm sure we have a lot of questions. Answering the first question, we haven't talked about this before. Yeah, we didn't use eye tracking software. We didn't do very gorilla usability testing throughout the process. We did not do formal studies on what users are looking at, which parts of the pages are getting board attention, apart from the basic data that you get by our embedded analytics. So we didn't use any eye tracking software. So we defended heavily on mid-spanel to give me the funnel, that is basically the interaction studies, right? Like where exactly users are clicking. In hindsight, yeah, maybe that would have been useful, but personally I don't really trust that particular data very much. So where did we disagree? We disagreed several on various occasions, most often on the home page. More or less, at all times I said, you know, sure, I love this agile process, etc. But you know, if you give me the word, I'm going to fill your feedback. So that's a call that I made and that's a call that an enlightened product company gives a designer the freedom to actually make that call. So that's an important thing. You work with the right clients, don't work with everyone. So one of the very important part, aspects of having a collaborative design is you have stake owners, or product owners basically, right? Like from a product perspective, if there is a future discussion as to what exactly we need to put in, my call would have been the final, like, okay, this is the future we are getting in, this is the future we are not getting in. In terms of UI, we would discuss whatever till the cows come home. Like, his call would be the final. So we had given these positions or, you know, authorities and we didn't challenge them. Because otherwise it's going to get picked. So one area I remember disagreeing quite strongly was the gamification. I thought it shouldn't go in. I thought the social aspects shouldn't go in. I still designed it. And though I think it's important to also, if I look back at my sort of mental state, I don't think I did my best work on those bits. So it's extremely important. This goes back to the point about being a product owner. Once you move from just being a visual designer to a product owner, you are able then to do your best work. Because you believe in really what's going to come out of it. And it's not just, you're not just working on features for someone else. And eventually we did leave the game to you as well. That's because of the estimations.