 So I'm going to tell you a bit of a story today, and I'm probably the only designer on stage today. I think so Let's get into it on the slide showing up. No There we go. Cool. So in 2003 the New York Times interviewed Steve Jobs about the success of the iPod and This was my favorite part of what he said So he said design is not just what it looks like and feels like Design is how it works Now since you're a platform engineering day, I'm going to guess you probably don't consider yourself a designer But if you're responsible for deciding how your organization's internal developer platform works I want to convince you that you are actually doing design So in this session I'm going to share how you can use principles from the field of UX to create an internal developer platform That your developers actually love using and you don't even need to wear a black turtleneck to use some other principles that I'm going to share with you today So by the way, my name is Kirsten Schwartzer, and I'm a lead product designer at Octopus deploy So how do you avoid getting into a situation like this where you've spent months building an Internal developer platform, but the adoption is slower than you hoped it would be the users you do have are running into frustrating issues that are slowing them down and You're not really getting the glowing reviews that you expected for all this hard work that you've put in So why is it so hard to design a good internal developer platform? I think the answer lies in the definition and I really like this one from internal developer platform org So this is the only time I'll read off the slides, but it's a really long one So an internal developer platform is built by a platform team to build golden paths and enable developer self-service An IDP consists of many different tech and tools Glued together, that's your first clue in a way that lowers cognitive load on developers Without abstracting away context and underlying technologies. That's the second clue And then depending on the maturity of the IDP it provides several interfaces and access points That's the third clue So figuring out how to glue together different tools to lower cognitive load While not abstracting away context is a really tough UX challenge So my goal with this presentation is to give you a really clear direction for what to do next So I'll be sharing some practical UX principles that you can use and combine So let's get into it. Are you guilty of designing things in a way that makes sense to you, but not to your users? So I want to introduce you to the false consensus effect now. This is a cognitive bias where humans overestimate the extent to which our preferences and our habits are normal and the same as other people So one of the most important realizations you can have as a designer is that you are not your user and Your solution may actually be more of a reflection of your own preferences than your actual user needs So we've actually run into this challenge a bit at Octopus. Most of the engineers that I work with Build features for Kubernetes. So they use Kubernetes all the time But their day-to-day looks totally different to someone who works on a platform team at a multinational Corporation, you know running production clusters across many geographies. Their needs are not the same So how do we overcome this cognitive bias? so you want to start doing light weight user research and I know you're very busy and this is something that you're going to have to do on top of everything else that you're already doing But I think it's worth it And so I've tried to make it as simple as possible for you to get started So what you want to do is called a think-aloud study This is where you ask one of your users to Do a typical task with your IDP so it should take around 30 minutes to an hour not longer than that You want to remind them that you're testing the platform. You're not testing them You want to ask them to share their thoughts out loud as they're doing the task? remember to press record and Basically stay quiet and let them talk while they complete this task So there are lots of fancy tools on the market that UX researchers use for this sort of thing But any video conferencing tool that has recording and transcription is good enough and After you've recorded those sessions you want to analyze them to see where do users run into friction? Where are they getting stuck and so you want to start creating a backlog of those ideas and You can also note down how severely something affects the user experience and how often this crops up across the different users that you speak to So once you start implementing this user research habit So I would recommend starting with like one a week nothing too crazy you'll start to Gain a lot of confidence that the effort you're putting into your IDP is Actually going to improve your developer experience because it's based on the problems that your users actually have You'll also be a lot less prone to stakeholder interference where your boss comes in and tells you what they think you should build But you already know what to build because you did the research and you have the data to back it up So your users will also feel like you're listening to them and you might discover some really interesting issues that were actually Causing them problems that you wouldn't have expected So in addition to what you learn from your users, I've curated three additional UX principles that relate directly to IDPs So in the 1980s at the IBM user interface Institute John Carroll and Mary Beth Ross and came across a really interesting phenomena So they noticed that users Wouldn't read the manuals that came with their bright shiny new computers. They would just start using them Even though the paradox is it would have been better for them to read some of the manuals and the docs up front You know build up some foundational knowledge and then try to use the computer but humans are not rational and We should design for the way that our users rarely act instead of how we wish they would act So in the case of your IDP, it's really unlikely that your developers are going to read a bunch of documentation upfront They're going to be much more motivated by the specific task that they want to accomplish So this doesn't mean you don't need documentation, but you do need to keep this in mind when you design the onboarding experience So let's go over some ways that we can simplify that onboarding experience Knowing that the docs likely are not going to be the first port of call So the first thing you want to do is to understand the onboarding experience and what that's actually like for your users So you can watch them through talk allowed studies You can interview them you can survey them and then you can start to piece all that data together on a user journey map Now a user journey map typically covers the end-to-end user experience from start to finish But since UX is probably not your day job. I'd recommend just focusing on the onboarding experience to get started So the first step is to break that experience into distinct phases So that's the columns that you see on this table. So discovering the platform getting access your first project and so on So next you want to fill in the actions that your users need to take in each of those phases Then you want to write down their thoughts and emotions. Are they confused? Are they frustrated? Do they feel confident in the actions they need to take during that phase? Then you want to note down the touch points that they come into contact with and Now this is particularly important for an IDP because like we saw in the definition There can be so many different interfaces and access points and there may be some non-obvious ones like let's say Your sick ops team slack channel where they need to request access to tools. That's all part of the onboarding experience Now as you note down those touch points You'll start to recognize where friction lies in the onboarding experience and you can note that down under opportunities and a good place to look for that is where you have to switch between different interfaces to complete the task So once you've completed the map up to this point You're gonna start really getting a good grasp of what the user experience is actually like and what it's like to onboard Into your internal developer platform and you can keep updating this user journey map as you work on improving the experience And so it really becomes a living document and a guidepost for you know What your users do and how they feel as they use your platform over time? Now the next principle is focused specifically on reducing cognitive load during the onboarding experience It's called progressive disclosure and it's basically You deciding to not reveal all the information at once and rather giving your users Information that they need at the point when they need it So for example if you have a service catalogue you can create a recommended section with just a few services That you know users will get immediate value from and it just makes their onboarding experience a lot less daunting Here's an example of something a team at octopus recently did so If you want to select steps for your deployment process, I think we have more than 150 of them How do you know which one to pick so they created a featured section which is specifically aimed at new users and Helping them decide which steps to include in their deployment process as they get started Now my next tip for improving the onboarding experience is to provide contextual help So this is where you give users relevant information Within the specific context of the task that they're completing So I know IDPs are often made up of like a bunch of commercial tools open-source tools and some custom bulk pieces So you probably don't have control over all of the interfaces And that's why it's really important to evaluate the commercial and open-source tools that you do add to your stack Based on how good their contextual help is For example, does the UI of your CD tool give users contextual help when they need to feel confident about a complex selection in the UI or Does another tool in your stack have a help flag in the CLI that gives users an idea of the type of commands that they can use or That gives them specific help for a specific command that they're having trouble with without having to leave the interface So if you're creating a portal with a custom or an open-source UI You could use something like app cues Which is a platform that lets you add an onboarding checklist as an overlay on top of whichever interface it is And this will help users Basically understand which steps they need to take in the right sequence without leaving the interface And then if we're looking at IDEs I think the most sophisticated form of contextual help that users currently have access to Is something like github co-pilot. So it's basically where the AI Proactively provides suggestions for what users should do next based on the specific task that they're working on Now my next principle comes from Jared Spool He is a legend in the field of UX and he says that errors are a proxy for frustration So I agree and I think there's three parts to solving the error problem The first one is To prevent the most commonly occurring errors So if you use any logging solutions or if the tools in your platform come with built-in logs It's a really useful exercise to count the error messages that occur the most frequently It sounds a bit boring, but it's actually really high value So another way that you could get this data is to mine support tickets from your developers to see which errors crop up the most often and You may even want to interview your users if you find errors that are a bit unexpected and don't make sense to you They'll be able to tell you where they're going wrong So once you have this list of errors that you want to address Think about the different ways that you could help users prevent those errors from happening in the first place So if an error is caused by incorrect user input, can you give them better validation? Can you give them templates or snippets that already have the correct information in them? And again, can you give them contextual help to help them make complex choices in an interface? So the second part to tackling the error problem is actually helping your users when they do encounter errors and Giving them error messages like this is a guaranteed way to add to their frustration So for the parts of the platform where you have control over error messages It's really worth your time to write good ones and you don't have to rewrite them all at once You can take a really pragmatic approach based on the ones that users encounter most often So for the errors that you actually have control over and that you found occur quite frequently You can create a scoring rubric to evaluate how good those error messages are So there are lots of more sophisticated scoring models and error guidelines out there But I tried to really simplify down to the core of what you really need to get started So you want to answer yes to each of these five questions Are you telling your user what happened? Do they know why it happened? Well, they understand what they should do next Do they recognize the words that are being used and is the tone positive and supportive? So let's look at a better example that actually takes those five criteria into account So this is telling you what happened. It says you need additional permissions. It's telling you why it happened It's because you're trying to integrate with external APIs The user will know what to do because it tells them they need to complete a form and it also links to that form in the button at the bottom There's no obscure language that the average application developer has never heard of and most importantly It doesn't blame the user instead. It focuses on the problem and not what the user did wrong Now the final part to reducing frustration because of errors is to create really good documentation Now I know we covered the paradox of the active user at the beginning But like I said, that doesn't mean that your engineers don't need documentation They're just more likely to reach for it once they find themselves in a tricky situation where they don't know what to do next So some people say that your UX should be so good that you don't need any documentation But I've been working on highly technical platforms for the last seven years and I just don't think that's true This is not the same as using Instagram or Uber like we're designing Complex platforms for users who are doing really technical tasks. We're probably gonna need some documentation The next thing you want to do with your docs is to provide step-by-step guidance for new or complex tasks that users need to accomplish So they might try something on their own first Figure out that it's a bit hard and then decide to follow a guide So you want to make sure that you break those guides into very clear sections with subheadings And you want to make them as linear as possible So if there are any side quests that your users need to do like Running a command in the terminal or creating an account in some tool You want to put all of that in the guide and make it really linear So they won't need 12 windows open to figure out what they need to do next Now the next principle we're going to cover comes from the field of cybernetics And it's called Ashby's law or the law of requisite variety now. I have the complex True version on the screen But in essence what it says is that a system needs to be able to handle the variety of its environment to survive So how does that actually apply to an IDP? I? Think it can be really tempting to oversimplify an internal developer platform and try and force as much standardization as possible But if your system doesn't meet the complex demands of your users environment It just won't survive in the long run So I think there are two parts to Actually using Ashby's law to improve the developer experience So firstly you want to be able to handle the complexity of your users environment And then you want to be able to handle the changing nature of their environment So as users become more proficient in your platform, they're going to bring more and more advanced use cases to it Users don't stay beginners forever. So don't forget about your advanced users Now in the field of UX there are 10 usability heuristics that were created by Jacob Nielsen in the 90s and Number seven is flexibility and ease of use and what it says is that you should design a system that caters to both inexperienced and experienced users So you want to do that by providing things like Advanced options to more experienced users that make their configuration more customizable like the example that we have on the screen Another way is to give them shortcuts or automations so they can do repetitive tasks faster So basically what you're doing is you're providing multiple ways to achieve the same task, but catering it to different levels So the main thing that you want to remember is you don't want to over simplify at the cost of your advanced users You have to think about both Now the last part to Ashby's law is all about being adaptable So we've seen so much change in the industry over the last year Many companies don't exist anymore large language models on our part of our daily lives and the amazing CNCF community just keeps creating new tools You don't want your platform to become stale and to no longer match the environment that your user operates in It needs to be able to adapt to future changes And this really is a key part to ensure that it keeps getting used over time So this may even affect how you architect your platform Like I said in the beginning I agree with Steve Jobs Design is not just what it looks like and feels like design is actually how it works So the first thing that you should do when you get home from kube-con is to start getting user feedback So that's really going to help you build a backlog that's based on user research then you want to focus on onboarding on Errors and on the adaptability of your platform So if you do those things the people who already use your platform will have a better experience they'll be more productive and they'll tell their colleagues and This creates a virtuous cycle where the more feedback you get the better you can make your platform The more Users you get and the more productive your team becomes and your IDP can actually end up in a situation Where it just keeps improving your developer experience over time and that's the power of investing in UX So here's a cheat sheet of what we've covered today The slides are available to download at the QR code and I'd love your feedback I'd love to hear what you thought of the presentation and Yeah, if you want to come and say hi, I'll be at booth g26 all week. So you're welcome to Come and ask any questions there as well Thank you so much That was fantastic. Thank you. Anyone got any questions for Kirsten? Oh, yes so I've actually got to Because I do all the kind of stuff you're talking about there for my squad One of the questions was you were talking about the linear Documentation make sure you don't have any side quests totally agree But what I've also found is that you end up with a lot of duplication Because you don't want to send them on a side quest But then you end up having the same information and then it might start getting out of place because you rely on someone else to update it in three places Do you have any tips for prevent that or are there a better way of dealing with that or is that the exception to? linear stuff Yeah, that's an interesting one. So I think something that That's a bit counterintuitive to think about is that sometimes when we design things We want to make sure that the sort of model is as clean as possible and like we're not repeating ourselves and things like that But sometimes it's worth making those trade-offs to put everything right in front of the user So it doesn't have to be a blanket rule. We do that every single time, but let's say for the first experience It may be worth trading off that duplication to just make sure that users don't get lost When they need to navigate through a bunch of different links because it can be quite hard to orient yourself to where you are which step You're busy completing So yeah, I think especially focusing on the first user experience It's worth the duplication but later on it might be a trade-off. That's not worth it If you're thinking about more advanced users, they'll be able to navigate it probably quite well Does that answer your question? Yes Thank you, and I've just got another question and you had this Novice, I see as advanced users user experience Which do you do first? Like you know out of releasing kind of thing you would start with one probably rather than being able to provide for both Who gets priority? Do you give the advanced people the tools or do you go? Well, we want to bring everybody on board at first. So I Think when it comes to increasing adoption Focusing on new users first. It's just it's easy wins basically if you can remove friction make things obvious like what to do next Those new users will eventually become advanced users. So I think if I had to approach it That's that's probably what I would do is is focus on the new users first. So you actually You also start getting a lot of data where people are getting stuck and then you can work like through that journey I think I showed the user journey map earlier. So you can actually extend that to the full user experience and start to include more advanced use cases But yeah, I'd recommend focusing on new users and on their onboarding to get started. Yeah Hi So one question you said that we should do those think aloud studies But this mainly focused on existing internal developer platforms. How do you? Integrate user feedback or user experience When you evaluate such a project and plan you and tell the developer platform from from the baseline on where users don't might not know What is possible? Yeah, so that that's a great question. So in that scenario typically what we do is more generative like discovery Research so we want to discover the problems that users have and just interviewing them is the best Yeah, sort of best bang for your buck in that scenario if you can spend 30 minutes with them ask them about their problems Which things are taking the most time, you know, which things are frustrating them the most they will tell you So it's it's really about listening to your users and I'm really lucky So the product manager that I work with is sitting here in the back of the room And I think we did like almost a hundred interviews last year the two of us With users to find out those sort of discovery Generative questions for the new things that we actually want to build. So yeah, that's what I would recommend. It's just interview them Yeah, hello Happy birthday again One of the questions that I wanted to ask like we had a lot of discussion about onboarding But in our company one of the challenges that we have like we have a lot of tenured engineers and They know how to get around the errors of the system pretty well So it's sometimes really hard to get like proper feedback from them because it's like, yeah I'm good with it kind of feedback So like how do you actually get the frustration points from those tenured people that knows that they're like truly advanced users And when they are the majority of the users of the system So that's also something that you learn the more you watch users is what users say Isn't always what they do. So I would actually in that scenario Really watch what they're doing as they're going through that study like they may say that something is easy But then they actually still get stuck Somewhere they just know how to fix it So in that scenario, you might be improving something for a more novice user because even a tenured person gets stuck There they just know how to get out of it So I would say really pay attention to the video recording and what users are actually doing Versus just listening to what they say because sometimes those things don't actually match up Yep, any other questions for Kirsten Other than why are you doing a talk on your birthday, but we appreciate it. Okay. Thanks very much Kirsten. Thank you