How to Be a Designer in a Developer's Tools Company

Tan Hsiao, YuChien Kao at UXDX Community: AI Research and Designing for Developers. Video: https://youtu.be/0giJVRWJ9Hk

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.

Introductions and what a designer does at MongoDB

[00:00:08] YuChien: Hello everyone, welcome to the session. Today we are going to share our own experiences about how to be a designer in a developer tools company. I am YuChien, and I'm a staff product designer. About my professional experience: I have about ten years of enterprise design experience. I previously worked with [pedc][?], Morgan Stanley, Compass, and now MongoDB. My mission is turning complex challenges into seamless, user-centric solutions. In my personal life, I'm a minimalist, I love to be simple, and I love traveling around the world.

[00:00:54] Tan: Hi guys, I'm Tan Hsiao. I am the product design lead, and my hashtag is I love challenges. I was an engineer and transitioned to design. Right now I'm leading a team at MongoDB. I was fortunate enough to grow with the company, with 57% of revenue coming from the product I work on. I've worked with different industries and all kinds of different sizes of company. I immigrated from Taiwan to the United States. Last year I lost 45 pounds, and I also ran the New York Marathon, and my next goal is to join the [highx][?] in New York. Back to YuChien.

[00:01:35] YuChien: Oftentimes when you think of product design or UX design, you might think of consumer-facing products like Spotify, Notion or Robinhood, as we use them daily. At least this is how I tell my mom and dad what I'm doing as a product designer; it's easy for them to understand. So you may ask, what do you do as a product designer at MongoDB? Do you need to know coding as a designer here? What do you need to design for a database?

[00:02:13] MongoDB is a leading NoSQL database company. Although developers can create the database through code, some users still need visual references. So as product designers at the company, we simplify the database creation process through the UI. Compared to traditional database creation, we help our users manage databases easily with just a few clicks.

[00:02:45] Today we will break down our talk into three parts. As a database company, we have a huge amount of data processing every single day, so first we will talk about big data. Then we will talk about how we transitioned from serving IC developers to serving more enterprise customers, with our platform design driven. Finally, we will cover how we provide AI tools to our developers in this modern AI world, and then we will end with the key takeaways.

Simplifying big data for developers

[00:03:17] Now I'm going to share how we simplify big data for developers. Compared to end consumers like you and me, our target audience is slightly different: it's developers. [So L my love Celsius student.com][?], Game of Thrones, [borain][?], science fiction, and more and more. But if you dive deeply into developers, they are the people who graduated with a computer science degree. They will be happy if they can make things work more quickly, and they also love solving big problems. However, bugs or breaking code could actually keep them up at night.

[00:04:07] What we want them to think when they use our product is, wow, I can just create a database in just a few seconds. Or, I could take a coffee break, because MongoDB will just notify me if anything goes wrong, or will actually prevent all the errors for me. So now I'm going to share the details about how we design for developers.

[00:04:32] Not all the MongoDB designers have an engineering degree. However, we do the same work as other product designers: researching our target audience and understanding their jobs to be done in their day-to-day work. At MongoDB we are fortunate to have thousands of engineers to interview, who also help us to understand developers' pain points. In addition, we work with cross-functional teams internally, including PMs, engineers, marketing and customer support, to deep dive into the developers' end-to-end life cycle, and also understand how our services impact multiple areas.

[00:05:17] Our database processes millions of files and data every day. This UI displays the clusters' health and performance. We have continually [iterated][?] on this view, and also leveraged the customer data to identify the high-priority metrics. The layout shows the hierarchy: the critical information appears at the top, with less important metadata below.

[00:05:45] We also have many services across the platform, but users don't necessarily know how they can best leverage these services. With use-case-driven design, we help developers effectively complete their tasks. Moreover, users can actually discover features that they weren't aware of before. Once the user gets into this use-case-driven flow, they will be guided step by step. We have seen tremendous success with this design, which has increased feature adoption a lot.

[00:06:22] This is also another example of how we prioritize the primary versus the secondary data to have the developer track the task. Developers glance through the high-level data at the top, and then see if they need to take any action on the detailed data below. When we design an experience, it's important to measure the success with data. These are the two projects we successfully launched and also leveraged with A/B testing. Both of them had a really great impact on our customers.

