The process of developing SLIs and SLOs for a user journey can be broken into four steps. We foreshadowed a lot of this process in the previous module while talking about the SLI menu, but now we're going to put the pieces together explicitly. The first step is to figure out what types of SLI you want to measure for your journey, and set down high level specifications for these SLIs. This is where the SLI menu comes in handy. It provides a simplistic mapping of user interaction to recommended SLI types that cover a surprisingly large proportion of use cases. Your SLI specifications will sound pretty generic at this point. The next step is to make the difficult choices and describe in detail what the events you're measuring are, any validity restrictions to the scope of the SLI to a subset of events, and what makes an event good. You'll also have to weigh the pros and cons of the various measurement strategies, and say exactly where and how the SLI will be measured. These refined SLI implementations need to be detailed enough that someone could build or configure monitoring infrastructure to gather the data without needing to ask any further questions. With your SLI implementations in hand, you'll need to critically examine how your infrastructure serves the interactions that make up the user journey. Pay careful attention to how that infrastructure could fail and the implications for your chosen implementations. Any failure modes that your SLIs won't capture, hopefully there won't be many, and they'll be low probability, should be documented carefully. If you find something that's too high risk, it's a signal you need to go back and rework your implementation, likely by changing your measurement strategy or augmenting it with a second one. Once you're happy with the SLI implementations, you can choose your measurement window and set some SLO targets. If you've got time, you can wait for a couple of measurement windows to gather performance data before setting your initial targets or you can estimate targets based on your business needs and already existing signals of user happiness. Sounds easy, right? Well, it can be if your user journeys are simple and your infrastructure is architected to make SLI measurement fast and cheap, but the devil is always in the details.