Ep. #5, Developers are People Too

Justin Baker: Transitioning to the developer world, you now see this emphasis on functionality. When you look at a developer tool that has to integrate into a complex stack, if you try to tailor a UI that's too functionally strict, you now limit how the developers can actually interact and use your functionality.

Steve Boak: Transparency, trust, all those things are just really important. Even how verbose an error message is can be the difference between leaving someone confused and actually helping them fix a problem.

David Dollar: Four buttons in a consumer application, none of them are probably dangerous. If you're building a developer tool, there's a very high chance that a lot of the things that a developer can do are dangerous.

Justin: You have to assume that developers are not perfect even though they think they are.

Steve: Hi, I'm Steve.

David: And I'm David, and you're listening to Don't Make Me Code, the bi-weekly series where we discuss developer experience and some of the unique challenges we face building developer-facing products.

Steve: Don't Make Me Code is brought to you by Heavybit, a nine-month program for developer-facing startups. For more information, visit heavybit.com.

David: If you're interested in being a guest on the show or if you have a specific topic you'd like us to dive into, you can reach us at dmmc at heavybit.com or on Twitter at Don't Make Me Code.

From Consumer Apps to Developer Tools

David: Thanks for joining us. We're calling this episode Developers Are People Too. And we're joined by Justin Baker from LaunchDarkly.

Justin: Happy to be here.

Steve: Justin, do you want to give us a quick bio on your background and what you do for LaunchDarkly?

Justin: I've been mostly in the consumer application space for about six years in design. And I just recently moved to LaunchDarkly last year. And it's been a wild transition from creating mobile apps for consumers that are on the go, such as a application called GoMocha, which was a geospatial coffee ordering system, so it's a different demographic, to developing a feature flag management platform geared towards developers and for continuous delivery of software.

David: Awesome. So yeah, we wanted to kind of talk about the transition from building consumer products to building developer products and some of the differences involved in design, some of the things you have to take into consideration now, and seems like you have quite a lot of experience with that.

Justin: Yeah, so one of my best experiences creating consumer products was a product called CellBreaker, which was in 500 batch 13 in 500 Startups, the accelerator in Mountain View. And for this product, we really wanted to make it as easy to use as possible. Every single functional consideration was, how do we minimize the impact on the actual consumer? How do we actually get them to want to use it on a regular basis without inundating them with functionality?

Users or consumers don't want to think too much of what they're doing with a consumer application. They want to just use it and have it give them value immediately.

Transitioning to the developer world, you now see that there's this emphasis on functionality. It's about how do I access what I need to do on a regular basis. And the actual minimalism isn't as important.

The usability is more about, how is the DX transparent? How do I actually access all this functionality on a regular basis without having to go the extra step?

Developers love shortcuts. They love being able to use their keyboard, not even have to touch a mouse. And that's part of the experience that you don't see in consumer applications.

It's this, I want to use very powerful functionality quickly, and thinking is okay, but it's not about minimalism. It's about knowing where I am, about continuously being oriented. And not ever feeling lost in what you're doing.

Steve: How do you think we balance that? So we've seen this problem too, where there's a lot of emphasis in developer tools and in professional tools on information density and power. And you want, or at least the assumption I think for a lot of companies is that you want as much power at people's fingertips as you can get.

And so things like keyboard shortcuts, maximizing information density, those tend to be priorities of professional tools companies, where in consumer products you see a lot more focus on minimalism and simplicity. But it feels like in the DevTool space we're going a little too far towards power and density, and so how do you find yourself trying to balance that?

Justin: Yeah, so when you look at developer tools, you're designing for somebody that you think will be using this every single day, multiple times per day and doing very deep, complex tasks with it. And when you design for a consumer, you're basically designing for very short interactions.

So you can think about it, your Instagram or like a little Reddit application. You kind of look at it, scroll through, look at something, you're walking somewhere. These are one to two minute interactions. You're not really doing any complex inputs, and you're not looking for any complex functionality.

It's more of how do I get some instant pleasure out of this device. Now, when you look at a developer tool, it's okay, I need to do this very complex task. Now, how do I do it simply, but how do I not get completely distracted by everything else in the application?

