The web site of jiawp

Getting Started in UX Design

Are You Already a UX Designer? Intro Hey everyone. My name's Kurt, and I want to welcome you to Getting Started in UX. In this course, we'll be looking at what kinds of problems you would solve as a user experience designer, the skills you need, an example of a process you might use in a project, some of the deliverables you'll produce, and how you can get started in the field. By the end of this course, you should have a good idea of when UX is the most useful, some of the limits it faces, and whether it might be a good career choice for you. So let's dive in with the burning question on everyone's mind. What exactly do UX designers do? Well, UX isn't a highly specialized skill, it's a highly generalized one, so if you're interested in it, then there's a good chance you're already doing something that's a part of UX. It's this broad generalization that makes it so difficult to pin down. One way to answer what they do is by looking at the types of problems they solve.

What Problems Do UX Designers Solve? Let's say you have an issue with your credit card bill, and so you call customer service. After navigating around some menus, the automated prompt might ask you to put in your credit card number for faster service. Once you've done this, you get to talk to someone who will almost certainly want to confirm your identity, so they'll ask you questions like your address and date of birth. If they can't help, then they may transfer you. You'll hear snazzy hold music and automated messages advertising products or telling you that there are other possibly better ways to contact them. The next agent you talk to might also ask you to confirm your identity by answering the same questions. It's a frustrating process, and it's why most people don't like calling the big companies they buy services from. Phone companies are even worse. But let's say we lived in a magical world where large companies valued their customers' experiences. How could we make this one better? Well, for a start, why not skip having to type in your credit card number at all, and instead, have the customer service rep ask you a single question that identifies you reliably? Once they know who you are, they can see your credit card number and all the relevant details about your account. When you're transferred, why not have the system maintain your identity for the next rep so you don't need to go through authentication repeatedly. By shifting the burden of authentication from you to the credit card company, your task of calling them is completed faster and with less effort on your part. The experience has been improved, and at this point in our project to make calling the credit card company less awful, we've identified a possible objective, reduce the authentication burden on customers. But what skills did we use to identify this problem, and how will our solution actually work?

Skills and Challenges It may seem like common sense, but identifying this objective would have required some strategic thinking and leadership skills. Why were you looking at this problem in the first place, and if you were to fix it, what would the benefit be to the business? Did you convince your manager that this was something worth fixing? Next, you might need to do some research to confirm your theory that customers find the current system arduous, and to understand how the system got this way in the first place. All of this will help you to define the problem you're trying to solve. Once you have evidence that you're fixing the right thing and you know what constraints exist that make it the way it is now, you'll need to start to design a solution, and then you'll be working with development staff to get their input into your design and make sure that the final output of the project actually meets the goals you set out in the beginning. So for this project, you'll need to have the strategic mindset to look for problems, the leadership skills to convince your managers and team to tackle them, the research skills to confirm your ideas and define the problem more clearly, and the design skills and development knowledge to craft a workable solution. That's why UX requires such a broad skillset. Another of the big challenges you'll face is that nobody is amazing at all of the skills we've just described. Full confession, I don't really like doing research because I'm honestly not spectacular at it, and I've met people that are, and they absolutely love trying to get into users' heads and understand what they're thinking and why they're thinking it. Now, I love getting the results of this research, but I don't love conducting it. I've worked on teams with full-time anthropologists that would hand over amazing reports filled with insights, and I've worked at startups where it was on me to craft the surveys, pour over the videos, and test concepts on my own. As a UX designer, you'll find yourself in both situations over the course of your career, but Theodore Roosevelt said, "Do what you can, with what you have, where you are," and that's one of the core challenges of being a UX practitioner. Another challenge is that many people won't know what you do, so you'll also need to spend a lot of your time educating and building trust. In addition, you'll need to be educating yourself because the field is constantly changing. Ten years ago it had a bunch of different names, and 10 years from now it will probably have changed again, so you not only need to stay on top of best practices, but above the field itself and how it's changing and evolving. By the way, ABL isn't a real acronym so try not to drop it in conversation. Are you freaked out yet? Well, a little bit of fear's a good thing, but don't worry too much. There are few jobs that offer the variety, the challenge, or the opportunity. I've been doing it for well over a decade, and I honestly feel like I won some kind of career choice lottery. The demand for UX designers is huge, and while it will evolve over time, there will always be a need for people that care about making things better and can help bring it all together to create something amazing. Hey, you made it. That's the end of the first module, so let's review what we've learned. First, your job in the simplest terms, is to be the voice of the customer at your organization and try to improve things for them. We've also learned that you'll need to employ strategic thinking, leadership, and research skills, design, and understanding of development to accomplish your work. Finally, it's a tough job, and it demands a lot, but ultimately, it's incredibly rewarding and totally worth it. Sound good? Awesome. I'll see you over in module two.

