Mar 10 2010
Most web design studios in Portland and around the globe have a set process that goes a little something like this:
Discuss / ask questions
Design
Build / code
Launch
There might be some variations but for the most part that's how it goes. There's nothing wrong with that – that's pretty much what our process looked like for a long time. But being the type that likes to change things to make life and work easier and provide better results, our process has changed a bit.
Aside from including as thorough an Information Architecture phase as possible, we've actually combined phases 2 & 3 above into one large iterative process.
A static mockup isn't enough
Many, many web designers and agencies provide a static mockup. It'll get created in Photoshop or Fireworks and after some initial spit and polish, gets presented to the client. (Again, this is how we used to do things too.)
Problem is, the web isn't static. There are moving parts on every single page of 99.9% of websites – how the links look on click, rollover / hover; how the page loads or refreshes (or doesn't refresh if using AJAX); image slideshows and modal windows (think lightbox galleries); re-ordering of items in a list or table; I could go on. While showing things like this in a static image isn't impossible, per se, it can't match what it's like to actually click around and see the design in a browser, the way it's intended to be. So we opt for a prototype that clients can actually click through and interact with.
Design doesn't end with a single phase
Part of the problem with having a single, specific design phase is that design doesn't end there. It continues on right up through development, testing / QA and in some cases, all the way up through launch. Just because a client is presented with 2-3 mockups (let's say, the home page and 2 subpages) doesn't mean that's all there is to design.
It boils down to the details. The heart of good, nay, great design, is the details. Sweating the details is what makes some sites stand out above others and is something we always strive for. For instance, anyone can create a web form, but how it looks and functions for the user is all part of good design. More often than not, it's just not possible to show something like that in a static Photoshop mockup, especially where browser differences occur. And let's not forget that Photoshop (and Fireworks) just flat out aren't web browsers and so their rendering of type isn't going to be the same as Firefox, Safari, Chrome, IE, etc.
Details like these (and a whole gazillion more that I haven't mentioned) don't always get addressed in a single design phase, and in some cases, can't be addressed. Instead, it makes a lot more sense (for us anyway) to let the design continue into the development phase where, inevitably, some new detail will need a designer's touch.
Shorter timelines
Perhaps one of the things about web design that is often misunderstood – or flat out not understood at all – is the amount of time it takes to create a really good site. It's not unheard of for a designer to bust out a site in a day or two or three. But how many clients want a site "busted out" as opposed to having one created that takes a lot more into consideration than the whims of a designer or developer?
Our process merges design and initial development into one phase, allowing our team to shorten overall project times. There's no waiting for official sign off on a specified design phase.1 Instead, development starts almost parallel to the design. How much gets developed (i.e., just front-end HTML/CSS development or more sophisticated back-end development) is likely dependent upon the project and the client. This also means that HTML/CSS developers don't have to go back to the design team when a particular layout won't work, which then means the change needs to be relayed to the client who may have already signed off on the design. And of course, having development start earlier also means testing happens right from the start, rather than waiting for the graphical elements to be completed. The key for us here is that our designers know how to code HTML and CSS.
Iterations rule
Let me clarify something: iterations and revisions aren't always the same thing. Even seasoned professionals make this mistake. Revisions tend to just be implementations of feedback given from a client; nothing more nothing less. Iterations take on more responsibilities which we love.
A true iterative design process focuses on making continual improvements to the site, but in smaller components. Rather than attacking the entire site at once, specific sections or features are tackled in shorter time frames. Think sprints rather than marathons. This allows for our projects to have a much more defined scope and more realistic timelines.2 It doesn't mean that client feedback isn't a part of the iterations. On the contrary, an iterative process keeps things from becoming overwhelming for a client. It keeps everyone's focus on one particular section rather than spreading attention thin across the entire site. This iterative process really allows us to work closer with our clients for each specific component to incorporate their feedback and to ensure the project is moving forward and on its way to meeting objectives.
Far from perfect
Does our process mean we're better than other agencies? Nah - we don't think in those terms. I don't even think it means that our process is better than other processes. It's simply a different take on the web design/development process. And one that has been serving us (and our clients) quite well. But that doesn't mean it's set in stone. We're constantly improving where we can to make sure we're able to provide the best work for each of our clients.
1. This of course doesn't mean sign-off on design doesn't exist; it does, but it's just not as black and white as having a static mockup.
2. However, it's important to note, that much of this needs to be planned for before the project even begins.