So developer tools I feel are being made for the habitual user, which is somebody who's going to be using this every single day, which is why onboarding or simplifying what you first land on isn't as important as a consumer application.

Because then, okay, well, the developer will take the time to orient themselves with the application because the stakes are so high. Consumer application, if I download an app and it's just hard to use right away, I'm done with it. And then for a developer tool, you expect that the developer will actually put in the effort to learn the application and even run into some hurdles, but overcome those hurdles.

Learning Curves, Pride and Personalization

Steve: That's a really good point. I think an interesting distinction too. We hear a lot about progressive disclosure and the idea that by sequencing steps you can sort of walk a user through a process. But I haven't heard this talked about as much.

But the idea of progressive degradation, and that when you count on something like a dev tool being used every day and the user gets better at it, they learn it, is that something you try to bake into the design of your products too, like that as someone gets better at this, we're gonna give them a way to streamline it and make it easier?

Justin: Yeah. So with LaunchDarkly, we actually, when the product was first launched, we didn't really have this quick start wizard. And then we added that in and we thought, oh wow, everybody's gonna want to use this right away to orient themselves with the product.

It turns out only about 70% of the users actually like doing that. And then you have this subset who just love just to start right away. And they don't want to go through a tutorial because they feel like that's hand holding and that kind of takes away from the fun and the challenge.

The challenge is figuring out, okay, how do I use this product and how do I figure it out myself? There's a pride to it, I think. I want to kind of get your thoughts on that. What do you think about the pride issue and being able to understand a complex tool and harness the power of it on your own?

David: It's almost like the complexity, yeah, you're right. Like there's a pride thing to it or something. Like developers actually do like their things just to be a little bit complicated. Just a little bit of a puzzle almost, or something that actually seems to increase just like emotional happiness when dealing with something.

Steve: There seems to be an element of personalization to it also. You see this a lot with open source tools in that, I mean one, they need to be configurable, but a byproduct of that is the personalization that comes with it.

So everyone gets to build their version of the dashboard or whatever it is and they get to feel like they own it. And that seems like asking people to do a little bit of work if the reward is more personalization and power for how they're using it, that seems like a pretty good trade-off. Right.

Justin: And the other consideration, every developer has their own style in how they like to code and how they like to architect their system. So for a product like LaunchDarkly, where there's one way to do something absolutely correctly, but there are multiple ways to do it and to still achieve that same functionality.

And if you limit a developer to this one process, this is how you implement and this is how you have to do it, it's kind of like a turn off. Whereas flexibility becomes an attractive factor, saying that, oh, we have an API, or there are multiple ways that you can be creative in how you do this, and then that can integrate much more easily into their existing style.

Steve: Yeah, and taking that idea even a step further, we're still spending a lot of time working on our UI. We're still a fairly early stage company and we're working hard to make onboarding easier.

But as we grow, I'm considering the entire UI an onboarding tool, that as people learn how to use our APIs and get comfortable integrating the product into their code, they might not use the UI at all. And I think that angle is interesting too. You need some way of introducing people to your product, but then, like you were saying, not only giving people options, but letting people choose the one that's gonna let them get their job done the fastest.

Justin: Right. And the other consideration, when you look at the complexity of an actual application and the stack itself and the infrastructure, every product is very different.

Whereas if you're a consumer, it's kind of like you have one interface and it doesn't matter, there's no complexity from the user standpoint. There's no infrastructure they need to do, there's no big adaptation, iOS, Android, done.

When you look at a developer tool that has to integrate into a complex stack with all its caveats, with all its infrastructure, if you try to tailor a UI that's too, I guess, functionally strict, you now limit how the developers can actually interact and use your functionality. So sometimes the more flexible the better, but it's about finding that balance between flexibility and adaptability.

Steve: Yeah, that might be an interesting one to unpack more too, because I know David and I have something in common where we spend a lot of time thinking about AWS, Amazon Web Services, and when we entered that space, I assumed there was going to be a lot of consistency.

