UX & Web Design Master Course: Strategy, Design, Development

The purpose of this course is to share what I know with you — to show you what it takes to build a website from start to finish. From the initial idea roiling around in your head — or your client's —to structuring information and content to visual design and development. I'm going to give you absolutely everything you need to know to build successful websites, no matter the purpose, the audience or the industry.

Reinforce what you're learning using the bonus 30-page UX Guidebook. It's a great tool to reference as you progress through the course, or while developing your own custom sites. It's filled with worksheets, exercises, checklists and activities that will help you apply great UX to any kind of project.

You can download the guidebook from the course sidebar.

Every website or app project should start with strategy, and strategy starts with asking a very simple question: Why Are We Doing This? Before you commit massive amounts of time, energy, resources and money to something, you have to consider the reason(s) for doing any of it. And in order to succeed, you need to be sure those reasons are the right reasons.

No matter the industry, niche or product type, a core component of developing solid website strategy is asking three crucial, universal questions. Whether you’re building something from the ground up or redesigning an existing site, your marching orders are the same. You need to find out:

1. What’s worth doing?
2. What are we creating?
3. What value does it deliver?

We’ve got a handle on what the business needs, along with an understanding of what users need. Now — from all of that we’ve researched, from all that we’ve heard from stakeholders and users — what’s actually worth our time and effort? What’s worth the organization’s investment in the project? What’s worth our investment in the project?

Part of your job is to make sure that everyone involved — from client stakeholders to design and development team members — is in agreement. You want shared understanding of the project goals and what needs to be designed and built in order to meet those goals. And you want to make sure that your discussions address the why, in addition to the what.

Value is subjective, and its specific to that person’s reason for visiting your website in the first place. Keep this in mind: when a person visits your website, they already know what they want from it. So at this point, your task is to make sure that the value you (and/or your client) believe the website provides is a match for what users expect its value to be.

I'm going to walk you through a very simple but powerful exercise that you can use in order to find strategic opportunities and determine what's most valuable — to both users and the business.

The UX designer’s job is to address not only the information concerns and the related needs of users, but to insist on being very selective and analytical in designing task flows and functional elements that serve a greater goal. That greater goal includes what the business or the site's creator needs as well in order to survive — and prosper. Designing with the UX Value Loop in mind ensures success for both groups.

Business goals come primarily from the folks who are carrying the most responsibility and risk for the project’s success: stakeholders. These are your subject matter experts, the people who can explain to you what success means, both for the business and for them. One of the first critical things you have to do is find out how each stakeholder defines success — and how different those definitions are.

So once we know what the business goals are for the product, now it’s time to figure out what people (a.k.a. users) want from it. What are they after and what do they expect? What’s the value delivered to them in this equation? The best way to identify these needs is to ask questions of the people who will be using what you design and build.

So at this point, we’ve heard from business stakeholders and users themselves about what their goals and needs are. But how do we use that information to make decisions about Information Architecture, or content strategy, or visual design or interactive technology? The best way I know to connect the two is to create what’s called a decision path.

In terms of design and development, a website’s feature set — what we’ve all agreed we’re going to design and build — is defined by requirements.The more complexity we have, the more requirements we need. The more features we decide to implement, the more detail we need for what exactly those features are, how they should be designed and what level of coding, scripting, plugin or CMS platform is necessary to implement them.

Requirements fall into three essential categories, each of which you must address and find answers to:

1. Things people say they need.
2. Things that they actually need.
3. Things that they don’t know they need.

Whatever requirements you create, you need to document them — even when you are using Agile or Lean methodologies. Documented reference of what matters most gives the entire team, on your side and on the client side two things:

1. A sense of the scope of what you’re building (and what you’re not)
2. A reference point for progress during the project lifecycle.

It’s pretty much common knowledge (or it should be) that the discovery of feature or functionality requirements during UI design or development, is pretty much a recipe for disaster. Unfortunately, it happens quite often. Spending time determining, socializing and getting approval on scope will save you tremendous pain later on in the project.

During the initial stages of any project, you can bet on two things happening:

1. Everybody and their brother has ideas about features.
2. There will be a significant number of questions surrounding content, features and functions that no one has answers to.

Both of these facts can quickly expand the scope of what you agree to design or build, unless you corral them both up front. Here's how.

Here's an interesting (and fun) game you can use to determine what features and functionality matter most. More than a few of those things that sound like good ideas simply may not be possible. At least not right now, anyway. We may not have the time or the budget or the talent to pull these things off. This exercise will help you draw a clear line between what’s doable right now versus what has to wait for later.

