How To Empower Developers To Build A Greater User Experience

Marie-Laure Thuret at UXDX Europe. Video: https://youtu.be/UOHZ1b0DFtw

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.

Developer experience at Algolia, and why it matters

[00:00:00] My name is Marie and I'm a product manager working at Algolia. For those that don't know Algolia, we are a search as a service company, meaning that we want our customers to have the best search and discovery experience. To give you an example, if you are an e-commerce company and you want your users to search and browse your products, you can use us. I'm here to talk to you about how investing in developer experience can actually help you empower developers to build a great user experience.

[00:00:36] Developer experience at Algolia has always been something we were really into, even before I joined the company more than three years ago now. But today it's reached a stage where not only do we care about the developer experience we provide with our REST API, for instance, we also have four different teams working on all the tooling on top of it, meaning the backend SDKs that help you push the data to us, or the front-end libraries so that you can build the search experiences themselves, and the technical documentation. Algolia has a search engine that is closed source, but all the libraries are open sourced, and you will see later why this is actually a great idea, to open source.

[00:01:28] So what is developer experience and why does it matter? Well, developers are users like any other kind, and they are experiencing some kind of journey along with their implementation time. It all starts with a problem they are trying to solve. At that stage, what matters for them is to know if they want, or if they could, use a tool or a project that will solve the problem, or if they have to build something themselves.

[00:01:55] Let's say that they discover you. They arrive on your website, and what matters at that stage is that they can sign up quickly, get access to some API keys, so they can start. When they start, what they want to evaluate is that your tools or your projects will actually answer their needs. If they confirm that it is, then they're going to end up in this loop where they will have questions such as, how can I achieve this, or that, or this and that, and so on.

[00:02:26] Now hopefully, if all that journey was successful and was pleasant for them, maybe they can become an advocate of your project toward the developer community, and in our case, because the tools are open source, they can become a contributor.

[00:02:45] If we take a bit of a step back and we look at two different personas on the project: on one side you have the business. Usually what business people want is to delight their users, providing them the best user experience, and if they can have this in the fastest possible way, it's even better. On the developer side, the people that are actually going to implement those features, what matters for them is that the tool they are using makes them efficient and integrates nicely in their own ecosystem. If you look at the crossroads between those two personas, in between, that's where developer experience comes into place.

Pillar one: key enablers

[00:03:31] So I wanted to share what I think are the four great pillars of building a very good developer experience. It all starts with key enablers. The specifics of those enablers will probably depend on your project, but there are some key themes within them. If you want the developers to focus on what matters, meaning the user experience they are going to provide, the very first thing you might want to do is to provide out-of-the-box performance. We all have experienced interfaces that are long to load, and the infinite spinner, and so on, is not very pleasant. So you want to make sure that the performance of what you are providing is great.

[00:04:26] You also want to provide a service that is reliable. If you build the best experience ever but one of the services you are using is not working, it's pointless. Reliability is not just a matter of providing the best infrastructure, it's also stuff like thinking about what is a good retry strategy[?], things like that, and this can be hard to do, can be hard to think about, so that's a territory where you want to help developers.

[00:05:03] Last but not least, you want to make sure that developers understand your domain specifics. If I take our example, search: traditionally search is a back-end engineering domain, meaning it's back-end engineers that are traditionally working on those kinds of things, and it can be very hard to understand what makes a good search experience. At Algolia, from the very beginning, we were like, okay, we want customers to have the best search and discovery experience, which means that we want to empower our front-end developers to build such interfaces, and therefore they need to understand what makes a great search experience. You want to give them quickly the knowledge of knowing how they can achieve great relevance of the search results, or some tips about the display of the search results, and so on.

Pillar two: tooling and UI libraries

[00:05:53] That actually leads me to my second pillar, tooling, because tooling is the way you can actually provide that very easily for developers. So yes, we offer a REST API, but what we say to all our developers is that you should use the SDKs. You have SDKs for every backend, for stuff like pushing the data, and you have SDKs that we call UI libraries to actually build your front end. They have different purposes. There's one need, one tool.

[00:06:32] If I deep dive into the UI libraries, because I'm going to talk about UX, we decided to provide a set of open source libraries. The goals behind those libraries were to hide the search complexity and to provide best practices and good design out of the box. By that I mean we provide widgets. Widgets are great, but most likely developers would want to go beyond, they would want to customize the colors, or they would even want to change completely the UI, so we wanted to make them highly customizable.

