This is something I don't do often enough for sure. Some of this is laziness, but some of it is just budget constraint. But this is one of the most important parts of creating success; whether you're building a new product or working on a client project.
To me, I have recently started first with the basics of the product/project. I did not always do this, and as a visual designer first, this is very hard to do, or to at least force yourself to do. Before doing anything visual, begin to define what the hell this thing you're working on is. Whether it be a simple template (or set of templates) for a client, or if it's an actual shippable product, what is necessary and what is extra.
Once we begin to narrow down the necessry items, this allows us to think about the project as a whole from the onset. And once we add in visual elements, hopefully starting this way forces us to question why we're adding what we're adding. How will this work, is it plausabile to work this way, and is it really necessary to work this way?
Starting with an iterative mindset makes the project way more flexible too. Diving into the build and overall structure first doubles down on this, and can help designers have an overall sense of what markup to design for. It also can help with quickly implementing some design elements (either in the browser or from the designer) and allowing the clients to review this in their browser. This is something that is sorely missing from most (that I know) project work, and I would imagine can greatly help the client understand the process and grasp browser inconsistencies.
I think the last part would be hugely beneficial for most clients, as they are used to getting flat comps and then having issues understanding why IE8 and Vista renders the type differently than Photoshop on a Mac does. I've also always found viewing something and using something are two completely different things. Using something inherently brings up scenarios that you just don't get while designing/viewing that same thing.
And with more and more work going towards responsive, this will certainly help bring hard to plan/design for scenarios that come up with any project. What to do with content X, Y or Z and A, B, or C breakpoint? This way, we don't have to wait until the last few hours of a project to deal with it; we can engage the client for their point-of-view (from both a business- and content-user-perspective) and incorporate this while there is still time and budget to do so.
However, functional spec is something that might live outside of this, especially for client work. I say this because functional spec on a client project can increase the scope ten-fold in a blink. And I don't mean that it has to be absolutely rigid, of course not; but for the most part the overall objectives and how to make that happen should be fleshed out to a pretty good spot before getting going.
I can already hear other designers moaning about this, and perhaps they are to do so. But think about it, the thing that made instagram an overnight sensation was not how the buttons on the app looked, or how the 1px inset border was there or not. What made it so successful and fun to use is its speed and simplicity of what to do.
That's not to say that once you get the product/project to a certain point, that it's not appropriate to add in all the extra garnishes and meticulous detail that sets one product apart from another. There certainly is a point and need for this. Design is becoming exceedingly important to the web (at least to people not in the web business, it's always been important to us), and if done well, design can make or break a project or user interface. But, if focussed on (at least the visual part) too early, then the final prodcut can often suffer because of it.
There's always this possibility. I hope and don't think I am wrong in this case, and based on my experiences, I think this can produce great results, or at least help to get a project on the right path from the start.
Mused on February 11, 2013