[00:07:01] A quick recap about simplifying big data for developers. We designed a way to simplify database management and effectively visualize big data, to simplify the decision making for developers. Analyze, prioritize and personalize the tasks by understanding the developers' ecosystem. Provide the flexibility and bridge the coding with UI, so developers can have visual references. And lastly, we bridge the services together to make it simple, and eventually drive feature adoption.

[00:07:39] MongoDB started as an open-source project and evolved into a company. As the company focused on developers' needs, and after these design transitions, we are now loved by millions of developers. With millions of developers and increasing enterprise adoption, we have expanded our services to support more workloads, and transitioned into a platform that better meets enterprise needs. This shift became essential as macroeconomic challenges impacted startups, highlighting the need for a strong focus on serving enterprise customers, who continue to invest at scale.

Designing for the enterprise

[00:08:24] Tan: Now let's talk about the design use cases for enterprise platform design. Today we are discussing the significant shift in our focus, from being focused on IC developers to catering to enterprise needs. You might wonder what's the difference between these two approaches. Developers focus on getting the job done, as YuChien mentioned. Their goal is to build effective tools to streamline their work and boost productivity.

[00:08:56] Initially we created a single product tailored to a specific use case. Over time, with more products, we realized we could save enterprises significant time and money, reducing data migration and onboarding costs, while they are still delivering results. As we expanded to serve more enterprises, we saw that large enterprises have thousands of developers across different departments, each building unique tools and systems, and they all love our product. So our focus shifted from just meeting the IC needs to enabling collaboration across teams. Now I'm going to show you more use cases, to give you a taste of how we solve this challenge.

[00:09:39] Before we jump into that, there's a crucial business decision that influences the rest of the decision making here. I think that is the difference I want to call out beforehand: the trade-off between quality versus quantity. In the enterprise, [strologas][?] millions of users, but not all of them contribute the same value to the company. As a result, we constantly balance our decision making. Sometimes a small group of key customers using a feature can generate multi-billions of dollars in revenue.

[00:10:16] Use case one: take the example of a car manufacturer company. How can they handle an application with different workloads globally? One database needs to support different end consumer markets. Maybe one market, Japan, has a much smaller database workload, versus the United States, which is the biggest market, so they have a much larger workload and have to maximize the database performance. So how does one database scale horizontally for specific needs but optimize the cost?

[00:10:56] For this large-scale enterprise workload, we focus on making database management more flexible. Our goal is to ensure our database configuration works well for both the individual contributor and the large enterprise, with intuitive, easy-to-use design. At MongoDB we make the configuration process seamless. Instead of forcing the developer to read long documentation before using the [CI][?], we built in-UI guidance and education in the product. This helps them easily scale up and scale out without reading a lot of documentation, making the experience smooth and also efficient.

[00:11:41] Use case two: how do we solve the design challenge of designing a centralized management system that empowers the org to scale over time while enhancing engineer productivity? Enterprise engineers often face the challenge of managing repetitive data migrations, and they frequently have to navigate between different projects to track the progress at different times. Some migrations could take days or weeks, and even larger migrations could take months.

[00:12:16] So we designed a dashboard to clearly visualize the process across multiple projects and database migrations, consolidating it all in one place at the org level, to reduce context switching, and to streamline the workflow by creating a standardized workflow, offering templates that can be applied across different projects.

[00:12:41] Database access is also another critical requirement for enterprises. To enhance security and control, we designed various roles and authentication methods for centralized control, to allow the enterprise to protect their sensitive data at scale and manage their assets through a centralized view.

[00:13:03] This is a [sepal][?] framework for integrating the various enterprise components. Our north star, our guiding principle, is always to create intuitive, developer-centric interfaces. We apply this to modular design focused on scalability; a centralized management system for streamlined control; integration flexibility with APIs for streamlined connectivity; and, as I mentioned before, security and compliance to protect sensitive data and meet the industry standards for the company.

[00:13:40] Again, enterprise is focused on reducing cost and on business scale. A well-designed enterprise system is essential for enhancing operational efficiency, improving collaboration and supporting enterprise growth. In the next part, we would like to talk more about how AI shapes the future of design.