How UX Designers Do Their Work Intro Okay, welcome to getting started in UX, How UX Designers Do Their Work. You just got the lightning tour of what a UX designer does, so in this module, let's dive a little deeper into a process you might follow to solve a UX problem. By the end of the module, you should have a good idea of the steps required in a basic UX project. There are many ways you could begin. For example, you could be designing a product from scratch or maybe you've been asked to look deeper into how an existing product or service works, or diagnose a problem. Regardless of how the project came about, you'll probably use an approach that looks something like this. Step one: figure out what you're trying to do and why you're doing it. Step two: get a broader understanding of the problem and some data to work with. Step three: create your solution. And step four: go test it. Having a process that you and your team trust is essential. If you've ever found yourself finishing a part of a project and not being sure where you should go next, a good process would have helped. Creating one takes time and experience, but even if you're new to the field, you can still evaluate a process. For example, it's more important that they be simple to understand and use than that they cover every possible situation in detail. They also need to be flexible in their application because no two projects are exactly the same. And finally, they should offer a variety of tools in each phase. Your process is a framework, giving you direction and options in order to reach your goal, rather than a list of hard and fast rules that should be followed. So let's look at each of the steps in more detail starting with defining the problem.

Defining the Problem The importance of knowing what you're doing and why you're doing it cannot be overstated. It seems obvious, but you'd be shocked how many projects start without a clear understanding of the challenge or how you'll know you've succeeded. Your job is to make things better for the user, but you also work for a company and you owe them a duty to help them succeed, so you need to both understand and embrace their strategy. Let's assume you're working for an organization that understands the benefits of providing a good user experience for their customers. To begin with, you want to make sure you understand their goals as they apply to this project. Are they trying to grow their user base, reposition their product, increase their revenue per customer? The company should have a clear idea of what they want to do and why they want to do it, and once you understand those reasons, then you can start to look for opportunities to accomplish their goals, while also helping the user. Too often, the relationship between companies and their customers are cast as zero-sum games, where the company's gain is the customer's loss, but this is a short-sided and wrong-headed approach. Increased competition, potential disruption, and eventual extinction of the outcomes for companies that achieve their goals at the expense of their customers. Uber is a good example of a company finding a way to exploit this kind of opportunity. They were able to identify a market that was stagnant and wasn't serving its customers as well as it could. They provided an experience that was markedly better by focusing on areas where they could improve people's experience and quickly win over customers. Finding ways to embrace your company's goals and achieve them by improving the experience of customers is really at the heart of your role. It's these opportunities that will end up defining the problem you're trying to solve. You'll know you've defined the problem when you can clearly explain why you're solving it and what you hope to achieve. In our example of calling the credit card company, their goal might be to improve their customer satisfaction numbers to reduce the number of people that leave and go to other credit card offers. So at this point, you have a hypothesis, that by making calls to customer service faster and easier, you can improve customer satisfaction and reduce churn. Sounds good, and the next step is to see if you're right.

