Articles

Web Design from the Gut

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

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?

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.

Finding Inspiration

"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.

Visual Prototypes

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 [2]. 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 frequently encounter web designers who take pride in not having to think about the "technical" aspects of site development, and avoid anything remotely related to programming like the plague. They create comps and leave it at that. If I may offer my two cents, I believe that attitude is on path to extinction, and those web designers will have to revert back to graphic design eventually. If that’s your thing, then cool; there are great careers to be made out of pure graphic design. But if you’re serious about building a career designing for the Web, it’s time to start sifting through the technical shelves at the bookstore, and biting on a topic or two. If you look across the board, the best web designers out there are very technical. Take Shaun Inman, for instance. Not only does he have a fantastic grasp of graphic design, but he can also take XHTML, CSS, PHP and JavaScript for a good spin.

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.

@Jake - Funny how those things work out. I used to look at that and go, "Man, I''d like to do something to that navbar." Now it''s barely noticeable to me.

As for wire frames, it''s Visio 2007 and I used the resident shape libraries; I believe I also used some combination of "stencils by Nick Finck, Garrett Dimon, and Jesse James Garret":http://nickfinck.com/stencils/. I have found myself using Fireworks (yes, Fireworks) for wire frames lately because of its "frames" feature (let''s me capture states). Not to mention, I''ve found the drawing tools are just right for wire framing.

That was a really thorough overview of the process and is close to the process that I go through and similar to the process that I''ve seen others go through.

Personally, I skip the sketching process and do all my initial wireframing using a graphics editor. This lets me drop in blocks of actual content and get a sense for how each of the UI elements play off each other, as well as determining how I want to structure the design hierarchy. At this stage, I''ve already got a grid to play with and I can go on to the next stage of graphic design.

PS: it was a surprise to see my name linked up in the middle. Thanks for that. :) Hope to catch you at a conference soon.

Craig P. said on Dec 9, 2008

Nice! Excellent explanation of the process/struggle that we web designers go through to come up with good work.
Also thanks for pointing out Tanya Merone. I have a feeling I''ll be frequenting her site from now on for inspiration, too!

Nishant -
Great article and presentation at World of Web Design Boston. I thought it was one of the better ones at the conference.

Considering the time constraints you were under when you developed the throwaway prototypes, I was wondering if you would be willing to make the PSD files public. I''m interested to see the structure and detail of the layers and accompanying styles of both the prototypes and resulting comps. Hopefully this can my own design process.

By the way, any extra Website Named Desire posters leftover at the Mix office?

Great Article here, starting with a paper is must for any sustainable design. I am going to send this article to some of my print-design mates who says that webdesign is just about phtoshop and some lines of code.

By the way, two thumbs up for the MIX Site and i just loved the Oxite page.

@snookca - The sketching part is something I''ve started lately. It''s more about capturing random thoughts and ideas than sketching wire frames with a pen; but if I feel inspired, that''s OK, too. My mind drifts at a crazy pace and picking up a pen and paper seems to help slow it down. I shall be there at SxSW, and possibly WDN. You going to either?

@Craig - If you find a better list of links, let me know.

@Nat - Are you interested in the PSD''s for the prototypes or the final comps? I''m sure I can clean them up and share them. As for the posters, we have a boatload. Email me your address - I can''t promise that I can get them to you right away, but I''ll put you on the list. Be sure you subscribe to the "twitter":http://www.twitter.com/sitenameddesire/ feed. That''s where we post giveaway announcements.

@Nitin - Thanks :)

@Dan - Thanks, dude. FYI - I mentioned you guys (Adaptive Path) in my talk at Web Design World (Boston) last week. I owe my love for Moleskin notebooks to Adaptive Path; you folks handed every UX Week attendee one of those last year.

Very nice article, Nishant. Many people have a very difficult time putting down into words the process by which they ''create'' or ''do'' anything. Processes evolve, sometimes naturally, but nearly always as the result of outside influences that push and pull on them over the course of their evolutionary phase. To give structure to the final result takes talent and a very good understanding of what it is you do.

You''ve done an outstanding job of laying out a framework that any current or budding web designer can use to hone their craft. I, for one, look forward to reading more of what you write.

@Jim - Here''s what I think is interesting - before this article, I always found myself stumbling to explain why I was doing what I was doing, or why it was going to take as long as it was going to take to stakeholders on a project. Thinking in meta about this process and writing it down really even helped me understand why the heck I do what I do. I''ve always been a bit hard on myself and externally apologetic/defensive about asking for time to "get inspired". That''s a thing of the past since I wrote this article: I finally understand why it''s nothing to be apologetic about. On the contrary, it''s necessary and justifiable. I''m glad I was able to share my revelation, though. And thanks for the compliments. Way too kind. :)

@Nat and others interested in the PSDs - I''m currently working hard on our next release around data visualization, but it''s on my radar. I want to make sure I do the necessary clean-up before releasing them and will get to it next month. Hope that''s cool.

Greg Chingwe said on Dec 27, 2008

Nishant,