And I think particularly because you deal with people deploying infrastructures in AWS, like, I honestly thought we were gonna see a lot of similarity, but I've heard you say before too that on this whole idea of customization, that something that at least we thought was going to be pretty consistent turns out to not be at all.

David: Yeah. We basically end up seeing a range of application. People are deploying everything from Meteor to PHP to whatever, the things that they need for those various, the infrastructure that they need, sort of the supporting services they need, all of that just is completely different. And they may not even think about their application the same way that I think about applications.

It's usually very enlightening to sit down with a user and just kind of like give them free rein and see basically how they diverge from what I expected them to do as they start to use it, because it tends to be quite a lot.

Steve: Yeah, and the idea of personalization, part of the exercise seems to be finding the right vectors. What are the ways that people are gonna want to customize this, so that it's not completely free form, but at the same time you're building a product that people can customize in the right ways to get the best use out of it.

Integrations and Onboarding

Justin: Yeah, and parallel to that in the consumer world, so back in around 2005-2007, you see the emergence of how do we integrate social media into sharing everything. And you see this pattern with consumer integration.

Now that you have Slack, HipChat, all these team management tools for businesses emerging, now a robust developer tool has to integrate into that cycle. You need to be able to have webhooks and connections to all these sources in order to be that powerful tool. And I think it is analogous to the rise of sharing within consumer products or within social content. And now you see that need to integrate and be part of the ecosystem.

So developer tools cannot exist as isolated packages anymore. They need to be able to integrate with your existing stack, your infrastructure.

And that goes a lot into this personalization. So you personalize the tool for how your company operates and how your application operates.

Steve: Yeah, and the integrations are a part of that. It's not even just about your tool. It's how does your tool conform when it integrates with these other tools, and how do you get the maximum benefit out of that?

And yeah, Slack integration is a good example, where if you're posting updates there, you want to make it as easy as possible for somebody to add that integration then be able to send their updates there. And yeah, that's a good point.

David: Also speaking of a Slack integration, it was kind of interesting, you see over the last couple of years if a developer product was going to have Slack integration, it would often be, okay, go over here and click these five things and go get an API key and paste it back over here. Maybe write some code and now you can have some notifications in your chat channel.

Seems like, maybe due in large part to the influence of consumer side things, that we've actually seen a lot more trend towards just click a button and it's done. I'm personally quite happy for that actually.

Justin: Yeah, yeah. Would you guys say that whereas before, if you had a developer tool that looked too nice, it was seen as, you're kind of masking this functional minimalism in a sense. And now if your product makes integrations very easy, is that now seen as more robust?

So has it kind of come full circle? If it's hard to integrate, well then you didn't really think about the functionality. Now if it's easy to integrate, well now you must have this robust product that can actually harness the power of both products.

Steve: That's definitely one area where things have come around, that like you were saying, the integrations being easier is now table stakes. So in the monitoring world, a lot of people need to integrate with a tool called PagerDuty, which is what people are using when they're on call and they want to get notified when their systems are broken.

And so just over the last few years, they moved from a pretty standard API integration to something that looks a lot like a Slack or something consumer-ish for integrations, a couple of clicks and you're there. And that's now how they're recommending doing integration.

And I think a lot of even the hardcore dev tools are making those kinds of things easier for exactly that reason. It's part of the table stakes of people getting their jobs done.

Integrations are a good segue into setup and how people configure these tools, our tools, and how people onboard into them, and we were talking before the show about how high the stakes are in the DevTools world. And we ask a lot of people when they onboard into our products, whether it's writing code to actually integrate with the product or to install software on their systems.

And when I say their systems, it's not even the system that the developer owns, it's like their company.

So there's personal risk, there's professional risk involved in that. We ask for a lot.

And so making it easier is really valuable, but making it less error prone also, getting people through it with zero chance of mistake, making those things really important to the process seems valuable.

Justin: Right. And if you look at the difference between onboarding a developer and onboarding a consumer for a consumer application. For consumer, you can download an application, you can create your account, you just use a social login, boom, you're in, and they usually make it so you can perform your first action, get the value almost immediately.