Research The first thing to know about UX research is that it's practical research, and this means that your methods aren't going to be as strict as say academic research, and your results are unlikely to be concrete. Instead, the goal is to reduce the risk in a project by learning as much as you can, with as much certainty as is feasible. In a real-world application with tight timelines, multiple teams, and rapidly changing markets, there is generally overlap between the phases in our process. For example, you'll likely be conducting some research while you're working on defining the problem you're trying to solve; however, in this phase, we're going to focus on understanding who you're designing for and whether or not your hypothesis is correct. To begin, let's look at three types of research you could conduct. We'll call them deductive, interrogatory, and experimental. Note that these names aren't official or academic classifications. I just made them up, but they're meant to help familiarize you with the different ways you can learn about and test your hypothesis. With deductive research, you are dealing with everything you can learn without actually talking to users and stakeholders. You want to look for information that will allow you to infer a probable conclusion. For example, you could conduct a competitive analysis to see how other companies in your market are approaching problems, and what kind of successes and failures they're having. You could look for existing research on a topic related to what you're trying to understand, or best practices that are used widely and have been shown to produce positive results. You can look at or refine personas or journey maps that have been created for other initiatives. In short, you don't need to reinvent the wheel every time. Look around, see what's been tested already, and build from that. Interrogatory research is just an overly fancy way of saying, ask questions. This is an extremely useful form of research as it allows you to talk directly to customers and stakeholders, instead of guessing what they think. To address larger numbers of people, you could conduct an online survey. This works especially well for quantifiable data. This might tell you for example, that 30% of our customers chose frustrated as the emotion they feel the most when they call us. To dive deeper and to understand why people feel the way they do, you could conduct interviews or hold a usability lab where you can watch your users try to complete a task and then ask them why they made the choices they did. These activities will help you achieve a deeper understanding by allowing you to learn the reasons behind your users' actions or stakeholders' beliefs. These formats also allow you to go off-script and follow interesting branches of conversation, learn related items that are important, but weren't necessarily on your original agenda. Asking people what they think is one of your most powerful research tools, but sometimes you still need more. Sometimes people will say one thing, but actually do another, and that's when experimental research can help you. The most well-known form of experimental research is the AB test, where users are sorted into cohorts and then some are shown one option and some are shown another. Their responses can then be measured and the better option chosen. Sometimes there aren't two options to choose from though, and so another way to learn what users are doing is just by watching them. There are tools, for example, that allow you to see full video of users on your site, and the tech things like rage clicks, which is users repeatedly clicking on something to try and get it to work. They can show you how your users are actually using your product. Want to know how many visitors will sign up for a new product you're planning to launch? Put up a credit card for them and allow for pre-orders. Asking someone if they'd pay for your idea is one thing, having them actually pull out their wallet is another. On their own, none of these techniques can give you a complete picture, but used in conjunction, they can help you understand what users want and why they want it, which should help you confirm your hypothesis and move onto the next phase, which is designing the solution.

