Website Workflow
April 17th, 2010
I find myself explaining the process of website design & development repeatedly, so it’s time to write a show-and-tell post. First off, let me say that this is my process. Other designers & developers may differ somewhat, especially if they work within larger team environments. Yet, every site does go through a similar creative to implementation process.
Client Says: I Want Need a Website…
that looks like Name That Site, with effects like Name That Site, and maybe a header like Name That Site, but not like Name That Site, with a menu like Name That Site, but not so complicated like Name That Site, and I really don’t want anything like Name That Site, even though my competitors are all like Name That Site…
Azzcat Design Says…
Great! We’ve got a good start. But before we worry about how the site is going to look, let’s focus on how it’s going to work. For your business. Let’s answer the following questions:
- Who is your primary audience?
- What is your message?
- What is your call to action?
This is basic information that will help me determine an appropriate graphic style and what to emphasize on your page(s). Of course, client and Azzcat Design will need to cover budget, timeline, etc.—but that’s not the focus of this article. The next big question for client is:
Do you have an outline and content?
- No…
- Sort of?
- Yes!
If client’s answer is #1 or #2, not to worry. The point is that one way or another (I know writers/I can edit) we’ll get to #3. And that’s where I take all the info about the audience, message, call-to-action, site outline and content and put it together into a wireframe.
Wireframes
The point of a wireframe is to visually lay out the structure of the site and UI elements. There are many ways and tools to depict a wireframe—the simplest of which is with good old pencil & paper. And though I certainly use p&p in the beginning, my wireframe tool of choice—for sharing with client and performing revisions—is Balsamiq. I like Balsamiq because it allows me to quickly put together a page layout, share with client and easily edit.
Because of Balsamiq’s built-in ‘sketchy’ quality, client is able to focus on UI and information structure without being distracted by graphics/colors/styles. Focus here is on the skeleton, rather than the skin of the site. Site organization or structural layout edits at this point are simple and inexpensive.
Here’s the wireframe for Eye Styles. The vertical grey stripes are the structural grid: not meant to be seen, but for later design layout and CSS coding, using the 960 grid framework. The yellow sticky notes are just that—explanatory notes to client—a Balsamiq feature.
After reviewing and revising the wireframe—and with sign-off from the client—I proceed to the next step of website design & development.
Design Comprehensives (Comps)
This is where I flesh out the skeleton. Working in Photoshop, I build a graphic representation of the site, including background images, textures, icons, font treatments and more. Not every page is comped—just those necessary or substantially unique. Most of the time, this means a landing page + one secondary page—depending upon project scope.
Not so very long ago, most of what would eventually go ‘live’ had to (at some point) be created in Photoshop for ‘slicing’. These days with CSS3 techniques for borders, shadows, colors and more, this is no longer the case. These things will not be delivered to the site by http calls for images. They will be part of the CSS code (a single http request)—improving site speed & performance. For those browsers that support CSS3 (that’s about everyone except IE) such niceties are known as progressive enhancement. Other elements, such as typography, are more or less depicted in the comp as they will appear live. For instance, I use Typekit, an awesome, cool, fast web-font replacement technique. Because the fonts will be delivered live to the user (yes, even to IE!), I do not have access to actual fonts (unless I already own them) via Photoshop. In this case, I’ll use a similar font for the comp.
The sample at right is a capture of the PSD file for EyeStyles. You’ll see that the comp is very close to the final site.
I submit the comp(s) to client for review. I no longer offer multiple comprehensive styles as standard. Turns out, after working with a client through planning & wireframe stages, I’ve got a solid idea of a suitable style for them. No need to offer a whole candy store of flavors—that just complicates digestion and costs more. Then, upon client review, revisions and sign-off, I move onto the next step.
Mark-Up/Static Coding
At this point, we’re about half-way done. Specifically, I’m about halfway done! Client should be finalizing copy edits and eating bon bons while I enter the geek zone. ;-)
I fire up Coda and mark up the HTML, breaking down the page elements into chunks for the browser. I’m quite the proponent of HTML5 because of it’s brevity and inherent semantics. Love <footer> sooo much more than <div id="footer">. (And it even works in IE, thanks to this handy dandy shiv!)
Once the HTML is marked up, I write the CSS. In order to not reinvent the wheel every project, I’ve put together my own CSS framework, Mashup, built with the parts I like best from other frameworks, including Bluetrip. My Mashup is spartan, but with typography relationships established. It’s a great starting point for styling new sites. And from here, I can easily try out other font styles with my Typekit account.
When I’ve got everything looking sweet in Safari and Firefox browsers, I move on to the really fun part of web dev…
Testing
Because, you know…something isn’t gonna work in IE. :P And you gotta fix it!
Templating
These days, more often than not, websites will not remain as collections of static pages. Rather, they utilize some sort of CMS, such as WordPress, Drupal, Expression Engine, etc. (I’m a WP fan.) For any CMS, static HTML files need to be broken up into specific template components, such as header.php, index.php, footer.php, and sidebar.php. There are more standard template files, for sure, but you get the idea. Long story short—the well-tested HTML & CSS files need to be configured to the CMS templates.
And Tested. Again!
Once the kinks are worked out, I’ll have client review the site (from my development site), tweaking as necessary. and following client-sign off, I’ll zip the theme and, finally…
Launch!
At which point, it’s my turn to eat bon-bons! :)