[00:07:11] Also, because we know developers, some of them want to go further, maybe they want to do something that we didn't think about. So we wanted to make sure that those widgets were all relying on lower abstractions that we gave access to, so that developers that want to go further can use those abstractions and maybe build stuff we never thought about.

[00:07:35] Finally, we decided to match the various front-end ecosystems that exist out there, not all but some of them. For the ones that are familiar with front-end development, it's a wild stage, there are many, many different frameworks that exist, and today if you are a developer that works with vanilla JavaScript you're most likely going to expect very different APIs, very different patterns, than the ones that are using React, for instance. For us it was a very important thing that the different types of developers would find the tools that help them achieve what they want in the best way.

[00:08:15] To give you a more concrete example of what those UI libraries bring to developers: let's say you want to implement search on your website, and at some point you will think of something like, I want to add a brand menu on my website because I want my users to be able to filter by brand. Without our UI libraries, our answer would have been something like, sure, just use the client, then use the helper, and then add the different interfaces. Now with the UI libraries, what we can answer to this developer is, sure, just use the menu widget. And most likely we will not answer anything, because there will not be any question before, because it's kind of obvious.

Pillar three: documentation

[00:09:04] My next pillar is documentation, because you can provide the best tool ever, you can have, I don't know, inside your code the best comments, if you don't have proper technical documentation to guide developers toward implementation, you're missing something. So documentation is a big topic, there are conferences dedicated to how you should write technical documentation, but here I wanted to share some tips on what we discovered building our own.

[00:09:44] The first thing that works pretty well is to provide concrete examples. There's the obvious one, like code samples, things where a developer arriving on a guide or on an API reference can quickly paste some code and it works. I would say if you do that, you should always think of providing code that works out of the box, meaning they copy paste it and they don't have to modify anything.

[00:10:11] But there are other types of example that exist as well. For instance we decided not so long ago to create that page called the widget showcase, and today it's one of the most popular pages[?] of our technical documentation. The goal was to display all the widgets we offer in the different kinds of search patterns that exist, and we did it in an interactive way, meaning if you go on that page you can actually play with the widget and you can see the code of the widgets, and if you want to use them you can go to the API reference afterwards.

[00:10:50] Also, you should make sure that you provide a logical path so that developers can progress from beginner to advanced user. When someone starts with your project, they don't know anything about it. What matters at that moment is that there's a getting started page explaining to them how they can quickly get started, and if with that page they can have a very good overview of what you provide, it's good, because it makes them understand the value proposition behind your product.

[00:11:19] Once they reach the moment when they say, okay, I'm going to use your product, what you want is to guide them through all the different features you give access to, in a logical way, in a way that makes sense for them to get everything. It sounds easy, but actually it does take a bit of thought behind the different order of the pages, et cetera.

[00:11:49] Finally, you should make sure that you provide various types of content. We all learn in very different ways. Some people prefer to read text, others prefer to watch videos, and others to get their hands dirty and play with some code straight away. We didn't want to match only one type of person here, we wanted to address them all, so we decided to basically match all those kinds of learning ways.

Pillar four: communication

[00:12:15] The last pillar I have for you is communication, and it's basically the glue behind all of the previous ones. Because developers are users like any other kind of users, and the very first thing you want to do about them is to learn who they are, how they think, what they need, and the best way for that is to put your own developers in front of their users. So at Algolia everybody, every engineer on every team, does support. It's even true today, when actually we do have a dedicated support team, but everybody keeps doing support. For the teams that are in charge of all the toolings, because they are open source, everybody can actually write an issue, open feature requests on GitHub, and they're always in contact with all those developers, so they get a chance to really know what works and what does not.

[00:13:12] Another thing you want to build is a knowledge base, meaning if someone at some point has a question because they don't know how to do something, you would probably answer them. If that knowledge, you put it online, either, for instance for us, on the community forum, or also through Stack Overflow, no matter the place, if someone that has the same question googles it and finds that place where it's already answered, then it's a win, because they will probably not go to your support and it will save us a bit of time.

[00:13:46] Finally, you want to make sure you nurture a relationship with the developers, and in a sense you want to make sure you communicate to them often the changes you are doing to your project, to your libraries, et cetera. So for instance providing a clear changelog with everything that is new, and so on.

What to watch out for: there is no single type of developer

