 This is a session about requirements gathering, which sounds exceedingly boring, until I made up a catchy title. And look at you, you're all here, which is amazing. Thank you for coming. The agenda today is pretty simple, if you've read through the abstract, and it's just a little bit about how challenging it is to gather requirements, and then some things that I've learned along the way. So I have been working in Drupal for 10 years. Various hats in information architecture, user experience, and project management, and with some kind of capacity doing a requirements gathering exercise with every single project that I've worked on. And the one thing that I've learned through this is it's extremely hard, it's extremely hard. And it's something that can only be successful if you're using multidisciplinary teams, and you have everybody invested in it. So I would like to know who you are, how many of you work in Drupal, consider themselves Drupal professionals? Fabulous, okay. How many of you are technical? Great, how many of you are creative? Nice, how many of you work with content? So a lot of people wearing a lot of hats here as well. Okay, that's great. And why are you interested in this topic? I know why I'm interested in this topic, because I have felt the pain, because I've had projects where we thought we knew everything, and we didn't. And you find yourself asking, why don't you just tell me, just tell me what you want, and then we can do it. But they don't know, they don't know. So some of the things that I've been learning in the past several years, I've put together into a presentation. And one of the most mind-blowing things that I learned was this concept of conscious requirements, unconscious requirements, and undreamt requirements. And that's what I'd like to describe today, what those are, what the challenge is, and how to go about uncovering some of them. So what I'm talking about is typically three different scenarios. You have a redesign where it's pretty fresh, refresh, upgrade, there's a couple things you want to do, things to move out, things to move in, but there's something there to talk about. There's either a Drupal site, or there's some sort of legacy system, or there's something approximating a site of some kind with pages, so there's something to look at. Then, number two is brand new. I'm gonna spend less time here, because I have the feeling that most of you are looking at number one and number three. And number three is kind of the most terrifying thing, and that's like the rescue project. We built it, and then it didn't quite work out, and then we didn't get along with our team anymore, and now we either have to fix it, or rebuild it, or start over again. How many of you have been in that situation on either side? Right, okay. So you know, this kind of stuff happens. And then the more I looked into it, they kept calling requirements gathering an emerging field, which is strange, because we've been building things for a long time that have requirements of all kinds. But this is something that we're notoriously bad at for all kinds of reasons. One of the challenges that we face is that sometimes we're trying to map one-to-one for a customer requirement, or a stakeholder requirement, and somebody makes a request and it becomes a feature. Or there's an input and we put a checkbox next to it. Or we get caught in too high level or too granular. And one of the things that I want to propose is there must be balance. And there are so many different kinds of people that have their own way of seeing things that how do we get everybody on the same page? And certainly when they come from different backgrounds, you have the added problem of the materials that you're getting from various teams are going to be so different and so, what's the word? Inconsistent, all kinds of things. Super, super granular to crazy high level and everything in between. So much documentation that it seems as though we have enough. If I have 100 pages, there's gotta be enough to build this thing because there's 100 pages. I don't need another page. First, I don't wanna read 100 pages. But if I do, I should be able to build it. That's the concept that I think we're coming from. We just tell them just throw everything at you and you should be able to build this. But we forget, where does it come from? And who creates it? And what's the language? And there's so many little sticky things. And you imagine that if you take one degree of variation off of the direction, the path we're gonna go, eventually you're gonna be really far off further down the project. Hopefully when you've been moved to a different project. So this is the kind of stuff we're getting. We're looking through the proposal and the wireframes and the Photoshop files and the spreadsheets and the user stories. And we're just trying to break our heads and come up with some sort of unified plan forward of what it is we're actually building. And traditional stuff is very dry. It's gonna be, there's constraints and conditions and there's systems and a lot of technical people bring amazing documentation. I am a spreadsheet queen. No, really I've actually been called that. And I love detailed stuff, but there must be balance. This is what it looks like. We've got like super crazy high level stuff to incredibly granular. And it all kind of looks the same in the end. Because they're coming from different backgrounds. They're showing us different things. And not one person is going to be able to understand everything from every point of view. So how does this come together in a melting pot? Well, I'm gonna talk a little bit more about the actual problem. You have this 30,000 foot view and a few key features that have been really fleshed out. Pretty amazing features. Because somebody spent the time because that was their baby. So, but that's not the whole site, right? Then we've got a situation where we don't really know what the priority is. I like this picture. I don't know if it's real, but I like it. The wrong focus, right? They bring you a project and they just got like three pages on one feature and a little paragraph on 14 other features. So I would think big paragraph, main priority. Not always right. You can be precise without being accurate. You can be precise without being accurate. Precision gives you the illusion of accuracy and completeness. Because it's right, every little, that's a real F and that is an S and that's an I. And you can still read it. But it's not accurate. So balance, what does that actually look like? I have a goal to, first I gotta understand what language you're speaking. What have you brought me? I gotta fill in the gaps. I gotta figure out, is it high level? Is it low level? Well, what do you think it is? Cause that's a big deal. If you've given me something that you think is high level and it's really very granular, there's a disconnect and there's something that we need to talk about. So the very first objection you will have. But they're just like, if we say, no, this isn't what we need to do and there's discovery and we're gonna mispronounce time and money and you have a deadline, they're just gonna go to someone else. Yes they will, some of them will. And they will be back with a rescue project. Because they couldn't build it. So you need to ask yourself, are you trying to win an argument or are you trying to win the war? Cause if you build what was asked for but not what was needed, you're gonna be the people they're leaving to go to someone else to. In many cases, I think we should all band together and do this thing. So how are we going to do this? We have these conscious requirements. So these are the ones, the no brainers. We need an events calendar because we have events and we need to know when they are. That's a good place to start. Great, there's tons to unpack there but at least we know what it is. Unconscious requirements. This is really interesting to me because I've gone through a lot of projects that have started off in a crazy custom built legacy system that had all these auto magical things happen. Some of them were business process, some of them were made just because that was the way that we figured out that we could make it so they kinda forced their business processes into that because that was the tool. We had to try to figure out the difference and then there's these undreamed requirements, things that we'd love to be able to do if we would know about them and they don't know to ask and I don't know to ask because I don't know that it's actually there or not but the way forward is pretty subtle. They can't always articulate what they want. They may not answer in the way that we ask them to answer. They only know what they've experienced and they're not gonna be experiencing things that you've experienced because they're coming from subject matter expertise, domain expertise, their business and we're coming from tool expertise. We know how to build stuff but this is the place where we can provide the most value. You wanna be a rock star? This is the place where there is the potential to really, really knock it out of the park. Like the kind of pride that you come home and all those horrible 14 hour days like but I built this thing and they loved it. This is Mining for Gold and this is a slide from Jared Spool's keynote in 2011. I love it though because it kind of shows like we have process and product knowledge of our tools, of our system, of what we can build. They've got knowledge of their current system. They have knowledge of their business and we need to all kind of get in the same place. So this process focuses on what I've highlighted there. So this might be a typical requirements gathering process. So you have, you're offered a request. This is what we would like. There's some information gathering. There's some analysis, modeling. Validation is an important one and then towards the end there's something that the sales people do. I'm not gonna cover that part. I kind of think of it as like what kind of requirement are you when you do a quiz? Do you like purple? Are you high level? Do you have visuals? Is there a diagram involved? There's somewhere, they're gonna land in there, right? They're gonna be like super big picture, really granular but here's what you remember. Abstracts, the big picture stuff, that's what's gonna give you the patterns. The patterns that make you make something that's going to be efficient, that's gonna help you hit budget, that's going to be modular, that's gonna be scalable but there's the except when we do this thing and then we have it like this, but on Thursdays and then Nancy comes in but she does it a completely different way but we totally need to support her because she's really awesome and she's been here so long. Yeah, so specifics give you outliers and outliers cost a lot of money. But we wanna find the middle way. We wanna find the middle way. So conscious, high level requirements, loaded words, like we wanna build an online community or a membership portal or eventually we're going to do content personalization. I mean these are so big, so big that they're own project pretty much some of the time and this like auto magical thinking that well it was gonna appear on the page but in this page is about swimming pools so all the swimming pool stuff will appear here but we don't actually have the IA to support any of that yet. So typically just request without a good understanding what it is but you can understand where they're going with it. Very vague usually, kinda loaded. Granular conscious requirements are things like layout specifications without really having any IA done or very specific content creation form requirements without actually knowing Drupal or request for very specific modules that maybe somebody told them we're good for some other site that have nothing to do with their site but they just like this is a good one, you need this one. And then some content editing screens I've seen described to the very last label and button. So this is the kind of granular stuff that is conscious they've asked for it but really needs a lot of pushback. The most challenging for me personally as an analytical person is this type of request. Where do you begin? But I found a way. We need to begin unpacking requirements with some business insight, with some content strategy and with some information architecture. And when I see something like this I know where to begin now because I start with a big picture. What does this actually do? What do you do? And somewhere in there is the site that you're building. There's something, combination of those. But you can probably figure, okay, so this is what it is. This is what the purpose of the site is. Awesome. So this engaging thing that it needs to do. Well we have digital analytics for that. We have metrics, very well thought out metrics and metrics, I don't, metrics different than data. The analysis part is gonna be totally different than the report that says all the percentages. So actually deciding what you're gonna monitor is another session. And then we can go into the unconscious. And these are often assumptions about things and you can tell because they have certain ways of referring to them. They'll say things like widget or plug-in or feed. And it could mean so many different things. They've mentioned responsive as a priority. Their current site is not responsive but they also have 16 different layout possibilities. Red flag, right? There's things that are contradictory in many of these unconscious requirements. Often where the CMS begins and ends is an unconscious requirement because sometimes if they're coming from a legacy system it has something else on it. It's got some sort of ERP or CRM or XYZ and it just kind of, because I'm Canadian that's why I say Z. And those things are very important to figure out because it's often something in somebody's head that oh yeah, well it used to, and then there was a line there but we've moved the wall and we're building it something else. So sometimes you get into this trap of just tell me what it does and then I'll tell you what happens. Resist this because then there's also this. You do it the same way but in the opposite direction. Because then you end up with describing what's in the hat. It's this thing and then we put things and then it comes out and ta-da! And it has nothing to do with what they actually need. They're just trying to recreate something they have without actually knowing what the possibilities are. So I'm sure you've heard it before. To focus on the desired outcome. We're focusing on the unstated problem, not on the stated solution. So this is a lot of the time you're gonna get requirements that are solution-based. They've already decided what it is they need. And that's where this sort of uncomfortable thing happens when you're not really wanting to have that conversation about well, why is this what you say, oh no that doesn't sound, what makes, no that doesn't sound right either. Like it's a hard conversation to have. But I think it's worth it and I think with practice you can actually have these in a very gentle and positive way. And I'm gonna throw a quote up there because it's Einstein. But this is kind of what we should be doing, right? Like let's define the problem because I've got some great solutions but I don't really know what the problem is. You've just told me that you need an events calendar. So these undreamed requirements are things that no one may know how to ask about because they just kind of go about doing their thing and it's up here for them, super close. They may totally blow your mind. They may be like, I can't believe no one's ever thought of this before or they may be so extremely subtle. But matter incredibly to somebody. You know some of those editing tools or little minor changes. Wow, it's so much easier to use now. And a lot of the time they can be tools that we already know about but we just need to figure out what it is that we're solving. It's very subtle. Second objection. But there's not and they don't and I, but I want it. No, I want it, I want it, I want it, I want it. Just build it, I can't just build it. No. And my answer to that is, well, do I really want to work with that person? No, it's, let's just have one more meeting. And let's discuss. And just a few more clarifying questions. And let's talk about it. And walk me through because now I'm gonna throw another quote up there and this one's super awesome too. It doesn't have to be confrontational. We're not trying to point out mistakes. We're not like, I'm in about your business and I'll make it better because I know nothing about your business. No, just like, you know, kinda walk me through your day. What are you doing? What's really hard right now? Okay, what's easy? What do you do on paper? Like, do you sticky notes attached to your, what do they say? Is there like a cheat sheet for your content creation process? What's on it? And we're just not, we're not trying to run their business. We're just trying to figure out what's in their head. So here's a few techniques that I think can be extremely helpful. And I'm grouping together end users, administrative users, stakeholders on the periphery. I'm just grouping them all together because in the end, we're kind of using the same technique on all of them in context. So abstraction. Abstraction can be very difficult for some people. Technical people find this easier because your job is to write some logic about something. But most people that are non-technical find abstraction extremely confusing. So they will come to you if you're, they're gonna describe, this is a camera and I really like how it works and I push this button and it takes a picture. They have described their camera and what they do to take a picture. If we abstract that as a technical team, we might say the user needs a mechanism in order to take a picture because the button might not be, might not be the right thing anymore. And that is incredibly valuable way of just uncoupling those assumptions that have already been made about something because we're already jumping to the button. Might not be a button. This, the diagramming can be all kinds of things. The fishbone diagram, mental mapping, content grouping, anything that makes sense to the people in the room, I think it's fair game. And then you can start to look for patterns because remember, abstraction gives you patterns that gives you better information architecture, better usability, better scalability, cheaper than specific outliers. Then there's apprenticing and interviewing. This is just basically the demo. This is the screen share, show me your system, walk me through what you're doing. Cause there's guaranteed to be that thing they do where you're like, can you just do that again? Why? Why are you cutting and then pasting and then going the next page and then opening and why, I don't understand, why are you doing that? Because there's a problem to solve there too. They've done it that way because they've always done it that way or there's something or missing. There's something that happens in between. And there's a lot of stuff where there's a dovetail with the real world. There's something that happens over here in the office beside my computer that has nothing to do with the system but maybe it could be part of the system. Like maybe I go over there and I find and the file and I pull it out and then I type it in. There's gold there. I'm imagining in the past there was a demo of a legacy system that I was watching and there was this complicated procedure for creating a report and then pulling the emails off of a report and then cutting and pasting the emails into an email and then making a news, and the whole thing was just like, is that an email list? Yes, yes it is. Huh, we can build that a different way. And then there's business events. And this is a really, really interesting one because a lot of the time I work remotely and it's hard sometimes to get people to describe their business events and activities during the day when it's remote because you can't follow them around and go, hey, what is that? What are you doing over there? But I had a really interesting project for a bookstore where they had an online ordering system and I was there with the lady who was fulfilling orders and she was like, oh, this is awesome. This is a super amazing system. We really need to keep this as it is, which is, that's fine, it was fair. But there was one thing about it that was a little awkward that she didn't notice because they had interns come in and go and pack the books up. They'd go to the shelf and find the book and put it in a box and pack them. So they'd get the order and then they had to look and see what the shelf code was for the book. So they'd take the order and they'd look at the book and then they'd go into their other system and look up the shelf code. Why not print the shelf code on the order or in the system where I can see it? Why have this extra additional step? And this is the undreamt stuff. Nobody figured that that would be maybe a good idea to have it on there. So I go, oh, it's on shelf blue squirrels. So I'm gonna go over there and I'm gonna get the book I'm looking for. And brainstorming? I think, I mean, a lot of people are extremely terrified of brainstorming because what if they think up a bunch of stuff that they want and then they think it's included because we talked about it briefly in a meeting and now we're gonna get it? No. There are things you can do to brainstorm safely where you keep the creativity contained, where you open up the box and not let everything fly out at people's faces and it's not that messy. And it's great for new products. I'd say I wasn't gonna mention the new products so much but brainstorming's great. If it's something that doesn't exist, if we're not sure what it does, I love doing research and seeing what's existing. What is it like? People are always like really super obsessed with their vertical. Yes, but is it exactly the same as my product? No, but the process is the same and the interface is the same and demographics the same. And so we take it from here and here and here and this at least gets us a little bit further. We don't need to reinvent the wheel and we can stand on the shoulders of giants as my friend Ann likes to say. And mind mapping, these are for visual people and I say this because sometimes I like being creative and sometimes I don't. But there are so many people out there that love to just draw it out. And nobody's ever gonna hand you that, well actually did happen once, thing as a requirement. We did this on the whiteboard and we're including it. It's a sketch of what the new system should be. But it's great, I mean just get started. Let's have the conversation. Let's have the conversation because we need to find the middle path. We need to find the way. A simulation model and I can see that it's very expensive and we don't have the time. This can really just be your wireframes and making them clickable. Or this can just be, you know, just look at some screenshots of similar Drupal sites, the backend, it'll be a little bit like this except it'll be your information here and then you'll go here and you can make a prototype and I'm not talking about something fancy, you can make an approximation of what something's going to look like and if you wanna invest in some templates for a registration workflow, for a product, purchase workflow, those are really valuable because we know what this stuff looks like but often our stakeholders and our clients don't and if we just show them vanilla a lot of the time, it's all right. But it also gives us the opportunity to discuss things that may not be exactly as they need and all of a sudden we've seen it on a piece of paper and they're like, well, but we don't do that with our credit cards in it there and now we've had the conversation before we've built it. So prototypes doesn't have to be scary. So what are we looking for? We are looking for the big picture. We're looking for relationships. So the big picture to me is what does this site do? What does this business do? What do the users do? What are we expecting from people when they arrive? And then the relationships are really important because some of the time if you just get a site map, if you just get some designs or a wireframe or maybe even a list of content types, you're not really seeing the relationships between things and it doesn't have to be an entity relationship diagram. It can just be that sketch, right? So we've got this professor and he's got a class and he's in this room and there's a building over here and just kind of show me how you imagine it to work because more often than not, that natural relationship that is described in a business kind of way, like this is how it works in the real world is actually a pretty good model for the system if it works, like we're not gonna force it but me trying to think of relationships based on what I wanna display is not as good as actually having a logical sensible structure that's the information architecture in me speaking. Context is also extremely important and what I mean by that is both context of use and also the context in which we're actually doing all this planning because if there's a huge change coming, we're gonna want to plan for that as well. We're gonna like what's the next big thing for everybody here? What are the future problems? What does the system need to do in the near future? So contextually if I'm using it, I'm using the site on my phone, where am I? What do I need to do is different but it's the same kind of context like what is the, where am I in my situation? Then where the business is in their online situation because there's often when there's a redesign, there's some huge goals and huge leaps ahead and there's things that the system needs to accomplish. So that brings me to priorities and reasons because priority's gonna be really hard because the priorities sometimes come down to personal preference of whoever wears the biggest hat in the room or has the nicest title or something. But honestly, priorities need to be what makes sense for the organization. What is their mission and vision? If you don't have that kind of person involved in the project, you're in trouble because then we're just designing it because somebody's told me we need a new website, there's a list here, I need to follow it. If we don't have direction, then those very, very difficult decisions at the end when money's running low and we've got enough to build for and we really need six and who's gonna make that decision? It needs to be on somebody's head that has that mission and vision and grand scheme of things overall picture. Yes, we can do a little of this. What are our options? Because the reasons for things can be very complicated. It's cheap and fast to build features but it can get really, really expensive when you wanna customize things and change things and have them be just so. And that's the fight that usually happens. So if you can define some of that really, really early, the priorities, the big picture, the reasons for things, then you can come back to that because it's one of those documents that I think sometimes gets created, a type of charter, and then it's really far down in teamwork or base camp or whatever you use so nobody ever looks at it again. And I think it should be brought out. Maybe even every time you provide a PM report, we're gonna look at our priorities again. It doesn't have to be 15 sentences long. It could really just be a couple of points. Really gotta get this thing built. Really needs to be able to sign up people. So keeping that focus is going to help, I think too, with the build. And then I think with the last three here, assumptions, constraints, boundaries, this is what we're talking about when you say scope. Scope is not what I need. Scope is what I can build for you within this amount of time and this amount of money. Scope is not, I'm not gonna get the thing, but I need the thing. It's like you have this much money and the cookie is this much and you can't buy half a cookie, so what are we gonna do? So these conversations, I think, are part of requirements gathering. And I'm a really big fan of having them conversations road mapping out all the things that you can think of over the next two years and then drawing the lines and then saying, okay, I understand that sometimes budgets can be managed creatively. There's plenty of organizations out there that split between years. They gotta build this. They gotta build a certain way, but then they can build stuff. So all of those conversations, if you have account managers that can have those conversations, like how, you know, we're not trying to nickel and dime you, but how can we work creatively to actually build stuff with the resources that you have available? And resources, I would also include their content resources, because if you're making an extremely large shift with content, that takes a lot of time and a lot of effort. So I think validation is a piece that we skim over. We'll send them the piece of, there it is, we've estimated it. There's our description and there's all the discovery assets, deliverables, elements, sign here please. And I really think that that's an opportunity to do the validation. Now, for stakeholders, that might be showing them high level stuff, maybe just some specifics on the priorities, how we got to the features, some of the exercises, some of the very key decisions that were made in order to bring us to a certain point, because nothing is as crappy as having some supervisor come down and say, what have you been doing for the last six weeks? Everything's changed and not being aware of the process, informed and invested, bought in and understanding how we got to the place that now it looks completely different from what they asked for. That's a really, really difficult situation. So I think with this validation, there's many different ways of doing this, but you wanna focus on the decision makers and end users, sometimes in the middle those people get a little bit shortchanged, administrators, content creators, but there's a lot of room there because there's things that can shift in that area. I think for users, and this is another session perhaps, doing some user testing, navigation validation, all of those exercises in the UX realm are very valuable and showing that information as part of the presentation of requirements that have been gathered. We know that this is important because of this test that we did. We think that this actually can be left out because no one mentioned it during our interviews. And then comes the negotiation. I mean, it's a little bit of a trading card exercise. If you don't have the money for everything, then what comes in and what goes out and what needs to be changed. And sometimes if you affect one thing, everything else changes too, and it's incredibly difficult. But I think those are the conversations that aren't being had, those difficult, all stakeholders in, how we got here, how we need to move forward conversations. So now what I wanna do with a few minutes here is I'm gonna leave some time for questions, but I wanna actually use a metaphor because I do this with work with non-technical people. I wanna say, okay, so we're catering a meal. If you just get a list of recipes, or if you just get ingredients, what are you gonna be missing? I mean, there's high-level stuff that is pretty important. Why are we having this meal? Who's coming? Are there any allergies I need to know about? Like, there's some things that need to go into it. It is not just a list of stuff. And I'm gonna go to the store, and I'm gonna buy it, and then I'm gonna do the recipe, and there it is. No, there's this huge eco system around it that I'm trying to balance. So maybe the request is, prepare an informal two course dinner for four, and it must have protein. And they're probably not meaning protein powder. Right, but there's things on, there's things when we get an RFP where it can be interpreted that way, like protein, shrimp, or steak. I'm not sure. So that, when we start to scope a little bit, we're gonna apply the boundaries. It's gonna be after five, guests are available this time. Oh, we haven't even talked about when it's gonna happen yet. Oh my gosh, have you ever had that, the RFP, and then there's this whole big humongous thing that nobody ever talked about. This is why many lenses, using many tools and validation walkthrough. So now we're gonna do a little bit of fact gathering. I have a shelfishology, so I don't really want to be serving shelfish to my guests, because I would like to be alive for the rest of the dinner. And I like spicy food, I really like peppers, this may or may not be relevant, but they've given me the information that I can now look at and say, okay, I think I've got something to work with here, because this is the kind of information that will help me figure out what and how. Because this is just enough, and then obviously that you can get into a lot more detail with something like this. I can do some analysis. I can get into a lot more detail. I think Agile is so cool, and I think Waterfalls is cool too, but somewhere in the middle is where everything is happening. And so some flexibility, I find that with the most successful projects, the flexibility is that the client, the stakeholders, the team trust each other, that if a change needs to be made, that we're not trying to screw each other, we're just trying to make it well, working and make a beautiful product. So in the end, this is what was made, and I think, I chose a name that I can't pronounce for whatever reason, and that would be really clever. But if I got that at the very beginning, I think that would have scared me off. I'm like, I don't know how to make that. Or if I just got a picture of ingredients at the very beginning, I don't know what I'm making. I like olives, maybe I'll just eat them plain. And the validation is like, so this is kind of what we're looking at, it's gonna be this, might switch out the napkin, so that matches your branding. And then at some point, they might have been thinking this, and I might have been thinking this, but we've had that conversation. And when we've gone in and actually looked at things from all kinds of directions, we were able to realize and have a good laugh about it. And have a bit of a trade-off exercise. Well, we can't do this piece anymore. Well, what are we gonna do if this happens? And the risks are something to start talking about the very beginning. And we have some data to support things now. We know what's important, and we know because many people have been able to talk this through with us. And inside this negotiation that happens, things will change. And I have to feel, as a professional, I have to feel like I didn't do anything wrong because something changed. I did something right. And I need to be in a situation where I feel safe about that, and my clients and stakeholders respect that. They respect me as somebody who has experience and knowledge in order to come up with the best possible solution. And we throw another quote up there. I know this was from a long time ago, but I just wanna say it's the mix of these abstracts and these specifics and qualitative and quantitative and a little bit of this that all needs to come together that in a very, very scary way, but if we've talked it through enough, then we can learn each other's language. And I know that there will probably be some questions now, and I always leave not enough time, but now I've got enough time. I'm gonna ask some questions. Yes. Yeah, that is a very interesting question. So the question was, how do you approach requirements gathering if it's an agile versus a waterfall approach? And I've done both, and I went and did the Scrum Master Training and all of that. And I think there's this idea that with waterfall, we have to write it all down first, and we have to know every last detail until before we can actually begin. And with agile, that we can just start. And I think the truth is somewhere in the middle, and you're gonna have a similar list for both. I think agile just means that we can stop and change our mind every two weeks. And waterfall sometimes means I can change my mind whenever you want, but, and it just comes down to like, how amiable are we to that? Sometimes that's what happens. But I think that if it's a project that needs to be waterfall, it needs a lot more planning time up front. And they can't just hand you a big 100 page document, say it's all in there. And agile basically means that you can plan out larger chunks and then get into the details during the sprints. I think there's a microphone over there. I don't know if it's, if we should be, I don't know, just yell. Yes, glasses. Yeah, right. So the question is, how do you help your clients who are engaged in an agile project understand that they can't just keep changing things over and over again? Well, part one is, do they have enough money to change things over and over and over again? There are, and I'm not even joking, there are many projects that are like that. They are just ongoing. It is, it's a gardening project. You know, every season we're doing something different. We're improving something. We're making something better. And that's the project. But that's probably not the kind that you're looking at. You're looking at the ones where there is a fixed budget. And I think that if you have allocated budget towards things, so instead of saying, I need an events calendar, how much does that cost? Well, I don't know, how long is a piece of string? What you, what you can do is say, of this budget, how much should we allocate for this feature? If we just, you know, out of the box, Drupal, Vanilla, boom, it's going to take up one quarter of this budget. You have three quarters left to customize. So they can change within that budget. I mean, I've done that before. That works really well. But like completely sweeping changes, well then nobody was told what the website purpose was. If we're changing everything, like it's e-commerce and community and now it's e-learning, like which one is it? Let's just, then the project's too big and it needs to be cut into smaller pieces. Does that help? Cool. Yes. Yeah, okay. So, had something like that recently and there is, if you look at the web metrics, there is some sort of success factor that they can understand that makes it a successful website. So for example, say I have content publishing, I've got people coming to the site, they're looking at ads, they're encouraged to sign up for something. There are things that we can measure as a business for them, right? Like, hey, so I usually ask, what are you measuring? What are we starting off with? How many, and they're like, oh, it's Google and analytics and it's all in there. No, what are you measuring as a business? Where are your subscriptions at? Oh, okay, and how much do they usually go up every year and how much would you like them to go up? And what if we could get some insight on user behavior for you? Because a lot of the time when you ask, what are users doing on your site? They'll be like, Google analytics says about page. That's not what they're doing. What are they actually doing? So there are tools and some of them are, can we really settle? Gorilla analytics, you can get on the call, a support call. CSR, if anybody has customer support, if you're just like, hey, you know what? You can really cut the budget for FAQs and support. If we just can listen in a little bit or talk to your customer support people about what clients are asking, all of a sudden, phew, right? That customer support call, that's costing them something. It was like $6 a call or $2 a call and all of a sudden they're taking half as many. That's money. So the decision makers, if you can suggest that there might be a way to save some money, you can come up with a little plan and just kind of sneak in and try to find some stuff, more often than not, they're quite receptive. So instead of like, you know, I'm not asking if the users prefer red or blue. No, I'm not even asking them. Sometimes I'm just looking over their shoulder. You can also come up and talk to me after if it's like a super secret thing you want to ask me about. Gosh, yeah, many. There are, I should probably, when I upload my slides, put a reading list at the end because that would be easier, I think, than me trying to think of them through. A lot of stuff's online. A lot of that, there's some really amazing sites that are producing some really great articles that didn't exist 10 years ago. Like just, nobody was talking about things like that. So, yeah, subscribe to a few. Cool, so, yeah. Yeah, so the question is about how do you recognize unconscious requirements of your own organization? And let me just, let me tell you a little metaphor. When I asked my kid who's 14, what she's done at school, she says, you know, same stuff. And that's what we think about our own organization. Like, I go to a shop to work and I enter some data and I process some things. And that's where I want granularity. Like, that's where, like, okay, sit down. You push a button. You enter your password. You navigate to this, like, I wanna know where all those little individual things are that you're doing because some of those are gonna be a little bit, like, unnecessary, funky, a little awkward. And honestly, if you just make a log of all kinds of things to somebody else who's not been looking at it for years and years and years when you kind of explain what you're doing, there'll be some questions. Somebody'll say, oh, well, why, because when we do that, we have this thing and we pull it in the export. And so I think it's hard to tell culturally what's happening unless you go to a different country and see what are they doing over there. So there's, I think there's an incredible value to going to meetups and talking through processes with other organizations who have similar but different types of processes because they're gonna say, we had that problem. We solved it this way. We were, you've been trying to do that for years. How did you do that? And again, those conversations, it's hard to do this in a silo. It's hard to do this all on your own. The message here is to really get involved and have those conversations with multi-disciplinary groups with everybody on your team and pulling in people that you had like grandma. I'm gonna explain something to you. You tell me if it sounds weird and which part you don't understand. That is a totally valuable way of testing and validating something. I try to explain things to my kid because she's extremely non-technical at 14. It's really weird, but it works. Chad. Yeah. Right. So are they resistant to trying a usability study or are they resistant to, okay. Yeah. Yeah, so how do you bring in some usability research? How do you bring in the voice of the user if the stakeholders are resistant? Sometimes I do it secretly and what I mean by that is I look at analytics. I look at the paths. I try to write out mission critical tasks. So if your business is signing people up and they need to get through registration and everybody drops off at step two, do you wanna find out why? Because I need a little bit of ammunition, right? You can't be like, let's see what we can find because then they're just like, you're just digging holes and filling them in. But you can find a little something and say, hey, so I noticed that this is really interesting thing happening to your site. And here it is, I'm seeing it in the analytics. Should we find out why? I guarantee you, they give you a permission to just do that one piece and that's gonna give you, I think, the foot in the door to do a bit more. Yeah, that's a hard question. So the question is about RFP, initial quote, and then some kind of discovery process or IA or something that happens and then something completely different that you need to reconcile, yeah? And do you document how you got from A to B because that's, yeah, okay. Right, no, no, I think that's a moving target. I think it's going to be, I mean, it's different than saying because you've made a decision that changes what we're building halfway through, this is now 50% more work. That's different than I think re-estimating the entire project all the time. But I think you can get to a place where you can say we re-estimate at this point. Usually it's after information architecture, wireframing, when you're heading into design, we re-estimate at this point. And this is the place where there's a whole bunch of stuff that's just happened that we've learned more, that we've realized is more complex. And if you're able to show where everything is more complex, like see, and this is so tedious, we've done this before, like the RFP says you have this and then we found out that you really need it like this but with 3D, whatever. Then you can map it out and say, because this is now more complex, we need to add more time for it. However, sometimes they go, but we don't want it to be that complex. We want it back to that original estimate and then you're in that negotiation again, then you're in trade-offs and then you're, okay. So you've told us how it was built because sometimes there's the legacy system that they're trying to quote on. We've figured out that this is built in a really funky way, but really we think that you only really need like this piece here, all the rest, I don't know. This is, and this is a really big thing that happens with access and roles and permissions in my experience. So there are people who leave their computer unlocked and their office door unlocked and they work with people they like, but they want to nail down the access. So no one can edit my blog. And I just don't see why they want to spend money on that. If I'm friends with Nancy, poor Nancy, I'm just going to let her know that I edit my blog, please Nancy. And if she's like, if she's having issues with that, that's an HR problem. That's not a technical problem. Five minutes. Yes. Yeah. Yes. Yes. Yes. Usually they're completely useless. The way that they've been done. Yeah, because they'll be leading questions. They'll be, you know, the kind of like customer, appreciation or, you know, net, what do they call them, net promoter scores. Well, there's nothing to do the website. So like, hey, I really love your, do you like this pizza company? Yes, they do. They love our website. No, they've just said that they like your pizza. It has nothing to do with the website. So I really find that a lot of surveys, they just haven't really nailed it yet. Are they like, do you think our website is easy, not easy, difficult, not difficult? And it's just people are just like, I just want the survey to be done. So I think a lot of surveys are done extremely poorly. And if you can pull out some information to show like, this here is a little bit gray and fuzzy. We would like to maybe ask these questions again, in a different way, in an educated, like everybody thinks they can run a survey now because they can use the tool. The tool is not the way to get the best analysis because there's this thinking that has to go into the questions in order to actually get reasonable answers that are meaningful. So I mean, that's difficult and hard conversation too. I've definitely had those like, hmm, yeah. So the survey, there's a few things I want to know. Yes, which tools that I use. I have a UX role, so I do design a test. I would love it if I can work closely with the stakeholder team because they need to have buy-in. They need to understand what we're testing or they just don't appreciate the results very well. So there's different tools that I have and it comes down to what do we want to find out? What are we trying to find out? User behavior, user preferences. Is it optimal structure? Is it comprehension? So depending on the question that I have that I'm trying to answer, I will use different tools. Sometimes I'll push those back to the client and have them with my help, with my facilitation, actually run the test and then I'll look at the results. It just depends on what it is. Does that answer your question? It's a whole other session. Cool. Well, I think we're kind of out of time, so yeah. Thank you so much. Do feel free to approach me and you see me and you have a question or if you wanna talk to me now I just need to drink a water.