Bridging the gap: Successful collaboration between engineering & design

Anusha Dayananda at UXDX Community: New York. Video: https://youtu.be/3ejBc8rPSrA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and Shutterstock's content pipeline

[00:00:04] So, bridging the gap. I want to get started by giving you a little bit of background on who I am and what I do. I'm Anusha Dayananda, though you can call me Lucia [?]. I'm the software development manager at Shutterstock for a back-end engineering team called the content pipeline. And for those of you who know or who don't know Shutterstock, I want to give you a little bit of background on who we are.

[00:00:27] Shutterstock is a content provider. You can license images, videos, photos for personal and commercial purposes through our native apps and website. We've been around for 16 years. We have about 1.7 million customers around the world. We have about 1 million contributors around the world who contribute their content, images, photos that they've taken around the world that they want to license. And we have about 330 million plus images and counting. It just grows every day. And we have about 17 million plus videos. All of that content goes through a pipeline, and that is through my team. We ingest all of this awesome content into Shutterstock.

[00:01:22] I also have a background in healthcare technology. Prior to Shutterstock, I'd been working in healthcare technology for about eight years, basically innovating and making patient data collection easy, as well as reporting easy, at the federal and government level and for hospitals across the nation. So with this combined experience, I wanted to give you an overview of what gaps I have identified when product, design and engineers collaborate, and give you some tips and tricks that you can utilize on a daily basis to make your work easier and your cooperation much better.

[00:02:06] All right, this is a brief agenda. We went over the introductions. I want to walk you through all of these topics with an example and some best practices.

The triad and how engineering is seen

[00:02:18] All right, I know this question was asked in the beginning. I was sitting right in the front, so I couldn't really get the count. How many of you are product managers, product owners here? All right, so we have a few. And design? All right. And engineers? Awesome. And how many of you, and this is a question targeted towards the product and design teams, speak to engineers every day or on a regular basis? Cool. And do you often feel that you all speak the same language? Never? Okay.

[00:03:02] So that's why I'm here. I want to show you how we can bridge this communication gap that we have, and how to make this easier for all of you, from an engineering perspective. I want to give you some background on how I see this triad. I'm gonna call this the triad. From my perspective, a product team is someone who creates an idea, who has an idea, and they figure out what to build, why we are building this, and whom we are building this for. And from our perspective, design is someone who humanizes that idea and humanizes the technology. How do we humanize this? How do we make this work better, for a better user experience?

[00:03:50] Engineering is the third aspect. What I feel most of you think is that engineers are just implementers, builders, timeline providers, effort estimation providers. Okay, so going back to the last part I was saying: what do I think most of you think of engineering? That we are just here to build, write code, implement according to specs, according to requirements, and we give you timelines and we give you effort estimation. This is what I think most of you think of us. But I want to focus on the last part: that we are more than that. And I want to give you an insight into what additional value, apart from all of these beautiful things that we do to make the product happen, we bring, and how you can leverage that additional value.

What engineers actually bring

[00:04:45] So here I'm throwing out a bunch of technical jargon, something most of you have heard. You probably understand what this is. So what does engineering think about? We consider many things. When a requirement comes, when a feature comes, and the product team or the design team comes to us, we not only think about infrastructure, we think about performance, we evaluate risks, we think about stability of the application, we think about reliability, consistency, so on and so forth, and of course security. So many things. Imagine that one request turns into so many things in our head.

[00:05:24] But what do we actually do? We are not just thinkers of the bunch of things that I put on that slide. We're more than that. We are problem solvers. Think of us as someone who has solutions. We're not just timeline providers. We don't just provide efforts and how long it will take to build this. We actually provide insights into short-term and long-term possibilities. We are technically your insurance policy, because we can think about and see the future. We know exactly how the architecture is. We can predict what can come next. So utilize this.

[00:06:08] And because we have all of these insights, we can actually provide multiple options. We are problem solvers. We can provide multiple options to solve the same problem. And what's beautiful is, because we can see the future, we can think about the future, we know exactly how this is architected, we can actually build foundations for future work, to enhance your product for the future. And apart from that, when a request comes to us, we don't only start writing code. We do research, we investigate, we figure out what's out there. We look at other technologies out there, and we expose ourselves to current market trends. So what does that actually mean? These market trends can lead to more ideas.

