How Data Privacy Literacy Is Shaping Infrastructure

Hi, everyone. Today I'm going to be talking about the blurring boundaries of infrastructure design, and more specifically, how our users and designers are shaping our infrastructure. For those who don't know me, hi, my name is Megan, and I'm a design lead at Cloudflare. There I work on our developer platform and AI products, but in the past, I've also worked on ML ranking, maps and spatial computing, AR, VR, and XR technologies. From some of my past experience, it might be clear that I spend a lot of my time working at the intersection of technology and design.

That means I spend a fair amount of time in places where you don't typically find designers, going deep on the technology, understanding what our users need, and rethinking how we can use existing tech or even inventing new tech to better serve our users. In my time in this role, I've learned that this approach can sometimes seem pretty radical, especially as we go deeper and deeper in the stack. And my hot take is that the boundaries in between interface design, front-end design, and backend design actually do not exist. They're artificially created by us, and that makes sense because in most of tech, that's how we build our products. But today I'm going to show you that these boundaries are really blurring through the lens of two major shifts that I've observed in our industry.

The first is a change in our users, and that is that they're becoming more and more technically literate, blurring the lines in between interface design and infrastructure design. Cloud storage is a great example of this, where a very infrastructure-heavy solution has now become a user product. User needs are directly shaping how we design and build our infrastructure today. My second observation is that the technology that we use to build our infrastructure is also changing, and this is shaping how we build our infrastructure. It is becoming more and more permutable, blurring the lines in between front-end design and backend design.

Most developers now consider themselves full-stack and need to make decisions both in the backend and the front-end that should start to include our user needs. The combination of these two changes together is shaping not just how we design our infrastructure, but also who should be involved in those decisions and who's considered, particularly those that are shaped by our user needs, and that role is often played by design. Now, before I get too ahead of myself, I want to walk through both of these changes in a little bit more detail. The first change is a change that we've seen in our users, specifically in their technical literacy. If you're not familiar with this term, user technical literacy really just refers to how much our users understands the underlying technology that powers the applications that they use.

To show this change, I'm actually going to walk through a timeline that has four major milestones. These milestones highlight a shift in our users' mindset on how much they understand the technology that they're using, and it's happened over the past decade or so. This is going to be done through the lens of privacy, but I don't want to be too focused on the specific privacy moments, but instead on the changes in our users. So, let's jump into it. This all started about a few decades ago when, as a result of social media, we started to share our real identities online. This, if you remember at the time, led to some pretty widespread debate leading to the first shift in user technical literacy, awareness. We now started to become more aware of the underlying technology that powered our application. Now, a few years and several pretty viral incidents later, we started to realize the danger of an unregulated data market, and it forced us as users to educate ourselves on how the systems work, leading to the second shift, education on the technology that we are using. Even a few years later, and even more incidents, legislation and news coverage forced us to go even deeper in understanding exactly how this technology worked, and this led to a third shift. We were no longer just educated, but we also became opinionated and nuanced experts on the technology that we're using.

And that brings us to where we are today, expected. It is now expected from our users that we build our products' privacy first, and they have very clear expectations on us as builders about what they want and what it should do. Now, at this point, you might be thinking, that's cool and all. But what does this have to do with how we design our infrastructure? And if that's what you're thinking, that's okay, because that's not we are today. Most of the conversation has been primarily focused on ensuring we're not collecting PII, or personally identifiable information, or sensitive data, especially if it's not necessary for our application. If we do go a level deeper, it's often in discussing how we're explaining these pretty complex concepts to our users in the UI. And while what we collect and how we explain it to users is very important, if we stop just there, it feels like we're stopping before our jobs are done. And that's because it's really not just about what we collect. The piece that I think is a little bit less talked about is all the decisions that come after we decide what to collect. It starts with how that data is processed or transformed by our application. It continues with where that data is stored and how it's managed, who has access to it. And it's made even more complex today by how that data might be used after the fact for other derivative use cases, like AI model training. In a world of cloud compute, personalized advertising, and AI, it's really no longer enough to just talk about what data we collect, but also what we do with it.

