 Thanks for coming. I know we're the first session right after lunch. Hope everyone had a good lunch. Hopefully someone left me a vegan box. No, I'm just kidding. I did actually get one, so I've already ate. But yeah, thanks for coming. So we are Jesse and Hank. We're going to introduce ourselves real quick. And we're going to talk about the art of discovery. Our aim today is to shed light on this critical phase of a project lifecycle of discovery, where it sits in the creative process, how design and technology converge to unlock innovative solutions. So as I said, my name is Jesse. I am a solutions architect and a team lead at Evolving Web. My background is in full stack development across various open source platforms and with Evolving Web, I work on a ton of different projects that involve pretty exciting and fun impacts, including higher education, which is what we're going to be focusing a big part of our talk on today. So I have a slightly different background than Jesse. Actually, my first time at DrupalCon and also new to this industry. I've at least been working at the Evolving Web for a year and a half now. And before, I've studied the industrial design, something very different than most of you did. And I've been working in the field of design communication and production since. And before joining Evolving Web, I've worked at an exhibition design agency that was specialized in immersive visitor experiences. So I was working with very different technologies, very different dimensions even, and using different tools, of course. But in essence, I was contributing to what we're all doing here. And that is crafting experiences, using content and technology to transform audiences. So like I said, a while ago, I've joined Evolving Web. I think most of you know our company. We've been around at DrupalCon for a long time. And so I renewed my focus to creating digital visitor experiences. And as you know, Evolving Web is a full service digital agency. And I have the honor to lead the design team that consists of very talented UX, UI designers, content strategists, and UI designers, and art directors. And I'm really honored to be here and also to speak on behalf of them. So everything that I'll be presenting today is what I've learned through working with them and through being involved in projects with clients. So I'm really thrilled to show you some examples later. So at Evolving Web, we create websites for large institutions that serve, like in total, like hundreds of thousands of people maybe every day. A lot more than fit in a museum, for instance. So I'm really excited that we can work on these big projects for governments, for health institutions, for tourism, libraries. And in fact, we have a lot of experience with working on higher education websites as well. So as you know, higher education is a highly competitive domain. So I've met many people at DrupalCon already who work at universities or building, maintaining their websites. And as it turned out, it's for a good reason, because more than 85% of prospective students, they see the website as their primary source of information like before going to university or even while they're at it. And I don't think this comes as a surprise to most people in the room, but most people are using their mobile devices for all of that work. For the research process or the research process of what they want to attend in a higher education and the application process. So we have this quote where about 70% of students are using their mobile devices for this. Like I said, I think pretty much everyone in this room would completely understand that and not only surprising. So higher-end clients oftentimes pose some unique challenges that some of the clients might not. And we sort of group these into a few different categories. We think of them as technical, operational, and design challenges. On the technical side, there is things like compliance. We're always thinking about accessibility. We have to consider the long-term maintenance of a project, future updates, content, how that's going to evolve, and all that kind of stuff. We have a lot of external integrations as well that we have to think about, like different student information systems, for example, how we can access some of that data. There's also a lot of considerations into how we can tailor the experience for content managers and content editors. We want to empower them, and so how can we do that? On the operational side, we are oftentimes dealing with a large organization, and oftentimes there's many different stakeholders in that organization. Sometimes they even have some competing interests. We might have some pretty specific deadlines. We're usually driven in these cases by the academic year, not so maybe not so flexible on some of those timelines. And of course, these institutions have a pretty large content base. There's lots of legacy content that we're working with. We start thinking about how to handle all of that. And on the design side, with all this content comes multiple levels of navigation that we have to consider. We're also thinking about the brand heritage. We worked on some branding work for a Queen University, a very old institution within Canada that we wanted to refresh that design, but also evolve it into something new. And we're also thinking about the different abilities of the audience, whether that be geographical or language abilities, or otherwise. So we are pretty familiar with working with all these kinds of different challenges, working with higher education institutions. So at Evolving Web, we tackle these by embracing collaboration and co-creation, which is kind of why we're presenting this together. And we think that using effective communication, we can leverage the power of collective intelligence, of all the information that we're gathering, of all this entire process. And ultimately, when we're talking about collaboration, we're not just thinking about within ourselves, but within the larger team, including, of course, our clients' teams. So through all of this, we think that we can get a more diverse perspective, more innovative ideas, and ultimately, a better outcome. So to use that example again of Queen's University, imagine having worked there for like 10 years. You're working in-house on your website, and you have gotten to know it so, so well. You probably have 1,000 ideas of how you can evolve it in its next iteration. And so you're starting this project to work on that. This is your time, and all those ideas are gonna lead up to this new web design project. This is a huge opportunity, and it might even make or break your career with that institution. So those are the kinds of projects that we're looking at working on. So we're talking about the discovery part of this, though. How do we make this process into something that, basically tame this complex process? So our goal throughout the discovery process is bringing clarity and focus to all these challenges, all those challenges that I previously listed, and trying to bring in some structure to that process. So how many of you have seen a figure that looks kind of like this? It's probably familiar to anybody that has worked in sort of the discovery area. This is what this process looks like to somebody who maybe hasn't undertaken it, somebody from the outside. So our goal is to try to break that down into a better process. We wanna get some new insights that will lead to new perspectives and open up new possibilities throughout this whole process. But in order to do that, we really do have to bring some structure to that. So we start to try to do that. We split it up into some more phases. So within these, sorry, within this process, we start to break down this into these different stages where we can start to make sure that we are reaching our outcomes within the budget and the time limitations that we have. If we don't basically have this process, then we start to maybe go off course. We start to discover and discover and discover. And at the end of the day, we don't really have something at the end. So now we're introducing this model. So when I can talk from my experience that I've made that mistake very often and I've learned also from other people's mistakes, there is always more to discover. So if you don't put a sort of plan to it, how you can approach it and where you create moments to explore and diverge and also a moment where you can have to stop the diverging and then start to converge again. If you don't do that, it's gonna go on forever and the horizon is always coming to you and when you're there, you're seeing new opportunities. So it's very important to stick with a plan. So what we apply often here is the double diamond model that's often used in user experience design. And it consists of those four stages. So the discovery, the define, the develop and the deliver stage. And these stages are meant to be iterative and nonlinear. And we can move back and forth between these stages as we refine and improve the design. But it is really intended to arrive at these points between define and develop to create new starting points and to make gradual progress. So for this presentation, we're focusing on the discover and the define stage, which is the discovery. So just to give you a high level overview of the discover stage. So this stage involves researching and understanding the problem or the opportunity at hand. And the research, as I said, is divergent. So it means that you try to get very different perspectives to get a complete understanding of what the challenge is. So during the discover stage, we've gathered a ton of data and ideas. And during the define stage, it's time to synthesize those findings. So we try to refine the challenge into questions that can be solved. And this actually turns problems into opportunities. And at the end of the discovery, we have a very strong foundation for the design and development stage that we'll follow after. So it's really creating a new starting point. And so now we get back to the idea of the art in discovery, which is really about clearly articulating the solution space while keeping the balance. There's a dedicated balance between desirability, viability, and feasibility, not in any particular order. And so it requires a holistic approach and validation amongst the whole time, amongst all the key players in the process. So there's lots of check-ins, lots of working together as one team. And this whole idea, this whole process, this whole performance requires an orchestration of what we call our ensemble. So we have a bunch of different people that are involved in this, including, of course, our key participants from our client, as well as then our UX designers who have focused a lot on structuring all the content. We have our visual designers, the art directors, the UI designers, and they're making all the interfaces much more intuitive with experienced, distinctive experiences that are unforgettable. We have our solutions architects who are working to find a sustainable way that to develop this new site or platform. And last but not least, we have our project managers, the conductors of this orchestra, that are really key to keeping everything, keeping everything moving along throughout the process. So let's get into some of our research now. This is sort of part of the first phase is we're looking at, basically, what are we working with today? What does the existing site look like? We'll probably get some answers from that, but maybe not all of the answers because, of course, this is the time to build something new. So we're not really looking to take everything from there, but we're gonna get a lot from there. And that's gonna include things like the infrastructure, any requirements that are based on that, maybe some integrations, like I mentioned like a student information services systems, maybe what the existing content editor workflow looks like. We certainly don't want any sort of regressions or any stuff backward in that area. We're gonna look at the content structure of the existing platform. So we're looking at the information architecture, the site map and applications, all that kind of stuff. We're also looking at the content types that exist today. So that includes the fields, taxonomies, all that kind of thing. And of course, the components fit into this really well. That's gonna dictate what we have and what we're going to in terms of the different pieces of the website. But as I said, there's only so much we can really take from that old site. At a certain point, we're gonna have to start going towards the new goals and asking a whole lot of questions to get ourselves there. So we're gonna start asking a lot of questions of the content editors and figuring out how are we structuring this new content perhaps? What kind of fields do we need? Is it too rigid? How is that all gonna be structured? We're gonna start looking at what kind of flexibility is needed in some of this new content. As well as then, what kind of components do we need that might get us maybe the best of both worlds between something that's flexible and something that's highly structured? We'll also start looking at the operational capacities that are needed. Maybe some graphic capabilities that the content editing team may have to manage some creation of some elements there. We'll start looking at maybe what their coding or HTML knowledge is. Maybe they can help out. Maybe they don't need all the enhancements that we might add. Or maybe there's something that we can add that's gonna make the experience better for them without having to do to know any code. And we'll sort of start looking at what kind of pain points are there that we can help to address in the next iteration and start to plan for those. We're also working with all of our stakeholders to understand the overarching business objectives and of course the desired outcome of this new site. So we're asking a whole bunch more questions like what exactly do you want to achieve on this new site or what does success look like? These are pretty high level questions of course, right? They're not specifics, but they can help us to focus on the problems. Not only the solution is just yet. We'll get to that later, but we can have a better impact on the outcomes by asking some of those types of questions. We're also looking at the ideas of what to measure going forward so we can understand whether the solution is working towards the desired outcomes. Sometimes we can measure that through things like Google Analytics, maybe there's usability test thing, user feedback, all those kinds of things. So we can start to ask some questions to figure out how are we gonna start to factor in those measurements early on? Of course, what's in scope for our project, right? We don't wanna go back to that continuous loop of discovery and more discovery and not really getting to an outcome. And then all that leads to, of course, the limitations that we have. We'll have some budgetary limitations, some timeline limitations, maybe even some on the teams that we're working with in terms of the resources that are available. So this is where the fun begins for our design team. We're gonna of course do some research in the needs and aspirations of the end users of the website. So we aim to better understand their behavior, their preferences and their existing pain points. And the research really starts with defining who they are. And what we do, we perform very often surveys, sometimes interviews with representatives of these groups and use those outcomes to create descriptions of each user type in which we clearly articulate their needs and their behaviors. So this helps us much better understand their need for information and also to find ways how to resonate with these users. So in order to create those solutions that are intuitive, that are efficient, that are enjoyable for these users, we need to really understand them, their tasks, their context and what they need in terms of information. So because everything that we do eventually serves the needs of real people. So as you've seen, our research takes into consideration a lot of different perspectives, like the client's needs, the user needs, the needs of the team of the client, the business needs. And it is very important to get that sort of holistic understanding of what the challenge really is. Because if you look at all these different angles, you get different outcomes. And to really come up with a solution that fits in that overlay that Jesse just showed, you have to have that, have seen those different perspectives and see how they relate. So I think it would be interesting to look at a very different example that I've taken from my home country. So I was wondering, who of you have come to Pittsburgh by airplane this week? Oh, that's a lot of people. So you've had an experience at an airport. So let's look at an airport as an example. So airports are places that really fascinate me. So for me, visiting an airport is almost like visiting a website. They don't come with a manual and users can navigate those spaces without any guidance. Basically, those spaces are designed so intuitive that you get to your gate and to the point where you need to be. So these places are heavily designed and with that purpose in mind. So the calls that you see are all used very intentionally. You won't see like there are large yellow spaces because these yellow signs have to really stand out. This is what guides the visitors on their way. And so everything is presented on a nice neutral canvas. This is my favorite airport, Schiphol Airport, Amsterdam, of course. And as I'm navigating through that space, I see these signs as calls to actions. It's really guiding me on my way and I find some reward because for me, if I follow those instructions, I arrive at my gate a lot faster. And this gives me more time to relax in a bar, in a restaurant, do some shopping or just relax. And this is also what is in the interest of the airport. They don't want you spending time in lines. They want you spending your money in the bars, in the restaurants. That's what makes them money. And that's also why they advise you to come three hours before you are departure time. But if they do it well, this is also what airports earn their reputation. And what I find interesting is that in the case of Schiphol Airport, this is sort of like seamless transition from the digital to the physical space. Their website is designed as a sort of first stage where visitors can already get familiar with what they're gonna be expecting at the airport. So all of these way-finding principles, they've been applied very consistently over these different experiences. So it's basically guiding the visitors to their destination, adding value on their way and reinforcing that brand at every step of the way. And I think these principles also apply to a higher education website because basically for a student, their study is also the first part of a very important journey, maybe the most important journey of their lives. That is to go from high school to learning your first job and making a very important decision on where you want your development to go. So now we've clearly defined those needs of the users in that research. How can we actually design that journey that takes you to that destination? So we've already covered some of these stages. We've started with our initial research, of course, like before jumping on any project, we reviewed the RFP and we go through every existing material that's available to us in research. We can evaluate these surveys, interviews, and then based on those outcomes, we do more targeted research and really identifying these opportunities and the challenges as well. And then what we very often do is we start co-creating with the most important stakeholders in a project to align these participants also on priorities and opportunities. And I'll give some examples later. And eventually we need outcomes. A discovery has to end up with some clear deliverables that give guidance to the next stage of the project. So I'll briefly cover some of those deliverables as well. And also a strategy like how to implement it. So not only the basis of our next step but also when we're gonna build this, how can we do this and how can we ensure that this is going to be realized in time. So an example from our research that we did for Queen's University. It's, this is a workshop that was a user journey map that we created in this workshop in the breakout room. So of course now everything is going through Zoom meetings and Teams meetings. And basically we're asking participants from the client side some important questions. So we emphasize with the user, in this case it's Hailey, the health and science researcher. So we try to emphasize with her like what is her thinking? What is her, what are her needs? What is she searching for in terms of information? And we try to frame opportunities through how might we statements, you see them like in the bottom part. And then very important once we've all co-created this we're going to do some consensus building. So we take these rubies and we're actually gonna put them on the thing that matter most to Hailey. And we also put some bandages on the aspects that are causing the most pain. And what is really important if we would not do this, we're actually not creating consensus. And this is I think the most important element of this workshop is that we actually land on something that we all agree on. So then we can take those findings and take it to the next step in creation of this was a content map and this eventually lead to a site map. So we're actually designing those pathways that flow through the website and that bring those target audiences to the information that they need. I know it's all very small. So at evolving web visual design is never an afterthought. So back in the days we would sometimes to apply our direction to wireframes, but especially for universities branding is such an important aspect of what we do. That we want to use this opportunity of the discovery phase to gather as much information as possible very early in the process. So recently we've been working on like optimizing our visual design process. And we've been conducting some workshops with clients to do some benchmarking together on the competition and to get their preferences and to start to better understand what their audience will prefer. And of course the big advantage is in these workshops you have opportunities to ask questions about the input that they've provided before. So what we typically do before any work session we already send out a questionnaire that gives us input to actually create a custom experience during the work session where we can use examples of their existing website and to look into what is good, what they feel like they wanna keep, what needs to be changed and also to bring in some examples of other websites. And then eventually the most important part is that we take those findings and we transform it into a deliverable. So in this case we created a stylescape for a client. So a stylescape is basically like a very early visualization or representation of where it could go. So it is a combination of all the imagery, the typography, the color palettes, and other design elements that we can bring together in a desired look and feel. It is not a final design, it's really meant as inspirational tool and to create sort of starting point and something to align on at the end of discovery. We noticed that it also really helps to get some excitement going. So far those research processes are also like very intense and our clients are always super happy and excited to see what this could look like because it becomes a lot more tangible. And so this presentation of stylescapes is often very interesting. So in this case our director Shane, he took the building of Oak Hut University and as an inspiration for this style. So you can see the building in the image. It has all these openings and we use that as the basis of this creative concept. It's called Windows into Oak Hut. All right and then we're gonna get into some of the technical discovery. Now we've sort of separated these out into some different sections of our discussion today but really this is, we're working quite closely together throughout this whole process and you'll see why in a moment. It's not quite as separate as we might make it seem. Throughout this process we're getting together a lot of deliverables of course and on the technical side, we're thinking about a lot of different things or creating a lot of different things. First off, a documentation of all the things that we're doing. So all that research, the figuring out what the different sort of problems that we need solutions for, each one of those, we're documenting all that information and the few different areas. This is more like a technical scope document. We have some other documentation that might include all of our different separate research and testing results, lots of architectural documentation and diagrams to help show how all the different pieces are coming together. So much more as well that might just be sort of supplementary documentation as well. We're also thinking about the content structure. What are our content types looking like? What kind of taxonomies do we have in place to support some of the other features that we know we're gonna need? The content, sorry, component inventory, how that's all looking. And then of course we're thinking about the migrations. We're starting to work on a big project that might involve a Drupal 7 to 9 or 10 migration. We start to think about how that's all gonna play in together. It's not always required, but in a lot of cases we probably will have a bit of a migration step in there. So as we're creating these documents, the first one I'll just highlight a little bit about is sort of that technical scope document. And as I said, we're building a couple different documents. We have, sometimes, we usually have one that's more of the scope document that's sort of like an external document that we use a lot to, we want it to be more focused so that we can use it to communicate what we're building with our clients. So it's got some pretty specific details in that way. And it's allowing, it frees up our other technical documentation to be a little bit more detailed, technically detailed, maybe something that our clients don't really need to know about all these finer pieces, but we want to keep track of internally. So by sort of separating these out, we allow those two documents to remain or two or three or four or however many to remain focused in their area. So that technical scope document is talking about the entirety of our discovery process. Nothing in here is really new at this point. It's probably all based on the discussions that we've had, whether they be through email or Slack messages or the different meetings that we're having with our clients. It's all stuff that we've discussed. And this is our sort of summary, our final deliverable out of this phase. Some examples, one main example of that might be something like the, what we're gonna do to integrate with a single sign-on solution or service. So while we're trying to figure out all these details and document them all, we're also not wanting to get too specific to detail. We want to still remain a little bit higher level. And that just allows us to, while keeping in mind this potential endless loop of discovery, we don't want to go too, too deep just yet. We want to leave some flexibility, but still have the ability to focus that we need. So it's kind of a delicate art and balance in there too. And if you think about some of the content structure documentation, the content structure itself that we're creating, we are using this directly, usually from the earlier design phases where we've been doing the wireframes and the actual, maybe some of the UI designs, maybe even from those stylescapes where we start to pull out what some of the structure is gonna need to be. This usually is a big part of that collaborative approach here when maybe we're helping the design team in building some of the wireframes and designs. And then it comes time to define the actual content types, and then they're helping us to inform what those content types are gonna look like and what different things we're gonna need, especially when we start thinking about the taxonomies. This is an example from the Princeton School of Public and International Affairs. I just have a couple of little pieces of how we might take a design like this and start to break it apart. We don't always have a fully fledged design at this point. We might be looking at more of a wireframe or even the stylescapes, but if we look at something like this, we might start to see there's an author here, that's gonna have to be some sort of a relationship field there, we'll have some taxonomies here for the topics, and we'll have a source field here that might be like just a free text field on these entities. And then we'll have an intro field, so that's probably just a simple text field as well, but then we might get into the description where we probably need some more editor control of the links and formatting. Maybe we're looking at more of a, something that enables us to have more of a rich text component in there. And then let me get back to the idea of the migration planning if we dive into that a little bit deeper. This is just a very simplified example of something that we usually do when we're thinking about migrations. We try to create that mapping of where our content is coming from and sort of where it's going to next. And as I mentioned earlier, our high-red clients usually already have a ton of existing content. So this is a pretty big part of this whole process. So we're always keeping this in mind, this potential migration, especially at this phase, we're not yet getting to the point where we're thinking about or rather where we're trying to implement same migration scripts or anything like that. At this point, we're just doing mappings, or just in the earlier discovery phases. But this is happening throughout the whole process usually. Once we get into this more technical discovery phase. And a big part of that is gonna be figuring out what we're doing with the existing content. It's not always gonna be a simple automated migration. This, when we're rebuilding a website, is probably the key time to rethink some of the content. Maybe it needs to be rewritten. Maybe some of it's not really relevant anymore. Or maybe it's just simply that we can pick it up and move it over with some field mappings, like what we're showing here. So this is the point where we're really thinking about that. There's also often cases where we have to pull content out of somewhere else. Like maybe it's a PDF. So we try to think about where someone that's coming from. That might end up being a brand new content type that previously was the news releases, for example. So that's one of the key components of the discovery process on our end, is to figure out how this all is gonna happen next. And as I mentioned, that stylescape that Hank was showing was gonna start to evolve into a UI kit that starts to get into a bit of a system. And we start thinking about components. And really, again, this is highlighting the collaboration that needs to happen between all of the different players because we're thinking about, on the UX side of things, we might be thinking about the content structure, but really on the design side of things, the visual design, they're starting to think about the different elements and how they're gonna look. And then on the technical side, we start to think about what are those components gonna look like? What's that structure? What feels do we need? How are we gonna implement them? All that kind of stuff. So there's a lot of that that needs to happen together. None of that can really happen on its own. Otherwise, we might not end up with the best solution in the end. So time for a little wrap up. So next slide. So what is important in discovery? A lot. And I know that this is a very high level overview of what discovery is. We could go into detail of any slide that we've shown for a whole hour, I think. But we wanted to give you an overview. So collaboration is essential. That's why also we decided to give this session together. Collaboration is essential to gather those different perspectives, to find opportunities together, but also to get some limitations. And that helps our designers, for instance, to focus their efforts on what really matters and where the solution can be found. So that collaboration is essential. Also, once we come up with new ideas, we validate those ideas before presenting it to the client. To make sure that it's actually feasible. So, second one, planning. We commit to that plan and to a timeline. And of course, it's important to build in some flexibility because as we know, discovery will always lead to new insights. And some of those insights can actually be important enough to do some additional research. So it is important to build in that sort of level of flexibility. And then communication. I always tell my designers that half of the time they should be communicating and not designing because communication is basically, it is designed. And creating like, for instance, visuals to really clearly communicate design intentions with clients is really worth it. Like investing more in communication will serve a project, absolutely. And then, fourth one is about people. Like understanding the needs of the end users. But not only the end users, also the content managers, for instance, of the client. Like what do they need? How can we make them successful? That is a real important aspect of what we do. So we can really help our clients to own their digital presence. So once we step out, that they have the tools and the capabilities to continue that work as it was intended. And then to iterate. We know that we gain knowledge over time and we get feedback. And doing that fast and in an iterative way really helps us to get more out of a project. So that's why doing these activities in the discovery phase, doing them fast, making iteration and changes is really important. So yeah, that's it. So now we are right at the middle. So that's a new starting point. And the discovery for us, Devolving Web is the most exciting part of a project. At least for me, it is, of course, like there's a whole world that comes after. But it creates that new starting point. And from this point on, we have like a very clear structure and very well-defined design principles. And we no longer have to base ourselves on assumptions of what we think is good for the client. No, we actually have consensus on and we have research to back up our decisions. So now we can really move forward into the design and development phase based on those informed decisions. And yeah, and the good thing is that we co-created this. So it's not only us who created all of this. No, we did this together with the client, with the students, with anyone who is actually an important contributor to the success of this project. And so I think that we mentioned this a few times, but this discovery phase is pretty crucial for everything that we do at Devolving Web. Without it, we really wouldn't be able to deliver on all the promises that we make to our clients, which is we need to be able to meet all of their strategic goals. We also wanna make sure that we are going beyond by supporting them in a continuous measure and constantly optimizing for the performance and making sure that we're able to continue to track and meet those goals. So this discovery process is really what enables us to focus our efforts and make sure that we're focused on what really matters most throughout the rest of the project. So setting ourselves up for that. We are, I hope, obviously a part of the open source community here. And so we really have a philosophy that is sharing our knowledge and tools with our clients to make sure that they can continue to own their own digital presence. And so we do that through just a couple of examples of some ways, but the design systems that we create are inclusive and allow them to build things themselves. There's components that have to go into that. There's the whole UI kit and ways that we can support the content editors. But we also have other guidelines around how to maybe use some of these components. That's pretty key to ensuring that things are actually gonna have the outcome that we intended when designing and building these pieces. And a part that goes into that is of course the whole style guides around things like writing and the tone of voice and then the visual style guides too. Brand guidelines like the logos and colors and typography if those sort of didn't already exist. We also go along the areas of helping to support with training and other ways that we can support. And that includes things like for content creators and site managers, because without knowing more detail about how this is all done, that's probably not gonna be the best way for success. Then just ongoing support in any way that of course that we can. So we are looking to create that ever better experience and creating a great experience for the end users that continue to evolve. All of this has that sort of same end goal in that way. And we help our clients to keep their content up to date with that is relevant to their audiences. We structure the content in a well-organized manner that we hope is gonna be future-proof. All of our designs are navigations and everything we try to make very intuitive so that a website doesn't need a manual for their end users. In addition, we try to ensure that our designs are modern and professional and engaging with visual content. And the experience that reflects the institutions of values which goes back to the idea of the heritage of an institution. And all that we hope is gonna leave a positive impression on the users and inspire trust in with their audience. Here's a project that we show before the stylescape. We create a little video one minute to show what the end result looks like and also what results it was able to generate within a few months after the site got live. So yeah, that was our talk. Thank you so much. We've wrestled to like 45 slides I think in 45 minutes. So there's time for a few questions. Please, yeah? Yeah, that's a very good question. So what, oh yeah. So the question is how do we separate the wants from the needs from all of those different perspectives and stakeholders in the university? So the way that we approach it is by getting them together in a work session where we organize a vision and goals workshop. So before we ask these questions through questionnaires and we're already mapping it and then through an exercise where we're going to, like using post-its, everybody can write down what is the most important needs or wants and then jointly we're going to prioritize that. And by doing that together in a group, we actually get to listen to everyone's perspective. So moderation is very important here because there's always people that are not comfortable speaking up while the dean is in the room. So we always try to bring in someone, either a moderator from our side or from the client side who's actually paying attention. So everyone has an opportunity to raise what their needs are. And then by prioritizing that together, we actually get consensus on what is most important and of course it gives us also information of what is still important but not at all priority. Did that answer your question? The important thing that they wanted, of course that person convinced the whole group that I was like the most important thing, ignoring perhaps one of the top five parts of the website in general, which is accessing black women where that gets some of the current students and that teaching stuff. So it becomes one of those things where because there was this cognitive dissonance of everybody going to go this route, it's totally perhaps one of the most important aspects of the site that no one's taken a look at. So we're kind of wondering how would you, as far as your discovery, you can pick up on things like that or how do you do that? How do you do that? Yeah, I think in every project we have these kind of things happening and these activities that we do, there are several. So we have a questionnaire, we have this work session, division goals, workshop. And at the end, when we synthesize all these findings, we are bringing that together in recommendations. So there's always us giving a final recommendation of what we think, like having seen all of those inputs is most important. And when we feel that there's a dissonance, like what you're explaining or like your example, then we will definitely raise that and give a recommendation. Any other questions? I think we have time for one more. Sorry, yeah. What's your name? So yes, I can speak to that. Yeah, we also do workshops for content creators. We organize voice and tone workshops. We do the content mapping, like here is Adrian, he's in our team. He's, you wanna speak to that? Any more questions? Yeah? It's so great, it's a great challenge for you to do that. No, we trust our clients, but not with something as important as personas. So of course we listen to them. I think it's a very invaluable information to get whatever they have and then to review it. So we do extensive research. But yeah, in some cases, when it's not a whole website, overall, there is already good material to work with, but yeah, this is always a subject of further research. Well, don't hesitate to reach out to us. These are our email addresses. We'll be around, we have a booth downstairs as well, where we will have a little drink at the end of the day, I guess. Yeah, come and visit, ask any more questions that we didn't get to and we'll be happy to chat. Thank you so much. Thank you.