Not sure what accessibility changes will have the most benefit to your existing software? Are you in the build process and need to make sure accessibility has been appropriately considered? Use this checklist as a starting point.
A little while ago, I wrote an article on the steps to take before starting the web design workflow. The steps mentioned in that article ensure that a solid groundwork is laid for a successful web design project. The next logical step? Let’s chat about my web design workflow for a standard website project.
Before I jump into my process and the tools I use, let me say that this isn’t a case of “the right way” or “the wrong way”. This is just my way. Some designers design in the browser these days; some use frameworks, and so on and so forth. There’s more than one way to skin a cat (or carrot, for those attached to their cats like myself). So hopefully you can take from this article those pieces that will help you on your path, and perhaps make some suggestions in the comments too!
The first step we take once we’ve completed all of our pre-design steps is to enter into the research phase. This phase is fairly broad, but the overall goal is to become as familiar as we can with the client, the client’s industry, and to identify potential solutions as well. Generally speaking, we look into the following areas:
Competitors/industry: by familiarizing ourselves with the client’s industry and competitors, we can start to identify who else is out there, what solutions are being put forth, the state of web design within that industry and so forth. Then, we look to better everything for our client.
Keyword phrases: tool-wise, we use Google’s Keyword Research tool (although I’m going to look into SEOMoz‘s tools, at the recommendation of some fellow web nerds). Our goal here is to identify which keyword phrases are being targeted, how competitive they are, and the volume of searches for those phrases. Then we can optimize the site around the best keyword phrases for our client.
Potential design solutions: here, we’re looking for any potential solutions out there we may need to implement on the client’s website. For example, if there is a large amount of content likely to be used in a smaller area, how can we solve that problem? Perhaps a jQuery accordion, slider, or other solution. We also look into more general solutions to generate ideas: web design galleries and the like.
Post-research, we compile our findings into a document and brainstorm to organize and find solutions to everything we’ve found.
Tools: Google, Google Keyword Research Tool, various online CSS galleries, Pages (for compiling content).
Once we’ve tackled all the research, we move into wireframing. The purpose of wireframing is to quickly mock up potential web layouts without getting caught up in the finer details of design (which come later).We take what we identified via the needs assessment and research components to ensure we’re laying out the content in a manner that will meet the client’s needs – for example, if we know the client wants to drive traffic to their gallery page, let’s say, then that goal will be reflected in the home page wireframe.
We wireframe out each unique sub page and revise in-house until we’ve found the best solutions. Revision is important to mention here; it’s easy to revise simple wireframes compared to a huge, grouped/layered Photoshop file.
In our case, we don’t view wireframes as a locked-down, inflexible design – things change as you move into the Photoshop stage. Instead, we use them as base guidelines for where content and information needs to go. I personally start the wireframing process with pencil & paper, then move to Illustrator; however, Google’s Drawing app looks kinda handy.
Tools: pencil & paper, Illustrator, perhaps Google Drawing.
Once the wireframes are where they need to be, I move into the actual “design” phase (although, really, I view this whole process as “design”). This is where we take the layout, defined in the previous process, and flesh it out graphically. I’m personally a Photoshop guy; some people design in-browser and some people use Fireworks too. Whatever turns your crank.
This stage needs to bring everything together: the results of the needs assessment, the findings from research, the results of the wireframing process, and the client’s brand from colors to typographical rules to “personality”. When I say “personality”, the easiest way to clarify that is to think of the difference between MailChimp‘s personality and Constant Contact‘s personality. They’re both email marketing/newsletter solution providers, but they couldn’t be more different in their personalities.
Now, I mentioned that I’m a Photoshop guy when it comes to web design, but I’m slightly lying. I always have an Illustrator document open for each client web design project. This is usually titled “ClientName-WebElements.ai”, and it’s where I create custom icons and all those sorts of things. You can make all this stuff exclusively in Photoshop, but I find it quicker to create these various web design elements in Illustrator and just copy/paste them into the Photoshop document as smart objects.
In this initial design phase, I usually design the home page and a unique sub page for the client to view in the initial presentation. We don’t show more than one concept any more – it’s my opinion that it’s up to us, as the web design professionals, to choose and present the single best solution for the client, which can then be revised. We also don’t design every single unique page at this stage either, since if there are heavy revisions coming down the pipe, we’ve just created a lot of rework for ourselves.
By designing the home page and one unique sub page, we can give the client a good idea of where the site is headed visually and revise it from there without redoing a bunch of work.
Tools: Photoshop or Fireworks; Illustrator.
Once the initial home page and sub page design is ready to go, it’s time to present these to the client. Just like anything, there are a bunch of ways to do this: some people send PDFs, some send JPEGs, etc. We use a hosted “mockup presenter”, which allows the client to view the static web design mockup in the browser; this is the best way to approach static web design mockup presentations, in my opinion. One, you can just send a link. Two, the client is viewing the design in its proper context: the browser. You’re not designing them a PDF or taking a photo for them: why would you present your designs as such?
Some solutions out there for presenting your static mockups include Zurb’s BounceApp, the Design Presenter WordPress theme, and Zurb’s Influence app (in private beta).
Once you’ve figured out how you’re going to present your designs to your client, there’s one more question that needs answering: will you present the designs in person, or will you send them via email?
Generally speaking, in person is the better way to handle this. You are there to immediately explain your design decisions, answer questions, and mitigate any concerns from the client. However, we can’t always be there in person. In those cases where we’re sending the designs for review via email, we make sure to write out an in-depth analysis of the designs and include the link to the designs near the bottom of the email (so the client hopefully reads your notes, instead of just jumping to the design link).
It’s important to finish up the email by explaining what the next steps are that you’d like the client to take: in our case, to review with their teammates, consolidate feedback, and provide us with that feedback in written form.
Tools: Zurb’s BounceApp, Design Presenter WordPress theme, Zurb’s Influence app.
Every once in a while we knock it outta the park on the first take, but more often the case is that a design requires some revision. We always make sure to ask the client to speak in terms of “problems” instead of solution. A good example of this:
When the client articulates problems instead of solutions, that allows us (the design experts) to come up with the proper solution to the problem. When the client starts speaking in solutions, that can sometimes open the door to inexperienced suggestions (like using Impact for body copy… *shudder*).
Once we know the problems that need to be addressed, we jump back into our design program of choice and work to solve those problems visually. If we have the go-ahead that the overall look and feel is great, then we’ll also design each remaining unique sub-page at this point as well.
From there, it’s back to the presentation stage! Generally speaking, our project estimates are based on a max 3 revisions prior to design sign-off. I can’t remember the last time we needed more than three; articulating this point to your client will help open up clear lines of communication, which will help the project move smoothly.
Once the client is happy with the static designs, we get written sign-off (usually via email) so we can move into the our development workflow… which is a topic I will write about in the next couple of weeks, to keep this website project process series going.
So, how about it? What’s your web design workflow? Any apps you can’t live without, or do you have a rock-solid process you’d like to share? Leave it in the comments!