Presenting Your Design Work: Designing Your Project Story From Start to Finish | Jasmine Friedl | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Presenting Your Design Work: Designing Your Project Story From Start to Finish

teacher avatar Jasmine Friedl, Director of Design

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

11 Lessons (43m)
    • 1. Introduction

    • 2. Defining the Problem: Crafting a Problem Statement

    • 3. Defining the Problem: Evaluating a User Need

    • 4. Defining the Problem: Defining Success Metrics

    • 5. Crafting Your Process Flow: Putting Together an Outline

    • 6. Crafting Your Process Flow: Collecting Process Steps

    • 7. Crafting Your Process Flow: Polishing Your Story

    • 8. Designing Your Deck: Determining and Applying Style

    • 9. Preparing for Speaking: Capturing Your Speaking Notes

    • 10. Preparing for Speaking: Preparing For Engagement

    • 11. Preparing for Speaking: Review And Practice

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

Have you ever gone into a design presentation and lost complete control of the direction of the conversation? Or the feedback you’re receiving isn’t quite what you’re looking for? This class will help you craft your design presentation for interviews, critiques, and product or design reviews. This class will cover problem framing, narrative, style, and engagement, and it will help you architect and design a presentation that you can modify for multiple scenarios.

This class is for product designers and UI/UX designers who desire to have clear, concise, and effective presentations of their design work at different stages of the design process as well as for different audiences. There’s no experience required, but it is helpful to have a project—even a small one—to use for the lessons.

Materials Needed: 

A presentation program like Keynote, PowerPoint, or Google Slides are free and effective tools to create your presentation.

Meet Your Teacher

Teacher Profile Image

Jasmine Friedl

Director of Design


Jasmine Friedl is the Head of Design in San Francisco at Intercom, and has built and led design teams at Intercom, Udacity, Chan Zuckerberg Initiative, and Facebook.

Education has been a driving theme in her work, both in career and other investments. At Facebook and CZI, she partnered with Summit Public Schools to develop and build a personalized learning platform for K12 students. At Udacity, she led design and research to democratize technical education. She's also taught interaction design at the Academy of Art University, and works with her husband Tanner Christensen to develop tools and resources to help new and transitioning designers by building educational tools and resources for design.

