Web design workflows in 2010?

April 21, 2010 12:40 PM

What does a web designer / web UX designer workflow look like in 2010?

I am a web developer who doesn't know anything about web design. I can make scalable, standards compliant websites, but I really don't know how to make them look professional. I can either learn to design myself or ask a friend who has a previous art background but no web design experience to help.

In either case, I need to know how a web designer does their work. What underlying theory is there? What programs are used and in what order? What hardware is necessary to do a nice job? From start to finish, if a web designer gets a project, what steps happen in order to bring it to completion?

I would ideally like as many specifics as possible. If you are a web designer, what do you do? Do you start with mockups on paper or in a particular program? Do you work primarily in a vector graphics program like Illustrator, in something like Photoshop, or in tools created for web design like Dreamweaver? What does the process look like, and where do you spend most of your time? Do you have a library of effects or templates that you've developed over time for particular purposes? If you work regularly with web designers, what have you seen them do?

Any insight into the modern workflow of designers on the web would be much appreciated!

posted by pbh to Computers & Internet (12 answers total)

In either case, I need to know how a web designer does their work. What underlying theory is there? What programs are used and in what order? What hardware is necessary to do a nice job? From start to finish, if a web designer gets a project, what steps happen in order to bring it to completion?

For the best web designers I know:

• Art school
• Inkscape
• A text editor (kate, vim, gedit)
• Anything (MacBook, an old Dell, a MacBook Pro)

For many sites, they create full-site mockups in Inkscape. Then they'll write the pages from scratch in XHTML/CSS, and create image sprites from the mockups, keeping track of positioning to make page elements. Most use templates but these tend to be more for basic positioning and resetting browser CSS than for any styling; writing the style itself is a per-site task.
posted by tmcw at 1:05 PM on April 21, 2010 [1 favorite]

My workflow has changed a lot over the years, and it is stripped down now to the point where I can make designs much easier, faster, and better.