In this part of the course we're going to create a test plan. That plan will tell you which browsers and devices are within the project's specification. It'll help you focus on what matters most and will reduce development time and costs. It'll also set client expectations early on, which reduces the potential for misunderstanding later and minimizes scope creep. And most importantly, a good plan allows you to launch with confidence that everything displays and performs as expected.

The time to create a test plan is now, early in the process. You will rarely have a situation where you can test everything you’d like, to the level of detail that you’d like. So the first thing you have to do is be realistic about what matters most — because you can’t do it all. You start with the people using the website — your users — to get a handle the scenarios that are most relevant to them.

You use the information from the DEFINITION work — on your user’s browser/device scenarios — to determine which scenarios you will fully support, which you will partially support and which you won't support at all. This is how you will divide and conquer.

Here you're testing all the links in website pages, forms used in the web pages for submitting or getting information from the user — in addition to cookie and database connection testing.

Usability testing, in a nutshell, helps determine whether the website is easy to use. Is navigation clear and consistent? Is content logical and easy to understand? Usability testing identifies problems before they're coded. The earlier issues are identified and fixed, the less expensive those fixes will be in terms of time, schedule and (of course) money.

What happens when something goes wrong? When users enter incorrect information or the wrong password? When the sever crashes? When the browser or OS has a problem with a request? Making sure your website provides feedback in these instances is critical to delivering great user experiences.

Compatibility of your website is quite possibly its most important attribute; users will expect compatibility with their chosen device, its software and its OS. Compatibility testing covers browser compatibility, OS compatibility, mobile browsing issues and even printing options.

Performance testing accounts for heavy loads where a large number of users are simultaneously accessing or requesting the same page or content. In addition, you do stress testing to see how the site and the server react to stress — and how each recovers from crashes.

The importance of website security can't be overstated. If you're responsible for proprietary or sensitive data available only to logged in users, you want to be sure the site is secure. And when you have both public and private data/content, you want to make sure there's clear segregation between the two.

A quick recap of the Definition section of the course, highlighting the critical concepts I want you to take away and remember.

When you're in a department store and can't figure out where a particular product is, you might look for signage or labeling on the aisles or hanging from the ceiling. You're looking for the department or category your item might be in. That's Information Architecture. And how easily it helps you find what you're looking for is a measure of how well it works.

Content is usually the reason people are coming to your site, app or system in the first place. All the stuff that they can read, consume, absorb, interact with — even purchase — is essentially, content. The content you decide to include forms the foundation of your Information Architecture, so content is where you start.

Because content is strategic, there are certain considerations that have to be taken into account when you start thinking about what kinds of content should be included on your website. Content requirements help you figure out what kinds of content will be most relevant, appropriate and useful to site visitors.

A key step in creating a website of any kind is identifying how content will be created, edited, approved and posted to the website. This is what we call a content workflow, and whether you're designing a small website for yourself or a massive ecommerce website, taking the time to figure out how it should work is critical. Managing content is the first place where small site owners get tripped up post-launch, and it's the issue that makes a large website quickly cluttered and unusable.

Even with a small site, Information Architecture can be a multi-layered, many-headed beast. Here are my tips for working through complexity, context of use and client preconceptions.

Now that we know what content we need and how it will be created and managed, we take all that information and apply it to the business of creating and prioritizing an IA model. Specifically, we're addressing content labeling & taxonomy, and file (HTML) naming & taxonomy.

Good labeling — in navigation menus, page titling, links and buttons — helps people quickly and accurately predict what they'll get before they click or tap. The more descriptive the label, and the closer it is to what the user would call it, the higher chance they'll interact with it.

How you organize and name the files that live on your web server is every bit as important as the content they contain. Your file naming scheme should line up directly with the IA in terms of categories, subcategories and labels.

When a lot of content winds up in a single category, you have a new issue to deal with: what order do I put it all in? Some of the methods we'll discuss in this section will help you group and classify your content, creating obvious hierarchy and clearly differentiating between category levels.

In this lecture we'll discuss the most common types of IA models: Hierarchical Tree, Nested List, Hub-and-Spoke, Bento Box and Filtered View. We'll also explore how each model works and what kinds of sites each model serves best.

In this lecture we'll explore what the Hierarchical Tree IA Model is, how it works and what kinds of sites it's best for.

In this lecture we'll explore what the Nested List IA Model is, how it works and what kinds of sites it's best for.

In this lecture we'll explore what the Hub-and-Spoke IA Model is, how it works and what kinds of sites it's best for.

