We’re very happy to see so many young professionals joining us today. Without further ado, let’s begin with the most awaited event of the evening.
On Team Designers, we have Gyan. Gyan is a Product Designer at Microsoft and also an IDC alumnus. Gyan is particularly happy to be here because he feels we don’t invite him to IDC enough. You’re always welcome here, Gyan. At Microsoft, he’s working on Microsoft Word. In his free time, he’s a recreational coder, a typography enthusiast, and enjoys reading science fiction.
Next in the panel, we have Divya, who is also an alumnus of our department. She is currently an Associate Senior Designer at Atlassian. Divya works on the growth team for Jira Service Management. Previously, she has worked with the AI Ops Team, specializing in using AI for incident management. She has a background in fashion and interaction design. She’s passionate about women in STEM, mental health awareness, and exploring the world through books and literature.
We also have Nachiket, an alumnus of NID. Nachiket is currently working as a User Experience Designer at IBM. Previously, he has worked as a Front-End Developer at Tech Mahindra. In his free time, he’s a creative nomad who loves to wander through art, books, and nature.
Next in Team Developers, we have Ayush, an illustrious alumnus of IIT Bombay from the Computer Science Department. Ayush is an Applied Data Scientist at Microsoft, working with the Bing shopping team in India. He specializes in product ranking and relevance and has also worked at Samsung R&D, focusing on AI-driven phone heating reduction.
We also have Nikhil on Team Developers. Nikhil is currently associated with TurtleMint and has previously worked with TCS. He has a background in instrumentation engineering and a knack for programming. In his free time, he likes to travel and write poems.
Another developer on our panel is Nagaraj, who is joining online. Nagaraj is an alumnus of VIT and is currently working with HP Inc. as a Framework Technical Lead for UI. Prior to HP, he worked as a Senior Technical Manager in Samsung mobiles and printers, developing various in-house platforms. His interaction with designers are in bi-weekly about design firmware for new platform developments.
Now, let’s discuss the rules. We will give one allegation per team, and the other team has to defend that allegation. We have allocated 10 minutes for each allegation. The discussion will involve designers giving allegations on developers and vice versa, with defences from both sides.
Thank you for joining us on the panel. I’m supporting Team Developers. Who else is in for Team Developers? (Laughter) Okay, okay. So, I think AJ sir, if he’s around, was also supporting Team Developers. For those who don’t know, AJ sir has a B.Tech in Computer Science from IIT Bombay. So, when he comes here, he’ll be supporting Team Developers, not Team Designers. Let’s hand it over to Bhavna, who will also be the moderator for the event. Over to you, Bhavna, the limelight is all yours.
We’ll start with Team Designers and Team Developers. The first allegation from designers to developers is that you occasionally prioritize speed over quality, leading to rushed solutions. Designers, you’ll have the opportunity to add to this allegation before developers justify themselves. The same goes for developers; you can add to the allegations before designers defend themselves.
Sure, I can go first. There have been instances where we have an ideal scenario with everything ready on our end: all the Figma files, documentation, etc. We hand them off to developers, and the first reaction is often, “We can’t do this,” or “That’s not possible.” Sometimes, it’s not even a matter of possibility; it’s just that it will take too much time or is deemed impossible. This compromise impacts the quality and overall product experience. The end-user doesn’t care about our technical constraints; they just want to use the product. That’s how some of the projects I’ve worked on have panned out.
Let me go next. I understand the need for speed in fast-paced environment. There’s always constraints with time. Something I would like to hear from you is, about the accumulation of design debt over time when we keep prioritizing speed over quality? And do you think there are instances where it’s justified to prioritize speed over quality?
Yeah, it’s a valid point, and this is our business scenario. We need to deliver more to get more user trials. The demand has changed; people are now waiting for new features and we’re catering to different market segments. By rushing solutions and prioritizing time-to-market, we can get the feedback we need to improve. That would be one reason why we might prioritize speed over quality.
So, I’m not saying quality is not important, but quality is not the only thing, right? We need to provide solutions as well. It has to be through several iteration cycles to get to know user opinions and market trends. Only then can we develop a good solution over time.
I’d like to add to this. Perfection is rarely achieved in the first round. It takes several iterations. You need to understand user opinions in the market. Only then you can have a good solution over time.
There’s something called a POC (Proof of Concept). First, we need a POC. If you’re not launching something in the market, what’s the point? Products need to be monetized. Many products are coming into the market one by one, but those that launch first get more attention. Bard came after ChatGPT, but ChatGPT got more attention. Why? Because it was launched first. They’ll keep improving - 3.5, 4, 4.5 will come along. Launching first gives you a strong foothold in the market.
So we have developers here, right? How many of you all are supporting team developers or have worked as developers? Yeah, so you would definitely like to take this.
Everything in tech, business, product—everything is about trade-offs. What trade-offs are you ready to make? Sometimes you want to achieve quality, you want to make a product perfect, but there’s no such thing as perfect. You crave for perfection but lose your customer in the end. So sometimes, in design or some things, you have to compromise. As Nikhil said, we are actively getting feedback about how the product is doing as part of business and monetization. Then we can make incremental releases, but definitely quality is one thing you have to maintain consistently, so that’s also a considerable point.
Thanks a lot, Manish. Let’s give it to team designers now. Let’s have some claps going on!
Designers, if you have more points, you can bring them up.
I understand the point of first building a minimum viable product, getting it to market, getting feedback. Iterating—the first version doesn’t need to be perfect. Done is definitely better than perfect. Also, when you’re a team with limited resources and a limited number of engineering hours, you are going to try and optimize for time. For any given task, there’s an effort required and an impact you think it might achieve.
I feel the challenge is that anything that has low impact just gets ignored altogether. Anything that’s high impact but low effort gets done immediately. That’s what you tend to focus on. And anything that’s high effort and high impact, you put in the backlog and then never get to. So there are certain things which would make a real impact on the user experience, but because they will take effort to understand, they are difficult challenges, it feels like a lot of times we just never get to those things, and then they remain a user pain point forever. Any thoughts on that?
So, you talked about the backlog we are creating. If the feature or the experience is of that much importance, then we’ll get that feedback from the ground. If the product requires that, then it will become a P0 point, a top priority. We are constantly getting feedback, so if we have pushed some things to backlog and we are getting that priority, we will eventually develop that. We will not push all design feedbacks or all design things, experience-wise, to the backlog. We have to prioritize because there are many things that are crucial—security-related features, production situations—so we have to compromise on something.
We also have to see how many people we are actually blocking. If development teams are able to progress, then only will the next cycle or phase start. There are also other scenarios. It’s not always just about low effort and high importance. It’s also about how frequently you are about to use that feature, based on different market analyses. Even those scenarios would come into the picture.
There’s an 80-20 concept; if 80% of people are using only 20% of features, we focus more on those.
I want to add something to conclude. As designers, we can be idealistic because of the nature of our craft. We don’t build the things, the engineers do, but we envision how they could be, and sometimes that may not be feasible to code. So what’s worked for us - and this remains a debate in design - if designers understand the conceptual model of how code works, that can help bridge the gap between idealism and pragmatism. This helps in presenting more effective designs that can actually be developed.
So, are you ready for the next allegation? It’s an allegation against designers from the developers. The allegation is that designers create visually appealing designs that are difficult to implement within the given timeline. Before designers start answering, developers would you like to add anything to the allegation?
Yes, I would like to give an example: look at the advent of VFX in movies like Bahubali or Openheimer. These effects are stunning, and they make you go wow. But applying such concepts everywhere is impractical. If you were to do it in say a web application, it would involves complex layering, software, and hardware enhancements. We cannot do this all the time.
Yeah, so I understand where you’re coming from, but as designers, we’re taught and believe in thinking out of the box and creating a delightful experience for users. We aim to create competition in the market by giving that “wow” factor, which other products might not have. This is how we compete and create leverage for our designs. It’s the role of a designer to think outside the box and offer innovative solutions for the business to thrive in the market. This will have some impact on the technical side, but without such efforts, exponential growth is less likely. Take examples from specific industries like e-commerce; initially, the ideas might be rebellious, but once adapted and recognized, they represent the future. Look at AR and metaverse technologies; they were in early stages but had the potential that couldn’t initially be realized due to technical constraints. It’s our job to push these boundaries and extend the limits.
I would also like to unpack what visually good design is. Because as designers, we are taught a very old philosophy, which is ‘form follows function.’ Your functionality should be in place, and then the form sort of scaffolds over it. There are projects where you can do a minimum viable experience—do it in Comic Sans font if you want to and make the buttons clickable. But some products do need that high level of fidelity. You can’t compromise on visual design or aesthetics there because maybe competitors are doing way better, and you need to get it out there. Creating something that’s not visually appealing will not engage users, which becomes a tricky situation with the dev teams. We know that this will increase build time, but it will also increase the number of people who are using the product or engaging with the product.
User experience that increases the product usage, which comes up into the picture after a long amount of time. This means if we are scaling something or if we are improving something at that point, correct? So, in the first phase, feature-wise, there are sometimes some things that are not needed but have been placed into that particular domain. There are times when we try to convince designers that this should not be in this particular domain. Then why are we considering it? They come with the argument that they have been in the market, they have researched it, and know that it is important. It can create some kind of droppable situation for users if there is some user experience around it that we’ve created. Say we added an animation, but user is not waiting for that value. Some sort of optimization needs to be done if a search box is wasting more resources than the total amount generated on that particular platform. Then what’s the use of that?
I think what you’re saying is sometimes there’s no reason for some kinds of visual enhancements to exist. There’s no reason for something to animate in, or there’s no reason for a button to have extra ornamentation. And in those cases I’m completely aligned with you. If we’re doing something that actually degrades the user experience, then that’s just bad design. If you’re building something that actively harms the user experience, I also agree it’s a mistake. Obviously, you try your best to not end up in those scenarios. We try to do user research and make sure that what we’re building is actually required by users. Otherwise, you don’t have product-market fit, nobody will use what you built, and your product will die.
However, I think maybe the original allegation was that visually appealing designs take time to create. Something I find interesting these days is that Design tools are moving more and more towards code. For instance, if you use Figma, it has variables, and components variants that can represent different states. You can animate between a hover state and a click state. You can use variables that affect other components. Design prototypes are approaching the complexity of code. Webflow can generate responsive websites. Even with Figma, you can get designs detailed to a degree where you can maybe use a plug-in and export it as working code. So sometimes it becomes difficult for me to understand why it can’t be implemented if I can do it in the design software that maps one-to-one with how something gets implemented. The tools can export CSS values and motion curves and animations can play back in reasonable file sizes with Lottie.
You’re put across a good point, and I hear the same thing from a lot of designers. What is the configuration of the system where the Designer runs Figma tool or any other software designers use to design and play back? It’s probably a high-end processor, but that’s not the end-user environment. We are not going to give Macs and iPhones to everyone. We’re in a market where UPI Lite is also successful, right? We have to consider a range of devices from very low end segment to very high end segment. Lottie is a great example where we are bringing down the speed of execution when an animation is playing and some other process is also coming in a printer or a small embedded phone. The moment we say embedded, we need to have a definite response time - the user cannot wait two minutes, usually we’re talking in seconds. So with these consraints, we cannot deliver rich experiences on all platforms. That is our major concern whenever we say it’s difficult to implement because the visual aspect would take up almost all of the CPU, leaving less for the actual business logic.
So I guess we can conclude that designers are getting better tools for their creative expressions compared to developers.
We need to be creative; otherwise, we will continue the same experience for decades. But we also need to consider the environment or domain where it is going to be applied.
Bhavna I think I see what you’re doing there and I’m going to add something. I understand wanting everyone to have an experience that works, and if your experience doesn’t work at all on low end devices then that’s also bad. But I also don’t think you shouldn’t only design for the worst possible device and not have progressive enhancements for better devices. I don’t think we’re at the point where animating a little button will take up 100% of the CPU. We can have some nice things; I think we deserve a little treat now and then. A little explosive animation when you subscribe to a channel. I think we can have that much fun.
Phone? I don’t think so, yeah. I’m not saying in respect to phones. I’m working with printers these days. During a job, if there are heavy animations, the printer is going to hang in a medium—not in a high end. So in a high-end environment, you can do more animations, but there are different environments, exactly.
I think Manish also has something to add.
Thanks. Just to add, we are concerned about this because there’s Google page ranking. When you search something, your website should come up first. What devs want is for you to be searchable, to be number one. And that’s based on how fast your page loads. That little animation that you added increased page load by 2 seconds, and dropped our ranking to 10. So, now whenever somebody searches, they get nine other products in the market, and your system falls behind. That’s one concern that devs have.
As part of our ranking team, I can say for sure that it’s not based on animations. The top pages that load up are always about relatable and filtered content.
When we talk about ranking and speed and SEO, there’s also another side to consider. The majority of the audience we cater to and the businesses impacted need to realize that there are also products and services where people line up, waiting an entire day just to experience that. So the quality of experiences is equally important, if not less so, for bringing in more business.
At the end of the day, it really depends on the sort of project you’re working on. Not everything has to be super functional, and not everything has to be super aesthetic. It’s highly dependent on what you’re working on.
With a little trade-off here, we are moving to the next topic. The allegation to developers is that you may not fully prioritize scalability in design, which makes future changes challenging. Designers, do you want to add something before developers start defending?
Firstly, I’d like a clarification over what this is supposed to mean. Are we talking about scalability in being able to handle more users? If so, I’m not sure that’s an allegation I’ve ever had for developers.
The concern is that designers design for certain use cases, but when it gets implemented, technical feasibility takes over. Future changes and scalability are often not considered, creating technical and UX debt for both teams.
I think let’s have the audience also add to this now yeah sure because we have so many bright young designers here—anybody wants to add?
Actually, tools like Adobe XD already have scalability considerations built in. This allegation is false; the tools make it easy for development, not just for design.
So the allegation is that we, as developers, are not focusing on scalability, correct? There may be some instances where this has happened in the past, but as we grow more product understanding, this issue becomes minimal.
Most of my examples are from the printing world, and we do need to design for different sizes and functionalities. However, we strive to create a common behavior across all devices.
I’m with the engineers here. It’s hard enough to match the design specs as they are. Thinking about undefined future scalability seems a bit much.
When it comes to Legacy code, if we can’t make changes, it’s not entirely our fault. It’s a technical constraint that needs to be dealt with at a higher level.
I think the design tools have become very user-friendly, making it easier for us to provide accurate CSS code for developers. The tools also help in creating better responsive and adaptive designs. Is there a gap for a similar tool for developers to speed up their processes?
Some projects may require a minimum viable experience, but others need a high level of fidelity and visual design. Maybe it’s not the right time, or maybe competitors are faring much better. You can’t compromise on aesthetics in those cases. It becomes a tricky situation with development teams to convince them that although this may increase build time, it will also engage more users, thus benefitting the product line in the long run.
Correct, but sometimes there are features that are not needed yet are included in a particular domain. We often find ourselves trying to convince designers that a certain feature shouldn’t be included. Designers argue that they have market research backing their choices. This leads to situations where if a user experience is crafted around some sort of animation, and it doesn’t actually add value, then some sort of optimization needs to be done. If a search box is inserted into a particular panel and it consumes more resources than what it generates, then what’s the use of that?
I get what you’re saying. Sometimes there’s no reason for some visual enhancements to exist; there’s no reason for a button to animate or have extra ornamentation. And in those cases, I think I’m completely aligned with you. If we’re doing something that actually degrades the user experience, then it shouldn’t be there.
that help businesses thrive. Sometimes these designs do challenge technical feasibility, but pushing those boundaries can also result in exponential growth. Technologies like AR and VR were once considered too futuristic, but now they’re becoming a reality. Our job is to keep pushing the envelope to deliver better experiences for the user.
The following is an automatically generated transcript from a panel between developers and designers. Keep as much of the original text as possible since we don’t want to mis-quote the speakers, but clean up the text and fix possible transcription mistakes. Mark speakers with #### Speakername when possible. Do not provide follow up questions.
It’s more about trade-offs in tech, business, and product. You have to decide what trade-off you’re willing to make. Sometimes you aim for perfection but lose your customers in the end. Compromises have to be made, but as we receive feedback on how the product is doing as part of the business and monetization strategy, we can make incremental releases. However, maintaining quality consistently is also a considerable point.
Thanks, thanks a lot, Manish. Let’s give it to team designers now, let’s have some collabs going on.
I understand the point of building an MVP (Minimum Viable Product) first and getting it to market. We’re a team with limited resources, so we try to focus on tasks that are high impact but low effort, leaving things in the backlog that are high effort and high impact. Those tasks can improve the user experience but often get ignored, causing persistent pain points for users.
If a feature or experience is important, we’ll get that feedback from the ground. Those items become priority zero and need to be developed immediately to prevent product failure. We have to prioritize, especially when dealing with crucial security-related features or production situations. We also focus on unblocking development teams to keep the cycle moving forward.
We take into account not just low effort and high importance, but also feature frequency and market analysis.