 Okay, it's about time to get started, so thanks all for coming. What's on the menu for today? At least for this session. The usual hellos, but what I want to talk to you about was a kind of a strategic design framework that we can use to help define the strategy for a product, a service, or a project, and how then design as a craft can help make that strategy more concrete and specific so that we can actually make it happen. So we're going to go over the framework, a model for that approach, and once we've done the theoretical bit, we'll look at some practical, more deliverable, focused things that you can do to get started with this approach. My name is Roy Schulten. I work for Wunderkraut in the Benelux as a UX designer, and I'm also a longtime Drupal Core UX designer and contributor. So I work a lot with designers and developers at the same time in the teams and with clients. And boy, are we busy making all the things. So, of course, designer and developer collaboration is a hot topic these days and has been for a while now, and we've basically already agreed that we don't want to keep throwing Photoshop files over the wall to get them implemented. We want component-based layouts and modular style guides and getting coders and architects involved sooner so that we can make the right decisions. All that jazz, but even if we agree on all of that, there are still challenges, right? The designer has some kind of input, and from that the developer is supposed to make something that is shippable. And there's a couple of differences in that. Design is explorative. It diverges, it creates multiple options through sketching, and the starting point is this whatever kind of plan, and we'll talk about the plan a bit later. But there's a plan or a briefing for the project, and from there the designer generates multiple options, sketching, mock-ups, reworks, and then the three or four revision rounds that were agreed upon in the contract. But there's always multiple designs being generated before development can do its thing, and development has to be convergent because what we're actually going to build has to be that one shippable release that we're working towards. So the work or the spec needs to be unambiguous and very specific. And those are two very different mindsets. They're not exclusive. People can have them both or switch between those. But that difference in approach, that's the thing. But in the end together we, of course, iterate towards the right solution. Based on the plan we get to something shippable. So at this Drupalcon you probably have a lot of sessions where there will be lots to learn about this process, about how to design and build the things the right way. But today I want to talk about how you can help ensure that you're spending time and energy on building the right thing. So what can we do to know that we're building the right thing, that we're spending our energy and resources on, yeah, the right thing in the first place. So yeah, Mike Tyson notwithstanding, there is this plan. Something that gets you started to start creating a design. But designing and building that solution that is equal to providing an answer to a question, right? So then the question comes, where does this plan come from? What is this question? What happened so that this input we got for design and build became the plan in first place? So what happens before we get to designing and solution? Get to designing and building a solution. What was this question? So this is basically one way of framing what a UX designer's job is. Bring these three worlds together. The organization as it's the client, the organization as it's business goals. Technology provides the possibilities and the constraints of what we can do. And design represents, in most cases, the user. So what does the customer or what does the user need from this thing? And in the overlap of these three domains, there's the potential for a successful project or product. And in this talk, although design usually should be focusing on representing the user, I want to more highlight what questions we should be asking to highlight what the business needs are when you're starting a project for becoming successful there. So in that middle there, that's where the overlap is. That's where basically the plan should be defined. So what I want to talk to you about is the framework. We call it the double diamond. We've seen the first part of it, the design and the develop phases, based on a plan getting to something shippable if we move that to the right a bit. And you see that we first have, indeed, to define the problem or the opportunity. What is the question? And from there, so there's an initial insight or there's an initial trigger that requires that there should be a project. There's an opportunity to do something. From that insight, we have to then discover why we should be doing something with it and then define how we take on that challenge or solve that problem. And from there, we get a plan. So to discover, define, design, develop, roots, those are probably not unfamiliar words. Every agency has its version of this process. But we'll walk through this one in a bit more detail. Definition and execution. So what do we define first so that we can execute on it? So first, the actual insight. There's this initial trigger, right? This scan often should be based on insights learned or gleaned from the user research. We got a good example of this. This morning at the keynote where a usability test provides good input for knowing what we should be working on. But there's business reasons as well. And it's a good idea to find out that perspective as well if you're starting a project. So can we know what is the reason this project got approved? Do we know who the project sponsor is and what is the high-level goal? So luckily, businesses are basically quite simple creatures. They stay in business by either or increasing revenue, so selling more of the thing. They decrease costs, so making it cheaper to produce and sell the thing. They can increase by creating new business, so finding new customers. And they can increase existing business by selling more of the thing to the customers they already have. And that's the last and a bit more complicated one. Increase shareholder value. So that's obvious, but for now let's say that's basically about making sure the business can survive in the long term. But you can imagine that if you can ask these questions, are we here to increase revenue? Are we here to decrease costs? That's a whole different project. If we want to increase new business, that means that we're looking for new customers. That's probably more an innovative project than decrease costs, which is a project to optimize the existing processes and just reducing costs. So knowing this, if we're trying to innovate or trying to renovate or just trying to slim down the existing stuff, makes a big difference in the approach you're going to take. Another question to ask at this point is, what is the main purpose of this site? Is it a sales channel? Is it for customer service? Is it for brand awareness? Is it educational? Is it for entertainment? Very simple basic questions, but good to have on your checklist when you're discussing this potential project or discussing this project. So that's the kind of things you can ask when finding the reason that we're even having this project. The discover phase is about finding out why we should be even acting on that insight. So we have to build a rationale, we have to ask, answer the question why we should be doing something about this. So we have to basically frame the opportunity. So you have to discover why. And that means that we need to get clear about the market, the customer, and the product strategy. What do these mean? For the market, that means who are the competitors? So who are you competing with? What are the other organizations doing the same thing? How are they different? How do they position themselves? What makes them unique? And can we tell if there are any trends in the market that should inform what we're going to do? A lot of this information is often already available in the organization, right? The point is to ask your client to provide you with that information as well. We also have customers. Do we know for whom we are doing this? Is this a new target audience? Is this an existing audience? Big difference. Who are these people? And what do they want to get done? So for knowing, learning about who the customers are, of course there's the personas, the characteristics, the descriptions, profiles of archetypical users. There's user feedback through whatever surveys or customer service calls that get logged, that we can know what the customers are really looking for, and of course there's analytics data. So this is input for knowing who the customers are. And if you know the context of the market, I know what the customers are in that context, we can make some first high-level descriptions of the product strategy. So lots of bit more buzzwords then. Value proposition, so now we're starting to write our first outline of what this project or product could be. The value proposition is what is the promise of the value that this product or service will provide to the customer, and doing it in such a way that the customer actually experiences it as value. The best way to word it is to be able to do it in a single tweet. So can you formulate what this product will do for you in a single tweet? Then if you've got that and you've got the core of what the project should be doing for you. From that context, you can then start saying, okay, that means that we need this and this and this feature, and we can prioritize the initial scope or plan for what we need to be making. So in answering the first question, why we should be doing something with this, we need to get a picture of the market, the customer, and the product strategy. And the client often knows about market and maybe also about product strategy, and it's often that UX designers find that they may need some help with getting the picture of the image of the persona or the customer better, getting it right. But we want to ask these market and product strategy questions as well. It's not necessarily our job to help them define those, but we want to know so that we can get direction for what we're going to do. Okay? So if we have answered why and we want to proceed, then we have to start formulating the plan, define how we're going to solve this problem or take up this challenge. So we now have a more or less solid grasp on why it's a good idea to pursue this project. We want to now define how to tackle that. You do that with developing a concept. So a visual and interaction concept. You define an experience strategy. You define a content strategy. What are those? So for the visual and interaction concept, it means that we do design mock-ups. We create vision pieces. This is not the actual Photoshop file of the homepage, but this is the larger image of it's going to be something cool like this, a vision piece. For the interaction part we want to do, maybe we want to do customer journey maps. Customer journey maps are basically plotting all the interactions, physical and digital that a customer can have with the product or service. So that starts with seeing an advertisement for a new dishwasher somewhere on the street to looking that machine up in the store, to ordering it online, and to finding the customer support phone number after two years when the thing needs a repair. So it's the big picture of all the possible interactions that a customer can have with the product or service that we're designing. So it's very good for finding out where exactly you can be most effective, because people get more or less happy at certain points in their journey and where they're less happy. They can maybe do something on a similar but somewhat smaller scale that we find the main scenarios. So what are the main scenarios that we have to provide, have to enable in our project? A scenario is basically what happens at one of those points, interactions in the journey. So for now let's consider that this, just from the digital or online perspective, that would mean in the dishwasher example, are just the choosing, selecting an ordering process work, how does making an appointment for getting the repair appointment done? Those are scenarios within the larger customer journey and you want to create an inventory of all the scenarios you need to provide and you want to prioritize those as well. So that's your visual and interaction concept. How would it look and how will it feel? How will it behave? Another part of it of the how is, okay, what's the content strategy going to be? We have look, we have feel, but we have content as well, right? And for the content strategy we have to define so what is the messaging architecture basically, or the key messages? What is the core of the content? We have basic and key scenarios. We also need to establish what are the main, the key messages that we need to communicate? What do we want people to take away from us? And what is the tone of voice? What is basically the style of the content? What is the tone of voice? Is it witty and playful or serious business or something in between? And the third part of the how question is we want to define something of an experience strategy. An experience strategy consists of design principles. What are design principles? They are guidelines or rules of thumb for making design decisions even further down the road. The more detailed ones that we can't even foresee now. Design principles can help you still make considered trade-offs and make consistent choices. So a very typical example of a design principle would be that Google has one for speed over everything. Just with the rule of thumb of speed over everything enables them to make micro-decisions in whatever UI further down the road in whatever product. If the design principle applies and they have multiple options, they can ask which one is the fastest. That's the one we're going to take. Similar with Drupal 7, we had a pretty serious UX effort there, and likewise there were design principles defined. One of those was design for the 80%. So make the often performed tasks easy to do, make the rest doable. Or we also decided that provide better defaults would be a good idea. We didn't really do it. It was one of the design principles. So design principles are very useful rules of thumb that you can define from the outset that help you make decisions that take care of a certain kind of consistency in the design. And ideally, you can also agree on what are we going to measure so that we know that we're successful. So if we're going to formulate the plan, there's an experience strategy. Oh, sorry. There's a visual interaction concept, there's a content strategy, and there's an experience strategy in place. There's a lot of strategy for now. So we're in the part where we can say, okay, so that's the plan. What is in the plan? All of the above, just what we talked through. Put in a roadmap, or maybe a prioritized backlog, depends on how big the project or the services. But we have a plan now for how to evolve the product. Okay, so based on the plan, we're going in maybe some more familiar territory. I'll do this a bit shorter. But the design and the development are both about the how. So if you know why and what we can now dive into, how are we going to do this? Again, this needs content, this needs visual design, this needs interaction design. So for the content, that would mean that we find out what the sitemap will be, what the content model is going to be, and we make decisions about the information design. So how do we actually present the information? For the visual design, we go sketching, we create the style tiles and the mockups that further detail the actual look and feel of the application. And for the interaction design, the unknown wireframes, prototypes, and usability testing help us figure out the how of this project. So if the design is there, or at least enough of it is there, we can start develop it and even develop, means that even more detailed design is maybe necessary, all the necessary components, all the bits and pieces that make up the UI. Of course, preferably component-based and with a style guide instead of those eight or 23 Photoshop documents. We get to content production, writing the actual content, creating the actual imagery, creating the right photos, audio-visual material if needed. So we are doing production here. And yes, this is a UX-focused thing, and there's some code to be written as well, of course. And this back-end code implements, for example, the content model and some functionality, and the front-end implements the design, right, and the behavior defined in the interaction design. And then, iteratively, we can ship. And of course, we get to do it all over again for the next release or for the next version. So this is the double diamond. This is what we just went through. This is the initial trigger and insight where we have to answer the question, why should we be doing something with this, define basically the plan for how to go to tackle this, design multiple solutions, multiple options, generate multiple solutions from where we can decide what to build. We're going first, execute second. So now we're back to the point in the middle how to define that better plan. Because we talked through the possible steps in the first half of the double diamond. What can we do to create a better plan? So two things. How can we make a roadmap and how do we write a good project brief? So how do you create an initial roadmap in this discovery definition phase as part, basically at the end, resulting in a plan? So the good idea about the roadmap is that it helps with setting expectations in a world where there's never enough money or time to do it all. You need to chunk up the work and sequence it in a way that makes sense and makes your client successful and gets you to success as soon as possible. So what you want to do is gather all the insights, gather all the usability testing inputs, getting all the strategic input from the organization itself, group those in themes, so just put the related stuff together. And from there you can identify potential projects. So if this group makes sense, then okay, what would be a good Drupal grant project? Yeah, we're seeing that lots of people are failing because there's no on-ramp because we don't provide them with a guiding hand and getting the first steps. So there's a potential project there that we need to do and better on-ramping in Drupal Core, for example. So there's a couple of ideas for that and that would be project A. We would have project B, which is related to some other related efforts or problems. And so we create a list of potential projects. We want to rate those projects. We want to rate them along the pain that is being felt by the customer. We want to rate them for the effort required to solve it. We want to rate it by the value that it might bring to the organization. So what do we do? A three-by-three opportunity. So very painful at the top left. Not so painful, but quite confusing in the middle. No pain, but we see an opportunity for a real improvement at the bottom. Effort on the bottom. Small effort, medium effort, large effort. Just getting it done timing-wise, resources. And from there, you can then plot the projects. And you see the cost of getting it done is defined by the Euro signs on the dots. We can scale the dots. So if you map the potential projects in this way, you can then say, okay, where there's small effort needed to fix real pain, we have quick wins. We need to improve the confusing bits. And the opportunities are the innovative efforts we can do. So if we sequence that, because we want our client to become successful quickly, then we can then schedule the work and chunk it up and start with fixing the low-hanging fruit, improve certain things, and then look into where do we start innovating. So that's one way, a simple way, to create an initial roadmap for what you want to do in the project or in the product. But maybe you're not in a position really to contribute to the roadmap. Maybe you're a bit further down in the process. And you're not really at that table where this roadmap is being made. Then you still want to define for yourself, at the very least, kind of short-form project brief. So if you can do nothing else but ask these questions we've been talking about, and you have to select the minimal set of those, you would ask, for the business objectives, what are we trying to achieve? Why are we doing this? Answering the why. For whom are we doing this? What are those people trying to do? What are the main scenarios that we have to enable? And can we define some design principles so that we have some rules of thumb that we can make consistent decisions of, based off? Because design is not about getting it perfect, design is about making the right trade-offs. And design principles, as explained, help you there. Okay, so roadmap, project brief. Let's talk about one more level practical about deliverables. Two exercises are deliverables that are not the more standard wireframes and sitemaps that you may come to expect. Because I often see with the developers that when they get static wireframes, they have to reverse engineer where all the things are coming from. What's all on the page is a mishmash of fields, blocks, etc. They have to reverse engineer where all these bits and pieces come from. Because there's basically never a single source for what's shown on this page. So what can you do? What can you help define that makes that work easier? That's the content model. And this is something that's so natural to Drupal that we take it for granted. But this is actually quite, quite powerful. And you should make that... It's really useful to make that a concrete, specific discussion with your clients and the developer team. Because it's a really effective way to discuss what needs to go into the site and how that is structured. So what's in the content model? This one is a typical example of a recipe. The recipe has fields, as we know in Drupal, and it has relationships with other content types, like related recipes, related menus, reviews. You get the idea of a content model. This is a single content type in its relations. So what's in a content model? It defines the different content types, the fields that are in each content type, and the relationships between content types. This is very obvious for anybody working with Drupal. If you make that specific with your client, you can have a discussion like, say you're working with a special interest group that is pushing for some agenda, and you can start talking with them about content, not design, but you can audit their site, you can go through what they have now, and we know what they want to achieve, and you can talk about, I'm seeing that you have content that is related to the industry. This looks like industry topics. Makes sense, and that's something else than what you're writing for your consumer audience. We could do it with tagging, but it looks like they're two quite distinct things. And I see that you have a lot of audiovisual assets. Maybe we need a resource library. We need media assets. Is that a separate thing? Yes, yes, I agree. We have news, yes, and we have training and events, so that's probably a separate content type as well. And from there you can go maybe a bit deeper. So if there's a collective industry topics there and a collective consumer topics, and we can start talking about, okay, so what's a single topic then? Is that a content type? Yes, probably. And how does it work? Well, it's its own thing with a certain number of fields, but it also wants to point to facts and figures or reports or media assets that we have in the resource library. Yes, that makes sense. And from there you can detail the content model a bit more. And if you go another step where you start defining the actual fields, that's where the good old spreadsheets come in, of course, and that's where maybe the client doesn't want to be involved anymore, but this is a much more useful input for the developer or the site builder on what he needs to start with, what are the basic materials from which we can create those nice layouts. So if you start simple, you're just outlining the main different kinds of chunks of content you see in somebody's site or application, and you make that a discussion with the client, you get very specific about what's important to have. You can detail a bit more what the relationship should be and then take it to a spreadsheet and find out how we can import that to Drupal in the easiest way. But this is a much more actionable input for the site builder or developer than the wireframes where, like I said, they have to reverse engineer where things are coming from. So very basic taking for granted Drupal concepts but make it explicit with your client and you'll have very useful conversations. Another thing you might want to consider is instead of the static wireframes again doing the prototyping, because especially if we're talking about scenarios, then it's about the flow and it's not about individual screens but how we can make people work through a sequence of those screens. And wireframes, especially printed ones, are not going to really simulate that very well. And it's in the simulation that you have real value there. So a prototype and you may decide for yourself what tool kit you're going to use, be it HTML, clickable wireframes maybe, or even quick and dirty Drupal configurations. But a prototype, early sample, something to throw away, but it's built to test and has a thing to be learned from. And those are two very important benefits for prototyping over wireframing. Because it's easier to understand. If you can actually use it, more people can understand what's the idea behind this. And if they understand it better, they can get you better feedback. If we choose HTML, then we can make responsive prototypes. And then we can better manage the expectations from the start about how the look and behavior are on all different kinds of devices. If we're working in HTML, it's shared and updated easily. We provide some URL, put a password in front of it if you want. And people can use it from their own device. And they go, ooh, it works. And that creates buy-in. And that creates enthusiasm. And buy-in is always good to have. So people get enthusiastic there. Because they can use it on their own device. It kind of works already. Great. What I also find with prototyping is that you can't get away with a lot of mipsum or filler text as easily as you can in static wireframes. Because we're trying to get a grip on the flow, we have to provide actual content, put the right words on the labels of the buttons, et cetera. So it makes content earlier part of the process. It's a nice way of working to get both the designer and the copywriter and the developer together around a single deliverable, basically. Again, shared understanding is a good thing. And because it works, because it's clickable, we can test it with the audience. Yeah, a prototype is worth 1,000 meetings in the sense that just feeling it work takes away a lot of the yes, but and doubts. People might have or think they should have, just to have a voice in this. Okay, to recap, ask the simple and hard questions. When you're starting an engagement with a client, be very specific about that you want to know why we're doing this. For whom are we doing this and what are we trying to make? Are we being innovative here or are we optimizing existing stuff? All those examples. Why are we doing this? What is the opportunity? What do you really want us to make for you? And then it's up to us, as designers and developers, to get the best possible answer to that question. Ideally, you get involved with defining the roadmap. That could even be from the technical perspective, right? Just being able to help define how many dollar or euro signs should be on those. Subprojects can help prioritize things because you know you can make a rough assumption about how much work it will be to create or do that fix or new idea. Know where you are in the process. So consider this flow. If somebody comes to you and say, yeah, cool, go design this. Here's a couple of wireframes. And you can use this basically as your checklist to see if everything is in place from the steps before it. So too many words on a single slide. But if you're asked to do the design, then you should double-check if the why and the what answers are in place. Of course, you don't have to do everything all the time for every project. You do a quick scan and you see that, oh, this client knows what he's up to with the strategy. But he may need some help with getting to learn his customers. They have actually, oh, the concept makes sense. But maybe the content strategy needs some work. So you specify and customize this for each engagement. At the very least, try to formulate the project brief even for yourself because it often seems that this whole design phase is over and done maybe. So here's the stuff, go build it. That's usually not true because when you start building it, problems will surface. So I insist on creating that short form project brief. It's valuable input for prioritizing the stories in your backlog. But also because it's very likely the design is not yet done, all these unknowns will surface. And you can then refer back to this briefing and help the client and yourself make the right trade-offs. So that's basically what I had for you today. I hope that just getting this big picture maybe helps you frame or understand what you're seeing and hearing and learning in follow-up sessions in the content strategy track. Thank you very much. If there's questions, I'll take them. Yes, I'm being accused of waterfall. Yeah. So another way to think about the first half is what in Agile is called Spring Zero maybe. You need that. And yeah, you need that preparation work done. And you can be as heavy or as lightweight as the project requires. But it really, really does make sense to get not the big design up front, but the big idea up front, right? And that's what that discover and definition phase should do for you. Because you want to end up with a backlog that makes sense. And feel free to sprint and iterate through building the solution. But, oh, even... Of course, you have to revisit the actual idea again as well once every exact amount of time. And that depends on the size of the project and the lifecycle of the project, of course, how much that needs to be done. But yes, you have to revisit your assumptions and you have to revisit your assumptions in the plan as well. But yes, I kind of still assume that time is a linear thing, so we need to do that thing first and then we can work through it. Thanks again. Come to the sprints. Talk all the UX and design stuff. Did I miss a question? Yes? So you're saying in the... So in this first discovery phase where we ask why that we have to create a picture or knowledge about the customer. You're asking how do we make sure or validate that what we think we know about the customer is the right thing? Yes? Yeah. So one of the things is that even in the definition phase where we create the concepts, like the outline of the answer that we're going to build in the... the outline of the answer for the question that we're seeing, even there you can do high-level prototyping and get feedback from your users again. There's many ways, but it falls down to testing your idea with the audience once again. Yes? Well, it depends on again how many time... how much time you have and how much cycles you basically have or sprints to work through. But yeah, you should validate as soon as possible. Yes, come to the sprints. Do all the UXC things. And I'm curious for your feedback, so I put in what you think slide as well and give me your feedback. Thanks again. Yeah, so that's why I suggest that.