[00:07:02] And think of it this way. I know we write code. Visually, you just think of an engineer sitting at a computer writing code and trying to implement this. But actually we're visual thinkers. When a question comes to us, or a problem comes to us, we start drawing these flowcharts in our head. Every flowchart needs to have an arrow, and it has to have a destination. If there's no destination, it's hanging, or it's missing, that's a problem. So we can think through the scenarios, and we can actually think about all these edge cases and give you insights into all these unknowns that no one has thought of.

Tap into the goldmine early

[00:07:47] So I talked about what engineers do, and what engineers actually do, for quite some time, for two slides. Why not utilize this amazing information that we have? You already have all of this earlier on. Think of it as: we are a goldmine of information. The more you tap into this goldmine, the more it benefits the product, the features that we're developing, the future that the product is looking at. So tap into this goldmine, and come to us as soon as possible. That is the key here. Apart from this amazing information that we have, the additional value that we provide, tap into this information as early as possible. That's the key. Because the more information you are empowered with, the better the results, the faster we can think through issues, and the faster we can implement and deliver and ship a product.

[00:08:44] Because, to be honest, it's very cliché. We always say the devil's in the details. That is true, but the devil actually is in the details. Again, the more details, the more information that we provide to you, the better your product, your ideas, your designs are. You're equipped and empowered with all this information, so that you can negate or solve, or think through, all these issues and problems earlier on. That's saving time. So we want to give you all of this information, because otherwise you lose time. So more information to you and more information to us, and we can eliminate all of these problems.

An example: upload validation across web and native apps

[00:09:32] I want to give you a simple example, one of the examples that occurred to me where we had to be involved, and using this example I want to share some insights and some lessons that we learned and that we actively practice. I talked about contributors. We have about a million contributors across the world. What is a contributor? Anyone in any country can be a contributor. You can sign up on Shutterstock, upload your images, maybe someone likes it, someone wants to license it, and they can download your images and pay you. So contributors constantly upload images, videos, their hard work, through our site.

[00:10:14] This is a very common thing. A lot of applications out there, whether it's a healthcare system or a system like Shutterstock, image and stock photo applications: when an application accepts a file, any form of file, it undergoes some validations. We want to make sure that the file is in the correct format, it's not too big, it's not too small, it meets certain standards. This way we only provide quality images, quality videos to our customers. And our application validates it and displays a bunch of beautiful messages on the screen, which is user friendly. So everyone, contributors who don't understand how applications work, can understand the problems with their file and the problems with their images, so they can go back, correct it and retry. We want to make this entire experience, this lifecycle, as easy and as user-friendly as possible, for anyone in the world who speaks different languages. They can understand this in simple terms.

[00:11:26] So this is how the messages on the screen on the web look. And I said Shutterstock has an app, and this is how all these beautiful messages look there. So what was the problem? Let me take a step back, and I'm going to give you a history of how this came to be. Back in the day, the web team came up with this beautiful idea to enhance some of these validations. They wanted to add more. They wanted to make it even more robust. The web team had an idea. They had a bunch of new things that they wanted to add. They had a beautiful prototype built through the design team, and the package that had this wonderful idea came to the engineering team, to my team.

[00:12:15] Within a few minutes, we were able to identify that there were some concerns. The concerns were that, as simple as it looks, the web team was already equipped to do this. It was already available. All they wanted to do was enhance it. The immediate concern was that the app team was not really equipped. They didn't have the architecture, they didn't have the foundations to implement these validations. And this was a problem. So we immediately concluded that it was important to get all the stakeholders together as soon as possible, so we could all meet and discuss this.

[00:12:58] And we also talked about a second concern that we had: the fact that the native apps didn't have this architecture. Even if they wanted to bring themselves in on this project, they would have to modify the entire architecture so they could be consistent. So this was the second problem that we identified. The entire team, the product team, realized that this beautiful package that they had had to change, because the estimation and the timelines vary. Now we have two different platforms. We want to make sure the user experience is consistent across two different platforms, and we want to make sure that the communication between all the stakeholders happens as early as possible.

