Designing a responsive web product

- It's that time again. Your design manager or your client comes to you and says, "I want you to redesign our product. "And it needs to be responsive. "And it needs to meet all these goals. "And it needs to be beautiful, functional, and delightful. "And don't forget. "It needs to solve the problems of our users, "be done in three months, meet accessibility guidelines, "have good SEO, and am I missing anything? "Oh yeah, it needs to be scalable." Now, whether you're new to UX design or an expert, you can probably relate. In this video, I'm going to show you how to approach a responsive web product from start to finish.

So let's get started. When you first gather your thoughts about a new, exciting project, this is your trigger to start asking a lot of questions. Let me give you an example. "Hey, Brian. "This project sounds really exciting. "Before we kick it off, I'd like to understand "more about the problems we're solving "and the business objectives for this project." Here are a few questions you could ask yourself. What problems am I solving with this new project initiative? What are those core business objectives and key metrics for success for this project? For example, I'd like to increase the time spent on-site by 5% or increase member signups by 5%.

Do I have any data or existing studies to support the business goals and problems that I'm working on? Do I have an estimated timeline for completion? I've attached a checklist of questions in the exercise files that you can ask to kickstart your next project. Asking these questions upfront will help save time and money in the long run. Knowing these questions upfront will allow you to spend more time focusing on solving the actual problem. After you understand why you're doing this project, you can shift the focus to more specific research.

You'll need to understand your business, competitive landscape, and other related industries that have solved similar problems. This is a great time to start interviewing your customers to see how their pain points align with your new initiatives. You can start with surveys, questionnaires, or in-person interviews. Next, we'll start looking at the content of the product and what we have to work with. In this scenario, you might already have content that exists on the page, or you'll create it from scratch. Get to understand why you need this content and how it will help with the overall objective of the page.

Next, we'll start thinking about the features we'll include in the product. We'll create hypotheses targeted around solving the user pain points we gathered in research. I'd recommend creating a workshop with your team to start generating these ideas so no good idea is left unturned. Let's look at a few example hypotheses. By adding a playlist feature to the site, we can increase the member retention and allow a user to watch more content and save more videos to watch later. By moving the key benefits from the bottom of the design to the top of the website, we can increase our conversion rate by 4%.

By the time you discuss your hypotheses, you might have thought about how you execute your designs. You might have already sketched up your ideas as well. That is totally okay. As you start exploring the designs of your page, you'll want to prioritize the features and the content based on their importance. Think from the top of the page down to the bottom of the page. You also get to use the context and entry point of your audience to help you rationalize which features will live on which breakpoint. Think of it this way. Some features will make perfect sense on all screen sizes.

For example, a sign-up or a sign-in button, your navigation, primary action buttons, or your footer. But commenting or editing a complex workflow requires you to evaluate whether it's worth being built for smaller screens or if it makes sense based on the project objectives and key metrics of success. Taking the extra time to understand the content and prioritizing the core use cases of your users will make this process a lot smoother. We'll now look into the information architecture of the site.

This is the foundation of what your newly-designed responsive web application will live on. I'd recommend using an existing grid, like Twitter Bootstrap. Or if you have the resources to build one from scratch, then go for it. But make sure it complements your content. The last thing you want is for your experience to look like a template. I'd recommend always designing on the grid, because it helps you achieve balance, spacing, and organization in your design, which in result helps with the readability and scan-ability of your site.

Once you have your grid in place, you can start exploring what we call a box study. A box study takes your content and lays it out on all the different screen sizes that you're required to support. This helps you see the bigger picture of how your content will display on all the different screen sizes. It's the upfront planning that will help your team see how you're thinking about laying out the content across all break points. The beautiful thing about this is your engineers can prototype this out and be able to share with you any issues or concerns they might have.

I've heard a few engineers at Lynda.com call it building a skeleton. This doesn't have to be your final solution, but it's a great way to think through all the breakpoints and features in one swoop. Once you have finished your box study, you get to jump into sketching and/or wire-framing a higher-fidelity solution for all your modules and features in their desired locations. After sketching or mocking up your solutions and you feel confident, it's a great time to start sharing with your team to get feedback. I'll describe where I'm at in the process, the problem I'm solving, and then ask them for specific feedback that would be most useful to me at any given point in time.

As each section starts to develop, I'll start placing them into the box study to see the webpage come to life. We've all tested a responsive website and simply resized the width of the browser window left to right. But, depending on your content, you might have to optimize for the vertical height as well. So learn where your audience is coming from. Then optimize for those key experiences. After you've designed your product, you have a good opportunity to validate everything you've done up to this point with your customers before jumping into implementation.

You can do this by walking them through a common use cases with a high-fidelity InVision app prototype. Next you'll be responsible for translating the experience into a spec and delivering that to your engineers. The good news is you've already done a box study, which means the engineers won't have the major surprises looking at the final spec. Once the development process is underway, it's time to switch into support mode to make sure that implementation is handled the way you expect it. I've had experiences in the past where I wouldn't follow up with the engineers because I got too busy.

Then the outcome wouldn't be what I was expecting, which causes frustration for all parties. You never want to just throw the ball over the fence and hope somebody will be there to catch it. Your team will benefit from having your support throughout the entire build process. Here are a few typical ways to support your engineers. Set up a regular schedule to check in with your front-end and back-end engineers. It's best to work with each other to find the best solution. Ask for a test environment so you can validate the implementation.

Participate in team stand-ups and quality-assurance bug bashes. This is a high-level overview of my process in designing a responsive web product. I hope this helps you execute and become the expert in your next responsive design project.