A realistic chat about design process

April 18, 2006 | 5 Comments

There has been all sorts of talk about the role and process of design in various Web design communities of late. in that there’s been lots of differing opinion. Some feel you don’t need any sort of exploratory phases or documentation and that jumping straight to some sort of real deliverable is best. Others feel Information Architecture is a bit redundant as a practice. Still others doubt the value of design all together. I could go on…

I’ve held back from formulating a strong opinion on any of this. I can see pros and cons to almost everything I’ve been hearing as it relates to design process. (Those folks who doubt the value of design altogether are off their rocker.) As someone who has worked within many different processes, from the very, very rigid (Microsoft and Boeing) to the more freewheeling (Blue Flavor) and those in-between (Children’s and PBDH) I think I’ve seen quite a lot.

I’ve also been in the position to change that process numerous times. That’s neither fun nor easy.

Through all of this the one thing I’ve learned beyond a shadow of a doubt is that no design process is perfect. I also think it’s safe to say that your design process need to be able to adapt to the particular project you’re working on.

There is no “one size fits all” design process. It can (and probably should) vary greatly depending on the work style of the designer, the needs of the stakeholders, the budget, ect. Again, I could go on…

In theory I tend to lean towards the process with less overhead. Keep it simple, present “usable” deliverables as early on as you can, iterate often and make small course corrections as you go.

Having said that, I don’t jump straight into HTML. I usually start on paper and usually do quite a bit of exploratory work on my own. This is something I bill our clients for, yet they hardly ever see it. That might seem strange to some, but it’s something I use to get my creative juices flowing. I also like to do quite a bit of discovery with my clients to make sure I understand their problems really well. This often involves documentation of some kind. I know…blasphemy!

All of this works very well with my own working style. It’s really too bad I’ve usually got to work with others…

;0)

At Blue Flavor we try for a very collaborative design process. This means that we need to be very flexible with our clients. Nick and I are usually the players from our team working on the design. He’s much more, let’s say, “documentation”, oriented than I am. However, this often plays to our advantage. One problem with “getting real” to quickly is that when you’ve got to go back, you’ve got more rework to do.

By using documentation you can often get buy off on a direction early, thus saving you rework down the road.

But it’s a balance right? When we’ve got clients with tight budgets, for example, we need to lose some of that documentation and explorative design. Basically they have to trust us to come up with a good solution as we don’t have the budget to get buy off via documentation. As well, certain types of documentation—wireframes come to mind—often present their own problems.

This can be awkward for me as I like to go into the design process full understanding the problem and I like to spend time exploring various solutions. If the budget won’t allow for that, I need to change my process. Be flexible and all that. It’s not ideal for me, but I try and make it work.

The goal of any design process should be to get to the best possible design or solution. (I don’t believe in a perfect solution.) How you get to that design could very well vary from project to project. I try to find patterns that seem to work and stick to those when I feel it’s appropriate. I never go into a project thinking that I absolutely will or absolutely wont do something. I let the project tell me what I need to do.

Since starting Blue Flavor I’ve had a bit of a different design process for every project I’ve worked on. I’m happy (as I can be, when you’re dealing with clients things tend to come out a bit different on the opposite side no matter what you do) with every design we’ve done so far, and our clients are too. (Hopefully we’ll have some stuff for y’all to look at soonish!) I wish I could sit here and tell you how it was done, but I’d have to tell a different story with each project.

I think that’s as it should be.

Filed under: Web Design
Keyword Tags: web+design design+process

Comments

1. Jeff Parker said:

Maybe you can tell us some of your methods of coming up with or wireframing a website. I understand the getting the needs of the customer way before you start writing html. To me thats a no brainer. But how do you actually work to come up with a design you like for a client?

Me I do this in photoshop. I might create something 800 X 600 and then just start from there adding layers, this allows me to turn on and off layers to see different colors and fonts and backgrounds and borders and basically do a lot of things like that. I basically start with a sketch in photoshop as well before I even write a line of html.

Posted on April 18, 2006 11:27 AM | #

2. Keith said:

Jeff – Wireframes have always been a problem. We’ve done traditional wireframes (like you see done in Visio or Omnigraffle) and those can work ok. I’ve even done the same thing in pencil, which actually works well.

Since our UX/IA guy Nick usually does this, I tend to spend lots of time talking with him and rely on him to make sure I’m capturing everything correctly in the design. He does often create a pretty extensive blueprint that we’ll refer back to when needed, but we’ve also been pushing him toward functional prototypes.

These seem to work well for various reasons (in no particular order):

#1 – We can usually reuse the code
#2 – They provide the client a working model
#3 – They are easy to modify and create
#4 – They work just as well as an Omnigraffle file for documenting content areas, navigation, etc.
#5 – They can show things such as state which can be hard to capture in a “flatter” format

Posted on April 18, 2006 11:42 AM | #

3. Iamzozo said:

I aggree with it. I think its a good question, and a good article about which is the best practice to complete a design process. For me, it means: functionality doc, a paper prototype (only for main page, for the first impression), then make the grid, photoshop layouts follow the grid. But I build only the main page and some of the subpages and parts which means the all elements what the site included (buttons, icons, titles). The last step is to build the html page, i think this is one of the main part in the design proccess. It’s not only build up the layout, here i make the “design” which functional. It could be years if i make all stages of any parts of the site, like “if you roll over a button you will see this and if you…”. Html show how things will appear in a browser or another, how javascript works to show a block. I read an article, where somebody wrote that the functional specification is the blueprint of the site. Maybe, but i think it isnt the right way to build a website for a client. Photoshop could make the grid, the layout, effects, but couldnt show the whole functionality of the site. We did some sites and the problem alway come back, that plan what we do it in blueprints it isnt work in browser or not works properly. Get back to the begin, change the plane , change html… I still have not found the best proccess…

Posted on April 21, 2006 01:21 AM | #