- Collect functional and non-functional requirements, and a list of 5-10 websites that the client enjoys the aesthetics/design of, to get a rough idea of what the site will look like.
- Build a very rough wireframe on paper (although recently I've become a fan of Balsamiq.)
- Mark up a sample page of content of content using Notepad++, without considering what the design is going to look like. Headers with H1/H2/H3, lists with UL/OL, etc. There is maybe one or two DIV elements max, if any. No <div id="header"> or non-semantic like that.
- Add in my basic CSS reset and typography/element styling package (based off of Tripoli.
- Open up the site in Firefox and edit the CSS in-browser with the Web Developer Toolbar and Firebug so that all the content is in the same place it is in the wireframe, copying/pasting to N++ to save whenever it looks good.
- After everything is positioned where it should be, I start working on the CSS to make it look good/shiny/etc.

At no point in my process do I use Illustrator/Photoshop/Dreamweaver/Fireworks/etc anymore. I used to do my mockup in PS, recreate it in dreamweaver, blah blah blah... but it just slows me down at this point. Build it, interact with it, see it live, refine, refine, refine.
posted by Jairus at 1:11 PM on April 21, 2010 [12 favorites]

I worked for years (& years, & years) as a digital producer/project manager overseeing both designers and developers at a very large ad agency doing websites for very large corporations. I'm happily self-employed these days and continue to believe that form follows function but...

Back when I did manage teams, the designers usually started with sketches/wireframes, informed by the usability guys...

From there, or sometimes concurrently, they might do color exploration, font who-ha, etc. etc. Then on to Photoshop for comps to be approved by the client before being handed off to the programming team. As tmcw notes, sometimes full site mock-ups were created before a line of code was even considered.

I now design and build sites on my own, and I will admit I'm not the most creative bloke on the block. I have however been using Artisteer software for about 10 months and absolutely love it.. I can create adequately attractive site designs in a few hours and the software will export a single page with the thousands of lines of CSS. I'm super-productive with it and have been making a decent living since I started.
posted by bricksNmortar at 1:18 PM on April 21, 2010

Jairus, how complex do your web sites get? I've been using Closure and when you get to the point of using a lot of Javascript you begin to template the HTML and CSS. Everything becomes Javascript generated and sort of becomes a mindfuck.

For example, it is relatively easy to mockup GMail's front page, but if you wanted to mock some of the functionality (create new mail, move to next page) it becomes very time consuming, very quickly. I cannot imagine someone who does know Javascript well would be even able to begin touching the design, which could explain why a lot of the heavy Javascript applications tend to be so austere (no designer, just the engineer!).
posted by geoff. at 1:19 PM on April 21, 2010

geoff, the sites get pretty complex -- this is the workflow I've used when designing employment agencies, statistical clearinghouses, governmental agencies, and so on. There's a lot of back end stuff I'm leaving out as far as site functionality and logic goes, this is just for the presentation layer.

I use a lot of jQuery (especially for progressive enhancement), but not usually during the initial prototyping. Once I start building the site (and, say, developing actual menus), that's where I call it in.
posted by Jairus at 1:25 PM on April 21, 2010

Lots of UX designers start with a vector program (often OmniGraffle, Fireworks, Visio) to do a series of wireframes, which are kind of like blueprints. They just show where things are on the page without any design elements or colors, just black and white. The purpose of doing this is to speed up iterations, which is crucial when you have a lot of stakeholders who change their minds a lot. If you tried to do that in Photoshop, it would take forever. One the wireframes have been approved by everyone, you move on to doing visual design in Photoshop, creating full color mockups as close to the final page as possible. This involves finding good typography and photos; and either finding or creating your own illustrations, icons, textures and other design elements.

After that has been approved, the design gets sliced into HTML/CSS and you probably know how that goes. There are lots of slicing companies out there who do excellent work for cheap, which is great because it fills a huge gap. Most programmers don't care enough about the design to fight with browsers, so designers end up doing it, and that's a poor use of a designer's time.

But in the end, good design isn't about workflow or which tools you use. Those things can make you efficient and productive, but they can't make you into a good designer.
posted by AlsoMike at 1:34 PM on April 21, 2010 [2 favorites]

I've worked with a few hundred web designers, and I used to be a UX person myself, and this one thing has always been true: the best screen and UI designers all work with paper and pen. Only once they know what they're actually making do they sit down at the computer.

(And for that matter, at that point, it can usually be handed off to a "graphics person" anyway (sometimes called a "graphics technician") who can follow the sketch-recipe and make something lovely.)
posted by rokusan at 3:37 PM on April 21, 2010

Response by poster: This discussion has been great so far, though I'm still quite confused by the transition from wireframe to final graphical elements. AlsoMike's link gives me a really good idea of how things look at the wireframe stage, and I'm fairly comfortable with the idea of slicing a final design into HTML+CSS (though I understand there may be many annoyances in the slicing process). But I'm still confused by how the transition to the final visual design in Photoshop or Inkscape happens (and do people really use Inkscape rather than Illustrator?).

What does rokusan's "graphics technician" do? Do they use a tablet to draw freehand, are they drawing with a mouse, scanning drawings, or are they just merging various design elements in Photoshop? Is the color mockup of the final page a standard size? Are there Photoshop or Inkscape methods specific to web design, rather than sort of general photo transformation techniques?
posted by pbh at 6:38 PM on April 21, 2010

the transition from wireframe to final graphical elements.

The important thing to understand is that these are almost completely separate tasks. It's really mostly a quirk of history that they tend to be accomplished by the same person.

The wireframe, and most of the dirty UX work, is for getting the necessary features screen widgets in the correct order, logically grouped and roughly positioned.

The graphic elements, the colors and icons and photoshop work is a matter of taking that UX structure and making it aesthetically appealing. (This is aesthetics, so the "correct" workflow gets a lot fuzzier than for code -- freehand tablet work may be the way to go if you're aiming for that particular style; or collaged photographs or pixel-level drawing in Photoshop, or pen-and-ink and a scanner or whatever. Yes, there are "Photoshop or Inkscape methods specific to web design" just as there are vi methods specific to writing C++: which is to say, whatever works.)

It's important that the person doing the look and feel understands what was going on with the UX decisions and doesn't work at cross purposes to it -- if buttons x y and z are logically grouped together, the look-and-feel designer should reinforce that grouping by putting a border around them, or using similar colors, or whatever other graphical technique is appropriate to the look and feel.

But nothing in the UX stage determines which aesthetic technique the look-and-feel designer must use to reinforce that grouping. You could take the same wireframe and come up with a hundred different designs from it, all equally good (as long as they're appropriate to the type of site you're designing.) A bad look and feel can spoil a good UX design, or a good one can reinforce it, but that's about all they have in common.

(It may be tempting to read this as me downgrading the importance of look-and-feel design. Nothing could be further from the truth -- good look-and-feel is just as crucial as good UX design.)


Anywy, that said, here's my workflow. (Note that I'm a consultant in a fairly specific niche; nearly all of my work is in redesigning existing web applications with relatively complex feature sets -- generally there's a lot more UX work to be done than look-and-feel work. (Though often the client doesn't realize this before they hire me; frequently people think they just need new buttons and icons and can call it a day, and I have to convince them that their icons are the least of their problems.)

Step 1: map out the existing application's feature set and page flow by stepping through every page and writing down everything that happens on each one. This usually ends up as a grid of index cards or full sheets of paper laid out across the floor of my office. For sites with particularly bad UX, where it becomes clear that the existing page flow is pretty much a do-over, it can instead end up as just a bullet list of features. I've tried using flowcharting software, omnigraffle and the like, but it always seems to end up taking more time and effort than paper and pencil.

Step 2: remap that flow as needed. Lots of careful rearranging of index cards, sometimes merging several into one, sometimes splitting one into several, and always trying to keep the dog and child and breezes from open windows from making too much of a mess of them.

Step 3: Put the newly structured stack of index cards into a pretty document I can sell to the client -- nobody wants to look at a stack of scribbly index cards. This is the only document I tend to provide, and I try to keep it as simple as possible. Clients hate reading documents, and rarely give you useful feedback on them. They love clicking through prototypes, and give you tons of useful feedback. Lately for this I've been using Pages, because it makes pretty documents, which I export to PDF, because nobody can read Pages documents.

Step 4: For every non-trivial feature in the application, do a widget-level UX design -- figure out exactly what buttons and menus and explanatory text and etc best get the user from the beginning of the feature to the end. This step has gotten both a lot harder and a lot more interesting now that we have jQuery and AJAX -- a site page isn't necessarily just a page full of form elements anymore, it can involve a lot of complex interaction and popups and spotlights and in-page updates and what have you. For the simplest cases this can be a screenshot-like photoshop file, but most of the time I end up building a lightly styled html page with a lot of throwaway javascript to demonstrate the various interaction cases and to simulate any serverside calls.


Step A: (Generally best done after step 2, but can really be done in parallel with any of the above -- often when I'm too burned out on left-brain UX work I'll skip to this, and vv.) Start sketching out look-and-feel ideas for the overall site chrome, not worrying too much about individual page-level widgets. Some clients want a total departure from their existing design, others want just refinement and iteration. Depending on the job, this may start as pencil sketches, or as screenshots of the existing site that I start fiddling with in photoshop, or as de novo photoshop files, or as photographs or oil paintings or whatever. I always do at least three distinct designs, often more, which gets delivered to the client as a collection of PSD files with big [CONTENT HERE] labels over the otherwise empty page body. The client inevitably chooses the ugliest one, which I then try to salvage by recovering any good ideas from the other designs that still fit into that one.

Step B: (Best done after step 4 is complete for a substantial number of features, but depending on the job can happen pretty much at any time, even before step A) Start doing look-and feel designs for the page-level content and widgets. A lot of pages will end up having similar widgets from one page to the next, so after I've discovered a decent number of them I can start thinking about what they'll look like. For this I usually go back to plain PSD files, which are quick to edit-- but sometimes doing it in html is quicker; really depends on the feature in question. Once the client approves a general concept I'll start building them into the HTML mockup as CSS and sliced images. If I was reasonably smart about building the mockups, it will already have consistent class names this css will flesh out the whole design without too much work.

At the end of steps 1-4, ideally, I have a completely fake version of the website built out in HTML and JS. (In real life there's rarely enough time to do this for every single feature, but I try to hit the hard ones first so the client's developers can extrapolate from there and deal with the rest.) Often (but not always) parts of this throwaway javascript get iterated on and generalized as I continue to flesh out the mockup, to the point that much of it finds its way into the final site release.

And at the end of step B I know what it should look like.

1...4 and A..B tend to be done in parallel, but don't need to be; at least the broad strokes of either could be done completely independently of the other.
posted by ook at 8:17 PM on April 21, 2010 [5 favorites]

What does rokusan's "graphics technician" do?

In the studios I've worked in-for-and-with, and hired to fill, this type of person takes sketches (usually paper, sometimes digital wireframes), notes on color, and written requirements, and draws/models/paints elements called for, then assembles a mockup to review with the designer who did the sketch/colors, and probably the PM/project-owner who set the requirements. The mockups and final revised work is usually done in Photoshop, but in the last few years it's been a rising mix of Illustrator (first step) and Photoshop (second step). It's easier to handle objects/layers and scalable pieces in Illustrator, and if the project contains Flash or other vector components it's almost necessary. Photoshop (or any bitmap editor) on the other hand, is the way to get pixel-precise.

(You already know all about slicing things up and making tight and valid HTML/CSS/JS/whatever, I think, so I'm ignoring that step.)

I used the term "graphics technician" (and have heard others use it) to remove the "creative/artistic" aspect of the job, since that isn't really a part of that work and often confuses people. The creation (or "ideation" as some of the more clove-scented people like to call it) has already happened, and this person's innovation comes in how cleverly/concisely they can deliver the pieces necessary to fit the plan.

Is the color mockup of the final page a standard size?

The size(s), or at least the max width in pixels, is probably a part of the original specifications, on the same list as "Flash allowed or not?", "Max page size in kilobytes?", "iPhone layout how?" and "Which browsers must be supported?" It varies by project, but you're right to think about those things first, anyway. Too often, not pre-deciding those things leads to a very pretty and completely impractical product.

Are there Photoshop or Inkscape methods specific to web design, rather than sort of general photo transformation techniques?

Yes, because it's more about drawing objects and arranging shapes and layers, and as sites get more complex (and scaling begins to matter), the object-oriented Illustrator approach is getting more useful than making everything in bits. Photo-manipulation techniques (adjust curves, touching up flaws) are, well, almost specific to photos. There's some overlap, but even in my hacky personal noodling about, I notice there's a whole set of Photoshop commands and techniques used in touching up photos that I never use in making graphics for the web or applications... and vice versa.

I've never seen Inkscape (or for that matter GIMP) used in a pro shop, but it doesn't really matter (substitute 'drawing program' and 'painting program' for Photoshop and Illustrator as you see fit.) Specific tools don't matter that much, anyway: use what you know best.
posted by rokusan at 9:44 AM on April 22, 2010

Response by poster: I don't think I'm going to mark a best answer or anything because all of the answers are so good and so different (though ook's was particularly good, jairus' was particularly different, and thanks for following up rokusan).

If anyone has any suggestions for learning more, in the form of sites or videos or other material, I'd quite appreciate it, but otherwise, thanks for all the help!
posted by pbh at 12:37 PM on April 22, 2010

(to be clear, Inkscape has a smaller following than Illustrator but a very seriously dedicated and talented one. In a web shop, it's actually quite a serious tool - three designers check in designs to SVN or Git as SVG and can thus manage their work, and in some cases collaborate with git merging. Illustrator also has its strengths - speed when dealing with complex shading and many elements)
posted by tmcw at 6:18 PM on May 10, 2010 [1 favorite]