 All right, so it's one o'clock, so we'll get started. Hello, everyone, and welcome. Thank you for coming to this session. This is the big picture, how UX affects almost everything. And I am Mary Albert. And this is Charlie Kreitzberg. Hi. My colleague. So we are from Princeton University. We are the user experience office at Princeton. And we just got chartered this year. We've been in office since January. We've had plans laid since before then, but we've been active since January. And our mission is to promote UX throughout the university and help it become a core competence within our own organization, within the Office of Information Technology. And Princeton is a Drupal shop. We have 300 Drupal sites that are in or very close to being in production right now. And we offer templated and custom designed and developed sites hosted at the Aquia Cloud. And our main site that we call the core site is in the process of getting redesigned. And that will be our first Drupal 8 site. So we're in that process right now. It's very, very exciting. So that's us. I'm curious as to who you are. How many of you do UX as part of your job? OK, that's great. And those of you who aren't UX people, I'm just curious about the other sorts of roles that are here. If you can just maybe shout out a few of your roles. Any developers in the house? Any managers of development teams or design teams here? All right, great. Anybody just strictly on the business side? Money. OK, one, two. OK, important and very important people. All right, great. Thanks. So we took this quote from Google. We wanted to start off with this. 10 things that Google knows to be true. And the very first one is focus on the user and all else will follow. Google focuses on the user first to ensure that everything is designed to serve you, not designed to serve their internal business processes. Really like that. We are user experience advocates, as you can imagine. And so we agree that a comprehensive and relentless focus on the user may be the most important thing that you can do to ensure the success of usability in your organization and ensure the success of your products and your services. But we also understand that making that happen in the context of an organization within the context of organizational projects is difficult and complex. So what do we do about that? We have been working on a framework, which is what we want to share with you today, called Lucid. So we started this project to organize the entire range of UX activities. So this is a work in progress, but it's far enough along that we have things to share with you. And we'll give you a website where you can go to get detailed information and be able to use the framework. At this early stage, we do know that having this framework is already valuable to our mission and to the work that's being done within our organization when we develop sites and develop applications. And it's important that we present this framework in our evangelizing about UX and institutionalizing our practices at Princeton. So we want to share with you these initial activities that we've been undertaking. But upfront, we also want to ask this question, why should you care about that? Well, we think you should care because we think that it's potentially valuable to you as well. So having a framework helps you organize your UX activities and integrate them within the larger scope of your projects. But in addition to that, it helps you communicate both within your team and with your external stakeholders, all the people outside of your team that you need to make happy in your work. So we all know UX is the key to user satisfaction. That's where it starts. And that's really important. We know that when you integrate UX into your project, you produce better results, more usable, and more interesting products. But what we are learning is that UX is a lot more than just customer satisfaction. As we've gone through this, we've started realizing that there are additional dimensions to UX that were not immediately obvious to us as we started. And perhaps the one that was most important to me and maybe most surprising initially is that UX enormously improves team performance. One of the big problems that teams have is that people tend to have in their head not necessarily identical visions of what the project is, what the outcome is. And as a result, you get a certain amount of churn. You get a certain amount. As you go down the road, these divisions start to emerge. And they can lead to problems with decision making. What we've found is that going through a user-centric design process, which is largely built around wire framing and pictures, improves communication within the team and with the stakeholders. So that while words can be slippery by sharing wire frames, sharing pictures, everyone clearly sees what's being proposed. And when you go to a stakeholder and end users and you show them wire frames and prototypes, you get a level of clarity, which really helps people work through the scope of the impact of the project on them and on processes. So better alignment, clarity, and communications lead to better decisions and better project outcomes. I don't have a lot of numbers yet, but I have been told by some folks in the government who began to switch from traditional technocentric processes to user experience processes that they were getting projects done in about a fifth the time that it was taking. So UX also crosses organizational silos. So while we focus on websites and web applications, it can be easy to forget that the customer actually has several touch points with the organization. And all of those interactions with the customer, regardless of the channel, need to be managed. They need to be carefully engineered so that the experience for the customer is optimal. So what does this mean for you when you've got to get your website done, your web application done? Well, it means that there are people who are outside of the immediate design and development project team. It brings them into the project. And that mix is dependent upon the project, but it could include people such as marketing and communications, the training folks, people in customer service, those responsible for fulfillment, the legal department, among others. So all of these aspects need to be coordinated so the user has a seamless and a coherent experience. And that does transcend organizational silos. UX is also a strategic opportunity. How you design a site can affect who you attract, how they engage with your organization, their sense of comfort, their feelings of trust, how they compare you to your competition, and the impressions that they leave with. But if you understand your organization's strategy, you can design and help to achieve it. So for example, at Princeton, we're very concerned about information security. It's a critical element of our IT strategy. And the way that we use UX to help ensure information security is to ensure that they're designed in ways that prevent people from making errors that they otherwise might make. We're also using UX to try to ensure that we're creating things that people want to use, because they will find workarounds. They will use other applications that are not vetted or considered secure. And they'll put that information out there in these applications or in the cloud in ways that really expose the organization. And so that's one way we're tying UX to the strategy. And you can do the same. So pretty much every project, let me say if this is probably true for you, involves a cross-functional team. You've got developers, you've got business people, you may have UX people. Is there anybody who would say that isn't the case for the projects that you work on? So everybody is coming into these projects with a somewhat different perspective. And one of the things we found in our early work is that people who are not UX people really were not understanding the processes at all. They had no ability to really see what the big picture is. And because they didn't understand what the big picture was, they didn't understand where they fit into it. So we found that there were a lot of people, for example, who thought that UX was a task. And you had not a process, not something that's integrated into the entire project, but something that you have to place. And the argument would be, well, we'll do that at the end. We'll find some place. You can come in and you can do the UX. We also found many people who didn't understand different kinds of design. What's the difference between visual design and interaction design? And we're unable to make those distinctions. So what we realized is that to achieve the benefits of UX, we have to bring everybody involved, designers, developers, stakeholders, legal people, marketing people. We have to bring them all to understand the same big picture. That way, they will understand how they fit. So that basically was the problem that we ended up with was how do you communicate the big picture to a diverse group, which includes all of these different kinds of individuals. And that's the problem we set out to solve. So we started out by looking at frameworks, methodologies, and processes that other people had worked out. And what we found is that most of them organized UX as a collection of techniques and templates that could be applied to a project. And that's great, that's not surprising, because a focus on technique is really valuable to UX practitioners. And we think of those as UX in the small. But what was missing was a way to look at UX comprehensively and to get this bigger picture that would benefit the entire team and the stakeholders. Yeah, there have been a number of attempts to put diagrams together. This is one that Dan Saffer wrote. And it shows relationships in UX. And one of the things you can see about this is that if you're a UX person, this probably makes a fair amount of sense to you. If you're not a UX person, it's very daunting. And really hard for you to see how it fits. And there are other well-known diagrams out there. Jesse James Garrett has done some really nice work. Peter Moorville has some diagrams out there. If you haven't seen them, you've probably seen them and they're all out on the web. But they all have that basic problem, which is that they're meaningful to the UX practitioner but daunting to the ones who are on the outside. And that was one of the big insights that we had was we originally thought we were trying to pull a framework together for UX people. And what we realized is UX people don't need this help. We already know how the things we do fit together. It's the people who are not UX practitioners that are struggling and they're the ones who really need the framework more. So there's a standing joke in the UX community. You might recognize this. Every question has the same answer. It depends on context. It depends on exactly what you're trying to achieve here. It depends on a lot of different things. But it's true because every question has a lot of considerations in UX. It is complex. And it makes sense to the practitioner, as Charlie had said, but it doesn't make as much sense to people outside the field. And those are the people that we also need to ensure the success of what we're doing. Yeah, we also found that it drove developers nuts when they got answers like it depends because there's a cultural gap here. You have people who make their whole world is built around ones and zeros and things that are either on or off. And you can't have a hand-waving argument with a computer. I mean, computers are going to always be precise and you're always going to have to make a decision about what does a statement look like or what is a conditional like, things of that nature. And so when UX people are often kind of artistic and fluffy and you end up with conversations that are very difficult to bring to the same level. And I'm somebody who's actually been through both worlds, I started out as a developer and moved into UX because of my interest in psychology and wanting to bring computers to people. And I believe that the principles that underlaw UX are absolutely as, I don't want to say as rigid, but they're on solid ground from a scientific point of view. We just don't tend to explain where they come from or why those decisions are made so that if we could begin to close that gap and begin to explain for example to developers what are the underpinnings of UX so that there are, you can apply algorithms to make decisions about design that that would become a very powerful tool. So we decided to build as we've been saying a UX framework, what do we mean by a framework? A basic conceptual structure that defines activities and flow. It shows how activities interrelate and it serves a scaffolding. We did a little bit of analysis about the difference between frameworks, methodologies and processes. And let me ask you Mary if you could talk a bit about that. Sure, okay and we drew this so that it would become clear in my mind. So we picked a framework over a methodology or process because we wanted flexibility. Every project is different in some significant ways and so we wanted something that would provide structure and guidance but that wouldn't be so rigid or so prescriptive that you couldn't find it useful in multiple types of projects. Methodologies are prescriptive and processes of course layout specific steps to follow. And so the goal in producing the framework was to apply it to the widest range of projects and I will say even going beyond our website and web application development projects to projects where we've got to do UX for cloud solutions. Also we're looking at how we design services not just interfaces. So the framework can be applied in these various ways. You know the framework also in our environment has to be equally applicable to products that we're developing from scratch as well as products that we're purchasing from vendors and configuring and integrating. And that turns out to create some really interesting problems because you clearly don't have the same level of control when you're working in third party environments. So we need an acronym and the acronym for our framework that we've come up with is Lucid. And let me just mention the origins of this. The L stands for logical and what we mean by this is that we want a framework in which decisions are made using critical thinking. Not voting, not opinion, not power plays but when you're making decisions about design and the way things are going to be done we'd like those decisions to be made in a very straightforward and critical thinking way that's not always easy to do in an organizational setting because organizations are highly imperfect, people withhold information, they lie, they have hidden agendas and they're trying to influence you and create bias in all sorts of ways and you're usually under a lot more pressure than is reasonable with less time and less resources to get the job done. And so adapting, keeping logic as a piece of this can be very difficult and it's very essential. The second piece is around user centricity, you see. And what we mean by user centric design is around a value system. Every decision that's made, we take value judgments about what's most important. We believe that when you're going through a development process that the user should take primacy. We call this people first, which means that if there's a difference between, if there's a choice between a technical win, a user win or a business win, we will generally try to favor the user even if that creates a little bit more work on the business or the technical side. You can't always do that obviously. But that does lead you to the kind of results that you're going to want. And finally, the ID stands for intuitive design. And that's one of the cores of UX. What do we mean by intuition? We mean that the user has a mental model and that when the design of a website or an app is in agreement with that mental model, things work the way the user expects it. And that creates the least amount of load on the user, the least amount of work and the most usable interface that you can have. So logical user centered intuitive design. And of course the word lucid means clarity. And clarity is what this is all about. Clarity to the user, clarity within the team and clarity to your stakeholders. So I want to talk a little bit about how lucid evolved. Lucid was started in the 90s. It was first developed by Charlie and his colleagues to help organizations understand UX. And you can Google lucid and you will find the old model and it's something that has been taught in universities and taught in businesses. But in the 90s, there was a waterfall world and so lucid was conceived in a stage model. Now we're in the 2000s and many projects are using an agile approach. And so the new version of lucid is a lot more obviously iterative. Yeah. So here was the first thing, one of the first things we found that surprised us and seemed to make a lot of sense is that user experience actually has multiple dimensions. And we had started thinking about UX as sort of this single unitary thing that we could look at. But as we began to comb into it and do our research, we really became more comfortable with the idea that there are different aspects to UX. And we came up with these three key dimensions which we call project, design, and strategy. And what's interesting is that each one draws as its basis a different foundation. Lucid project draws its foundation from project management. Lucid design, which is about what do you put on a screen and how do you arrange it, draws its basis from cognitive psychology and cognitive science. And Lucid strategy, which talks about how your designs fit into the larger organizational context and how they drive the organizational, the organization forward, come from organizational effectiveness thinking. So UX spans those three areas. So let's start off by taking a look at the project focus. And this is where we've started our work and what we've been working on for largely the last four or five months. And it's around managing UX activities within a project and drawing on project management as a foundation. Now Princeton has a very sophisticated and mature project management methodology. It's not radically different in any way from any other standard project management methodology that you would find the sort of thing that's from the Project Management Institute, Princeton or any of these basic methodologies. Some projects are agile, some projects are waterfall. So what we first began to realize is to bring UX into the process, we need to begin to integrate it into the project management process. And we have to find a seamless way to do that. And the major thing that came out for us was that to be effective in a project management context, you've got to divide UX into two separate streams and they're two parallel streams. We call one the envisioned stream and the other the implementation stream. And as you can see from this diagram, the two streams continue in parallel but the envision is really heaviest first and the implementation is heaviest second. And it really comes down to draw before you build. I mean, that's the essence of it. And let me turn this to, I'm going to show you the same diagram in a somewhat more sophisticated view. Okay, so here you can see how we currently see the envisioned and implementation process. So the input to this are the business case or the project charter, which justifies the initial project. And there is data that we can take from that and bring it into the envisioned process. And what we have here is an iterative process that results in the development of what we call a concept prototype. Now that concept prototype could be as simple as a deck of wireframes or as sophisticated as a fully operational interactive prototype but without a whole lot of data behind it. And what you can see underneath the envisioned process is that there are sub-processes, discovery, which is around understanding your users, their requirements, the context of use and all of those kinds of things. Selection, which can be around technology, platform selection, vendor selection, purchasing of various kinds of software elements and visual design, which is what puts the gloss and the look on the projects that you're building. So you go through that process iteratively, bringing user testing in there, and of course this is standard UX. I don't wanna suggest to you that what we're doing is in any way different from standard user-centric design but it's also something that we're finding a lot of people do not understand or how it fits together. So the concept prototype then is delivered to the detail into the implementation area where detail design takes place. Late stage changes or screens that were not developed during the original envision process are taken, they are implemented and you then go through your release cycle. This can either be a waterfall or it could be an agile iterative kind of environment. So the second area of the framework is design and as we build this area out, we're hoping to clarify and explain the principles of interaction design and information architecture in a way that's meaningful to non-UX professionals and the basis of the design area is cognitive psychology. So understanding that the human brain has limits and it has needs for information processing. So we know that both developers and business people struggle sometimes to understand what is it that makes good design and on what should you base good design decisions. Well, we think that those should be made on cognitive psychology and we think that we can build out some relatively simple models of human information processing that will help people understand these basic cognitive concepts such as perception, attention, memory, cognitive load. You probably know Steve Krug's Don't Make Me Think. Well, that's a statement on cognitive load. So we want to, by teaching these underlying principles and helping teams to understand them, we can help the team to understand why decisions are being made in projects and why design decisions are being made and essentially that good design is based on brain science, not on opinion and not just on art. And then the third area of our framework is strategy and recognizing that design really interacts with strategy at multiple levels is a valuable insight that we've come to and we see the strategy working at three different levels. So the first at the center, the strategy is around UX applied to the individual project and the team. What's my strategy for getting this project done? What's my strategy for working with vendors? What's my strategy for having the resources necessary to get the project together? The second level is around the business context of the project. Every project carries with it, most likely it transcends the silos and connects with other business processes, other projects, other things that are going on. And very often we tend to look at a project in a rather narrow way. When we start looking at it strategically, we start saying who else needs to connect with this project? What are the processes? What are the projects? And how can we make the interactions across those other projects as effective as possible? And then the third level takes us into the organizational strategy, which says as an organization, we're trying to move in a certain direction. We wanna understand how to get there. The question is how can the designs that we're building facilitate and drive organizational change? We've also been working on a model for what I'll call UX maturity. As Mary mentioned at the very beginning, our mission is to create UX and make it a core competence of Princeton University. That is something I think that many organizations now wanna achieve. There's a lot of talking about design thinking in organizations. I'm not 100% sure what that means. I'm not sure a lot of organizations are sure what that means. But going through that is a process in and of itself. So we have identified six stages of maturity within the organization in terms of how they use user experience. It starts at the bottom with organizations that are UX unaware. They don't know anything about it. And then typically what happens is that somebody in the organization becomes aware of it. They kind of push it. They become a champion for it. And you get little bits of ad hoc UX appearing in projects. And ultimately, if that person or those people are successful, the organization decides that, yeah, maybe this is a pretty good thing and it tries to start integrating UX in a regular way into its projects. The next stage of maturity takes it up to where it starts looking for connections across projects, particularly true, I think, in places where there are retail or very customer-centric sites and we think about customer journeys so that there are multiple touchpoints. All of those touchpoints need to be engineered so that the UX is really good there. And that brings in all sorts of different departments, divisions, crosses the silos and enables you to look at that project in a wider business context. Getting very hot now is strategic UX as organizations are starting to say, how can we benefit from UX as a strategic focus? So beyond simply the business UX, now we start to look at UX as a strategic driver on its own. And that leads us ultimately to the final stage, which is UX culture, which is the sort of thing that a company like Apple would claim, where user experience has become so inculcated into the culture that everybody, every engineer, every salesperson, everybody thinks about UX in pretty much all the activities that they're involved with. So I'm curious, let's stay on the slide just for a minute. I'd like to poll everyone and see who here is lucky enough to work in an organization that has a UX culture. Oh, yay, okay, a few, where the rest of us will get there. You probably recognize where your organization is in this maturity chart. Anybody with a strategic UX focus in their organization? Okay, down on, okay, let's see if we can find the norm. Business UX focus, a few, okay, I'm starting to get a little bit nervous. How about project? How about focus on UX and the projects? Okay, that's where we are too, so. Yeah, and that is sort of, I mean, I think for most of us, and where a lot of this is coming from is how do we move things up to the next level? And what I think the position that we're taking is that you can't do that if you can't explain it to others in a big picture kind of way. Because we're in the weeds and we do understand how to do these things, but it's very difficult to explain them outside. And yet we're so dependent on those outside of our areas of expertise. So where is all of this going? I can tell you that locally where this is going is that we are building out templates, we are building out training, we're building out tools in order to teach all three of these areas of Lucid. And we're already integrating Lucid into a few of the key strategic projects in which our office is involved. But we can't be involved in every single project and we need to institutionalize practices. So by providing the framework and by providing these templates and tools, we would like teams to be able to do the work themselves. They can't always rely on right now a very small office. We're also intending to make this open source so that it's available to everyone for free. You know, can share it with you and you can share it with others. And we would like input from anyone who's interested because the more ideas we have and the more ideas that we can integrate, the better, it's stronger. We think that we can make this and the more useful we can make it to everyone in the community. So in institutionalization, we're hoping not just to institutionalize with us but helping others as well in your organizations to institutionalize best practices for UX. So let's move on. So we hope the framework will help you organize and manage your UX activities. We've given you ideas today. You will also have access to our work on our website and you can email us. We'll put up all of that contact information. We want teams essentially to focus on UX when it matters to focus on UX. And I would argue that when it matters is from conceptualization of the work and then iteratively all the way through delivery and post delivery as well. But it matters at all points in the project. It's very difficult to come into a project and put some lipstick on it at the end and try to help a team feel better about the other work. But if they're not principally focused from the get go on what is important and what is agreed upon in the team to be important which is the customer. And the person who needs to actually use that website that you're designing and developing or that application that you're designing and developing then you're sort of across purposes. So these templates and tools we're hoping will help people to recognize the criticality of considering the customer from the get go and then frame out their project and plan their project in order to accommodate that. So we also want this framework I think we said before we're trying to keep it as agnostic as possible and we want it to be flexible so you can take it and use it and apply it in ways that make sense for you and for your projects and your organization. We also hope that the framework will help you to become a teacher. Most of you said you were involved in doing UX activities. I think that one of the things you really need to do as a UX practitioner is you have to teach people all the time. You have to explain what you're doing and why you're doing it and what you expect from them and what you need from each other. And these are all very basic kinds of things which are very difficult for people outside the UX. It just looks like a blur to them. And as we said earlier, like this big collection of techniques that you could have said, yeah I grabbed this one and you say why and you say it depends. And they don't really know what to make of that. So we're hoping that by having these kinds of frameworks you'll be more effective in your ability to understand and communicate the big picture to the people who are not directly involved in UX and that you'll be able to more easily integrate UX into the project management process. So we begin working on the UX framework about four months ago. We've made a lot of progress but it's clear that we've got a couple more years of work before we're able to pull all of this together. Our goal is that what we'd like to have is a comprehensive framework that really takes the entire field of UX, the project management, the design and the strategy and integrates it in a way so we can lay it all out and you can see what all the kinds of activities are and how they might be used without in any way becoming overly prescriptive and telling you how to do them or which ones you must do because some projects are big and some projects are smaller. So that really is the intent of the framework, the Lucid framework that we're putting together. If any of this is interesting to you we'd really like to invite you to connect with us, collaborate, contribute. We have a website which is ux.prinston.edu so it's really easy to remember. It's in its early stages, we're starting to post materials on it and Mary and I are both available at these email addresses and we would really love to hear from you. Both in terms of materials you might need that you'd want us to share with you or materials that you've developed or ideas that you would like to share with us or suggestions that maybe we're on the wrong path in some cases and that we should take a different path from the one that we're on. We're at the beginning of a road that we think is going to lead to something very valuable and very useful. Yeah, we are to also remind you that sprints are tomorrow and since we know they affect almost everything about Drupal we'd like to urge you to attend if you can. So we have some time available to have discussions of this so if you've got ideas, questions, we'd love to hear. And we encourage you to share your feedback. Yes. We would really appreciate it. I'll just come around or if you have a question kind of line up a little bit so that for the value of the recording if you don't mind. Yeah. So you've been doing this for about four months. I'm just wondering if you've taken this to the different groups on campus or whatever and what their reception of it has been. Do you wanna talk about our project with the communications office and the envision process? Yes, we've been taking it to groups on campus. We've gotten mixed results. In some cases we've had a lot of improvement in the race of this and a recognition that this kind of thing is really needed. On the other hand, there are a lot of people who have been doing things a certain way for years after years after years and they're finding it very difficult to accept the idea that maybe there's a different way of doing it and that way is going to be better and faster and easier and cheaper. So that is a power. One of the big issues we're really having now is getting people to understand that envision must proceed implementation. We're seeing that as the, we're trying to bring this down to really short ideas that we can communicate. One of them is people first when you're making decisions and the other is draw before you build and we're figuring if we can get those two ideas across will really begin to have a foundation that we can then use to be able to create a UX culture. And I can tell you how we're trying to communicate draw before you build. So we have a lot of system architects in our organization and if you walk into any conference room and see the whiteboards are covered in these gorgeous diagrams of the back ends and infrastructure and they are, they're almost like works of art. And so, you know, those teams are talking and drawing out their ideas for the back end. We just want to bring that same sort of technique to the front end. And so we've got people who don't do front end who do know how to draw those back ends, but if there was a single thing that I could really get across this year to people in my organization, it would be draw wireframe, do it in low fidelity if you need to, but get the people on your team to agree to what's in that wireframe before your programmers and before your designers really need to work on it. Yeah, I completely agree with the draw before you build a concept and very low fidelity drawings can go a long way and it can be very iterative. But when you are trying to sell a design or a concept, sometimes you need to have more high fidelity designs, especially for higher up people who are used to getting very flashy, shiny pitches from the other vendors and stuff like that. So something like Dries in his keynote, the interactions around contextual editing and things like that that were kind of design fictions, but they were far enough along that everybody could get it. So you kind of need to have more than just the UX designer. You need to have a pretty good ability to convey those messages also in high fidelity as well, right? Yeah, I think every project is different and I've gotten in trouble going both directions. So I've had the experience where we've gone the route of building beautiful high fidelity wireframes and prototypes, which is always my instinct. I like to do that. And what happens is that you get into a meeting and people start picking knits on the tiniest little things and they can't seem to go back. So then I've shifted with one particular client, I shifted to a low fidelity prototype. I started using fonts that looked more like handwriting and sort of brought that informal look in there. And they loved that, but they weren't making any good decisions out of it because it didn't force them to confront realities of screen space and things like that. So I have found that both of those techniques can lead you into a bad place. I was gonna tell you something else which went right out. Oh yes, the other pitfall around that is around visual design. People love to critique visual design. They love to go in and argue about the colors and the way you've done things like that. And very often if you go in with a high fidelity prototype that has good visual design, what you find is that people then get into that, which is really a comfortable place for them to critique and you don't get any good feedback about the designs itself. And so what I've also learned to do and we're building into, it's one of the reasons in that diagram, visual design is separated from the other sub-processes is that we find it's useful to build wireframes that have visual design that are separate from the design of the site itself. Then they can go in there, they can critique the visual design, they can make all sorts of stuff and feel good about that in design meetings and then we can draw them back into talking about the site and how what the information architecture and navigation and presentations are going to really look like. So it's more of a mood board approach and satisfy that hunger and that need and then keep focus. You know, we use different tools. So we're balsamic for wireframing. We also use Lucidchart, not connected with Lucid at all. So we really try to target depending on the stakeholders and what we have to accomplish in that project. We're also working right now, where as Mary mentioned, we're in the process of redoing 300 Drupal sites plus our main core site, which is a pretty large site and we're working with designers who are external and you have this problem of how do you convey design concepts without stepping on their toes? And one of the problems I have often found with designers is that if you give them something, they very quickly become attached to the drawing you gave them and they just make it prettier and prettier, but it might not be a real good drawing because we're not necessarily the best in the world at doing that. And on the other hand, if you don't give them a lot of guidance, they go off in directions and you may lose really valuable time and resources in not converging. So we're now playing with this notion as to whether there's sort of a very high level wireframe that we can build that doesn't incorporate visual design but is really based around talking about the different kinds of objects on the screens, their hierarchies and their relationships that we can then hand off to designers and say, what could you do with that? How could you make that really neat? And that's an experiment in process right now. So we're just a few minutes over time and Dries will be speaking here. We have another 11 minutes. Oh, we have 11 minutes. Okay, good. We're not over time. Sorry about that. But stick around because Dries is speaking in here after we're done. The only thing I do wanna try to emphasize, thank you so much, but Drupal Khan has asked us to please remind everybody to please give you our feedback. I'm sure you've heard this at every single session. So there's the URL right there. So thank you so much. Thank you. And we'll stick around. If anybody wants to come talk to us.