Process

Designing for the web is part art and part science. The science part includes having a certain process that one goes through while working on any project. A defined process ensures that one doesn't skip a crucial stage; what might at first seem like overkill usually isn't.

1. Research

The research phase is crucial. Depending on the project, this might have already been done by someone else, but as a designer it's imperative to understand the background of the project. Some key questions to ask are:

  1. What is the problem we are solving?
  2. Who are we solving this problem for?
  3. Why are we solving this problem?

The answers to these main questions usually lead to more questions, and gathering feedback from the client helps establish a solid plan of action for the work. This phase should include customer interviews, to get details of what the end user is trying to achieve.

2. Sketching

Many designers make the mistake of jumping straight into their mockup tool of choice (Photoshop/Illustrator etc), but it's a lot smarter to do some low-fidelity sketches first. Paper is cheap and a pencil is faster than a mouse. Quick and rough sketches mean that you don't get too attached to any solution.

Sketching user flows and mockups

I use this stage to:

  1. Write out user flows for various tasks. What steps will a typical user go through to finish the task they want to? This helps start the process of thinking about the different screens/pages one might need to consider. Ryan Singer of Basecamp has an excellent post about designing UI flows.
  2. Figure out the basic building blocks for each view. What are the main elements that are needed on the view so that the user can do what they need to do without being distracted or confused?
  3. Think about hierarchy of information and how to use it to move the user along to the next step.

3. Wireframing

Sometimes the sketching phase isn't distinct from wireframing, depending on how refined the initial sketches were. Wireframes formalize the sketches a little bit if they finished at a very rough state. Depending on the needs of the project, these could be made (using a tool like Axure/Invision/Keynote or something else of your choice) interactive or static.

I prefer to keep these fairly low-fidelity as well, since this is not the stage to worry about colors, typography, or other important details of visual design/communication. It also helps keep the focus on figuring out whether the flow is working or not. Quick user testing with these wireframes helps reveal flaws in my thinking or assumptions, and reinforce the importance of keeping the end user in mind.

4. Visual Design

This is the fun part, where the needs of the project are taken into consideration to come up with a look and feel of the solution. This is a good time to play with colors, typefaces, visual styles etc. Generating a style guide to help with development work is a great idea as well. I prefer this method because the look and feel of a website or an app is a result of how the various elements interact— type, color, buttons, links, forms etc.

5. Development

Depending on the team I am working with, I may or may not be involved with development. I am happy to transform my design into markup, but it makes sense to collaborate with dedicated developers on more complex projects. However, I have the ability to make smaller changes on the fly if needed, rather than bothering a developer to move that button 3px to the left!