 I'm told I have to unplug the thing. Hi, everybody. Hope you're having a good DrupalCon so far. Is this good? Can you hear me? I'm recovering from my slings cold, so bear with me if I have to cough. So I think we'll get started. People can come trickle in as we go. So you can follow along with the slides if you would like on speaker deck and my Twitter, Megan Aaron Miller. So hi, I'm Megan Miller, and I'm a designer. Actually, it's becoming harder and harder for me to talk about what I do. And that's what I want to talk about with you today. Today, I'm going to talk about how my concept of design has shifted over the past six months and how my purpose in life has become more clear. This is my quest in search of the why behind my design practice and the self-discovery and discovery of a new practice along the way. I designed my first website in high school on GeoCities. Oh, yes. I didn't know it at the time, but this was the start of my web design career. Fortunately for me, I don't have a record of my first website, but I remember it had a lot of black and pink. One day, much, much later, someone said these five magical words to me. How much do you charge? Lights went off in my head. People will pay me to do this. Wow. So on that glorious day, I started freelancing. Design for me at this point in my career was about satisfying the client while upholding my aesthetic values. I created visual systems and helped people present their content in a pleasing way. In 2012, I started working with Stanford Web Services. My crew is all here in the front row. We are a central creative web studio at Stanford University, tasked to create beautiful, effective websites at scale for the entire university. When I started, I was confident that I could meet the challenges ahead. Little did I know what was coming. We faced a queue of 140 site requests in our first year. How could we ever, with a team of six, tackle the sheer magnitude of websites that were being requested of us? In our first year, we launched six sites. They were complicated and wonderful and special in their customized Drupal Six way. And guess what? Our queue had grown in the meantime. Fast forward to today. We're now a team of 10 with two open positions. And on April 16th, my birthday, we launched our 100th production site. That's 40 plus sites in the past year alone. Boy, did we learn how to scale. And so did my design practice. We have a mandate from the university to meet as many website requests as possible, as efficiently, effectively, and cheaply as possible, while also maintaining high design and development standards. How are we supposed to live up to this mandate? We became a product development shop. My job was no longer about designing for a single client, but about designing for hundreds of potential clients. In 2013, we launched Stanford Sites Jumpstart. It's a set of pre-built website templates that enable us to rapidly provision sites on demand. Through modular features, flexible themes, and installation profiles, we're able to jumpstart our clients by matching them with a template that best fits their needs. Today, we have three Jumpstart products that we use to rapidly provision sites to the Stanford community. So six months ago, my concept of design revolved around our product, the design of features, interfaces, and the user experience. The scale of the problems I was solving and the systems involved in my design work had drastically grown. But design decisions had larger ramifications and impacted the success of our clients and the effectiveness of our team. I was having a harder and harder time, keeping the big picture clear in my head, and so was the rest of my team. And then I learned about service experience design. I felt like a veil had been lifted from my eyes. Why hadn't I known about this entire field before? I so desperately needed new methods, concepts, and ways to communicate about the larger problems I was faced with and designing for a suite of products and the customer experience that they created. Nobody teaches you this stuff in design school. They talk about usability, and they talk about user experience of interfaces and interactions. But the customer experience extends beyond the interface. How are we supposed to design for that? It turns out we're in luck. Service experience design is here to save the day, or at least my day. So since November, I've been on a mission to learn everything I can about service experience design and begin integrating it into my day-to-day practice to shift the focus of my work from product to service and to start thinking end-to-end instead of interface. Now I'm up here speaking to you at DrupalCon, a fellow member of the Drupal community, and as a designer, not claiming to be an expert yet in service design, but more of an ambassador. This is my synthesis so far in understanding this field and how it can benefit us. To take you with me on this journey, I want to start with a story. It's spring break. Your dad drove you and your best friend hours to get to the park, and you made sure to arrive early. There's 10 minutes to go before they open the park gates. You have your ticket in hand. Bidu, they open the gates and scan your ticket and you run. You run, laughing past vendors, buildings, music playing in the background, shifting as you pass. You run out of breath, panting. Everything is a blur, but you did it. You are the first group of the day to ride the viper with no weight. Very important. During this magical day at the theme park, you wait in lines, you find bathrooms, you purchase food, you lock up your belongings, and of course you ride the rides, each one a unique experience. At the end of the day, you get back to your hotel room and you snack and giggle on the bed, reliving the thrills of the day. And 15 years later, you find a photo in your scrapbook of you and your best friend riding the viper. The theme park is the service ecosystem, and each ride, line, bathroom, and vendor are all touch points in the particular user's experience. This particular story is a single path a user can take through the theme park. It is their end-to-end experience, and it's just one of seemingly infinite use cases that can occur at the theme park good or bad. Some of these terms might be new to you if you're hearing about service experience design for the first time today, and others might need some redefinition. So let's dive in. Let's start with the basics. What do I mean by service? By service, I'm referring to the value you provide your customers. It's a holistic understanding of the systems, processes, and people required to deliver a consistent quality customer experience. It's bigger than a single product, and it refers to the entirety of the customer experience and the systems that support it. A service ecosystem is a complete picture of all points of interaction involved in creating and offering your service. It's comprised of contexts, devices, channels, environments, and experiences. Each of these points of interaction can be a touch point for your customers. These touch points take place in channels, mediums such as in person, over the phone, web, email, and when a customer engages with our service, they experience it through time. This experience unfolds and can be captured as a narrative end to end. This end to end experience a customer may have with our service may be representative of a more iconic customer journey or use case that we want to understand better in order to improve our service. These iconic use cases help us zoom in to particular areas of our service where we can have the most impact. In a complex service ecosystem, there may be hundreds of touch points and a seemingly infinite number of end to end experiences, unique ones that a customer can experience. It's important to be able to decide which use case to focus on in order to have the most impact. At Stanford Web Services, one of our main challenges to scaling our Jumpstart website service is that many of our clients have trouble seeing how our out-of-the-box templates could become their unique customized website. We've done this a lot and it's easy for our team to envision how with a few simple tweaks on the template, you could be there. But how do we help our clients see the possibilities? I wanted to unpack this problem using the lens of service design. But first, let me introduce you to Howard. Howard manages a mid-sized academic department at Stanford. His primary concern is to please his faculty while keeping the department on budget. He knows his department website is important for presenting the public face of his department to the rest of campus, the greater community and to peer institutions. But he doesn't know how websites are made or what the right tools are. Howard is balancing budget, time, pressures from his faculty and students and the overall goals of his department. When it comes time to make a new website, Howard is already feeling overwhelmed. Let's take a look at all the ways Howard might learn about our Jumpstart website service and all the touch points he interacts with just to make a decision about whether to use our product. In learning of our service, Howard usually would start with a word-of-mouth referral from a colleague. He then might exchange an email with Sarah, our manager, who would set up a phone call to discuss whether his site would be a good fit for our service. The conversation continues this time in person with other team members to better understand Howard's requirements. And throughout his conversation, Howard looks at the service page, our demo website, our product roadmap and the site request form. How can we better design this experience? This is not a user experience design problem. This is a service experience design problem. In Howard's journey as a customer, he's engaging with our service across many different channels, in many different contexts and through many different touch points. We have to be able to design between the gaps, between the touch points in order to improve Howard's experience. We need tools to do this. We need the tools of service experience design. In approaching this problem, I first wanted to get a better understanding of the totality of our service. I wanted to create a holistic map of the service ecosystem that would illustrate the complexity of our service and show how Howard's story fits into the bigger picture. This service ecosystem map would include all the touch points, tools, conversations, interactions, clustered by context. Here's what I created. I know it's a little hard to read. I'll tweet out the original of this. In the Jumpstart service ecosystem, you'll find tools like JIRA, Basecamp, Harvest, Slack, infrastructure like servers, web authentication, customer interactions like troubleshooting or help ticket resolution, and supporting documentation like our product roadmap, blog posts and our user guide videos. I attempted to cluster these into relational groups by context, illustrating all the various touch points that both the customer and our staff interact with in order to deliver the service. And here on the map is where Howard's story fits into the bigger picture. So this map helps us visually understand the complexity of our service experience and how the particular use case I'm interested in analyzing fits into that larger service ecosystem. But it's a challenging amount of information to display and the results is a somewhat complicated artifact to read. I wanted an even more high level overview of our service to see more clearly how Howard's story fits into the end-to-end experience. The next thing I created was an end-to-end overview document. This document highlights the major steps of our customer experience, as well as key behind-the-scenes processes that go into supporting our service. This end-to-end overview helps us see the big picture more simply, showing in broad strokes the experience of our service. What I ended up creating is three layers deep. The first layer shows the most iconic and ideal end-to-end experience we desire for our customers. The second layer illustrates our product development life cycle. And the third layer shows our environment support for our hosting infrastructure, which we also run. This kind of document gives us the big picture in broad, easy-to-understand strokes and helps people new to the service or VIPs understand it better. Each one of these steps is an area we might want to drill down further into, exploring the details of our service experience at that step, such as the site request step that best matches Howard's journey. So now that we see how Howard's journey fits into the big picture, how can we uncover insights into improving his experience? We need to zoom in and analyze in detail the steps that make up his use case. We need to create a service blueprint. This is the meat of service design, and it lets us conduct a detailed analysis of the steps involved in an iconic use case. Through this detailed analysis, we can uncover true opportunities for insight. Here we take our site request step and unpack it into its many sub-steps. Now remember, Howard's story includes many different contexts, channels, touchpoints. In order to map his experience, we need to involve people who are experts at all of these touchpoints. So I brought together a subset of our staff that can speak to different aspects of Howard's experience. This group included our developers, our customer experience specialist, our business manager, and one of our producers. Together, we were able to map out the steps of the iconic new site request use case. Now, to be honest, it didn't start looking like this. It started as a Google Doc, as most good things do, to facilitate real-time note-taking, and you just can't generate insight from a document like this. It's too messy. What we want is a visual system to display the steps and their nuances, a system that is geared towards generating insight. If you're familiar with service blueprinting, you may be more familiar with this front-stage, backstage, swim lanes format, where the customer actions are on the top and below it as you go deeper, you're deeper into the systems and processes of the organization. The template I've chosen to use was developed by Eric Flowers, principal service experience designer, Intuit. We've been collaborating to create a more actionable blueprint template, and we found that this format is more effective for analysis. The most important thing to remember is use a template that fits your use case, your company, your way of thinking. In the top section, you list the step description. So try to kind of break down your use case into discrete steps. And you have a picture of a touch point, a relevant touch point. For example, a site request form. You have a list of the actors involved, both the front-stage and the backstage, so the client and our staff, and any systems involved in the step, like a server infrastructure or an email service. You can also list observations or facts, some notes about the step, any metric or data call-outs, and any policies or rules that are relevant to this step, and this is an important layer, especially in an institution like higher ed. At the bottom are three areas to capture insights from your team, a place to make note of follow-up questions, a place to capture moments of truth, either as aha or uh-oh, either way, a revelation, and a place to take note of opportunities you can think of. And you can use color to differentiate between steps that are visible to the client and hidden to the client, or behind the scenes. There are many more layers you might find useful to add to this, like time per step or customer emotion per step if you have that data, and that might be useful for your analysis. By spending time to put your use case into a blueprint template, you're translating your insights into a visual system. And when you're done, you effectively have created a visual heat map of your use case. Suddenly you can simply see where the most people were involved, or the most systems, or the most opportunities. I find this to be pretty powerful. So this is what leads to actionable insight and why the blueprint is a powerful tool. I wanted to share a few of the insights we uncovered during our blueprinting process, just to show the variety. For step two, where our client emails Sarah directly, what if we had a decision-making tool to let clients choose features online before even contacting us? It's an idea. For step four, where our client and our team get together to talk about whether their project is a good fit for our product, what if when it isn't a good fit, we simply don't mention our product, but instead we treat it more like a custom project, which it is. Or step 12, this was a technical detail we uncovered. When we deploy our jumpstart site template, what if we could automate the creation of new databases and allow for more than one deployment to happen at once? Cause right now we can't for some reason. Or step 14, adding our info on this new client into our client tracking database. Right now we're manually hunting down this information in like five different places, and we uncovered that in service blueprinting. So what if the deployment script, which knows all this stuff anyway, could just spit out a report at the end and say, here's your site, copy this and paste it in. Or better yet, make a feed API. So these insights are about business, they're about technology, and they're also about strategy. It's, they're tied to an understanding of both the customer's experience and our experience as well, the surface to core process and systems that we have on our team. Now that we've identified opportunities for service improvement, taking into consideration the fine details uncovered, and the larger context in which those details live, now we're back to something familiar, creating a proposal for work to be done. The next step is you work with your product and business owners to outline the scope of work involved and address the identified areas for service improvement. From our analysis of our Jumpstart site request use case, we now have several promising opportunities to explore, and the ability to create a plan of attack. These artifacts and explorations have given us understanding at scale, both the big picture and the minutia. On one end of the spectrum, the insights might be too specific. On the other, too general. We need these varying levels of zoom to generate useful insight that fits within the context of the service as a whole. It's just too big to get all at once. But on each level, we can reach understanding and create opportunities for insight. Even if you're not doing service design yet, realize that your work lives somewhere on this spectrum, and there are always ways to expand your horizons. Through this process, we learn eight important principles that are at the heart of service experience design. One, experience focused. By focusing on experience, we are focusing on what really matters. This is our guiding light, our grounding rod, our gravity. The experience of our customers, but also our experiences behind the scenes. Two, narrative driven. Time is a critical dimension in service design. Through storytelling and narrative, we can illustrate service experiences and design within the gaps. Relationship centric. A service experience is built on relationships, people to people, people to organizations, organizations to organizations. If we can understand the relationships in a service ecosystem, we can understand the fabric of our service experience and all the people that need to be part of the conversation. Co-creative. Service design is not like UI design. You can't do it alone at your desk. Instead, you have to involve all the people that participate in your service experience. This might mean pulling together a cross-functional team that might never have been in the same room before, ever. You might have customer support staff, developers, business owners, architects, all helping you paint the picture of your service. So service design is the product of co-creation. End to end. At the heart of service design is the belief that seeing end to end will help us understand the totality of our service experience and it's the best way to generate true insight. But it is not enough to simply understand the customer's experience of our services. We also need full understanding of the processes, systems and people that go into creating that experience. This is the surface to core of your service experience. We have to look at the way we work together to fully understand what is driving our customer's experience. And in order to create a more consistent quality experience, we have to be equally committed to improving our own experiences behind the scenes. Service design is a holistic activity. Considering the totality of a service, the customer's experience, the staff's experience, all the context, channels and touch points. And for long-term value, you have to implement it as an iterative process and integrate it into your organization. As the service evolves, you need to iterate on your service experience. So these principles resonate with me and they're at the heart of why I'm drawn to service experience design as a practice. What do we do now? Now that we've identified work to be done, new experiences we want to create or even a new service experience altogether. It's time to move into prototyping. Our main goals in prototyping are to simulate the multi-channel service experience we want to create and test its viability. Before starting, ask yourself these two important questions. What is the minimum creation required to simulate the experience? And don't let yourself do more. Remember, the goal is rapid prototyping to test the value of your ideas. What are we testing for and how will we measure success? Get specific. Figure out exactly what you're trying to learn and define how you will measure the results. Studio Thick is an agency that specializes in providing service design. Here's an image from one of their case studies illustrating how they rapidly prototype service experiences, even when they require a physical space. Here they're simulating a service center and have built the minimum viable simulation required. Moral to the story, you can go far with cardboard and duct tape. And here's the service center they created based on their prototype. What's important here is figuring out what you need to test. For this project, Thick needed to test in-person interaction in a space before building it out into the real service center. Oops. To instill a culture of service experience design thinking, we need to figure out how to collect better data in our day-to-day service delivery so that we're closer connected with the experiences of our customers. This customer data is key to generating informed insight over time. It might mean that we need to introduce new processes and methods to collect the data in a more effortless way going forward. For Jumpstart, I've been working with our customer experience specialist, Joe, to gather help ticket data over the past year and better understand the pain points and requests directly from our clients. We're also using analytics to understand our user guide and feedback directly from customers in-person and through surveys. This data helps us stay confident that we're making informed decisions and painting an accurate picture of our service. Now we can prioritize what to focus on and make sure we're solving the right problems. By looking at the data, talking to the people that make up the service, you should be able to narrow in on the use case that will be most helpful to address in order to improve your service. Once you've narrowed in on your focus, you can assemble your team and dive in. This is messy, complex, challenging work. It means stepping outside of your comfort zone into new design territory, but there is so much potential. For us designers, where user experience design is like welding in your garage, service experience design is like welding at the bottom of the sea on a deep sea oil rig. It's a major change of context, but the fundamentals still apply. Taking a service design approach has helped our team improve the jumpstart service, creating new efficiencies, and for the first time, being able to see the complete picture of the service we offer. So why does Drupal need service design? We are no longer designing for single interactions. Websites are interconnected with other services. To design a website, we may need to understand the entire service ecosystem. And our research can also impact the client's offerings beyond their website. We might be in a place to make those recommendations. We have an opportunity to use our design thinking to help support the human systems behind the services of our customers. And to take this to heart, we have to acknowledge that we ourselves are providing services. Drupal is complex. Providing Drupal often means providing Drupal service experiences. On the flip side, I believe Drupal is the platform to support clients who offer complex services. And clients that have a service ecosystem should be using a powerful CMS. For web agencies, we can be adding service design into our discovery process. Customer journey mapping, service blueprinting, service ecosystem mapping. I know some of you have already started doing this and I would love to hear from you if you are. And for the brave among us, with the right clients, we could consider offering service experience design as a service. So think big. Think more holistically about designing experiences. Consider the experiences our agencies create intentionally or not. And learn new methods to design for an ecosystem. Because whether we intend it or not, all of our interactions add up to an end-to-end experience for a customer. My concept of design has shifted in a major way. It is no longer simply about creating visual systems or a usable product. It's bigger than that now. It's about designing a multi-channel, ecosystem-wide service experience. In my work, I'm finding new ways to think bigger and to visualize the end-to-end experience so that I can help my team grow and improve and help us serve our customers better. I have found a new reason to be passionate about my practice and to be proud to call myself a designer. I wanna leave you today with a set of suggestions, a toolkit of sorts, to help you build service design into your practice. First, consider mapping your service ecosystem to better understand your service and the totality of it. Include all the touchpoints and interactions and try to cluster them by context. Second, identify your high-impact use cases. The ones where you know improving those will drastically improve your service. Understand how these use cases might cross channels and touchpoints for your customer. Third, get the right people in the room to create a complete end-to-end understanding of your use case and create a service blueprint. Lean on any real data you have to make this as accurate as possible and generate true insight. Fourth, as you drill down into the steps of your experience, capture any questions, moments of truth, opportunities that become apparent and make a plan of action around those. And lastly, once you have a vision for your new and improved service experience or a new service, test your improvements through simulation with real clients. Focus on the minimum viable product to test as rapidly as possible. So this is by no means a comprehensive introduction to service experience design, but it's a place to start. I hope you consider adding aspects of service design into your practice and into the fabric of your companies. I've compiled some additional resources to help you get started, if you've been inspired today. So join me on my journey into service design, and thank you. If you have any questions, please use the mic because I think they're recording. I explained everything so well. Is anyone doing a service design in their agencies or practices with clients? Anyone else? How many people in the room are designers? I'm interested. Okay, great. A question, hi. I've got a question. So I'm assuming you didn't do this whole process from the beginning of offering your service? No. So when did you get to the point where you decided you needed to start taking a step back from the design and looking at the bigger picture, and then how did you get the buy-in to do that from management? Well, I got invited to speak here and was like, hey, I wanna do service design so I can talk about it. So that's a really good question. And I think for me, as I kind of illustrated in my journey, it was, things started to become painful as a designer. And it's almost like responsive designs. Like you squish your browser to like, oh God, what's going on, right? So we grew our team until we were like, oh God, what are we doing? And I think it's that moment where you realize that customers coming to you don't think of your product the same way you do. They think of it as you were late responding to an email or you gave a great talk or you helped them with a problem or you made someone else a website or they think of it from this holistic perspective because that's how they experience things. It's just their life. They just experience what you offer in their life. So once your product kind of goes beyond that and you're now looking at this experience, you need a different tool set. And for me, I had to kind of learn this other tool set and this is just my first kind of dabble in this. I'm hoping to go much deeper, but yeah, it is a different tool set than the UX tool set that we're used to or the visual design tool set. As far as buy-in, yeah, it's talking about the problems we're having honestly and kind of opening that dialogue with my team and my manager and all the leadership and other people we work with were part of a larger central IT unit. There's about 500 staff in university IT at Stanford. So yeah, it's a bigger conversation and Zach and I have started a community of practice on service design at Stanford. And we actually were surprised how many other people around the university are either doing this already or thinking about it. So yeah. I have a totally separate, shorter second question. How often do you pull your survey your users and how do you adapt to those surveys? So far, it's just been kind of once a year. We wanna do like a post-launch survey, kind of a satisfaction survey. The help ticket data we've been looking at kind of in an ongoing way for the past year. We don't have a tool yet to track that data with like metadata. So we were by hand cataloging all of our help tickets. It's pretty painful right now. So yeah, one of the big lessons from this was like, oh, we need to work on our kind of embedding data collection into the fabric of what we do. Yeah, yeah. Hey, that was awesome. We're actually starting to use some of the same kinds of templates or just starting, not nearly as deep into it as you're getting. But one of the things that I'm curious about is I mean, I don't know how close you are to your user base. I mean, I know that Stanford is very big. And I'm also curious whether they are sort of, whether they have a choice. In other words, do they have to come to you? Yes, they have a choice. They have a choice. So they can go outside of the university and have somebody else do the project if they want to. And then, so that kind of leads into the second question, which is, how easy or hard is it to sort of gather the information for your mapping? Because that's something that we've really run into a problem with. The discovery process of, I mean, you can draw sort of conjectures or you can ask the people on your side of the equation who are involved in the process, what the map is. But without talking to the actual customer about what their steps in their process are, it's not gonna be accurate. Yeah, so one thing I've seen Adaptive Fast do really well is customer journey mapping as a format for user interviews. So you could collect 20 customers that are willing to come sit with you for half an hour. Even getting them to come sit with you. Right, yeah, and incentives for that, come up with incentives. Coupa gift cards work pretty well at Stanford. But yeah, so you could do customer journey mapping. I'd be interested in doing that. We haven't done that yet. We are pretty close with our customers. We hear a lot about how they're using our product and we hear a lot of stories. So I was able to leverage the knowledge from my team a little bit more than you might in some other situations. But yeah, you're painting as much of a high fidelity picture as you can. And so you wanna use a bunch of different data points to triangulate at the reality. So the qualitative customer journey mapping might be a really good one. And then you've got your team and all their expertise and then you've got your analytics data and together you're gonna point at kind of the real thing. I mean, you could probably spend, actually Eric has spent a year making a service blueprint into it. And he's been sharing with me his process and I've been learning that yeah, you could spend an endless amount of time doing this. For me, I was trying to do this as rapidly as possible. I literally had one hour with my team to get all this information for the service blueprint and then also my own research and knowledge. The other thing you can do is try to recreate all the steps yourself. Pretend you're a customer, make yourself a customer account, be a fake person for a day and just try to do the thing. And that'll get you pretty far actually. Yeah, we've done some of that. Do you also, one other question, do you do contextual inquiry with your existing? I would like to, we don't do that right now. But yeah, so contextual inquiry if anyone isn't familiar is basically like kind of fly on the wall observation. So you go out and like observe your clients in their real habitat and watch them work on your product or interact with their office mates or whatever. And sometimes you could spend a couple hours with them shadowing them collecting data. Yeah, that would be another really great way to do it to get that data. Cool, thanks. Thanks. I know you touched upon it, especially with the first question there about surveys and collecting data and everything like that. It seems like a really important part of the process. I was wondering if you could expand upon what's been the most effective, what maybe you found out wasn't as effective as you might have thought and how you, and you also brought it up, how you built that into your process so that you can continue with the iteration and use the data going forward for the next level of service. Yeah, that's a good question. So in data collection, what's most effective? I think what I found is that different types of data give you a different level in that zoom. So the help ticket data analysis we've been doing is super minutia level. It's like people didn't understand the wording we had on the clear my sites cash button. And we figured that out because it was this number two help ticket request was like, why is my site not showing my updates? Clear the cash. But yeah, we have a sign on our wall. I'm sure every one of you does. Anyway, but yeah, so I think the help ticket data and probably that really nitty gritty data you might get from analytics will give you really specific insight. If you want the bigger insight, I've found that the qualitative, the stories are better. So the hearing from your customers, talking to people, interviewing them, because then you get this context of where they're coming from in their world and that's that bigger context that you're trying to get that bigger level of zoom. So I think it's all useful, but it might be depending on what problem you're trying to solve or how much time you have to do the work. So help ticket data analysis helped us identify really small little things that just turn into like, oh, we could fix that tomorrow, but the other stuff is bigger. So then you have to really decide, okay, we're gonna sync a bunch of time into this bigger story. Thank you. I work at a university library. So this was actually a very much welcome approach because this is of course always the question of the day that the users can't find the stuff and they come in here looking for the stuff and they don't know what your labels mean. That's a great context. So there are like multiple types of users, multiple types of services, the type of user, the same person, maybe a different type of user on different days. And I guess my question is, we have experts that are in the face-to-face channel, Google Analytics is our expert in the online channel, but what would you say is the role of personalizable experiences? So how much does a user need to know about themselves to get themselves where they need to go? Wow, that's an interesting question. Personalizable experiences, yeah. So we don't do that as much with our groups. I don't have a lot of direct knowledge there, but I think that's something, are you wondering about introducing that as a part of your service offering or do you already do that? We have a very just static, I would say, Drupal site. And so there's just navigation and we have a few sections that say, if you're trying to do this, go here. But there isn't that, when you hit the site, that's not what you see first. And my question is, is this something that you see that as working into service experience, being able to sort of guide the user in self-direction? I think you could do a discovery project on that vein, kind of talking about the customer journey mapping or interviewing where you can collect a pool of this variety of people that you serve and ask them really kind of insightful questions to poke at that issue and even ask them directly. Like if the website knew you were a faculty and provided you with this one thing, would that be helpful to you? Because I think, if you can paint a picture for them, they'll be able to respond to it, that's what I found. I think that there's, that's a really interesting idea. I don't think Stanford Libraries has done anything like that, but I know that there's very advanced search functionality going on in the libraries at Stanford that I've seen evolve over time. So the balance between knowing what you're looking for and predicting what your user wants, yeah, that's, I mean, all of us are gonna struggle with that. I think, yeah, coming up with maybe some really good questions to ask your users to figure out if they would be interested in personalization and what that might look like, it might be a good place to start. Okay, cool, thank you. Well, thank you guys so much. I know I ended a little early, but hopefully more time to gab and chat, come up and talk to me, thanks. And remember to rate all your sessions. Go to the schedule.