Will AI take over our jobs?

[00:14:03] As we enter the gen AI age, we have seen the recent news, like Meta just laying off 5% of its employees to focus on AI. And you might be shocked if you have seen this news from the Microsoft leadership: the era of SaaS as we know it is coming to an end. I guess the real question for all of us as designers is, will AI take over our jobs?

[00:14:32] Throughout history, from the Industrial Revolution, the dot-com, and now AI, technology and the new things that come up have made people uncomfortable. However, when it happens, this new technology helps humans focus on improving processes and finding better solutions. This pushes us to concentrate on what matters the most.

[00:14:58] We currently don't have a comprehensive answer for you, because we are not experts in AI. However, we have some examples of what we provide our customers to build AI tools, which might give you some idea of what's going to happen, and maybe help you to think about what your role could be in the future.

[00:15:23] We provide our customers with a search tool for modern AI search, to provide a more powerful way to handle complex data types and perform similarity search efficiently. By leveraging this, our customers can enhance their applications with advanced search capability. We also provide our customers with AI-powered predictive analytics features to reduce manual configuration and enhance database performance and scalability. We also help our developers more easily automate the process of migrating from traditional SQL data to the document database, which, we believe, is more flexible and easier to work with for AI applications.

[00:16:11] If you look at the tools, the services we have, here are some tool examples where we use AI to help our developers at MongoDB nowadays: code generation, data migration, developer tools powered by AI. As designers, we are surrounded by AI tools. Those are AI design tools, like Figma design file generation, design asset transition, design tools powered by AI. I don't know whether you notice there's a similarity between these two sets of tools, even though they serve different target audiences. So I hope this can give you some idea of how you could bring AI to your product, to better serve your customers.

What humans do that AI doesn't

[00:17:02] While we push those AI products and services in the design, we constantly have these questions in mind. Where or when should AI help, versus human judgment? How do we design AI to [come to place][?] but not add process complexity? How can AI be accurate, giving consistent responses from the library or from limited resources? And how do we have a positive ROI with AI? Constantly reading and writing into a database, or training the model, could be pricey. How can we have a more expected ROI for the business?

[00:17:46] In the end, we found out what we do well. We continue to focus on the customer pain points and the core problem, and then streamline the workflow, and then deliver more tangible business impact. If you don't know everything, just focus on three principles: improving efficiency, generating user value or business value, and increasing user satisfaction.

[00:18:16] Through the design challenges we have been through so far, we also noticed there are key differences between AI and human designers. AI won't really give you a prompt or a starting idea, or help the user to solve the problem the way humans do. We have to be intuitive to identify the customer pain points and the problem to solve. AI lacks the ability to set the overarching goal. It relies on humans to provide a direction, versus human designers, who can set specific goals to align with business priorities and value.

[00:18:58] While AI can analyze the data and suggest solutions, it lacks true empathy and understanding of the customer experience, especially the user journey. Human designers can bring more empathy to the design process, connect with the customer on a deeper level, and create solutions that truly resonate with them. Lastly, AI is great at providing insight on how to implement the solution, but it does not set the vision or direction for the design. We are responsible for setting the goal and setting a vision, which guides the design process, ensuring it aligns with broader company objectives.

[00:19:43] Last but not least, as product designers we tend to always plan for use cases and user stories, and we just have to admit that sometimes we cannot predict everything. We cannot plan for everything, even when we are well prepared and have all the skill sets, because we are not fortune tellers, or not great fortune tellers. We won't be right every single time, even when we have all the skill sets to predict future use cases.

[00:20:19] Therefore, here are some small tips that helped us in the past couple of quarters, couple of months, and I hope they could be helpful to you guys. Continuously focus on AI and service design, to learn how to bring new technology to the product to help your customers. You can also check out some books, like [guiding to make the making St wor smacking][?] and Product-Led Growth, and explore business, to make sure that what you build has product impact and business value in return. And last, apply the 80/20 rule to diversify your skill set in product design: balance product knowledge, technical understanding and strategy in your time investment, to maximize your impact.

Key takeaways

