The typical web design workflow

- Every designer and agency has a workflow that they like to use for their own projects. Workflows are incredibly personal things, and what works for one person might not necessarily work for another. So, in this movie, I'm going to give you my own personal workflow. Now, some of you guys may love it, and some of you may hate it. The point is, it gives you a workflow to start from that you can then take and modify it to fit your own personal projects or preferences. Most workflows can be broken down into four individual segments.

Planning, design, development, and publishing. Often over the course of a project, these segments will blur or shift, so be sure to make any workflow that you use flexible enough to handle the disruptions that every single project is going to go through. Let's take a look at these stages one at a time. So, the very first thing I do for any project I'm working on is to create a project brief. This brief covers the basics of the project, what the scope of the project is going to be, and what deliverables will be expected at the end of the project.

Doing this at the very beginning makes sure that my expectations match the expectations of the client. That's really important. Although this sounds like common sense, you'd be amazed at how often clients and designers have very different expectations. Next, I like to do a content survey for the site. Now, a content survey is a comprehensive listing of all of the content that will be involved in the site or project. Now, it doesn't mean that all the content has to be written. It just means that we've identified all the different content types and we know how much content we're going to be working with.

Or at least have a good idea of it. This allows me to create a content strategy. I'm a firm believer in the phrase that content is king. By understanding what types of content are in your site, you're going to be able to prioritize it and begin to plan for how your design is going to facilitate users accessing and interacting with that content. Now, at this point, I'm going to draft up an initial site plan that could include wireframes, sitemaps, and feature lists. I'm not going to focus on any visual design at this point.

And I'm not going to produce any mockups. Now, this is solely about content and functionality, and that's it. From there, I move into the design phase. At this point, I usually pick up my sketchbook and do a good bit of sketching. I love physically sketching ideas and coming up with say, hundreds of possibilities. This really works for me. Even though I know plenty of designers that actually prefer to sketch directly in code. You know, for me, a pen and a paper is much more liberating. Usually I'll refine my sketches and get a pretty good idea of how my site layout is going to look.

I don't always show these to the client, however. I'm actually becoming a bigger fan of using style tiles. Samantha Warren has a great site on using style tiles and how they can help in planning the design of sites. Essentially, you're just showing clients design elements, not full site mockups. This frees you from the very common problem of having clients get caught up in individual page design choices and sort of nitpicking rather that just looking at the overall design aesthetic. Brad Frost has recently described his process of atomic design, which is the process of designing individual components first, which are then combined into larger regions of the page.

If the project needs it, I'll generate prototypes next. Prototypes are typically working design mockups that illustrate other stylistic choices or simulate functionality. This allows the client to see not only how the site is going to look but also, how it's going to function. Prototypes aren't required for every project, but they can be an extremely powerful way of conveying ideas and functionality to the clients before you commit to any actual development work. When I feel comfortable that we have a solid design direction and that the client is happy with the direction we're going in, I'll usually generate site assets.

Now, your site's assets are going to include things like images, icons, other graphics, fonts, written copy, video, you know, any other asset or resource that the site is going to require. You won't always be able to generate all of these assets prior to development. I mean, honestly, you very rarely do. But when you can, it makes the process of actually developing the site a lot easier. At this point, I begin to develop the site. If I've done my planning properly, I already know how the site is going to be structured and what type of functionality is going to need to be programmed.

Now, typically, I've got a really good idea of how my code is going to look before I ever start. For larger projects or if I'm working with a team, I might actually want to develop some coding standards, so that all of the team members will be on the same page as they develop content. One of the things that I always try to think about when developing a site is whether or not the code is maintainable and can it scale if the site needs to grow. For basic sites, I can pretty much handle all of those things on my own. However, if the site has something like ecommerce or really complicated functionality that requires specialized development, I'm going to bring in another developer to help me.

Making sure that you have a network of agencies and developers that can help round out your skill set is a really important part of any freelance web design business. It's also a really good idea, during the development phase, to use some type of versioning software. aa I love GitHub and it's the current favorite of many developers, so I highly recommend it. It allows you to collaborate with team members, track changes, and then if you want, you can branch off copies of the site so that you can sort of experiment with it without changing the main site. It's also a really nice way to back up your site so you don't lose it if something changes within your local development environment.

Of course, during this entire process, you should be testing your site in multiple browsers and devices. Testing the site as you develop it will ensure that small errors don't become really big ones. As your site becomes more functional, it's a really good idea to begin usability testing, if the project timeline and budget allows for it. While bringing in an outside firm to conduct usability testing is extremely helpful, your budget might only allow you that for your larger projects. Regardless, you should try to find individuals that can test your site out and make sure it's functional and that the site is meeting the usability goals that you set for it.

As your development cycle reaches its end, you might want to bring the client in for some final reviews. It's really helpful to make the client understand that the site is about to go live, and they need to make any final revisions that they want. I've had too many sites that were reviewed to death with an endless cycle of reviews and updates that really prevented the site from going live when it was supposed to. By stressing that this is actually the final review, you're able to make sure the site is meeting your client's goals and expectations while preventing unnecessary revisions. After all this comes the fun part.

You're going to publish your site and celebrate as it goes live. Now, depending upon your arrangement with your client, your job might actually not be over at this point. I mean, it usually isn't. You still at minimum want to do extensive testing with the site and make sure it's performing the way that you expect it to. You should probably expect to have to do a few rounds of revision after the site is live, at a minimum. Okay, I know I told you I was going to describe the basic workflow, and quite frankly, that was actually fairly comprehensive. Sorry about that. I'm not going to pretend that I use every single one of these steps on every project.

Of course I don't. Every project is its own individual animal and I modify the workflow to suit what's going on in that project. Don't expect to have a polished workflow on your first project. By having a sample workflow, like this one, however, that you can use as a starting point, you can kind of see which processes are going to work for you and which ones you're going to want to modify or get rid of. In the end, workflows are incredibly personal. And eventually, you're going to find the one that fits your individual requirements.