Now, if this was a little bit too conceptual, no worries. I'm actually going to walk through a real example of how this has manifested in our privacy settings, specifically in iOS over the past decade or so. If you compare these two areas that you see here, you'll notice a huge difference in the nuance, the granularity, even the language and complexity of the controls that we now offer to users. Even a few years ago, the kind of language that we use in our products would probably only be available in some kind of developer mode or not exposed to our users at all. But now this is not just an expectation of our users, but it's also something that they have pretty strong and nuanced opinions about, which is why our controls are so granular today. And this is not just changing our interfaces, but it's also changed how we build our applications. App developers are now forced to design their applications to accommodate these very popular user features, when and how data is collected, whether it's continuous, in the foreground, in the background, how accurate that data can be, how frequently we get it refreshed. These are all things that used to be primarily engineering functionality decisions that now take into account very heavily user needs and their sensitivity and privacy. What this really means as a whole is that user needs are now shaping how we design our infrastructure. And that really brings us full circle to my original point, that hopefully it's more clear now how users are changing and that they're more technically literate than ever before. And this change in our users is causing their needs not just to inform, but shape how we build out our infrastructure. And where you'll find users, you should find designer as well. But it's not just the users and design that's evolving, it's also a big change coming from the technical side as well. And that leads to the second big observation that I've seen. Now, before I go into this next part, I want to caveat this all by saying I am by no means an infrastructure expert. I am, after all, a designer. So I apologize in advance if this isn't the most technically accurate part of my presentation, but I hope you give me a little bit of grace and you won't focus too much on that.

Instead, what I really want to highlight in this section is the changes in the technology that we use to build our infrastructure and specifically, the changes in the principles for how we approach building and how involved users and designers are in these decisions.

And once again, I'm going to walk through this change through a timeline of the evolution of infrastructure. I don't want to focus too much on the technical or chronological accuracy here. Instead, what I'm going to highlight is the big shifts in the practices, specifically, the best practices of how to build infrastructure and what motivated them.

The overall direction that you should end up seeing is a blur between the boundary of front-end and back-end infrastructure design. But most importantly, I want to highlight that a lot of this change has to date been informed by engineering performance and developer experience decisions. So let's get into it.

In the beginning, most developers had minimal control over where they ran their application and we all followed the same general global standard and that is that applications were run on a single server. Then a few decades later, we decided to break out front ends to run on content delivery networks. This was the beginnings of choice in infrastructure design, although it was still very much an engineering conversation.

You could decide to optimize your performance or make it easier to scale by moving parts of your infrastructures off of servers. Then, even a few more years later, we realized we could start to run compute over CDN, leading to serverless compute. This gave developers even more flexibility now to choose which parts of their application they wanted to run server-side using full stack frameworks like React. But once again, a lot of this discussion and a lot of this change was still focused on developer experience and engineering performance.

And then where we are today, or actually a year and a half ago. With the release of React server components and other similar client and server-side services, developers now have more choice than ever to build and to decide where they build and run their applications. Now, once again, you might be thinking, that's nice and all, but what does this have to do with user shaping our infrastructure? And the truth is, so far it doesn't. I haven't seen a lot of conversation around how this technology can be used to bring user functionality and help users have more of a say on how we build our infrastructure.

And I primarily think it's because we're still in pretty early days of understanding how this technology can be used and how to think about it. So I'm here to discuss that shift with you all today. Now, there's been a lot of hype around React server components, and I'm by no means an expert. But from a cursory glance, I've seen a lot of this discussion has focused on two main things, performance and developer experience.

The former really focuses on the permeability of load times and rendering optimization for shimmer screens like you see here today. The latter focuses a lot on the simplicity of code with data fetching. And while this is really interesting, I feel like it's only a first pass of what we can now do with this technology. As a non-developer, the opportunities that this enables that I find the most interesting are more in the privacy and security space.

We can now ask ourselves what code or data shouldn't be exposed on the client or on the server. And we can decide and design permutable infrastructure based off of the answer to that question. This can empower our users with the competence that their sensitive data will never leave their device. And similarly, you can enhance your own security for your infrastructure by preventing code or data from ever being exposed to the client.

In other words, you now have full flexibility to design your infrastructure to meet both yours and your user needs. But this isn't an easy decision to make, and I think it's because it's new territory and can be quite nuanced. With this ability and responsibility, you are now defining boundaries in between server and client like never before. And I believe this is going to be pretty unique per application or even per use case within your application. It's an explicit choice that you need to make to define where the data lives, where it's transformed, and how it's stored in between client and server.

