Lessons

Lesson Info

Gutcheck & The Product Brief

All right, so, our gutcheck recap. So what's great about design as you Ministry of Space stakeholders is that it just shows how subjective things are. (laughs) So normally when I do this type of process, you know what I'll do is I'll kind of go and review what are the ones that people responded to most. So what were the favorites? What were the ones that people didn't really respond to because I think that's also equally valuable. You know there is clearly something that people were not digging and so it's really worth it to explore. Usually any of them that kind of ended up in the meh, kind of middle, well I don't think you need to spend too much time on that. For our group what I wanted to do is just kind of focus on a couple that everyone really responded to and get you to talk a little bit about them. So first let me just do a quick little fly through of some of the examples. So this was number one. This was number two. This was number three. This was number four. Number five. And ...

number six. So to first start off one of them that was the most popular and they all did pretty good, you know, they all got likes but the one that was most popular was this one. This is one of them that people really responded to. So, you know, I'd like to say maybe, Moises, did you pick this as one of them that you liked? I did. So, why don't you talk a little bit about what you liked about it? I liked that it was easy on the eye. There was some white space that helped with that, and the hierarchy of, the things that are presented in this webpage. Mm-hmm, Hannah, what about you? Yeah, I liked this one too, because it's more like out of the box. It's not asymmetrical, and yes, I like that they have more ... The ratio between negative and positive space. Mm-hmm. Great. Lisa, did you like this one? Yeah, I did. Again, the asymmetry, and I'm just thinking about space, and it's unpredictable. So it wasn't something that ... There's symmetry, but understandable, but at the same time there's things changing, so conceptually it made sense to me. Great, yeah. And, you know, as you might kind of go through and talk with your clients, you can get a little more pointed, you know, asking about specific colors, you know? What happens if instead of this being kind of cool, it's like maybe for example, cools you already know because you've received a style guide from them that cools are not within kind of their brand pallet, right? And so you'd be like, well what happens if these were maybe in warms? Like do you think it would still work? And so you can kind of start testing things a little bit. Same with photography, you know, a lot of times people will like it or hate it because of the photography, because there's such a bold statement with that. And they might be like, you know, it's weird, like I don't like this because I'm seeing the back of his head. And why would I want to do that? And you're like, that's when you can kind of talk and remind people that well it could be a lot of different things. It's more do you like, the kind of, dual-toned style of it, right? THere's an effect that's going on and you know, ultimately no matter what the photo is, it would likely switch out. So lots for a lot of conversations. So the other one that people really responded to was this one, this was the other top pick. So, David, maybe you could talk a little bit about why you chose this one. I believe I had that you liked that one, right? Yeah, I just think, just the nature of the way the photographs are laid out, that would give you a chance to show like some of the, maybe the space photos. So you could highlight some of those shots there. But you also have, with this little grid, if you will, a chance to put some text and supplement some of the pictures perhaps. And of course, it's colorful. Lots of colors, and definitely yeah, I mean I feel if we were to look at the two in comparison, and you know this is where you can kind of talk about them back to back, you know, a much stronger sense of kind of a grid structure here, right? And that becomes almost more of a foreground element, where you know in this one it's played back a little bit and has that more playfulness, it's a little more asymmetrical, Hannah, as you were mentioning. And kind of allows for that, and that helps kind of set up maybe a little bit of a spectrum as you start to try to push that further about the types of thing that you may want to explore. You have these ideas of where you could go with it. Did you choose this one as one you liked? Yeah, I liked it. Okay good, so what did you like about it? I liked the hierarchy, and I like, it is quite versatile I would say. So you can easily apply this theme of our let's say administrative space. Photos and text, and it's legible so, and it would look good on many devices, I guess. Great, any other comments or thoughts that you guys had? We're kind of diving in. Lisa? If I were to compare this one to the other one this one's better for like, big images. Whereas those were like little tiny, you know, maybe on a landing page, I don't know, an archive, the other one. But this one's good for you know, strong imagery. Which was what we were talking about getting people excited about. Exactly, and certainly with something like the Ministry of Space, you know, we would really want to make sure that we had great images, which I expect we would. So there's a lot of opportunity there to kind of play that up. So great, so look at this as a really great way to have a lot of dialogue in a very relatively short amount of time to kind of pull these together. And this is something that now, coming out of this, you know you'll kind of be able to put some of these favorites into the product brief. And I think that really helps kind of kick off our last segment where we want to talk about this. So we've all this stuff that we've been gathering you know in this process. Goals, users, success criteria, we have some inspiration points, we have probably little bits of information we would have learned from the client just in that initial courting process, where does it all go? So for us it goes into the product brief. And the purpose of it is to kind of provide that larger context, so everyone knows on the team why we're doing what we're doing. And you know, in some ways this sounds really obvious, but kind of imagine that you know, as teams shrink and grow and people are gonna get moved off and they're like, hey you know, now Jim here is gonna be on the team, he's gonna help do x, y, and z. Before you spend a lot of time kind of ramping him up, send him a link to the product brief. He should be able to go through that and quickly get a sense of so much of the information. So much of the most accurate up to date information that's been captured here. The other thing is that it really creates very clear transparency with the client. So you know, that's kind of what's key it's lightweight but it's also shared with the client. It becomes this kind of more living document. So you're sharing it with them, and they're able to kind of quickly see like no that's not what I said. You guys totally did not hear that right. So instead of trying to present this as this thing where it's like, ugh we have to go back and change it, do another round of approval on this document that's still gonna be outdated, you know they can just go and either edit it directly or just kind of make a comment. And this is something, you know, we use Google Docs for ours and this is something that depending on the client and kind of the relationship and maybe even the number of team members, sometimes will give them complete access to go and add their own stuff in and change stuff and just like really just build it out with us or other times we might want a little more control for various reasons, and so we'll allow them to comment and so if they had something we can kind of either ask them a question or put it in and have that level of control. It's gonna be really kind of up to you on a per client by client, project by project basis on the level of control that you want to give your clients. So, you know, between teams and clients, it's really about kind of communication. And the thing that I want reiterate again is that there is no sign-off. This was like kind of the big deal that we really try to encourage when we do these things is that we don't want to go through this process and try to be like, okay now it's done. You know, that's just kind of, misses a little of the point. So even though we might have this kind of discovery phase and we move into these sprints we still may be adding stuff to this as long as it's helpful. There's a point at which you're gonna use it less and less but that's okay, you still have it so then months down the line you can go and reflect on it a little bit and just make sure, are we hitting our goals, are we making sure that we're kind of having the metrics in place to define success and measure that success and kind of do all of those things, are we making sure that we are targeting the right users, et cetera, et cetera. Now one thing you shouldn't worry about is you won't be responsible for all of this content. Because this can get potentially a little big, and it's gonna be a team effort. You know, everyone's gonna kind of join together and throw in little parts and kind of just work on it together as this kind of collaborative document, which is a great thing. And you know I have to reiterate that one of the things that was really kind of difficult but ultimately empowering is this idea of moving away from documents like this to be in some you know, tool that will do a better design to visually create something that's a little more beautiful, you know, like an InDesign type of program. But creating something that's more collaborative, right? Sacrifice the aesthetics for collaboration. It's very very important. The other thing is just, keep in mind that you only need to fill in the info that you need for that project. So I'm gonna go and show in the types of things that we're gonna put in here, but you may just need one or two of them. Don't feel like this is like, oh man, we have to go through this every single time this is ridiculous, that's not really the point of this. So first thing we want to kind of talk about is business context. If they start to get a little long, depending on the clients themselves sometimes will just kind of have a top level executive summary. What are some of the key insights or points that we just want to make sure they're kind of seeing as a way to draw attention to, because they are more important than all the other meat that's inside. The delicious little toppings. Make sure that the business and the project goals are in there, right? This is stuff that you've kind of teased out, part of the process that you've gone through to work with them and collaborate with them. We also really like to identify any business challenges that may come up, you know, what are certain things that we've realized that may add risk to the project. Just get them out in the open, like hey if one of the challenges is that your client is not available, put that as a risk. Just put it in there, and just point it out and talk to them and be like you know, one of the things that we're concerned about is we're not getting enough face time. Or the product owner is never really available and we're kind of all just going down and something's wrong when we kind of finish our sprint where it's not quite meeting up to expectations. Whatever it is, just start to put those challenges and some of those risks in there. And then of course success criteria. This will be something that may evolve, especially as they kind of figure more things out. They may not be able to identify success right away, but keep kind of asking that. Keep trying to get them to identify that. And you can also do that again for more, what is the short term success what's the long term success? So key findings, so sometimes what we might do and this depends on the project. We might do things like stakeholder or user interviews. So you know maybe it's a kind of thing that there's a couple key quotes from those interviews that we want to just point out, something that was really powerful became an insight. A heuristic evaluation of the site, so maybe you went through and it was an existing site and you kind of did a heuristic evaluation just pointing out some of the things that seemed really glaring and therefore areas of opportunity for you to kind of make some quick changes, or potentially low hanging fruit and it's just like let's kind of fix that and that will get us a good way to fixing this one problem. And then any user insights, as you're starting to do user research as you're starting to kind of learn stuff about them, also put in some of those key things. There's an assumption a lot of times that with team members, it's like oh you know we shouldn't put that in, maybe the developers don't need that maybe this person doesn't need that, but it's up to them as long as they have access to the product brief like this then they can kind of go through and at least they have access to it. But don't assume that because they're not in a role that's about generating user research that they're not interested in it. Put in who we're designing for. So this kind of goes into some of the prioritized user groups that we went through that exercise, as well as some of the personas, you know. If you're creating those that's a great thing to put in. Put in some design and brand inspiration. Now there's a bunch of stuff that can kind of go in when it comes to something like this. So mission, vision, value proposition, you know all those types of things can go in. Sometimes a client will already have that available. Sometimes they won't, same with things like core values or design principles. All of these things kind of the first four here, mission, vision, values, value proposition, design principles, voice and tone, those may be things that already exist even on their current site. Or they may exist in a separate document. So I always like to take that stuff and just put it back in the product brief. Because, you know, my team members don't know where to look for that, they're not going onto the site and having access to it, it's extremely valuable information and as you go through kind of capturing some of the features, functionality and just thinking about the overall experience, you can go and tie in your design solutions based on you know some of these different values. It's a really great way to kind of root stuff in meaning. Rather than just kind of, you know, what you heard. And your clients, don't assume that they're always up to date on this stuff either. If it's a big company, you know, they may have never seen that stuff before. Or maybe they did on some sort of onboarding process but it's been a while and all of a sudden they're gonna be like, wow you're really paying attention. Like you are really kind of going through and you know, care about what we're up to. And the other side is, you know, as designers there are also opportunities for you guys to help create this stuff. So if they don't have it, then it could lead to new tracks of work. Mood boards and style tiles or results from a gut check, you know we just put all that kind of stuff in there. And then also inspiration points. You know, that is something that they may have sent to you and you may have asked for them early on so put those in there as well. It's amazing how many times I'll go back and look at some of the inspiration points and be like oh yeah, they really responded to that, you know, why was that? Even as you're kind of going through some of these exercises later on. Competitors, this is an area that we really didn't talk too, really at all. But I don't want to completely ignore it. It makes sense to kind of pay attention to you know what your competitors are up to. Kind of looking at a competitive landscape, what are the different kind of areas. What are the direct competitors, indirect competitors, where does your product or your website fit within all this stuff. And this kind of becomes it's own key type of thing but really important and worth acknowledging. And you can kind of flush out some key competitors. Where maybe you want to have like an image of the site and kind of put in some of like the primary features or primary content that maybe makes them different to your experience, or even similar. You know, where is potentially the overlap. And there's a couple other sample things you may want to put in as well. Sitemap, you know you might have generated a sitemap early on, this could even be like very low-fi. Maybe in a workshop you have sketched one out as part of just a workshop with your clients. Take a picture of it. You know, same with wireframes, just sketches on post-its. Take photos of them, throw it in. Maybe they have a little more fidelity than that but whatever your working on just kind of show that there was like the thinking there and there was ideas there. Use cases, you know, user scenarios, these are also great things to put in there if you've generated them. User flows, you know, maybe there's some kind of key tasks that are really really important that you would want to kind of highlight because they're so critical to the experience. And you might want to put a couple of those in there. This is not meant to be everything. And I think that's the important thing. This is not the catch all for all the types of deliverables. This is really kind of about that discovery process to kind of show that, you know, you're on the right track and the thinking is there and you're really trying to think through some of their challenges and say a key user flow might be something that is important because it's really required, it's kind of meeting the needs of a primary user group as an example. Sometimes early on, we'll also kind of have a page of just high level epics that we've listed. And we be like, oh we started hearing some, boom, we're just gonna start to capture them in here. Eventually you won't need to because you're gonna start to be using a tool like Confuddle or something like that but this is really kind of early on in the process where maybe you haven't started throwing them into a tool like Confuddle quite yet. And then even a prototype. Now with this, you'd likely just have a link to the prototype and that way there's always an access point so if people have questions they can kind of know where to go and grab it because obviously it's a prototype so it's gonna be a little bit of a standalone thing. So it's either gonna link to a browser that's going to have, you know, an HTML prototype or to something like you know InVision or many of they other types of prototyping tools out there. One of the last things, might be the last thing, technical requirements, right? Now this is an area that is gonna be the kind of thing as designers you won't have that much kind of input in, but you should be aware of it. What are the browsers that you should make sure you're trying to support, you know, just get it out there, right? Now this could be something that was listed as part of the requirements in say an SOW or a statement of work, or even in the RFP process, the request for proposal process. Put it back into the product brief. Because again, your team members might not all have access to some of those documents. Some of those documents might be a little more executive level, and it's not shared across everyone. So pull out some of that information, put it in here, and just make sure everyone is very clear with some of those things. Even third party integrations, technology architecture, all of those types of things. Delivery process, who is going to buy the url, right? I don't know if you guys have ever done that, you're kind of like going through and you're like oh man, we're kind of getting close to launch I wonder who's gonna get that url purchased, you know? It's like, is it even available? Huh, we gotta start getting on that. Who's responsible for that? So just being able to have that kind of conversation early on makes a lot less freak outs happen later. And then kind of some time line stuff. So what we like to do is we'll put in kind of some major milestones and you know any kind of third party integrations where we have to kind of line up with stuff, like all that kind of stuff can also be put into the timeline to some degree just to make sure that it's lined up and people are very aware of those kind of key things. If you don't, then all of a sudden, you're gonna miss something. There's other types of things that you may want to put in the timeline as well. Certain things like, you know, maybe there's just like a very important date where there's a stakeholder review for example. Now this is kind of going independent of everything that you guys have done and you're kind of working very hard on your sprints but all of a sudden you know a month from now there's a stakeholder review a big board meeting, and all of a sudden you have to show something. Well that's gonna potentially derail some stuff. So just kind of put in here, so it creates that transparency. Those things often kind of pop up a little unexpected but you know the more kind of transparency you have the better. One thing that's important is that this does not negate the fact that you will likely need another kind of communication tool for your kind of project management, right? So something like base camp, slack, there's other kinds of tools that you can use to help communicate that stuff, you'll likely need something that's a little more robust and can count for that change. So this is kind of a quick example of our product brief. Just a screengrab that you'll get if you buy the class and it just kind of shows a lot of the types of things that we started to fill out. So you'll get a sense of where you can kind of make this your own and that's kind of what's great. I would encourage you to take this, make it your own, figure out the types of things that you'd want to put in and start to streamline it for the types of communication that you want to have.