It took me three and a half months to create the theme for this blog.
Ok, so I was on-and-off, and many nights I was just too tired from coding at work to do any additional programming (esp. of the WordPress template variety) afterwards. I also wanted to mimic what I thought was the right procedure to design; that is, I wanted to do design research, proceed with brainstorming and some sketches, move to creating wireframes, create comps in Photoshop or Fireworks, and then finally crank out the templates, at which point I’ll actually get to spew my technical musings onto the internet.
If you’re wondering, yes, the above was completely overkill for what ended up being a simple, clean design.
I think I began to realize this when I was slogging through creating page after page of mocks and comps. Blog design is inherently repetitive, and after looking at hundreds of other blogs for inspiration there was a standard that I tried to adhere to anyway, so in retrospect a style guide probably made more sense than full mocks. In particular, I knew I wanted a clean page, with simple lines, ample white space and minimal distractions; the complex banner images, drop shadows, and transparent graphics kept getting in the way.
Eventually I came across a post on Quora which espoused the virtues of prototyping in code instead of in a graphical tool. As my strengths laid in writing code anyway, I felt it was worth trying. As it turned out, though, working via the “living mock” actually worked better than I had expected:
- I’m not good at creating aesthetically pleasing designs, but working within Fireworks/Photoshop, there’s a temptation to try to draw something with a bunch of (unnecessary) effects. I’m better off sticking to simple borders.
- Adding to the above, even if I was able to draw, the next step would have required me to slice up the page and piece it back in HTML and CSS. There’s more markup, more resources to load, and the exact pixel dimensions make for a brittle interface anyway.
- The time I spent writing the code to implement one part of the interface bought me enough creative down time to think about the next element. For me anyway, interface ideas come in spurts; if I work on them continuously, chances are there is one recipient of a good idea on the page, surrounded by its bad idea cousins. Taking “coding breaks” turned out to space out the thinking.
- It’s easier figure out what’s wrong with a design when it’s directly coded and making use of real-world data as opposed to a mock with its perfect titles and neatly-lined-up category listings. I just imported my previous blog and saw immediately how the design would look with actual paragraphs.
- Of course, having the implementation done as a pleasant side effect of hammering out a mock is great.
The kicker here is that I tried and stuck with this method the second time around; the comp you see above is already mostly implemented as a WordPress theme on my hard drive, and upon taking a break and a step back at three-quarters completion, I decided to redo the entire thing using the first design as a base.
And despite its clutter, the first version designed in Photoshop had the benefit of following a few design best practices – 960 pixels, using fonts conservatively, and applying contrasting colors consistently – which I judiciously copied in the subsequent redesign. The rewrite took a total of 3 weeks; or, more accurately, some 10 nights of two-hour coding sessions on nights when I wasn’t playing video games with friends.
If I only read that post sooner.