Design At some point in the project, you'll need to take all of the information you've absorbed and synthesize it into a solution. In my experience, as you start to compile more and more data and insights into a problem, ideas for how to fix it will start to just pop into your head. There's no magic here. Most solutions are just obvious reactions to well-defined problems. So you should be starting this phase with a hypothesis, gobs of useful data, insights, and at least a few ideas for how you're going to achieve your goals. Many people try to start this stage without doing the work that comes before it, but that always leads to trouble. Now how you synthesize all this design is a very personal decision. The tools aren't as important as your ability to work quickly and comfortably without distraction. If you're visual by nature, you could start by drawing ideas out on a sketch pad. If you're more predisposed to language, you could begin by listing out the requirements for your solution, or describing the features as a story, sometimes called a user story or a use case. Regardless of how you begin, the deliverables you'll create will rely on a few key skills. You'll use user interface design to create the interface that people will use to interact with your ideas, and you'll need to be able to write to communicate your ideas, and empathy to see things from the perspective of the people you're designing for. That last one is probably the most important and the most difficult, so let's take a deeper look at all three of these. The word design is used by many people to mean many things, so here, we're specifically talking about user interface, the thing that the customer will use to interact with your work. Many UX practitioners aren't UI design experts, but even if you're not the one executing the design, you need to be fluent in what makes a good interface. To that end, you'll need a basic understanding of color, typography, and usability. Humans are emotional beings, so what are you saying with the colors you've chosen? Are you using them to focus attention where it needs to be? Is the type you've chosen conveying the right message? Is it easy to read? Have you laid the page out in a way that helps people understand the information and move intuitively through the experience? Have you added any small points of delight to try and endear the experience to the user? These are some of the skills required to craft a good user interface. Beyond the visual, as a UX designer you're primarily a communicator so writing is of critical importance. You may be blessed enough to work on a team with a dedicated copywriter, but regardless, you'll need to be able to clearly communicate your ideas and evaluate the work of others. It's often said in UI design that people don't read, but that's simply not true. People don't read content that's boring, poorly communicated, and not of use to them. To create a good experience, you'll need to understand where and when to use copy; how much you need, probably less than you write in your first draft; and what tone it should have for your audience. As a UX designer, you won't just be writing for users. Depending on whether or not you're working with remote development teams or partnering with other companies to produce the work, you may also need to create documentation to describe how things work, and what the outcomes are for success. It's also sometimes said that clear writing is clear thinking, and critical thinking will be needed to evaluate the ideas throughout the process. Another skill you'll need to evaluate potential ideas is empathy, arguably your most important skill. One of your primary responsibilities is to evaluate the different solutions available and choose the one that will work the best. Thinking about not only the thing you're creating, but how it will be seen and experienced by your customers is essential for success. Where will your user be encountering your work? Does your solution account for their mood, or what else might be competing for their time; maybe they're watching a TV show or driving a car or talking to someone in a crowded bar. You'll need to understand and communicate not only how it works, but how it fits, when it will be used, and why it's the best way to solve a problem. Which brings us to our next point, which is testing your ideas and working with the developers that will help bring them to life.

Testing Your design solution is built on hypotheses, so you'll need to decide which ones you should test and how best to do that. It's generally considered a good idea to test your riskiest assumptions first, so if the success of your product or feature is resting on a single hypothesis or assumption, test that one as soon as you can and with as little effort as possible. To that end, the first thing you'll need to determine is how much fidelity your test needs in order to be effective. Earlier we spoke about research methods, but for testing we want more concrete results than the methods we described. Realistically, you have three options: prototype, MVP, and full build. These are in order by difficulty and as we mentioned, we're looking for the easiest approach that will be effective, so let's look at how you would choose and which ones you would apply. A prototype is something that can be quickly built and tested, but which doesn't have the fidelity of the finished product. It's just a tool that communicates the value and experience of your work. It can be something as simple as a paper prototype, a few wireframes printed out and shown to a user during an interview, or something more complex like a series of design mocks that have been uploaded to a service like Envision and linked together, or a simple HTML representation, allowing the user to click through static pages that simulate the essential experience of using your product or feature. If this isn't enough to determine the validity of your hypothesis, then you could build a minimum viable product, or MVP, leaving out some nice to have features that would have taken longer so you can get your work into the hands of users faster and start getting feedback. The concept of an MVP is more challenging than it appears as you need to strike a good balance between doing the minimum amount of work possible while still creating something that's good enough or viable so that you can test your ideas. This option likely requires working with developers who will help turn your ideas into working software. There's a lot of discussion about whether or not UX designers need to be able to develop software. I'm here to tell you that the answer is no. You don't need to be able to code, but it certainly doesn't hurt, and you absolutely can't serve your team as well if you're completely ignorant of it. Now I've never actually met one of the fabled unicorns that is a brilliant designer and a developer all rolled into one. One side of the equation inevitably suffers, and with the exponential rise in the complexity of front-end development, it's becoming more and more true. That said, having a working understanding of HTML and CSS and a bit of JavaScript will serve you well and is more than worth the time. A basic understanding of relational databases, scripted versus compiled languages, and frameworks will also be useful. Code is the medium in which you work, so when you know how code gets turned into websites and apps, you'll have a better understanding of how feasible your ideas are. You'll know that ideas are reasonable versus extremely difficult, and this is a better way to learn than through trial and error and repetitive questions. Again, you don't need to be an expert in any of these things, but the more you know, the easier it will be to collaborate with your development peers and to know how much you should build at any given point in your project. Finally, your only option could be to build and launch the full feature or product. This is obviously the riskiest option because you're committing your resources to build out an idea based on a guess. If you're wrong, then all the work you've done will have been for nothing, and you're back to the drawing board. Still, sometimes it's appropriate and there are great examples of companies that sort of operate this way, like Apple. To be fair, they use prototyping extensively, but it's used internally to keep their work secret until it's announced to customers eagerly awaiting their next idea. So to test your ideas as quickly and easily as possible using a method like the ones we've discussed, you'll need to be a great communicator and be able to collaborate to pull this off, which brings us to our final topic in this module, leadership.