And it's not always straightforward. And we now have the burden and privilege of making that choice ourselves. But if this seems overwhelming, don't worry. We already have some early libraries that are designed to help you manage this. React has released some experimental APIs designed to prevent data from being exposed to the client for very sensitive information like secrets or other secure data. But I do want to highlight right now, once again, most of the focus has been on developer tooling. I'm optimistic, though, that with more designers entering this conversation and the evolution of this technology, we'll start to see similar APIs for user data sensitivity, preventing data flowing from the client to the server.

So to round this off, technology has given us more control than ever before on how we build our infrastructure. And the boundaries between front end and back end are really up to you to define. And it's not just a performance choice or a developer experience choice. It's one that also needs to be informed by our users and their nuanced needs. These two changes coming together, the changes in our users and the changes in our technology are shaping not just how we build our infrastructure, but who we consider in those decisions and who helps make them.

And this is a lot of change at once. So you might be wondering, wow, this is nice and all, but how can I include this in my practice in the day to day? Well, that brings me to the final part of my talk. Now that we have both the ability and responsibility to design our infrastructure, how can we do so in a way that optimizes for both engineering performance and user comfort?

Well, my solution? Let's do it with design. As user needs start to inform our infrastructure more and more, so does designers and so do the practices that they use. Why not use some of the very common UX tools that we use today to make decisions about how we design our interfaces to make sure user needs are at the forefront to also design our infrastructure? And so I'm going to walk you through a quick two step exercises that I recommend you start to add to your process. These are actually very common design activities that are retrofitted for exercises that we can use to design our infrastructure.

The first step is to create a data journey map. If you've worked with designers before, this might sound very similar to a user journey map. This is mapping all the components of your infrastructure and the flow of user and company data through your systems. And then we'll use this map in step two to identify the points of concerns and mitigate them with very intentional infrastructure design. These exercises are actually very quick and can be done by yourself, but I recommend doing them and they're best done with a cross-functional team. Bonus points if you include a designer.

Now I recognize just sharing these steps might not be the most clear, so I'm actually going to walk through an example of a retrieval augmented query or REG query to make this a little bit more clear. Starting with that step one is to map how the data moves through our system. The goal here really is just to break down my infrastructure into simpler component parts. So for this example, it starts with the user or client sending a query to an API endpoint. In my case, because I work at Cloudflare, it's typically a worker. This query is then transformed with an AI model into an embedding vector. I then use this vector to search a vector index to retrieve the related vectors. Yes, I just said vector a lot. Based on these results from the vector search, the system retrieves a document related to the initial query. And one thing I want to highlight here is that for our system, this is an internal document. So I use an AI model to summarize that document so it's not sent raw to the user, but instead generating a summary response back to the user based off of their initial query. A few notes about this diagram. The first is you might notice that I highlighted what is front end and what is back end here. And that's because I really wanted to understand when data was being transferred in between these two systems. The second you'll note is that the voiceover I just gave is much more complex than what it looks like is illustrated in this data journey map. And that's because this level of complexity was enough for my team to understand and do step two of this exercise, given that we're all very familiar with this technology. And that's really the secret to a good data journey map. It just needs to be clear enough to go into step two.

So for step two, we use this map to identify the places in the infrastructure where one, users might have concerns, or two, we as an organization might have security vulnerabilities. This can help you identify points where you need to more intentionally define the boundaries in between client and server not just based off of performance, but also based off of privacy and security needs. For my example, there are two such situations.

The first is in the initial query that goes from user to server. I want to ensure that there's no sensitive data in this initial query. And if so, I don't want to send it to our servers and ask the users to correct the query. The second is actually more on the security side of things where I want to make sure that the raw document data with internal information doesn't go back to the client. Only the summary and that it has no internal information that shouldn't be exposed. This all in all only took a few minutes in this exercise with my team was extremely valuable though.

And that's the last thing that I really want to highlight. I did not come up with any of this on my own, not the diagram, nor the concerns. I collaborated with my engineering, my sales, my PM, all my cross-functional partners to get to this point. And that really brings me to the final change that's happening. Is that as our technology evolves, so do our roles. The boundary in between engineering and design is closer than ever before. And I really encourage you to start opening up these conversations to more and more folks, especially as we start talking about AI. The exercises that I shared today are very, very common design activities. And I think bringing designers in can actually bring very diverse thinking and really make the solutions we build more robust. After all, we do build better products together. And so my call to action with you all is just that now we are all responsible design and engineering for designing our infrastructure in a way that can help us build a better product for our users. Thank you so much for listening. I'm excited to see you all at the rest of the conference.