[00:13:39] So we got together, and of course we discussed this problem as a team. We decided that our team, which is the content pipeline, would develop a new helper service to help the native apps come on board as quickly as possible. The difference was, the web app wanted all the error messages from it, and I'm going to use a pull and push model: they wanted to pull the error messages to their platform, whereas the native apps team wanted a push model. So we were able to accommodate both, and have a modified service to help the native apps team come on board as quickly as possible.

[00:14:20] So this small request from a web team expanded in scope, and we were able to identify these concerns and issues earlier on. All the stakeholders were on board. They understood the caveats, they understood the issues, the concerns, and even the solutions, and they adjusted their expectations and timeline.

Lessons for bridging the gap

[00:14:47] So, based on this experience and example, what we learned was that we really want to help everyone bridge the gap that exists, the communication gap between the teams of the triad: product, design and engineers. Some of the key lessons learned that I want to share with you: the triad has to constantly meet and communicate, as early as possible and as frequently as possible. Some would say that engineers don't want to attend meetings, they just don't want to be in meetings. That's a myth. No, we do want to, because like I said, we have so much information, and it's locked up, and no one is unlocking it. So please communicate, bring us on board as soon as possible, and have an open discussion. Don't package ideas and prototypes and waste time. Just bring us in. Go to your engineers, talk about the idea, and see what solutions they have, what options they have, or even the concerns they have, and leverage that information back into your own work and tweak it.

[00:16:00] The second best practice I want to share is: ask yourself if the feature and the product requirements have taken the engineering aspect into consideration, and if not, make it a mission to get those answers. Remember the two slides, the first slide that I showed with a bunch of technical jargon. Think about whether your design, your feature, your idea, your prototype has taken some of those into consideration. The more you are tuned into the way we think, the more you can make it easier for yourself and save your own time. This way, when you come to these discussions, you're more prepared. You can think like the engineers about the issues and concerns they would already have noticed ahead of time.

[00:16:48] And at the same time, learn to think like an engineer. Like I said, we are all about flowcharts. We're visual thinkers. Try to draw a flowchart. Start with: okay, what happens if he clicks this button? What should it do? What happens if this is a native app? What happens if he jumps between the web app and the native app? These are the things that we think through constantly.

[00:17:16] And in the same way, help engineers understand your world as well. Like I said, it's a myth that we don't want to. We do want to understand you, so expose us to the front lines, the customers, as soon as possible and more often. One of the things that we do at Shutterstock: one of my colleagues on the team actually attended the Oscars, because we have an editorial section which licenses events and shows, etc. And this engineer, who was at the front line, was able to see his work in real time, and it was super exciting, because he came back with a ton of ideas on how to improve the features that he had built over time. So this exposure really helps us think through certain scenarios or issues that you are thinking about.

[00:18:13] And like any bridge in the world, it has to be a two-way bridge. There's no point having a one-way bridge. So be open to ideas and thoughts from anywhere. An idea doesn't have to come from one place, and it doesn't have to be a moment when someone's thinking about it. These ideas, like I said, can come from engineers as well, because of all those things that we are exposed to. So just help us help you.

From handoff to osmosis

[00:18:44] And from my perspective, often product goes to design, they have this beautiful package, and they come to engineering, and they wonder why it's stupid. So let's not think that way. Let's make this more like an osmosis process, a continuous process. And the benefits from this model are that we eliminate duplicate work. Product and design don't have to go back to their desk and reinvent the wheel, which saves time and effort. And there's consistency in user experience across all platforms, because we keep that in mind. And we have realistic time frames, and we give you estimations that are more realistic, and everyone is on the same page, and we ship successful products.

[00:19:32] Like I mentioned, at the end of the day we leverage every stakeholder's expertise, which results in a happy workplace. Everyone's collaborating, everyone feels that their ideas are being heard, their voices are being heard, and we finally get to speak the same language. Once we go through this osmosis process, learn from each other, expose each other to each other's work, we can truly be eternal in that methodology [?].