Leadership Leadership wasn't listed in the process we spoke about earlier in this module, but that's because it permeates the entire process. Leadership may seem like an odd topic for someone just starting their career in UX, but it will serve you well to start practicing it as early as possible. A lot of people equate leadership with being the boss, but this is not a really productive or useful way to think about being a leader. In the context of UX design, leadership is more akin to guidance and facilitation. Your job is to help move your team towards a successful outcome, and this is best done by providing them with the information they need and provoking their enthusiasm. If you find yourself dictating direction or trying to overrule people, you've gone wrong somewhere. Being a leader in UX terms means being a resource, building trust, and creating the right conditions for your team to produce exceptional work. Here's a simple formula for being a leader without necessarily being in charge. Be a good listener. That means letting people get their thoughts out without jumping in to respond. That also means thinking about what they're saying and trying to actively understand their thoughts. Ask some clarifying questions. You know asking questions doesn't just prove you were listening, but it also should help the person you're speaking to clarify their own thoughts. The questions should ideally help to build on the strengths of their idea, as well as deal with any shortcomings it has. Finally, try to provide some insight. As a user experience designer, you're a subject matter expert so share that expertise. Help the other person to achieve their goal. If you treat other people on your team as if they were clients, then you provide the most utility and achieve the best results. When people know that coming to you is a pleasant experience and it helps them to achieve their goals, they'll tend to come to you more often. You'll know you're succeeding when you're being asked more than you're needing to interject. With good leadership in a project, communication is increased, allowing for more overlap between phases and iterations, and the final product will be of a higher quality because collaboration between talented, dedicated people trumps the lone genius, every time. So now you know why being a UX designer is so important to creating a great product or feature, and you should have a pretty good idea of how you'll approach the problems that a UX designer solves. You start by understanding what you're doing and why, so you can create some hypotheses. Get out there and start digging to see if you're on the right track, and then create your solution. Test it as quickly and with as little effort as possible, and then go back to the beginning if necessary and refine, based on what you've learned. Remember, these steps are less linear in practice than they're being shown here, and may even overlap a bit when you're in a real project. In the next module, we'll look at what things you'll actually make as a UX designer, why they're important, and when to make them.