[00:14:07] So investing in DX is great and I would really encourage you to do so, but there's some stuff I wanted to warn you about. The first thing is that there's not a unique type of developer. It's very easy, especially when you are working on developer products or tools, because people working on those projects are developers themselves, it's very easy for them to think that they know everything. Yes, I'm a developer, I know how everybody feels as a developer, so I know that we should do that. No, everybody is different.

[00:14:48] (garbled) The best way of overcoming that bias is to build a diversified team, making sure that your engineering teams have people coming from various backgrounds, various cultures, et cetera, just so that you don't have this bias of a unique type of developer.

A coherent strategy, and the costs of tooling

[00:15:12] Also, you should have, and should define, a coherent strategy. When we started building all those toolings, basically we were popping out a lot of tools, SDKs here, SDKs there, and then we had the versions in React, et cetera, et cetera. Because we were not that many developers at the time, everything, like the documentation, was spread a bit everywhere. Some of it was on GitHub, some had dedicated sites, et cetera. As a result we were confusing our users. Developers coming to Algolia were like, okay, what should I use? So really you should think of being very clear upfront about which tool you should use for which problem, and you should probably use your general documentation to guide developers throughout the discovery of those tools.

[00:16:07] Also, investing in developer experience has its costs, and you should be aware of that, because when you are shipping a tool it's not a one-time thing. Hopefully your project will live and you will have new features and you want to reflect them through those tools, and if you have different versions of the same tool it means that you have to put those new features in very different places, and you also have the maintenance, et cetera. So it has a cost.

[00:16:34] For that you should be careful about your velocity. Again, when I joined we were not that many[?], then we grew a lot, we added more people to work on those different tools, and as a result we were less productive, shipping less often than before, which sounds counterproductive. One of the reasons for that is because at some point you want to optimize a bit more of the code structure, you want to reuse more things you build. You should have it in mind, because you don't want to over-optimize at the very beginning when you are starting, when you are writing the first libraries, but you don't want to wait too much, because if you do then you will have to catch up and do those refactorings that can be really painful.

Ownership, structure and consistency

[00:17:32] Ownership is key until you need more structure. What I mean by this is, again, at the very beginning of Algolia it was one developer, one library. We had an expert in Java that would work on the Java SDK, we had an expert in Go that would work on the Go SDK, et cetera, et cetera. At that time there were no PMs, there was no developer experience strategy as well, so basically one developer was acting as a mini PM for their own library. At some point we grew and we wanted to bring a bit more coherence, so we added teams. And then teams need to be structured, need to find the way they are working together, and this does not happen overnight. Switching from a model where it's individual ownership to a model of, okay, now it's a team owning the whole tool, it takes a bit of time and you need to anticipate this.

[00:18:25] And finally, maybe my favorite one: consistency is an everyday battle. What I mean by consistency is, for instance, the method names, the default behaviors in all your tooling. For instance on the front-end libraries they were not the same. Advocating for consistency might sound a bit boring, because consistency is not a very pleasant topic, but it's very important.

[00:18:57] I was thinking a few months, four years ago now, that it was okay that the libraries were not consistent, because someone using the React version will probably not use the vanilla JavaScript version. And it's true, if your website is in React, probably you will not use the vanilla version. But the thing is, our customers' developers are not the only users of those tools. We have at least two other kinds of users.

[00:19:24] The first category of other users was what we called customer facing teams, so those are our teams that are working with our customers to help them implement us, or doing QA, et cetera. Those people, they don't choose which libraries they are going to use, because they are taking the one the customer is actually using. At some point they were like, I don't understand, in this one it's that name and in this one it's that name. It was hell for them.

[00:19:59] Another kind of user that exists is the team itself, because at the beginning of the journey with all those libraries, the people that were there knew everything, they knew why this choice was made, and this and this. But those people left, because they joined another team later in the company, or they left the company, and basically they left with the knowledge.

[00:20:26] So really you want to make sure that you have consistency in mind. If you have this as a routine to check, it's way, way easier than waiting for a pile of, I will not say the word, but yeah. Just have it in mind, think about it regularly, it's less painful than if you wait that long.

[00:20:52] So just to conclude and to wrap up: basically what matters is that developers are focusing on the right thing, and for us what we really want is for them to focus on reinventing what search and discovery is and to innovate on that territory. So it's very important that they have time to focus on that, instead of focusing on their issue with API calls[?] and stuff like that. That's it, thank you.