[00:21:09] YuChien: I'm going to share our key takeaways from this talk. For simplifying big data for developers: we empower the users by anticipating their next steps, even beyond the product, and also enable flexibility and streamline their workflows. For enterprise-driven design: enterprises love all-in-one solutions that centralize resources and also minimize data transition time and cost. And lastly, AI is not our enemy, but a tool to help us focus on the most important tasks. We can set a clear path for the solution and leverage AI to achieve it. And lastly, we cannot predict everything, so we should be as flexible as we can. Thank you for joining the talk with us today, and please feel free to let us know if you have any questions.

Q&A

[00:22:14] Rory: Excellent, thank you very much, YuChien and Tan. I really enjoyed that talk, and it's interesting to think about, because people forget that developers have to use those products as well, and they need a nice and friendly user experience too. I just have one question to get started, but if anybody has other questions out there, please do post them on whichever platform you're watching this on, and I'll put your questions through to our speakers.

[00:22:42] Rory: I'll start at the start. When you were talking about streamlining the presentation, you used the example of use case development. In your example, I think you had three or four different use cases. How do you map that to your UI? Each use case might want a different structure, or, as you said, there's prioritized data and there's lower data, but depending on your use case there's probably different data that's prioritized versus lower. So how do you, with a single UI, accommodate those different use cases?

[00:23:19] YuChien: Good question. Before we decide what use case we want to design for the user, we work with a data analyst to understand the percentages: what is the highest-percentage task that the user needs to use in this feature. And we also realized that there are actually a lot of features around the platform to complete this task. That's why we decided to work on this use-case-driven design. We also designed a high-level structure that can ensure consistency. Even though users are working on different tasks, they can still feel the consistency when they are working on the task. And then we also have guidance that walks the user through the different steps. So no matter which task or which use case users are in, they can always similarly complete the task in just a few minutes or a few seconds.

[00:24:25] Rory: Sorry, just to summarize: you were saying that you design for the primary use case?

[00:24:36] YuChien: No. For example, there could be five or six use cases, but we try to identify what's the most important use case for the user by how much they are using it right now. For example, we work with the data analyst to understand how many users in this product need this task or this use case. We also deep dive to understand the user story, and then talk to the developers directly to understand what are the most important jobs to be done they need to complete.

[00:25:17] Tan: If I could add on: we not only focus on the user requirements, analyzing from the data and tracking all the numbers for all the user tasks, but we also work with the product manager to focus on which features have the biggest business [modu][?]. That's making sure we not only focus on what customers really need, but also discover the business opportunities on the table.

[00:25:54] Rory: Brilliant. That actually ties in with my next question, about what's most important from a user perspective. Because you moved on to enterprise, and a big challenge that a lot of designers face, and a lot of product people and developers, is the sales "tick the box" of, we need a certain amount of features because we're comparing against some competitors in the market, versus what's actually important. Because when you're talking to people, maybe that's not actually that important to them. So how do you balance that as a team, those sales-driven features versus customer-driven features?

[00:26:30] Tan: I will try to take the question, but feel free, YuChien, to jump in. I think this is a very interesting question, a very good question, Rory. Yes, when we transitioned to enterprise, that's why I talked about quality versus quantity. It's a very different game. As we move into enterprise, yes, a lot of requirements [bit asset from ourself][?], because this feature, this project depends on the contract. There are contracts and deadlines we have to hit. So oftentimes in the quarter, we make sure we prioritize the most important things from those big customer asks. I think that will help with the business.

[00:27:17] But at the same time, as designers and researchers, we also really go out and interview customers: what really bothers you, what puts you on hold on this one, what makes you drop? I think that is the bigger question we want to ask. So while we focus on enterprise, we also don't want to lose the end developer who is working on this. Every company might deal with a different thing, but when I say we transitioned to enterprise, enterprises have different roles in the company. They have a CTO, they have solution architects, they have developers, they also have back-end developers. So they have different roles, and they focus on different things. We make sure we can help sales to close the deal, but at the same time, we don't want to lose the developer, because they love our company and we want that to continue.

[00:28:14] Rory: So you're marrying the two levels as best you can.

[00:28:20] Tan: Yes.

[00:28:22] Rory: Brilliant. Well, that actually brings us to time. I just want to thank you, YuChien and Tan, for sharing that case, and I hope everybody out there enjoyed it as much as I did.