Okay, But What Do You Actually DO Here? Common Deliverables Welcome to module three, Common Deliverables. We've discussed the general rule of UX designer and how they approach problems and how they do their work, but what do they actually produce? There are a lot of different types of deliverables a UX designer can make, and each of them comes in different flavors and can be applied at different times, so let's review a few of the most common, what they're for, and when you might want to use them. Journey maps are extremely useful tools for understanding an experience on several layers at once. Searching for examples of them usually turns up a lot of very pretty, but complicated documents that are covered with illustrations and arrows pointing all over, but those are often created by agencies looking to impress their clients. A journey map can be as simple as a travel board or a spreadsheet and still achieve its goal. The purpose of a journey map is to document an experience from beginning to end in more than one dimension. Even in our earlier example of calling the credit card company, you might start by looking at all of the steps someone goes through, including what may have led them to call in the first place. Depending on what their reason for calling is, you might try to create some emotional markers that show what they're feeling at each point in the journey. For instance, when they call, they may be experiencing anxiety or dread, followed by frustration, and then disappointment. Knowing each of the steps in the encounter and what they're feeling at each point would allow you to identify problem areas, sometimes called pain points, where the user is encountering difficulties. You can also document why that problem area exists, some ideas for how you might remedy it, and what the outcomes you would want for the customer experience after you've solved the problem. Journey maps are a very powerful tool, and even the process of making one can be extremely rewarding by increasing your understanding of where a problem is, why it exists, and what other factors might be surrounding it. Personas are a very popular, but sometimes contentious tool. While they can be extremely useful, they're also very easy to abuse. The idea is to create a fictional person that you can use as an example when you're thinking through possible solutions to UX challenges. Gathering common characteristics of your users into name persona can be a useful way to group and remember the traits that you need to consider and can help some people to put a face on the user, which is good for trying to empathize with them. The danger of personas is that they are absolutely packed with assumptions, and they can be relied upon too heavily, creating a system perfectly tailored to a person that doesn't exist. While having a persona to design for can help keep your team focused on building the right kinds of things for your audience, they should be used in moderation and always supplemented with additional data and perspectives. Use them with care. We spoke about how a journey map looks at how someone moves through an experience, but it's usually at more general level. For example, a journey map wouldn't normally look only at a login page, but a login page still has a surprising amount of complexity. For instance, it might need to be able to handle creating an account, as well as logging in, and it could also deal with forgotten passwords, social logins, email confirmations, and linking multiple accounts. How can you document all of these pages and paths in a concrete way that helps your team understand exactly how they work? Enter the flow chart. A flow chart shows all of the screens that a user could encounter; the order they will encounter them, if there is one; and the conditions that they need to meet in order to move on; and what the screens do if it's not obvious. In our login example, the user might decide to reset their password, which could also trigger an email verification. It happens off the page, but needs to be documented somewhere, so a flow chart can be helpful for covering all of the details of how something actually works. I love me a flow chart, and if you do too, then UX could be a great fit for you. In the old days of web design, information architecture used to be considered a job all in its own. These days, it's more common to see it as a deliverable produced by a UX designer. In some ways, it's a close cousin of a flow chart, but the purpose of IA is to show how information is organized so that it's usable, findable, and manageable. Information architecture allows usability problems to be identified and design concepts to be reinforced. IA is the structure of a site, app, or body of content. One example of IA is a sitemap, which shows all of the pages in a website and how they're grouped. What pages do you have to go through to get to them? Which ones appear on the main navigation? Another example is the creation of a taxonomy, or a naming system for a body of work. Are there themes you can use to make the content easier to find or to understand? These are the things that information architecture can help with. When creating anything of complexity, there's often just too much to hold in your head during the design process, so creating a requirements document can be really helpful. Requirements are exactly what they sound like, a list of things that an experience has to be able to do. So using our example of a login again, the requirements could be that the user be able to easily identify what they're logging in to. They need to understand how to create an account, still have it be fast for people who are returning to log in. They must be able to log in with a name and password or social, connect multiple login methods, or reset their password in case there's been a security breach or if they have forgotten it. They may also need to be able verify their identity through an email, phone number, perhaps even enable two factor authentication, which is where they need to enter a special code every time they log in. Requirements lists can get a little bit intense so having some kind of prioritization is very useful. If we were working for a startup with limited budget and resources, we may be able to prioritize the requirements into mandatory and nice to have. Social login may not be essential for version one, and so that can be set aside for a later version. Having prioritized requirements is the key to being able to estimate the size of a job and to have as a metric for the success at the end of a project. A classic. Wireframes are meant to be a simplified version of a design that communicates what things need to be on a screen, their relative importance, and how they should function. Wireframes can be very basic, often called low fidelity. A rough sketch on a napkin can be a wireframe. They can also be extremely detailed and pretty to look at. These are often referred to as high fidelity. They can be annotated with detailed notes or with a few sparse comments left as reminders on especially tricky elements. Wireframes tend to move in and out of fashion to some degree, but the following considerations should be used when thinking about creating them. Collaboration is almost always superior to documentation. Collaboration is dynamic and explains things on-demand to the degree that your team requires. Documentation, on the other hand, needs to be created and then read, often revised, and maintained. If there's a more useless activity than retroactively updating documentation after the thing it describes is already built, I can't think of it. My recommendation, keep it light. Now the experience level of your team will also dictate how detailed you need to be. High fidelity wireframes that are pretty enough, might even be mistaken for a finished design. They could be fun and satisfying to make, but ask yourself, why are you making these? Is it is a fast way to quickly flush out a concept and create a shared understanding? If so, then spending a lot of time achieving pixel perfection is probably not ideal. Are you working with a very experienced design team? If so, maybe it's better to simply create something that focuses on expressing intent and functionality and desired outcomes, leaving room for the UI designers to interpret and build on your concepts, rather than just decorate your wires. Finally, how dynamic and complex is the product? Is the work simple enough that wires aren't necessary? Is it so complex that they're not appropriate? With the former, you may be able to get by with other kinds of documentation, and with the latter, you may require something more robust like prototypes. We spoke about these in the previous module, but let's get into more detail. A prototype can be as simple as a stack of printouts showing wireframes for different screens in the order you would encounter them, or as complex as a functioning version of the feature, built without the finish design polish and possibly using static information instead of live data. What's important is that it shows how something works by actually allowing you to experience it at some level. There are also options in the middle using tools like InVision that allow you to upload your designs and stitch the static screens together to create a rough approximation of the final product that people can at least click through to get an idea of how it feels to use it. Choosing the right kind of prototype depends on factors similar to choosing how much fidelity to use in a wireframe. But what's most important is that prototypes are powerful tools for communicating how something works and allowing people to start to get a real sense of how it feels to use something. Some things just don't lend themselves well to description and need to be experienced firsthand. The deliverables we've just described are some of the most common you'll encounter. It's by no means an exhaustive list, but you can absolutely complete most UX projects using some combination of them. A note though about documentation. Remember, the more you document something, the more overhead you create. For every document you create, at least one person needs to read it, and that means that they're not doing their own work. If changes arise during the design and development of a project, and they will, then they may no longer serve as a source of truth unless you go back and update them. In short, documentation has a cost, and so most modern teams tend to favor a leaner approach. Now that's not to say that documentation isn't useful, just that it should be used wisely. Okay, you still with me? There's a lot of information to absorb, but the key thing to remember is that your job is one of clarification, creation, and collaboration. You need to understand what's going on, find the data to make good decisions, invent possible solutions, communicate them to people, and get their buy-in. It's a big responsibility, and it's why UX designers are in such high demand. Still interested? Well, on the next module, we'll look at some tips for getting started.