Awesome advise. I am planning to get serious with my web development. In the last 9 years I have primarily focused on databases but I want to branch off. Your advise is great. I like your idea of brainstorming. I am planning to develop my sites in .net using c#. Any advise on this? Thanks.

Very nice article, though I have to say that the "brown + white" combination makes it very hard to read in one go (I had to squint to reach the end of the article, and I now have a headache). Kind of tells you that the content was very interesting, but the format killed half of the benefits.

Might I suggest testing a few other colours, for the text or for the background? The green you have in the "opinions" section, for example, makes for a much more pleasant read. Perhaps a slightly different shade of brown and white will make it easier.

@Peter - Yeah, the brown has reaped some mixed reactions and I''m convinced its time to go with something a bit more saturated. The brown in the comments section, for instance, is much better, I think. We''re planning a release around mid-Jan, so I''m hoping I can push some tweaks then. Maybe I''ll squeeze something in next week when I''m back. Thanks for the feedback and for muscling through the content despite the color issues.

This is the best article I''ve read in a long time. It''s funny how every once and a while you need to take a step back from what you are doing and evaluate how things are done. I work for a software company looking after some divisional sites, not allowing me the most creative freedom but I have just been asked to develop a brand new site based on something completely different. It''s been a while...

WALSAQ makes it easy to find what every business owner needs: High-quality Ecommerce Design services at the most competitive price. Having a ecommerce website designed doesn''t have to be hard or expensive to accomplish, and WALSAQ proves it time and again, which is why WALSAQ is called the Next Generation of Freelance Services.

The design is good 7/10 I would say . A dark background comes hard on eyes though. The ''aha'' moment was really good and the preparation was awesome but the translation from the ''aha'' moment to the final design left something to be desired.

Quite a timely article for me, as we''re just trying to nail down some process here. Generally really well put but I''m surprised you make no mention of bringing in any kind of IA or UX consultation at any stage of your process?

Prototyping is great in theory but only if you''re testing them against something tangible - did you set some goals? I think your prototypes were actual more visual iterations (eg designing backwards until you are happy with results)

Great to know that I''m working in the right way, and I''m a developer! I tend to do most of these things already. Can''t promote the use of getting ideas out of your head and onto paper and more than this. It''s a fabulous jumping off point. Plus in 10 minutes you can do maybe 5-8 ideas!

This is a great walkthrough. I used to skip the wireframing step, but I tried wireframing with one of my current clients and it turned out to be a really good and important step. It gave them the idea of how the site will navigate, and they wanted a couple of changes that would have been hell if I didn''t wireframe the site first.

Thanks for sharing Nishant. Well-written. Captures the meaty stuff well. The re-design turned out well too. I recently re-designed my own design studio website - did not capture the process along the way - but I''m sure if I went back to it, I would not be able to write in such detail - mine was a more amorphous process - lots of back and forth, lots of iterations and finally the 80/20 principle - I did not wait for perfection to arrive. I simply launched. Feedback came from friends in the design space, students wanting to be designers, family, from people who have NOTHING to do with design. I implemented most suggestions and realized that they DID make the design better - in terms of intuitiveness.

@Alex - I actually allude to IA in several parts of the article (requirements gathering, feature wireframes, layout during comps, etc.) The IA for this project was spread out over the span of the project, so it''s not as obvious. We didn''t follow the typical process where IA is it''s own front-loaded phase to lock layout of information. We didn''t need to do this because (a) we were our own client (b) requirements were evolving because this was as v1 as was our team (c) we had a designer (me) who can do both visual and interaction design. (d) I just wanted to try a new way to get from point A to B.

The point I''m making is that this article is about an alternate process that blends certain aspects of the typical process together and offers some advantages over its rigidity. When you have a small team and a client that "gets" it, you can allow yourself some flexibility.

About user involvement, I think you''re asking - did stakeholders and potential users have a chance to review different aspects of the design? Yes - at multiple points in the project (after feature wireframes and we also had a couple of review passes after the comps wherein IA changed a bit). It was a pretty simple exercise since this is a pretty straightforward site; feedback came during the review sessions and also followed in email. Having said that, the real user feedback comes in after the launch; right now I have some very good and actionable feedback since the site has ben out there for around 6 months; both in terms of visuals and interaction and we are scoping a plan to to do a site refresh in the near future that hopefully addresses all the issues (like the one @Rajesh points out above) and also evolves the site to meet some of our new business needs.

Don''t get me wrong, there''s still tremendous value to the classic IA phase in web design. Aside from the widely documented benefits like focusing on content/information layout without getting distracted by visuals, the thing that a traditional wireframing phase offers you is the ability to herd a large number of stakeholders and that''s an amazing tool for a web professional. I''m currently leading the redesign of a project that has around 30 stakeholders and I''d be nuts to run it the same way I ran the MIX Online project. It''s just not feasible. The last 3 weeks have been all about locking the information architecture of the site through three rounds of feedback of wireframes created in "Omnigraffle":http://www.omnigroup.com/applications/OmniGraffle/. I managed to find a way to create a very transparent feedback loop that gives everyone a chance to chime in (sounds crazy, but it works really well and I will probably write about it at some point). Fortunately, I have the help of another phenomenal information architect (who shall remain unnamed for now) on that project.