If you want to try LaunchDarkly, for instance, you can't just click a button and go, I'm trying it right now, because it requires you to actually test it within a certain code base. There's effort that you need to expend up front in order to actually use it. Opsee too. You can't just, one click and just try it in your actual application. There's a process you need to go through.

So that onboarding, there's two steps to onboarding. There's the how do you sell the concept and the knowledge to actually use the product itself. And then how do you onboard them through the actual process and the usability of it. So I think, whereas consumer applications, they try to harness that both into one.

Steve: Yeah, actually a really relevant story for us. And this is a weird paradox.

So we integrate into a customer's AWS environment, and the way that we do that is by asking them for their AWS keys, just some API keys that they enter during onboarding. And the easiest way to do that would just be to have the input boxes there and have them enter whatever creds they have currently. And those might be root creds, like something with a lot of permissions that would be dangerous for them to enter. And when we first were trying out the product, we didn't have a mechanism for people to create their own creds.

And one, we got shit for that, for not being security conscious. And two, we have seen as people onboard into the product that they're happy and willing to go and add a new user, add specific permissions for that user, go through all these extra steps to create something safe for this onboarding process. They will go through extra work. They want to go through that extra work to make sure that things are secure for them.

David: Yeah, I mean it's almost like, thinking about that, it almost can be too easy, right? Like I'm imagining Opsee, if I go into onboard and I just push one button and you're like, yeah, your AWS account is all monitored now. I'm like, hey, well, okay, what are you actually doing here?

Steve: Yeah, you're skeeving me out right now. We were talking about transparency, and it's crazy. People will go and watch in their dashboards every single thing that we change in their environment.

They're very good at their jobs, they're very technical. They want to know every single thing we're touching and how we're doing it. So transparency, trust, all those things are just really, really important.

Champions, Makers and Managers

Justin: Yeah. Have you noticed that when you're onboarding a new company, you usually have a champion at that company who will be the one who takes ownership of implementing the product or at least trying it out? And they assume a lot of risk in doing that, a lot of trust that they need to get from their peers as well.

So I don't think anybody out there has an enterprise project that they run themselves. That just doesn't happen. You have to get your team on board and your team has to trust you, and what you do is going to impact what they're going to do in the future as well.

They're going to have to use this product that you're recommending. They're going to have to use the functionality as well.

So it becomes a trade-off. If something is too easy to do, it just evokes this skepticism out of your team.

Well, there's no one-click monitoring. What did they actually do? Like you were saying. So you're right. It is that trade-off.

Steve: Yeah, you brought up an interesting point there too, the social proof thing, that grassroots adoption of new technologies and companies I think happens because of social proof. Somebody tries it out, they have to be able to demonstrate value and ease of use, and that gradually takes off. And they end up being the champion and sort of the internal salesman to the rest of their team. And that all happens after that trust and relationship is built.

Justin: Right. And if you look at how, for a larger development team, how a product maybe a lower engineer will try and want to bring up to the higher ranks to get widespread adoption, how do they actually show that product's power and functionality to the higher-ups, how do they actually get that buy-in?

And if you have a product that has that perfect balance between a functional aesthetic and has that level of negratability and is intuitive for people to look at and understand the core functionality of it, the power of it, without you having to go in and write a bunch of code and show a bunch of things in the back end, it looks like it's a polished tool.

Whereas something that's completely, almost backend dependent now, that doesn't have that polished interface, even if the interface is just surfacing some sort of analytical tools, it's seen maybe now as kind of an incomplete product, that it's not mature enough to be an enterprise tool, to be a developer tool.

Steve: Yeah, I thought the story you were telling before the show too was really interesting, that part of selling a new tool within the organization is not just selling it to your peers, but potentially selling it to your managers and convincing them. And that might be an entirely different part of the product that needs to be shown to them. And so why don't you talk about at LaunchDarkly what you've got for managers versus makers and how you're balancing that?

Justin: Sure. So we actually take two levels of approach, and we've noticed that we have two sorts of audiences that we're trying to target. So you have the engineers who love to get their hands dirty. They love to actually try out the product, play with some feature flags, turn them on and off, test out rollouts, test some different languages and kind of just have fun with the power of the system.