Where to Start Your Career Getting Started In UX Welcome to our final module, Starting Your Career. So far we've covered a lot of the skills you'll need to practice UX design effectively. In general terms there are analytical skills required to research and define a project, creative skills required to solve the problems, and leadership skills required to effectively communicate your work and get by in. These are skills that are best learned through experience, so while school is a great foundation for broadening your knowledge and developing your critical thinking, UX design is best learned through reading, watching experts in the field, and especially by getting on-the-job training. Seeing as you may not have a UX job yet, a good place to start is with research. As you learned before, the field of UX is constantly evolving, so what you learn today could be proven wrong tomorrow. With that in mind, you need to begin looking for good sources of current thinking with the practice and reading them as often as possible. I have been practicing design for well over a decade and I still spend at least half an hour almost ever day reading and looking at examples of good work. When you see work that you think is really effective, try to pull it apart and understand why you think it's so good. In this job more than most, you'll need to be a lifelong learner, so it's best to start to develop the habit now. As you learn more and more about UX design, you should start to gravitate towards certain aspects of it, which leads us to our next point. You didn't just spring into being right before watching this clip. You have years of life experience doing things. You know what you can do and where your interests lie. Where those things overlap is where you should look for things that can be applied to a career in UX. Whether you are more creative, analytical, or you're a natural communicator, there are aspects of user experience design where you can hit the ground running. So when you begin your career, be sure to communicate these preferences and aptitudes to the more senior UX team members and to your manager. That's not to say you should only do the work you like and are possibly already good at. On the contrary, UX will force you to extend yourself and learn new skills all the time, but start with what you know and grow from there. Now you might be asking what UX team members I'm referring to since you don't have this UX job yet, and that's a fair point. So how do you get that first job? Well, you might be able to move within your organization or convince someone to give you a chance, but if that's not working out then there are two things that will help you land that first job, other than having a rich uncle buy you a design agency.