In this lecture we'll explore what the Bento Box IA Model is, how it works and what kinds of sites it's best for.

In this lecture we'll explore what the Filtered View IA Model is, how it works and what kinds of sites it's best for.

For complex websites that integrate content across different third-party systems, a single IA model may not be flexible enough to accommodate all structures. I'll give you a few examples of how IA models can be combined in order to present content intuitively and deliver great user experience.

There is no single “right” tool for creating an IA spec. There are multiple ways to clearly communicate content categorization, prioritization and relationships. In this lecture we'll look at the most commonly used, most readily available tools to create your IA — and share it with clients and users —easily and quickly.

Once you have a draft IA, you want to socialize and validate it. In other words, you share it with your client and with potential users in order to determine how easily users can find specific items, You want to find out which parts of the IA work well, and which need improvement.The quickest way to do this, and walk away with solid evidence to base your decisions on, is by doing something called tree testing.

Website Navigation Design is an extraordinarily wide topic to tackle, because it can be painfully simple or mind-numbingly complex. Because navigation can vary so much between websites, there are no hard and fast rules for organizing it. However, there is definitely a tried-and-true process for determining what that organization should be.

I am a big believer in dual navigation menus, which make a clear distinction between primary information (what users care most about) and secondary information (useful, but not as important). In this lecture I'll show you how (and why) to make that distinction.

When most people think about navigation, they usually focus on the persistent menus that appear on every page of the website: the global navigation. But as you'll see in this lecture, in order to create a truly valuable and useful website that delivers great user experience, equal attention should be given to local navigation.

For websites where navigation changes based on whether a user is logged in or out, challenges arise. Some websites may have a simple client area, while others have full-fledged communities. In this lecture I'll share my tips for organizing navigation across different user types with different levels of access.

Your navigation scheme is only valid — and valuable — if users can get where they're going easily and quickly. Validating navigation means determining whether people can tell where they are, where they can go, and in some cases, what to expect when they get there.

There may be more than one way to get somewhere on a website, but how do you know which way is best? How do you ensure that the most valuable parts of the website are seen and visited? In this exercise, I'll show you how to determine those key navigation paths that deliver high value, both to users and to the website owner.

So now that we've made some decisions on appropriate organization and form, it's time to put all that into a visual format that starts to look like a layout. We call that a wireframe, and I'm about to show you everything you need to know about creating and validating one.

I see examples of bad wireframing almost daily — prototypes that don't serve the purpose they were created for, because...well, they're not really wireframes. The quickest way to clear up this confusion is to talk about what a wireframe isn't, and that's what we'll do here.

Wireframes serve as the blueprint for design and development. They connect the underlying conceptual structure (or information architecture) to the surface (or visual design) of a website or app. In this lecture we'll cover what exactly wireframes are — and what yours should be.

In this lecture I'll share my tips for creating wireframes that communicate and set the proper expectations for content, features and functionality. I'll show you how to use wireframing to get (and keep) every member of your team and the client's team on the same page.

From paper & pen to complex software, there are any number of ways to create a wireframe prototype. In this lecture we'll take a spin through the most common wireframing tools and you'll learn what situations each type is most useful for.

In this exercise I'll walk you through the process of creating a wireframe using Axure RP Pro, step-by-step.

Once you've created a click-through prototype, the next step is to socialize it with team members and with your client. You'll learn who needs to be involved, what you should be asking them, and what feedback you need most from each group.

A quick recap of the Architecture section of the course, highlighting the critical concepts I want you to take away and remember.

It's the first question on everyone's mind, and it's the part they can't wait to get to! But great design encompasses a whole lot more that what you see. Here's a quick look at what that "more" actually is.

Appropriate UI Design enables website visitors to do what they came to do — and what they want to do. That's a balancing act, and it's not always an easy one. From the visual to the verbal, the UI can't insult their intelligence, but it can't talk over their heads, either. In this lecture I'll show you how to strike that balance and make sure every design decision you make is appropriate.

As you shift your attention to UI design, it's time to revisit the answers to all the questions you asked during your Definition and Architecture work. Every decision you make from this point forward — colors, images, fonts, visual elements — should serve those goals and be appropriate for your audience.

The UI design principles I'm going to give you over the next four lectures are timeless — trends will come and go, but following these rules will always get you real, measurable results. And they'll do more than just help you design a more intuitive UI — they can also help you identify problems and find solutions in an existing UI.

Timeless Design Principles, part 2 of 4.

Timeless Design Principles, part 3 of 4.

Timeless Design Principles, part 4 of 4.