Then we have the managers who are looking at it from a higher level perspective. Okay, how can this help me help our team deliver software faster? How will this actually work in our development team? Will it just cause a lot of friction now because they have to adopt a new product? Will this actually fit into our process?

And how can we harness this for long-term feature management, for long-term control? So you have the let's play with it and this is fun and it functionally works, versus the bigger picture.

And for the bigger picture, you need to show how is this going to be, let's say three months from now and you have a hundred feature flags. All right, how can I know what flag is on, what flag is off? How it's rolled out, the analytics, how flags are performing. And if that's not intuitive, then is that really an enterprise product that you want to have on your team?

So that's kind of the selling that we need to do. It's the functionality, does it actually work? Great. Now, is it gonna be an enterprise product that you can use on your team in the long run?

Steve: Yeah, that's an interesting thing that I've seen at every software company I've worked at actually, is the common traits that manager versus maker views have, that as you scale up you focus more on the roll-ups and trending, that you want to paint a picture of how things are changing over time, and you do that with graphs and groupings and clustering of information, where the person who's in the product every day wants to know about every significant event.

It's part of their daily workflow. And so whether that's a flag being activated or used by a user, whether it's an error in the system, you're gonna design for different levels of resolution on Lost Design. And I feel like that's been a common trait for the different audiences that I've seen, like managers versus makers.

Justin: Right. And then there's also this dichotomy between actually harnessing and implementing a product versus managing it. And typically for developer tools, no matter what the usability, they're great at implementational. You can just kind of get into the code and implement it.

Now for long-term management, that's a whole different story. When now you have to deal with, okay, I just want to get information very quickly. I want to get an overview.

And overview requires clustering, requires surfacing meaningful data. And not having things buried. Things need to be compared. You need to have these dashboard views. So it brings this whole new element to DX.

Errors and Content as Design

Steve: Yeah, and following on that topic more, we've already started talking about the different categories and the ways that we think about design depending on who the audience is, but we also were talking about things that we might not even think of as design being a part of what we have to do as designers of developer-facing products. And whether that's documentation or throwing errors properly. Like you were talking about status codes at LaunchDarkly and how you have to use those in a certain way and use them consistently.

Justin: Right. So just highlight a status. So for those not familiar with feature flags, they can take various forms. They can be on or off, or they haven't received an event. So there's various statuses that a flag can stay on, various states that it can take.

And if you just use, let's say, simple color hues to differentiate between a flag that's off or something that has an error, well, if I don't notice that something is not working, that's a big issue. And that can be addressed pretty simply by the design and by making it so, okay, well, critical errors are transparent. They're upfront. You can see them. You're not going to gloss over them.

And if you just take a function-first perspective, well, yeah, our product can tell you anything you want to know about a flag, but if you don't know about it, that's an issue between the design communicating effectively to you.

Steve: Yeah, and really error reporting is obviously a big one in monitoring, and things like HTTP status codes, and in our world, color has very codified meaning. Red, yellow, orange, green, these things have actual codes in the developer and operations community. So using them without a lot of careful thought can lead in a lot of bad directions.

Even how verbose an error message is can be the difference between leaving someone confused and actually helping them fix a problem.

David: Oh, definitely. And not even just how verbose, but if there are a hundred errors going on right now, are you gonna display all of them? Are you gonna roll it up as some kind of summary?

What if Amazon is down, like your monitoring product's gonna go crazy? What information are you displaying in that context? And yeah, is it still useful when everything is broken?

Justin: Design for developers is more than just layouts, more than just colors. It's more than just clicking and usability in that sense. It's also about the content.

And creating this unified content where if you actually surface an error and you explain what it is, that you're not going to leave the user confused. You're not going to muddy the waters of communication, for instance.

And just having that common unifying lexicon, it's critical for developer tools, more so than these icon-oriented consumer applications, where all right, well, if I click the wrong button, okay, well, no big deal. I'll just scroll over and I'll kind of learn that over time because I only have four buttons to choose from.