Create a Portfolio UX design is a trade, not an academic discipline. Unfortunately, I'm not aware of any UX trade guilds that take on young apprentices and train them up. So, how do you get a body of work that you can show in order to get a job? Well, you start by creating a portfolio. If by some chance you know someone that has a website and they need some work done, then offer your services at an extreme discount. Outline the process you'll use using the handy tips you've learned in this course. Decide on some measurable outcomes and then get to work. Make sure you document what you do and share the results that you achieve. Now you've got yourself a mini case study and a portfolio piece. If you don't know anyone that needs work done, then the next best thing is to find yourself a UX problem and go about solving it for yourself. There is no shortage of bad UX to choose from, so just find the online experience that currently frustrates you the most and figure out how you'd fix it. Same process as the above, although you likely won't have access to the people who work at the company and their insights. You can still show how you approach problems and what kinds of solutions you're capable of. Once you're on a team, they'll only get better. Seeing this kind of process and initiative from a candidate just starting out in the field is a great sign and something that a good employer will value highly. One thing I strongly advise against is working for free. People who don't pay for work don't value it. Unpaid internships are usually only offered by failing businesses or unscrupulous people, neither of which you want to work for. You can't charge much if you're just starting out, but your work still has value and you deserve to be compensated. While we're on the topic, a note about choosing projects. If you're freelancing, you'll have some discretion about what projects you take on, though sometimes we all have to pay the bills. When I first started out I was working on a website that sold what I assumed were bogus weight loss pills. I got about halfway through that one. If you're working for an agency, you have less choice, but you can see what kind of work the agency does before you take the job there. I mention this because whatever work you do, you'll end up doing more of, so choose wisely. Having a challenging problem to solve will lead to other people getting you to solve their challenging problems. If the work is boring to you, it will be boring to the people you show it to, so aim for something exciting, and if nobody will hire you, then just do it on your own and show anyone who'll listen how great it would've been if the company you targeted had just hired you.

Networking The second thing you can do will either seem very easy to you or absolutely terrifying. You need to network, even if you hate it, because it will serve you well. The more people you know in an industry, the easier time you'll have hearing about new opportunities, getting recommendations, and learning about your craft. A mistake I often see at networking events is for people to come up to each other and try to ascertain what they can get from the person they're talking to. In my experience, this is not how it works best. Instead of trying to figure out what the other person can do for you, spend your time trying to figure out what you can do for them. Do you have another connection that would benefit this person? Put them in touch. Did you hear about a job that wasn't right for you, but might be great for them or someone they know? Share the information. Be creative and look for anything you can do that is genuinely useful. Besides making you feel great, helping other people usually does that, you'll soon start to notice that all of the people you help and all of their friends will start reaching out and trying to do useful things for you. Networking means helping other people and being genuinely interested in them and their work. If you get good at it, you'll probably be a happier person, certainly a more popular one, and likely a more successful one as well. Look for industry events, panels, meetups, and conferences. They're all good places to meet people in the industry, and you'll probably be surprised at how friendly and happy to share knowledge they are, so get out there and make some work friends. So, to get started in UX, the best way to begin is by building off of what you're already good at, be it your analytical skills, your creative flair, or your leadership abilities. If you're trying to get your first job, then you'll need to generate a body of work to show how you approach problems and how you think. Finally, the best possible thing you can do is network. The more you meet your peers and build your network by helping them, the more you'll find opportunities heading your way. Also, good karma. So I hope you've enjoyed this course, and now you have a good idea of what a UX professional does, how they do it, and how you can get started in the field. Thanks for watching, and good luck out there.