Web Design from the GutDec 5, 2008 In Design By Nishant Kothary
Scour the Web searching for some permutation of the keywords "web", "design", "workflow", "process", "aneurism" - OK, not so much the last one - and, you'll probably find a plethora of literature that delves into five-phase processes that usually start and end with phases "Concept" and "Launch" respectively. Not that there's anything wrong them; in fact, they're generally quite accurate and most of those phases do, in fact, occur. But in my experience, it's far from linear; to the contrary, the process is usually pretty iterative, often random, and frequently characterized by all kinds of obstacles - from ridiculous deadlines to equally ridiculous stakeholders. In this article, we will reflect on the web design process - the real-world process - through the lens of the making of MIX Online. The goal is not to be prescriptive, but to attempt to extrapolate some practical lessons through this experience by explaining it in bold and honest detail
Let’s Do Something Brutal 
The site used to be a simple blog that, save the prolific content, left much to be desired. It was hardly representative of what the MIX brand stands for. As we started talking about the goals of the site, a few themes emerged:
- Content. Content is king, and we agreed that instead of a stream of blog posts, we would invest time in publishing rich articles on topics that web professionals would find interesting.
- Bits. The MIX Online team tends to explore interesting scenarios on the Web by building real software. We wanted to somehow weave that into the site in the form of software that we could give away.
- Design & Standards. The site needed to be beautiful inside-out. The new MIX Online would connect with the common user to the web designer to the web standards advocate.
We never really turned the above into a vision document, but over the period of brainstorming and discussions, the vision became pretty clear in the minds of all the folks involved. What’s important before you dive into any design exercise is to gain a clear understanding of the purpose of your site. It doesn’t need to be formal, and it doesn’t need to be complete; you can fill in the details as you move forward. But the high-level picture should be crystal-clear.
I can’t recall many days when I don’t reference the original vision in some conversation or another. As a web site evolves, a clear vision becomes the designer’s most frequently used tool in helping ensure a sensible evolution. It becomes infinitely helpful when an executive goes, "Why don’t we move that above the fold?" "Well,we could do that,but let me remind you that that pretty much changes our original vision. If that’s cool with you, I can go make the change," is always a more effective way to solve the problem than responding with, "You are not the boss of me!" or worse, "You smell like poop."
Paper or Plastic?
Get yourself a vertically-oriented, graph-paper Moleskin, and you will open your world up to all sorts of possibilities.
Yes, this is the customary section on "design begins on paper." Before you get turned off, I’ll share a secret that may serve as consolation: until recently, I had always felt that paper got in the way. From design books to shows (like the ones on HGTV), we’ve been exposed to sketches for everything from web sites to interior design. A couple of things always baffle me about most of these sketches:
- They often look exactly like the finished product.
- They’re beautiful. All the lines are clean, shadows in the right place, perfect grid systems, and so on.
We’ve been subconsciously conditioned such that whenever we try to sketch an idea out on paper, we’re aspiring to produce sketches like the ones I just mentioned. Years of unsuccessful attempts later, I’ve finally dropped the dream of sketching masterpieces and that’s helped expose the true value of the pen and paper in the design process. Specifically:
- It’s low-cost.
- It’s quick (and, it’s OK for it to be dirty).
- It helps you dive into details.
Paper should be used as a tool to facilitate brainstorming. You can use it for any aspect of the design from feature prioritization to layout. If you find yourself struggling to introduce a paper and pencil into your design process, you’re likely working against the natural grain of your thought process. Or, you’ve probably set up unrealistically lofty expectations from the mighty paper and pencil. My advice is to expect paper to help you explore and capture the images and ideas in your head, and nothing more. And if that means that you write down random lists of ideas, great. If that means that you sketch out site layout, even better. If it means that you draw intricate shapes that accrue to logo designs, I salute you. Whatever it is, know this – paper is a very powerful first step to designing something, and embracing it will bring you only good.
Feature Wireframes for the Liberated Designer
As of late, I have found myself creating something I call "Feature Wireframes" because they find the sweet-spot between specifications and real wireframes. Feature wireframes, despite looking exactly like traditional wireframes, only capture functionality without making any guarantee about typography, color, or even, layout. That’s where they differ from wireframes as understood by most UX professionals today which often capture layout. I prefer to save the layout exercise for my late night design sessions. There are a few benefits to creating feature wireframes:
- Designers think visually; trying to picture the site in the form of a feature wireframe forces you to think about the details, and subsequently, the feature set of page.
- Layout is one of the most important parts of a web design, and trying to finalize it within the first couple of weeks of the design phase seems counter-intuitive. Feature wireframes decouple the layout process from writing specifications, and keep the project moving forward.
- They unblock the development team who really only care about rolling up their sleeves on the core features of their site.
Before we move on, it’s probably worthwhile mentioning that feature wireframes are not for everyone, or every situation. But if you’re on a project with a set of stakeholders who trust your design chops, feature wireframes can be extremely liberating because they give you much-needed freedom to explore the best design solution.
I Scratch Your Disk, and You Scratch Mine
Once a rough vision is in place, and feature wireframes are pinned to the corkboard behind your screen, you’re ready (and generally itching) to roll up your sleeves, fire up your favorite illustration tool, and start painting pixels. The process I use is very similar to how professional interior decorators recommend designing a room: pick an object in the room as the focal point, and design the room around it. While the feature wireframes aren’t completely representative of the layout and elements in the site, they generally have some good ideas that you can use as a starting point for the site design.
"Good designers borrow; great designers steal.
Kicking off visual design for a web site is possibly one of the most difficult parts of the process. It’s very difficult to commit to a visual identity; almost as difficult as actually coming up with one. Something that really helps me get over "designer’s block" is browsing through CSS showcases. A while back I found Tanya Merone‘s portfolio through a CSS showcase, and I’ve been hitting it ever since because her Favorites section neatly lists most of the CSS showcases around. So, Tanya, if you’ve been getting a boatload of hits from Redmond, WA, that’s me.
I spent a considerable amount of time looking for inspiration for MIX Online during this phase. I bookmarked a few sites that inspired me, but nothing really blew me away. In an effort to keep the project moving forward, I moved onto the next phase: visual prototyping.
Whenever I enter the Photoshopping phase without true inspiration (and generally, this happens more often than not), I account for some failed concepts. I call these "Visual Prototypes". If you ever find yourself not entirely sure of the visual direction your site needs to take, but need to stay on schedule without compromising your quality bar, push forward. It’ll click eventually, but the key is to not get stuck. Stay unstuck.
And, thus, a good 30 hours of time was spent in Photoshop between two completely different concepts. I completed neither, but each explored different visual motifs, navigation metaphors, and layout. I now boldly go where no designer likes to go. I present to you, the failed concepts.
Yes, they look nothing like the final design, but if you squint, you’ll see several elements that made it into the final design. The lesson here, if there is one, is that prototyping is not just for engineers; it’s for web designers, too. While visual prototyping doesn’t work seamlessly, your comps will likely look like crap, and you’ll have to throw most of the work away, it’ll help you figure out some key stuff that will be integral to the success of the final pass.
The "Aha!" Moment
As designers, we’re conditioned to pretend as if the design process adheres to a deterministic algorithm: gather requirements, create use cases, create wireframes, and so on. When we don’t, it makes the rest of the team uncomfortable because it introduces unpredictability into the schedule. But the reality of the matter is that if you’re looking to design something unique and excellent, it rarely follows some predictable path. You tend to collect data and iterate back and forth between all the phases I mention above, and at some point, the right nerves fire, the moons align, and you have that "Aha!" moment.
The "Aha!" moment on MIX Online came sometime toward the end of the Visual Prototyping phase. Like many fellow designers, I am on the long list of folks who often visit Veerle‘s blog not only because she’s an awesome designer, but also because she publishes some great content. I came across an art post she did on James White, a Canadian designer . The first piece on this post, titled "Commodore", just blew me away. It had all the elements of a strong visual identity fitting for a site like MIX Online.
Don’t fight the "Aha!" moment and don’t be ashamed of it. It’s natural. Embrace it, and communicate its existence to your team without being arsty-farsty about it. Just be straightforward. If they’re smart and value good design, they’ll accommodate for it. If not, well, you know what to do, right? It’s a win-win.
The Final Pass
Jumping back into color comps after the "Aha!" moment has taken place is a wonderful feeling because you can almost picture the whole site in your head. All the pieces finally fit together. In the case of MIX Online, the inspirational piece allowed me to quickly make some key decisions that you now see on the site:
- The Commodore branding has 5 unique and very saturated colors. Coincidentally, we’d decided by then that MIX Online would have 5 unique sections. I decided to pair each section to a dominant color: link colors, footer elements, logos, etc. would all change based on the current section of the site.
- The site would embrace sharp edges and a clean grid as these are both characteristics of the retro olden days of computing.
- I experimented with type and final settled on a combination of Georgia and Lucida Sans. While Lucida Sans is a pretty commonly used typeface on the Web today, Georgia seems to have become increasingly sparse. All the more reason to help Georgia’s wonderful curves make a comeback.
- The lab section would provide an aggregate view of all our bits, but each lab would get its own section. This was a pretty natural choice because each lab is different from the next and potentially has a different audience, different elements, and so on.
The 80/20 rule couldn’t have been truer than what it was on the MIX Online site design. In the final pass, I created approximately 8 comps. Each captured a core section of the site, and the whole pass took just a work week. Comparatively, we spend a good 4-5 weeks brainstorming, capturing requirements, prototyping, and analyzing the site design.
Slice, Dice, Toss and Turn
Sign-off was pretty easy because pretty much everyone knew what was going on through the process. There’s a fine balance to be drawn between showing too little and showing too much through the process, but if you can get away with it, err on the side of too little. This is clearly just a preference of mine and I’ll spare you the reasoning. If you don’t have that sort of freedom, your ability to communicate clear timelines and status can go a long way in buying you that freedom. In any case, you should always spend a reasonable amount of time communicating the status of your progress and setting reasonable expectations for delivery.
There are loads of services out there that take your PSDs and promise to turn them into standards-based, semantic markup for very reasonable rates. Essentially, these are shops that employ front-end web developers – often in other countries – and project-manage the slicing and markup exercise from somewhere local. In theory, it’s a great idea, and if you browse around you’ll find that others with good credibility in web design such as Jonathan Snook, have written positively about it.
As much as you may not want to, you may need to farm out XHTML/CSS development due to scarcity of development resources. After reading others’ experiences with slicing services, and peering through sample code on several of the services’ sites, we decided to go with a different service. While our experience was not as excellent as Jon’s, we did get the whole site marked up in a week. And, it validated. But was the code semantic? Not really. It’s beyond the scope of this article to cover that, but watch out for an opinion on the topic in our Opinions section.
So, there we were, stuck with markup that validated but often made us cringe. What now?
The Platform Saves the Day
We did what good corporate citizens do: we shipped. We decided to clean it up as much as we could, and shipped it, fully knowing that we were going to refactor most of it in the future. Fortunately, our shiny new platform – built on the same codebase as Oxite – allowed for swapping out views without affecting anything else on the site. Oxite is built on a framework called ASP.NET MVC that was released by Microsoft to help web professionals build standards-based sites, something its parent technology, ASP.NET, always had trouble with. The framework is built on a very popular design pattern – chances are that you’ve used it unknowingly – known as Model-View-Controller, or MVC for short. The pattern essentially provides a way to decouple the presentation layer from the data model and business logic of a software application.
The capabilities of your CMS are of utmost importance to you as a designer because it informs the requirements exercise early on. If you’re designing for WordPress, you will likely have different options available for you than if you are designing for Sharepoint. Of course, understanding the capabilities requires you to delve into some technical aspects of web design. You don’t need a Computer Science degree, but an understanding and empathy for programming can go a long way.
I know, I know. You hate me for saying this, but I am just the messenger. I suggest that if you’re affected by what I just said, bookmark this article, power down your computer, and go buy yourself a few pints of Stout. I promise it’ll make it better. When you’re done, go buy a book that inches you toward your dream of being an awesome web designer. This one will give you a rock-solid start. OK, I’ll get off my soapbox now.
3… 2… 1… 404!
The last few hours are always frantic – emails flying all over the place, assets being created on the fly, last-minute code fixes that cause regressions, managers doing drive-bys to get status updates, your significant other IM’ing you wondering when you’re going to be home and if you’re going to have time to drop by the vet’s to pick up food for the cats whom you can hear frantically meowing in the background. No matter what amount of planning you put into it, the pre-launch hours inevitably get chaotic. But don’t read that as, "Don’t plan. It doesn’t help anyway." On the contrary, plan it all. Get it on paper and get everyone to sign off on it. Even better, create and assign tasks in your bug database. If you don’t, it’s only going to be worse, and you may slip your launch date.
In no particular order, here are some suggestions on how to make the launch exercise as painless as possible:
- Clearly identify the launch owner. There can only be one, and that individual is the axle for the wheel of your launch unicycle. In times of crises, it is critical for one person to be at a vantage point that affords them the ability to "make the call".
- If you’re the owner, start capturing each and every detailed task that needs to be completed in order to launch. No task left behind should be your motto. Assign an owner and a due-date to each. Delegate. Communicate frequently.
- Deflect last-minute design requests like Teflon. A simple way to deflect is to turn it back to the requestor, "Would you block launch if that’s not in?" Only accept "yes" or "no" for an answer. Logic always prevails.
- Do frequent passes through the site. Expect things to break until the last minute.
- Keep a sense of humor about you. As one of my old bosses over at Amazon.com always used to say, "It’s just a site. It’s not like we’re curing cancer."
Honestly, there’s an entire article to be written around "Launch". You need to hit the finish line, and all the decisions you make should help you get there. This isn’t to say that you need to launch at any cost; I’ve been on teams that triage ridiculously important bugs to hit launch, and that’s just not how it’s done. Make the wise choice for both your customer and your company.
The Real Fun Begins
The day after launch is generally a busy day because you quickly switch to maintenance mode. Not to mention, all those feature requests that you punted before launch come racing back into your inbox. However, what’s more important is that your site is online. Customers – real customers – are hitting it! It’s daunting because all those things you fought for and protected during the design phase for the customer are now in front of that very customer. What if the customer doesn’t like the design? Time for a quick pop quiz –
Q: What counts as valid customer feedback?
- Someone at your company emails you and says, "I’m not sure that image is encouraging the audience to click."
- Your wife emails you and says, "I really don’t like that color."
- Your colleague drops by and says, "Nice site! But I have one issue with it – I absolutely hate the way I have to click this to do that."
- Your boss – despite signing off on it earlier – says, "I think we need to do something about the placement of that text. I don’t think it works where it is."
- All of the above.
- None of the above.
If you picked (e), you win. You thought it was (f), didn’t you? Shame on you. It’s easy to forget that on the Web, the world is your user base. Some are more important to you than others, and you should absolutely factor that into making decisions around evolving a design. But accept the fact that everyone is a user, and all feedback is innocent until proven guilty. The sooner you accept that, the easier it’s going to be for you to design killer sites.
All I’m recommending is that you hear everyone out; you could justifiably ignore all the feedback, but don’t do it before you’ve assimilated it. Try to detach yourself from the need to think of it as criticism, and instead think of it as a clue that something may be broken. Once your site has launched, you’re an investigator – always searching for clues – trying to make your site reach its potential Zen (instead of trying to solve a mystery). If you’re a perceptive listener, users do all the heavy-lifting for you by giving you these clues. Combine those with site analytics tools and you’re bound to succeed.
In a Gist
"I saw the angel in the marble and carved until I set him free. - Michelangelo
My contention is that the web-design process – and more broadly, the software-design process – is barely understood. There are few who, through sheer creativity and experience, have found their own balance and rhythm in designing great web experiences. The wide majority, however, are still struggling to rationalize it and are still a ways from being able to standardize the process. But maybe that’s the very problem – one can’t follow a one-size-fits-all template when designing web and software experiences, because at some level it’s more art than science. Whether that’s true or not, one thing is for certain: there’s much to be discovered, and the journey has just begun.
- Jesse Bennett-Chamberlain‘s most-excellent write-up, Redesigning the Expression Engine Site, served both, as inspiration, and as validation for many of my own trials and tribulations around the web design process.
- The Anatomy of Web Design is an article I wrote a year after the publication of this article. It goes even deeper into the process focusing on IA, Content Strategy, and more.
- Tanya Merone’s bookmarks have saved the day time and again when I’m seeking some inspiration.
- Check out our very own blogging platform, Oxite.
- ASP.NET MVC is a framework that allows you to completely decouple presentation from business logic in web development.
- Windows Live Writer is how we publish posts on MIX Online. This article was published through Live Writer.
- Looking for this article in Belorussian? Patric Conrad was kind enough to provide a translation. Check it out.