Jasmine lives in the Bay Area with her husband and f... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Introduction: Hi there. Super excited that you're here. We're gonna talk about how to present your design work. So you think about the times when you actually have to present design work, usually come up in the form of a couple different scenarios. We'll give you a few examples. One is an example of a critique. Critique is this thing where you go into a room with a bunch of your peers and you put your work on view in order to get feedback or insights to make your design better. I'm another example where you need to present your design. Work is in something like a design review, which might feel a little bit more formal. Design review is something usually where stakeholders or other decision makers and even your boss have to choose the direction or give you feedback in order to block yourself or direct the progress in some way, or make sure it's hitting goals. Another example of sharing your design work comes in the form of interviews, So interviews are these things. When you really look at them, you going into a room with often strangers to show not only your design work but who you are as a designer what your skills are, what your values are. So these are all the different range of examples where you need to show your design work. The purpose of this class is going to be able to help you break down into a framework. How to put that design work together into a presentation and hopefully you'll be able to use that for a number of different scenarios. So the four steps that we're gonna do to be able to get to the end of showing your design work are the following first thing we're going to do is really look at defining a very crisp and clear problem statement that we can build your process around. The second will be articulating your process into a really clear what we're gonna call it Project story. That's all the work that you've done to get to the current final place. How do we crack that in a really mean away? Then in the third part will take a look at how to design your death. When you're looking at presenting your design work. The deck is artifact in itself. So how can we design and apply style to that actual debt. And lastly, when you're thinking about presenting to people, it's really a conversation. So we want to help you prepare for a speaking engagement. And when you think of engagement, there some part of monologue to that, how do you prepare for your narrative, but also how to prepare for the engagement of questions that might come up from means many groups of people. So with that, let's dive right in. 2. Defining the Problem: Crafting a Problem Statement: it's in part one here. We're really talking about defining a problem, and the first part of that is to craft a really clear problem. Statement. The question, you might ask, is why we need a problem. Stephen for design work. When we're talking about you, I Baxter product design. People really use things that solve their user needs, And so that's why we use a problem statement. If we're just designing for the sake of design, it doesn't really stand the test of time. So this exercise, what we're gonna run through is making sure that we have a problem statement to start from . So how do you come up with a problem secret? Very simply, you can ask yourself what user need. Does this problem solved? That might be pretty straightforward. You might also already have one from your design work that you could just come to the table with, and that's great. If you don't have one, try and identify those user needs that your design work is going to be solving. It's not. Here's a couple of questions that you can run through. You can ask yourself what was difficult for users previously, and now it might be easier for them if this thing is implemented. How does this make users lives easier? What newer added value is being provided to the user? So if you run yourself through a couple of these questions, you're probably gonna uncover a couple of the core things the core problems or singular problem that your design work is solving. If you can't come up with a problem by asking yourself these questions, it's probably a good time to ask yourself why you started this design work in the first place. And if you're doing it for yourself or if you're doing it for users. The reason I'm asking you to go through this now is because when you get into a room with a group of people in, there isn't a clear problem, and you have a limited amount of time to be able to present your work. It's very possible if the problem isn't clear that you'll spend much of your time discussing the problem instead of spending it on the design work, so make sure that you have that clear and ready to go. If you do already have a problem statement, that's great. Now's a great time to evaluate, edited and see if we get it into even better shape. So we know that we needed to be concise and clear and well edited so that books can focus on what comes next instead of taking time to take in the problem statement. So really great exercise here is to take it through an elevator pitch. And if you're not familiar with an elevator pitch, it's something that you can say in a very brief amount of time. So, for example, you get into the elevator on the ground floor and you may only be riding with your partner in the elevator for a few floors. Can you tell them the problem statement in that short amount of time so that they go OK, yeah, I get it. This makes sense. So as you're putting this together, keep that in mind. It needs to be short and sweet. The other thing to really look at is, is this a people problem, or is this a business problem? So I'll give you an example of to those things, a business problem might be saying something like, We need to get more people into our service. We need more users. A people problem might say something like, Man users find it really hard to sign up on our page, and you can see the difference between the two of them. One is making it better for us as a company, and the other is making it better for users as people in their daily lies. And it's okay to have business problems that we try and solve. What you want to do is make sure that you have, if you are starting with a business problem, that you have a complementary people problem that you can speak Teoh. That's how we make excellent experiences. Another thing I'd like to add is once you've determined whether or not you've got a people or a business problem, and if you've got a business problem, you've added on the people problem. Make sure that you're working on the editing peace and to edit very simply, make sure you've added it down to the chairman that you need to share your problem statement. I'll give you a couple examples of problems statements that you can read through to determine if this feels right for you. It doesn't matter the scope of your project or you know how big hospital on your project is . Every presentation of work will benefit from having a clear problem statement to make sure we guide the design towards solving that problem. So an example of a sort of a small scope problem we could say, is something like a button. So I'll give you an example here in just a phrase. And so we're making a statement to say, Hey, we figured out that this button doesn't meet some accessibility standards and people can't actually read the actions that they're supposed to take on the button. And so the way we phrase this here is through just a concrete phrase or statement. Another example that I'm using with a larger scope project is something called a How might we? And we're really posing a question for ourselves to answer as we're going through research and design phases. So the example here is looking at you. How may we help people who are struggling to manage their money? How do we help them manage it on a day to day basis? And so that could be a bigger project, which might be the launch of a budgeting app Another thing that you could do here is justly use a simple framework that says simply, We're building What? For whom? Because why? So you can use any of these frameworks to make sure that your problem statement is clear. So once you really captured in crystallized that problem statement, make sure you document this in a really visible way. It's important that you're gonna guide your listeners and your viewers through this when you do your presentation. But right now, consider it really important for yourself that as you guide your process, work and understand how to put your story together, that you also are speaking back to that problem statement. This could just be a sticky note on your monitor that helps you move forward and the next separate and look at where this would be really important is evaluating that user needs. Now that you have that problem statement and that clear user need, how are we gonna make sure that it's a really user name 3. Defining the Problem: Evaluating a User Need: So once you've got your problem statement written down, maybe jotted down that sticky and it's really helpful to sit down and evaluate the need. So when we have problems that we've evaluated by user research, user feedback data critique all of those sorts of things, we have better confidence that we're solving people's needs in the real world when we have problems that may have been sort of just a problem you just observed without validating and are evaluating it or something that maybe you saw. It was a problem. But something else that is something that other people might not see is a problem. That's when we get sort of these arbitrary or fabricated problems. So here, what we're gonna do is make sure that we have really problems. I'll give you an example of some of these things. So example of an arbitrary problem might be something like we were talking about buttons earlier. This color doesn't pop enough, so we want to make that you know, more poppy, how we know that there's actually user need behind that. Is that something that we just looked at and said how we want to change? Then we're just changing things for the sake of change, we might actually be disrupting people more than bringing value to their lives. Something an example of the self driven problem might be, you know? Hey, I was looking at my feet the other day and I couldn't find a photo that my friend had posted. And so I want to make sure that my special friends get their photos shown first in my feet . That's something that I have experienced that I don't know if other people have experienced that. So that could very be very well be a problem that other people have. But I want to make sure that I've evaluated that first, to make sure that's a real problem and not just a self driven problem. Good design process is really gonna make sure that we have a problem. That is a real problem. And we talked about, designed for the sake of design already, which is sometimes good as a practice exercise. But when we're talking about wasting time just doing for the sake of design, this is actually something that could be really costly for a business. So evaluating the problem is very important in both your process, but also for the sake of this presentation. So if you don't know where you haven't evaluated the problem, that's OK. But I'm gonna ask you again some questions to help you through this. So the first thing I'd ask yourself is, Why did I even start this? And some of you may say something like, I was giving a PRD a product requirements stock or somebody came to me and said, I need a mock for this and that's OK. It's OK to look beyond yourself to try and figure out where this originated from. If you haven't gone to this process, or if you have, now's a great time to go back to that data. Those user insights the user research that you have to figure out what happened in discovery process that kicked off the more visual phase of design. And I will say, if there was no discovery process work, you don't have insight into it. You want to do what you can right now to try and understand that you're sharing the story will be easier if you have the supporting data and information, you need to really craft that problem, but you don't have to force it. Just know that parts of your presentation might be challenged. And this is a good exercise to just go through to really understand what you know and what you don't know. So once you've established that, the need does actually support the problem and have some backing for that you want to collect all this and protect this away for part two. When we start to look at designing your process right now, we're gonna look at metrics for success. 4. Defining the Problem: Defining Success Metrics: soon the last part of defining a problem. We're gonna wanna look at defining some success metrics. So we already have the problem statement, and we have evidence to support that. This is a real problem that we're solving. How do we know if our design work is actually going to solve that problem? So now you're gonna want to share the plans or how you plan to measure success. If you don't know yet, that's okay, too. And this piece really circles back to that user problem. So if we have that problem, we see that that in the beginning, if we launch this thing, if we should this thing to users, does that problem go away? Does that added value get added on? And how are we gonna know that for there are many ways to look at metrics. And if you're lucky, maybe yourself for teammates have already done this for you. And this is just a matter of collecting materials. If not, you can consider the following. So there's definitely things that quantitative metrics and those are metrics that are geared around numbers that could be around things like task completion or time spent. How can you actually use data to measure whether or not the thing that you have implement has changed behaviors in a productive and positive way. You can also look at things like qualitative measurements, and these are things that we really need to understand. It might not be a strict data point, but we can dig in to a little and see how this has changed people's lives. This could be something like using interviews to evaluate satisfaction, and they're doing some sort of concept testing. You'll see both and user research qualitative definitely leaves heavier on the user research side. So let's take some examples from our problems. Statements from before the 1st 1 that he had was a small scope, which is the button. So how would we know if we changed our button color to be more accessible? How would we know if that was a success for the users who were having those problems with it? We could look at understanding that click through rate has improved, so people are actually able to get where they want to go by clicking on that button, because now they can read it or we could look at fewer support tickets. Maybe we had a lot of people writing in to say he can't read this. Can you fix it? There's a lot of ways that you could actually measure how to understand if a color on a button is more effective or not? In the largest go project, we were looking at the budgeting out. So how would we measure if a budgeting apple is successful or not? And here we were looking at this in the context of being a new product. So there wasn't one before, and now we launched it. So we don't have anything like baseline metrics so we could look at something like maybe we estimate the amount of new users we expect to have, and we hit a target of X number of new users. Or maybe we want to hit a quality rating such as, ah four plus star rating in APP reviews those air some ways that you can measure projects of different scope. So once you've got your ideas for how you measure success or you collected them from previously, you want to set them aside because we're gonna come back to that. It will be important to share and you're the beginning of your process. How did you think you were gonna measure success? And then also looking at the end of the process, If you were able to shift this thing that you're sharing or launch this thing that you're sharing, how do you know if it was successful? How does the actual performance match up to what you project it? So now you've got all the prep work done to have a very clear problem. Statement. You've got the statement itself. You've got evaluation, your user need, and you've got a determination for how you might measure success. Next, we're gonna die into the meat of the process. And that's how we put your project story together. 5. Crafting Your Process Flow: Putting Together an Outline: All right, so in part two, we're gonna be looking at crafting your process flow. And the first step here is really about just putting together an outline. So in part one, we did a couple really key things. We put together a really clear problem statement we evaluated the user need, and then we determine what our success metrics would be like. And those are really gonna be fundamental to our outline because the outline is going to tell the story of how we solve that problem. He stated at the beginning. So make sure you bring those back to the table a couple things when we're looking at creating an outline, we're gonna be working really low fidelity. And that's important because if you're a designer, you know the design process is very messy and complex. If you were to do something right now, like jump in your sketch files and look for key moments, what you probably do is you probably find yourself very in the weeds very in the details, and we want to stay really high level right now. So I would advise not going into sketch and just taking a simple tool like a bullet point list or a regular list or stickies that you could move around on a table that indicate key points in your process. What I wouldn't do right now, besides, going into your sketch files, is probably looking at something like a shell duck. If you're putting together slides at this moment, it's really hard to understand. High level flow out of glance. So stay and work pretty low. Fidelity. Whatever format you choose, just make sure it's one that's easy to edit and evaluate. It's much easier to cut things down than it is to add things later. So working lightweight helps you define what that story is up front and very quickly. So what should go into this outline? We started off with a problem statement, and we're gonna want to solve that problem by the end of the story. But how do you tell that story for me? It's helpful to break these down into a couple different steps, and I'm gonna make up terms here but will define these for the purposes of today as primary steps and secondary steps and then the details. So what I define is the primary steps are really what are the key moments in the story. So if you were to tell the story at the very highest level, the very simplest form, what are the things that you would absolutely need to tell the story so they could be things like the following. They could just be the high level steps that could be notable, pivots or changes anything that just feels unnecessary to tell this story. So the secondary things were really going to be those moments and think of them as moments of their helpful that really give character to the story. And so those could be things that further defined the steps of your process. They also could be things that share your personal skill. Er, in trust things that you found interesting things that you found challenging, and then the last thing you want to look at his details and these are these little bits and pieces that give crystal clarity to your story. They could be things like fun, fax or just opportunities to show attention to detail and in depth for your skills and your values. You don't necessarily have to have comprehensive detail, but chosen details can really help tell the story that you want to tell now, as you're going through this, if you actually find it hard to recall some of these moments these primary second, a step secondary steps or these details that's okay. Some design process is a really long, and our memories aren't all that great. What I would do is be crafty, so go back and use tools that you have at your disposal. One might be something like going back to your meetings and meeting notes. You could also go back through e mails or files are maybe your sketch files at this point to determine what the right moments were? If you are stuck or having trouble feeling filling in the details, do go into sketch and do whatever you need to do to fill that out. Just make sure that you don't get lost in there and just a reminder. It's definitely helpful to have more here than less here. When we're talking about it outline. It's really low cost to scratch out a line item on that list or something that you think you might want to cover. It will be harder to bring it back in, so flush this out as fully as you can. And maybe if you're thinking of very simple scenario like a 20 minute critique, that's okay. You could still work this towards what a 45 minute interview would look like and get the right material so that you can modify. You'll save yourself a lot of work in the long run. So as you're looking at these steps against your problem statement, it's really helpful to start to evaluate now to determine what should stay in what should go. So which one's air telling the right story about solving the problem, which ones air supporting or might be tangential? Do they take the listener on the right journey towards the solution of the problem? Is that the appropriate context? Or do you have too much? What are the essential? That's to tell your story. What are the details? It's okay to have both, but you just want to identify them. So when you get to the editing, what you know what to keep and what to remove. There's also something here about what speaks to really good design. What is bad design and it's OK, all done bad design, and that's great. Sometimes we have to celebrate the risks we've taken and the failing moments that causes to learn. I think it's really important here, though, when you're showing designed to give it a quick evaluation and say, This is good This is something I'm proud over. This is something I might want to talk about a little bit more in depth and understand how I evaluated this is bad design but may have improved it in the long run. So what's helpful to do here is as you're looking through, just send a bullet point list. As you're looking through. These moments sort of know how they play into their your story and what kind of moments there in a simple tagging system, whatever you make yourself could be really valuable here. So we've been talking about definitely more more is better here, and that's definitely chew. But what you also want to do is keep in mind here. What what do you need to meet the objective of your story? So when you look at something like, you know, high level case study, you might need 40 different steps to really understand how we got that budgeting out from user need to actually something that got four plus operating reviews in the APP store. For a button, you might only need two or three steps. Or maybe there's more because you want to show the generative work that you did. But when you're looking at think of a minimum case than maximum case, what's the maximum I could tell this story at? And what's the minimum that help you flex in between these different use cases or different scenarios we've been talking about? I'll give you a couple examples, and we just went through these. So one example is the button. So if we knew that users had a hard time seeing our button because our button colors weren't accessible, how do you show that you're really making the right decision so you could just show, You know, we went from blue to green or red to blue to a darker blue. But how much generative work have you done to really evaluate that we've made the right decision? So if you're working at a system level, maybe like the budgeting app, you have a lot more decisions to make in what steps you're showing, because it could be an infinite amount So here. How are you prioritising what you're showing in order to tell the clearest story possible. So once you've got that outlined together, the next step is pretty straightforward. What you're gonna do is pull together those what will call illustrations. And again, they're not just illustrations, but the examples of work and process to be able to tell that story that you've already crafted through your outline. 6. Crafting Your Process Flow: Collecting Process Steps: So the next step in crafting your process flow is really about collecting almost process steps. So in the first session, in part to what we did was we went over how to craft an outline, and that was really looking at sort of a high level overview of what is the story of your project? What we're gonna do now is look at that outlining. We're gonna see how we can map are visual representations or illustrations of this outline 1 to 1 fridge of those steps. So this is fun. You're gonna dive in and get all of your password. So when you're thinking about what are the right visual representations, there's a lot of kinds of representations that you can use to illustrate this process story . The 1st 1 that comes to mind, which is pretty obvious, is mocks. So what are these sort of visual representations or the interfaces that you have designed that show the execution of your project to your process? And that's great. You probably have a lot of those, and for many steps on your outline, you'll actually have more than one visual representation, and that's totally fine. But as you go back further along your process, you probably need to come up with a number of different kinds of visual representations. Some of those could be things like data representations like charts and graphs and things like that on. You also may need to use text, visual or presentations, things like quotes on statements, bullet pointless other things like that. You also make it into things like images, maybe even emoji. What are the things that tell your story in the way that is most you? And so here you're not worried so much about designing these things, but just bringing them together and suggested I could give you as you bring this together. It's just try and keep them as organized as possible. And that could be through dumping a bunch of files into a specifically named folder that matches one of your outlined steps. It could mean just naming files as you moving them over and thinking about how we're sequencing them now. Sequencing is important part of this process to most case studies that you'll run through sort of run from a dizzy, and that's where I started, where he ended up and all the necessary steps in between, and that might have been how you crafted your outline. And this will work for most case studies. You also might want to think about a different approach, depending on the scenario that you're presenting in now. One scenario that we haven't actually talked about yet is a portfolio scenario where you're not actually presenting to a viewer or listener. So think of this like your online representation or a portfolio that you might send over to a recruiter. There are some steps that you won't have that are part of our process in this class, like preparing for engagement, but you can still use the materials to tell that story. So what I might suggest, starting with here is more of a newspaper approach. And so if you think of a newspaper, I know not all of us read the newspaper nowadays. But if you think of an article online, even what do they usually start with? They start with the big image. They start with a header, a sub header. And so those are things that you can usually get the gist of the entire article without reading through the whole thing. Now, the downside of sending in a tizzy sequenced case study over to a recruiter is that if a recruiter doesn't have a lot of time, they might not actually get to the end. And if you save the best stuff, for example, the final product to the very end of your case study, someone might not actually get to that good stuff and might move on to another candidate. So going back to the newspaper approach. If you want to really highlight what you ended up shipping or what you ended up launching up at the very beginning, along with a big, bold problem statement that might be in your best interest. But again, this is all dependent on the kind of scenario you're presenting for now, despite what kind of sequencing you choose, you choose what's best for you. There's one recommendation I do have, and that's always keep your problem Statement towards the top. Good design is about solving people problems, and we've already taken some good time to establish what those user problems are in your project. So make sure that you highlight those front and center as you're looking through how you do the sequencing. Remember how we were working very lightweight in our outline. That was really important for a reason. You could do the same thing as you're thinking about sequencing now, either through that outline through, a bunch of stickies on your table are also through a shelled up. That would be a good time to start to put that in. And here again, we're not doing a lot of commitment or design work or formatting to the style or consistency. What we're doing is just putting placeholder images or putting examples of what we might think might go there. You could always do a lot of Polish work, and we'll get to that in Part three and how to really design that decadent. Now pay close attention to your process flow and how you're telling that story in the sequencing. So you put together an outline. You've got your problem statement and all that beginning materials and and you've gathered all these illustrations rebuild your visual representations of the process. Whether you know it or not, you've essentially put together a narrative. You don't necessarily have the words that you're going to speak, but you have the steps in the story that I tell your personal story in the way that you want to tell it. So it's a good time if you haven't yet to get this into Michelle back. And there's lots of free resource is that you can use. You can use Skeeto Power Point. Google slides, whatever works best you. But what we're gonna work on Nexus how we really start to polish up that story? 7. Crafting Your Process Flow: Polishing Your Story: All right, so at this point in crafting your process flow, what you've got is a shell deck. You've got a shoulder with a lot of materials and visual representations that tell your story like any good design process. What we're gonna do here is take a step back, evaluate what's working, what's not working, and then polish it up to get it in even better shape. So what we're gonna do here is we're going to go back all the way to the beginning. Remember when we made that problem statement? Hopefully you've been using that as a guide to decide what goes in your deck and what doesn't and what tells that story of solving that problem. But now is a really great time to pull that out again and evaluate every process. Step against that problem statement. And it could just be a physical sticky that you're holding and saying Yes, this tells us to worry. No, this doesn't again. Before we mentioned that going generative at this point is better than trying to narrow in . So having a lot is better than having too little, because now it's time where we're really gonna edit out. So This is also a great time to evaluate what parts of the process the really good design process you should be including. And there's an enormous amount of steps, and this is just a list of some of them. But have you gone through the problem? Statement The evaluation of need, The user research, the data. Have you done great? You acts like jobs to be done. User journeys, information, architecture, wire frames. Have you done really great? You? I like you know, all the pieces of the visual journey, including many visual iterations, pattern libraries and systems, any sorts of prototypes or animations. What are all the things that you need to include to not only make sure you told your story , but that you're also sharing in appropriate design process. So as you're looking for your deck, now is a really great time to just start to make a rough notes in whatever comments or notes section that you have that tell your story and you can ask yourself questions like the following. Why did you include the step? Is this a primary step? Is it a secondary step, or is it a detail? How does each step speak back towards the problem. Going through and evaluating these will really help you continue to tell the actual verbal story that you're going to share with your listeners. Hear what you're also going to do is just note the areas of opportunity or the gaps that you have. A quick suggestion I have is even at this early stage, you might want to take this and read through it with a partner. So get all your notes down and just ask, Does this tell a comprehensive story? This is just like sharing early design work. You want to get feedback early on so you don't miss anything. And here you're gonna no one of note things like what areas are gonna cause confusion on what are things that are skipped over and also, are there areas that are redundant and boring. So any feedback you get early on will help you polish your presentation, and you may need to do this multiple times to get the right kind of feedback to get your story in the right place. Remember, many of these scenarios could be sharing your process story in your project, where with people who haven't heard this before. So when you choose people to listen and give feedback to the presentation as it comes together will be really critical to get the right kind of people to get the right kind of feedback to make sure you're speaking to the right audience. So now you've got your slides in hand and you've got your rough notes. There's a couple things we have left to Dio. One is to really get in and design that deck, and the next will be preparing for the speaking engagement. 8. Designing Your Deck: Determining and Applying Style: all right. So Part three is really about designing your deck, and here you're doing two things. What you're doing is you're making some design choices on style, and then you're gonna ply that style to your deck. And the thing to keep in mind here is that your doc is actually a design artifact in itself . So you want to spend a little bit a little bit of time here on these decisions. If you're presenting to internal stakeholders that light defined how you make your deck design decisions here and it might be different than if you were to present your own work to a body of interviewers, for example. So the reason I differentiate between these two is because if you're presenting internally , you may already have some decks that are available to you, and you may be able to leverage them. For this part. Many companies have pre defined slides and slide decks that you can use. It already determined which colors to use, which typefaces to use margins to use what kinds of layouts to use. So ask yourself that key question first, is there something that exists already that I can use and I should be using. If you're not designing a deck that's bound to something already branded, you may have the opportunity to Brenda's yourself, and this might be a decision around. Is this something that you wanna brand around your personal style? So are you choosing typefaces and colors and placement and things like that that you've already used elsewhere? Maybe in your website or something? Or is this something that could be done in isolation and have a little bit more freedom? All these decisions for me, it doesn't really matter which you choose that the encouragement here is to really be intentional about understanding the context before you make these design decisions. So if you start designing your death, you'll want to start with some really some fundamentals, and we're gonna use master slides for those. Every pervert that you work in for slight sharing will have some master setting and master slides air really just these things where you define style on them, and then you could just easily apply that any similar slides. So go back through your outline, turn, determine what kind of different slide types you have, And again, this is a place where it's helpful to just be able to breeze through an at a glance outlined to understand whether you have mostly data slides, mostly quote sides, mostly mock slides. Once you determine those baselines, you can understand what the variations of each slide tight might be, and I'll give you an example of that. If you're looking at mocks in, that's a visual representation of the interfaces that you've designed. There's many ways that you can show mocks so you might show them justice screens. You might show them in a device. You might also show them in different devices and so different devices. I mean, you might show an iPhone or an android phone or a dust top browser. You might show them individually. You might show them in sets. You might show them together with text. So once you define the different types of variations of each slide, you could make masters for these, and in doing so, you'll make sure that you have consistency across all of your slides. Other crucial decisions you'll have to make are just the basics of good design, things like type style, things like colors, things like margins, headers, all those different things you want to make decisions on those and define them within your master slide so that you develop a simple system of what your slides should be and you can even see in this presentation that I've designed for you. I've done a little bit of that. We have the same slide for headers. We have the same slide for sub headers. We have the same slide for resource is, and so creating those masters really creates consistency. But hopefully is a viewer. You're even able to recognize what those slides mean without having to die too deep into what they're saying. So the next step is simply, too. Once you have your master size, you're gonna apply these across all of the slides that you put together in your shell that can remember these slides from your shell deck came from your outline. Apply the master slides to them, and what you'll find is there's things that are working, and there's things that aren't working. So if things don't match up to your margins, if text tends to run over, now is a good time to evaluate. Reapply to the master slides and adjust throughout your whole deck for consistency. here. You're also gonna want to flip through your slide deck just to make sure you're avoiding things like text jumping, placement of images, moving around, having different screen sizes on different pages. Try for consistency here, and the best way to check through this is to just flip through the duck yourself. Once your duck is complete, you'll want to evaluate and reevaluate and adjust and keep Iterating because that's departed. That's a part of the design process. And then the next thing you want to dio is get ready for your speaking and we're gonna go over that in part for 9. Preparing for Speaking: Capturing Your Speaking Notes: So our last part part for is all about preparing for speaking on. The first thing that you're going to do here is prepare your speaking notes so there are some presentations that aren't gonna need notes and an example of that might be if you have an online portfolio that you're putting a case study together for, you could still put the slides together, but not necessarily prepared to speak to it. And that's okay. I'm for many of our other types of presentations the scenarios we talked about earlier things like critiques and design reviews or interviews. It'll be helpful to prepare your speaking notes in advance. So this session is all about preparing you to speak in front of people. So in an earlier session in Part two, I ask you to jot down some rough notes that go with your shell deck. So if you haven't done that yet, now's a great time to do that. Once you have those rough notes down to help you get to that more detailed presentation, there's a couple ways that I can suggest that you do that. The first might be to just record yourself on. You'll be capturing your own oral presentation. So by that we do is you just flip through your slide deck, use the rough notes that you have and just naturally speak what comes to you based on those notes in those slides. Once you have that recorded, you can just transcribe that by using a service or just by listening to it and joining the key points down so that you have what feels like a natural flow. So another way to do this is to just write out your detailed notes. And you could either do that by just extending on sort of the bullet point list that you have or capturing out more of a script. Whatever you dio, any of these options is OK, but you just want to do whatever feels most natural for you. Once you captured this, either verbally or by writing it down, you want to make sure you update your slide deck to have the most accurate notes. And then, as always, you want to evaluate and go back through and ask yourself what what is working well and what is not working on what makes sense, what is missing and it is helpful also here at this point to go ahead and have someone else listen to you as you're speaking with your iterated notes, to see if they're clearly understanding what you're trying to say, or if there needs to be some iteration on that as well. While you're doing this, it's also helpful to time yourself again. Some presentations might have a short amount of time saying maybe five or 10 minutes so might be longer. For, you know, a new interview presentation or something where you have maybe 45 minutes to an hour. You want to have a sense of how you need to expand or condense. Timing yourself, while speaking is really important to get a sense for how long this will actually take. Once you get into a room with people now, depending on your comfort level with public speaking, the next two steps will really help you get that Polish presentation 10. Preparing for Speaking: Preparing For Engagement: So the next party preparing for speaking is that preparing for engagement. So it's fairly easy to prepare for the one side of part of the presentation, and that's the part where you're presenting your slides and you're speaking to them. It is also really important to prepare for engagement. And that's what could happen when the people in the room that you're presenting Teoh how questions are are confused. These are things that you could also prepare for. So right now what I'm gonna ask you to do is think of what could go wrong. Really. What's the worst that could happen? What are the things that could slow you down? Or perhaps I plying your intent? What would prevent you from moving forward? The first of all, it's really helpful to write down your objective, and we've been talking through a number of scenarios. When you present your work and different scenarios will have different objectives, and I'll give you some of those examples again. So objected in critique might be to get a range of feedback on a specific thing. When we're looking at design reviews or product reviews, you might actually be looking to get a direction chosen or to unblock your work or to get a green light on something. If you're looking at the scenario of an interview, you might actually be looking to just show your best design skills and your design values to a panel of strangers or a panel of interviewers. If you haven't yet write this down at the beginning of your notes in case you need to address it and make sure you add this the beginning of your notes. Because if you need to actually say out loud that at the beginning of your presentation that hey, we need to agree on a direction by the end of this meeting will be helpful to make sure that your listeners can really focus in on that. The same thing was getting a feedback and critique. For example, if you want folks to go ahead and focusing on visual design, if you make sure that they know that that's what they're they're supposed to focus in on at the beginning of the presentation that will help them do their job as a complementary partner in your presentation next, it really helps to identify what are the decisions that you don't want to go back on, make sure you add it to your notes so that you can speak to that some examples of how to say this or things like in last week's critique, we agreed on going forward with this just to remind them that we don't want to go back and re hash that other decision. Another example might be something like, You know, I know there's gonna be a lot of questions that come up around other users, but for the purposes of this discussion, we're just going to focus on our power users again. These air cues that you could get people verbally that help them focus in and drive the conversation to the outcomes that you you need another area to know for engagement is known ahead. What are the areas that might cause confusion or might actually need discussion to bring to alignment? Sometimes we call this check for understanding, so if you're going through something that might be confusing or might need to be agreed upon, give space and included time in the space to when you need to check around with the others in your party to be able to make sure but he's on the same page or understands this might sound something like the following, so I know I've shot a lot of data. What questions do we have before we move forward? Or another example? In the next step, we're gonna move on to potential solutions. What other questions can answer to make sure we're on the same page with a problem? There's also simple and engagement tricks you can use like saying, Are we aligned so far and asking everyone in the room to either give a thumbs up if they're aligned or thumbs down? If they're not to get a general sense of the participants in the room and see if everybody's on board with you? As you're looking through these few opportunities to check for engagement, you really need to consider where is the best time for this. It depends on the engagement of the group. Some people will be much more comfortable asking questions along the way, and others will wait for the opportunities that you provide. So it's helpful to prepare for both. So it's also really helpful to make sure you're baking in time and finding the right slots for these questions and also understanding that they might occur naturally. So having spots to check for understanding or to ask clarifying questions is always helpful . They didn't your notes so that you plan to include for this note that you also should incorporate the extra time into your plan timeframe as well. Another helpful hint that I have for you is no that sometimes when you're doing a presentation, things will take a wrong turn. And that's OK if you come prepared with the script that says something like, That's a really great question. It's out of scope for the conversation we have, but we'll be sure to come back to that later. Something like that is a great prepared tool that you could bring to the table to be able to keep the conversation on task. So while you're preparing for these things, you might actually be unsure what might be confusing or what might be contentious again. It's always helpful to run this through in advance and prepare with a body of people or individual to help you determine these things. So again, the more polished that your presentation notes and you're speaking notes get, I would suggest that you run through this with a friend or a colleague or a teammate to make sure that you have an understanding of what might be confusing and what might be contentious and what might be easily understood, it will help make sure that your presentation goes as efficiently as possible. 11. Preparing for Speaking: Review And Practice: so the very last session of our class is on preparing for speaking. And here is just about reviewing. In practice, practice, practice. You've done all the work. Now it's just time to get comfortable speaking. So take a moment and again Go back to that problem, Stephen. What feels really true to solving that problem, what feels like it's drifted off? Topic You should always be evaluating and editing to get to the most crisp, clear delivery of what you're talking about. Now, if you haven't time yourself speaking and you should have by now, do it again, see if you added time as you get more comfortable. Script. See if you condensed time. Make sure the time fits within the parameters that you've been given. Also, budget time for questions and make sure you're ready to evaluate which questions are valuable to the discussion and which might take you off course and lastly, practice, practice and practice some more. The best presentations are the ones that feel like they're really coming from your natural voice. So when I talk about practice, there's 1000 different ways you can practice, and you should do as many of them as you can until you feel really comfortable. One of my feet practicing from your notes. One might be practicing without your notes. You could try sitting. You can try standing. You try practicing alone with people in the room. You can practice as you're driving in the car. You can even practice in the shower in the morning. You could practice with noise, even practice in complete silence. The more environments you're able to try and go through your speaking notes, the more comfortable you'll be for any environment. I can't emphasize enough how important that practice pieces. Once you feel comfortable and confident with your presentation. That's great. Go ahead and time yourself again. Make sure you're comfortable within the constraints of a product story that you're gonna tell and the time that you've been given. And even when you think you're ready, be willing to edit and inter it again until it feels like it's in a really great place. And with that you should be ready. Go get him