But yes, I didn''t do such a great job talking about all these points in this article. I had to watch word-count, and figured I''d share the more unique stuff. I spend more time talking about topics like how to build trust within the stakeholder group, how to solicit requirements and feedback, etc. when I present on the same topic (I''ve delivered a presentation version of this talk at Web Design World, CRE8 and MIX).

And yes, the prototyping was purely a visual exercise. I experimented with a few different layouts, but that was a byproduct of what I was trying to get out of that phase.

Hope that provides some more context. Thanks for calling it out; gave me an opportunity to set the record straight about my opinion around IA/UX :-)

I love this article so much! Whenever I read an article about web design that starts by talking about content and the aims of the site long before reaching for PhotoChop, er sorry... PhotoShop I know it''s going to be good! And then you sealed the deal your ''Feature Wireframes''.
All-in-all what an intelligent and effective way to design presented in a well-written and highly valuable article - top points all round! Right... now to have a nosy round the rest of your site!

Hi!
Don''t know if anybody have said this but, despite I think this is a Really GREAT article (and I''m really thankful), I couldn''t read it all just because one thing: white letters over a dark background produces vibrant texts, and it becomes more and more uncomfortable as long as I read, so I had to take my sight off the text. That worries me because this site is intended for readers, doesn''t it? :( That''s quite sad because the design made me feel so free and comfortable, a really good (and needed) sensation on internet.

Best wishes for you all!!!
BTW, sorry if my English is not quite good, I''m a Spanish native speaker.

@Jedilady - Yes, this has been called out before. I''d have to say it is the most popular constructive user feedback provided about the design in the last few months, and it''s spot on. The color scheme is not conducive to readability; we gave it a shot, and lesson learned. Instead of doing a quick and dirty fix, however, I''m tabling this feedback for our next major refresh to the site. Glad to hear that the design makes you feel free and comfortable, though. That''s by design :)

I do appreciate you chiming in, and hope you''ll stick around to provide your feedback when the new design launches in the next few months.

This is a great article and really outlines the entire design process well. You also touched on a few points that I have previously been skipping, or quickly running over, during a lot of the work I do as a Chicago freelance web designer.

Well, I saw your article and after I got done reading it I had to comment on this. I am a professional web designer myself and I don''t give out my compliments much, but I wanted to tell you that your an excellent web designer and writer. This article kicks butt, plain and simple.

I used Fireworks myself for drawing wireframes since version 4 of the product it''s very powerful and easy to use. I find that it gives you the flexibility of drawing random shaps and seeing how they will fit together.

I personally sketch afterwards if I don''t get anywhere with fireworks, of if it will take me great amount of work.

I will switch back to fireworks though when I have a good idea to try.

I think you''ve got this one pretty much spot on, it''s never as simple and straight forward as you''d hope it to be! I look forward to reading more of your web design articles.

magic100 said on May 3, 2010

This is a great walkthrough. I used to skip the wireframing step, but I tried wireframing with one of my current clients and it turned out to be a really good and important step. http://www.yuregininsesi.com It gave them the idea of how the site will navigate, and they wanted a couple of changes that would have been hell if I didn’t wireframe the site first.
Great article!

I am pretty sure that is not a valid feedback, my wife knows little about web and websites :)
Loved the post

Snaldoy said on Jun 7, 2010

You’ve done an outstanding job of laying out a framework that any current or budding web designer can use to hone their craft. I, for one, look forward to reading more of what you write.
Snaldoy==>> http://www.thecookwares.com Your QA

That''s plenty of works to be done..but the end result is pretty impressive. That''s why I leave this to professionals and hire of bought it off from them. But overall, thanks for the interesting insight.

Great Article here, starting with a paper is must for any sustainable design. I am going to send this article to some of my print-design mates who says that webdesign is just about phtoshop and some lines of code.

By the way, two thumbs up for the MIX Site and i just loved the Oxite page.

Thanks again. I wanted to point out the follow-up article that covers our redesign as it may interest folks who found this article useful - "The Anatomy of Web Design":http://visitmix.com/Articles/The-Anatomy-of-Web-Design. I go into more depth about certain aspects of the process in this one and also point to specific follow-up articles on IA, visual design and copywriting.

Thanks again. I wanted to point out the follow-up article that covers our redesign as it may interest folks who found this article useful - "The Anatomy of Web Design":http://visitmix.com/Articles/The-Anatomy-of-Web-Design. I go into more depth about certain aspects of the process in this one and also point to specific follow-up articles on IA, visual design and copywriting.

I recently re-designed my own design studio website – did not capture the process along the way – but I’m sure if I went back to it, I would not be able to write in such detail – mine was a more amorphous process – lots of back and forth, lots of iterations and finally the 80/20 principle – I did not wait for perfection to arrive.