Now when I have a hundred things that I can do, it's much more important to actually surface what those things are in a much more transparent way, and also make those descriptions much more meaningful. And we have to be very careful with how we document and how clear our actual content is.

And a good example would be if you have a very ambiguous error and you have it just written very poorly, and it doesn't come across as something critical, well, it could be ignored and then suddenly things just cascade from there and it's a mess.

Steve: Yeah, or it could lead you down the wrong path. A red herring that costs you a couple hours of troubleshooting time or something, or that creates extra work.

We actually had somebody, in the Amazon world there's stop and terminate when you're talking about an instance and a running instance and what you want to do with it. And that's a really important distinction, it turns out. And so somebody clicked terminate instead of stop the other day, and that cost them a couple hours of work.

Right. And it's that kind of thing where, because people are using these things every day, how we save them time is really important. And so that's something we measure in every message we send to them and every tool that we use for communication.

Designing for Dangerous Actions

David: Yeah, that's interesting because you mentioned, yeah, the four buttons in a consumer application, none of them are probably dangerous. If you're building a developer tool, there's a very high chance that a lot of the things that a developer can do are dangerous. Right. And you want them to be able to learn how to use it and experiment and play and be able to kind of intuitively figure these things out. But you can't really just experiment with the delete all my code button and be confident in what it's gonna do.

Justin: Right. Yeah. And if you look at a consumer app, if you look at how onboarding has evolved, it's okay, well let's just use this one-click onboarding, get you on board and you can post something in one click as well. And if you post something you don't want, you can just get rid of it pretty quickly. With a developer tool, you have to build in these redundancies into the design that aren't quote unquote user-friendly, but since the stakes are so high, they are user-friendly.

Because you have to assume that developers are not perfect, even though they think they are, most of the time. Yet you have to assume that we're not gonna always make the correct action. And we have to always have these checks in place if the stakes are that high.

If you're going to press delete accidentally, and if one mistake can lead to a critical failure of your application through one click, that is a failure in DX design.

And you want to be able to say, okay, if you're really going to delete a feature flag, for instance, are you sure you want to do that? Okay, are you really sure? Okay, type in the name of it and then press delete so we know that you're definitely sure.

David: Yeah, I mean, you're basically getting in the way at that point, right? In any other situation that would be horrible. You're like, you've just added extra clicks and made me type and think and, but no. I mean yeah, you absolutely have to do that because the stakes are so high.

Steve: Yeah, imposing barriers for safety. Whether it's deleting something accidentally or, yeah, in our case we encountered this with just giving people access that was too simple to do things like stopping an instance or restarting an instance. So now there's an extra set of protection on that where they've got to hold the button down for three seconds before they restart the machine.

Justin: So for consumer applications, it's typically simple. Simpler is better is typically the key to a success. Okay, well, if I can post something simply, if I can do something with as few actions as possible, it's a good application. It's user-friendly. Now for developer tools, if it's too easy to use, does that mean it's actually usable?

If we're trying to make something easy, should that be the goal of a developer tool, is make something really easy, or should it make functionality as transparent as possible, or should it be as safe as possible? What should we err on the side of?

Steve: Yeah, we definitely use a different timescale. If I can't onboard into a consumer product in thirty seconds, I consider it a failure. And I don't know of any DevTools product I can onboard into in thirty seconds.

And so whether it's writing code or installing software on machines, you expect it to take some time. And so you might be measuring that timescale in minutes, but the same feeling of accomplishment I think applies. That at the end of the day your goal is to have this back and forth, where they give you a little something and then you give them something in return, and you have to give the reward.

Thanks to our guest, Justin Baker of LaunchDarkly, and thank you for listening. Remember, developers are people too, and we'll see you next time on Don't Make Me Code.

That's about all we have time for today. If you're interested in being a guest on the show, or if you have a DX topic you'd like us to dive into, you can reach us at dmmc at heavybit.com or on Twitter at Don't Make Me Code.

David: To learn more about Heavybit, visit heavybit.com. And while you're there, check out the library. It's packed with amazing talks from founders of developer tools companies and other industry leaders.